How Superhuman's Security team made Rootly the central system for closing security incidents faster
Thijn Bukkems
Security incident response on a need-to-know basis.
Private incidents, granular RBAC, and a separate legal channel keep each investigation inside the right circle.
A similar workflow to an outage, in a more secure room.
A security incident follows the lifecycle engineering already knows. What changes is who is in it, what they can see, and where the record goes.
T+0:00
Detect
Detections from Splunk, Datadog, or any tool that sends a webhook open a Security Event incident, and a newly disclosed CVE is declared from a short form in Slack.
T+0:01
Declare privately
Private incidents are visible only to roles granted access and people added by name. Rootly can remove everyone else from the channel.
T+0:02
Staff by incident type
The incident type pulls in security on-call, legal, and communications, and leaves out everyone the investigation doesn’t need.
T+0:05
Split the conversation
Technical response and the legal and business discussion run in separate channels.
Throughout
Keep the record
Every action, decision, and access grant lands in the timeline and audit log as it happens.
After mitigation
Close and review
Retrospectives for incidents that meet your security criteria can be written to a restricted location instead of the shared default.
Wired into the security stack you already run.
Detections open a private Security Event, fixes go out as tickets with an owner, and your own AI agents work the record through Rootly’s MCP server.
Detection
Remediation and record
Identity and secrets
SplunkSIEM
DatadogMonitors and logs
AWS CloudWatchCloud alarms
WebhookEDR, MDR, CSPM, scanners
JiraRemediation tickets
ServiceNowTracked records
Google DocsInvestigation notes
ConfluenceRetrospectivesYour AI agents
ClaudeCursorCopilot
Rootly MCP server
Security EventPrivate · SEV 1
SSO and SCIMOkta, Entra
Directory SyncGoogle Workspace
VaultWorkflow secretsDetection
- Splunk SIEM
- Datadog Monitors and logs
- AWS CloudWatch Cloud alarms
- Webhook EDR, MDR, CSPM, scanners
Remediation and record
- Jira Remediation tickets
- ServiceNow Tracked records
- Google Docs Investigation notes
- Confluence Retrospectives
Identity and secrets
- SSO and SCIM Okta, Entra
- Directory Sync Google Workspace
- Vault Workflow secrets
Your AI agents, through Rootly’s MCP server
Claude, Cursor, Copilot, and any other MCP-compatible client.
- Reads the record
- Rootly’s MCP server lets the agents you already run read the incident record alongside everything else they know about your systems.
- Scoped access
- It restricts which API paths are exposed, so an agent’s reach into a security incident is limited to what it needs.
- Follows through
- Agents draft post-incident reviews, schedule review meetings, and turn what was agreed into tickets with owners.
- Open source
- Apache 2.0, and it works with Claude, Cursor, Copilot, and any other MCP-compatible client.
“The Rootly MCP server bridges the gap between what Rootly knows about an incident and the context our own AI already has.”
Thijn BukkemsSecurity Tech Lead, SuperhumanBuilt for need-to-know.
Private incidents, custom RBAC, SCIM, and audit logs, set once for every security incident on Rootly Enterprise.
01 Permissions
RBAC built for the complexity of enterprise security.
Who sees an investigation and what they can change is set by role, team, service, component, severity, and incident type. Access is granted just in time when an incident fires and revoked when it closes, and the same permissions extend to connected docs.
Incident field and action permissions
Set the general incident permissions this permission set has.
Permission to set incident status values
Whether status can be set when creating an incident, or based on its severity.
Permission to set incident severity values
Whether severity can be set when creating an incident, or based on its current severity.
Permission to set severity to SEV 0 when…
Creating an incident
New incident form
Updating an incident where severity is…
SEV 0 SEV 1 SEV 2 SEV 3 SEV 4
Permission to set severity to SEV 1 when…
Creating an incident
New incident form
Updating an incident where severity is…
SEV 0 SEV 1 SEV 2 SEV 3 SEV 4
Permission to set severity to SEV 2 when…
Creating an incident
New incident form
Updating an incident where severity is…
SEV 0 SEV 1 SEV 2 SEV 3 SEV 4
02 Separation
Engineering and legal, in separate rooms.
A security incident can run across two parallel Slack channels, one for technical response and one for legal and business. Updates flow one way, and sensitive discussion never crosses over. For full separation, Rootly supports isolated tenants.
#incident-260402Technical response incident-260402Business response03 Evidence
An audit trail that’s ready before anyone asks.
One incident record logs each step in real time, so nothing needs reconstructing when regulators ask. Access is logged too, including who was granted entry, when, and when it was revoked.
Audit log
- Date
- 24 minutes ago
- User
Priya S.- Object
- Workflow run
- ID
- b41f5e55-1736-4a88-b8d4
- Action
- Update
- Source
- web
Status
started → completed
Completed at
No value → 2026-04-09 12:15:05 UTC
TimelineCommunicationsTasksFollow-upsStatus pageRetrospective
Include system events
Add an event to the timeline
Rootly updated the incident
Teams added Search
Marco R. updated an action item
Task added Check access cluster health
Marco R. updated the incident
Services added elasticsearch-prod
Enterprise-grade security and compliance.
SOC 2 Type II attested, built to support HIPAA, GDPR, and CCPA, and provisioned as code through Terraform and Pulumi, so governance is part of the configuration rather than a separate project.
Nobody stumbles into an investigation.
A private incident is invisible to the rest of the org, and access to it is invite-only and controlled end to end.
A process for every kind of incident.
Phishing, data exposure, and vulnerability response each get an incident type with its own form, workflow, and roles.
On-call for the security rotation.
Security on-call gets its own schedules and escalations, and a page falls back from push to SMS, voice, Slack, and email until someone answers.
Access follows your identity provider.
SSO and SCIM keep Rootly’s users and groups in step with Okta, Entra, or Google Workspace, so when someone leaves, their Rootly access goes the moment your identity provider removes them.
Mitigated is not the same as closed.
Superhuman’s Security team runs the slow half of the lifecycle through agents on Rootly’s MCP server, and its median time from mitigated to closed is 3.8x faster.
| Stage | Before | With Rootly |
|---|---|---|
| Post-mitigation work | Prioritized against other urgent work | Driven forward automatically |
| Post-incident reviews | Written when someone got to it | Drafted automatically, then reviewed by people |
| Review meetings | Scheduled by hand | Scheduled and transcribed automatically |
| Agreed actions | Assigned and ticketed by hand | Tracked tickets with owners |
| Orphaned action items | Reassigned by hand, with the new owner catching up | Reassigned from the incident record |
“Every capability Rootly ships is one my team does not have to build. That is the whole value for me: We spend our time on security, not on the tooling that runs incident management.”
Thijn BukkemsSecurity Tech Lead, Superhuman
How Superhuman's Security team made Rootly the central system for closing security incidents fasterThijn Bukkems
KnowBe4 switched from PagerDuty and turned Incident Response into a repeatable, predictable system with Rootly.
Matthew Duren
Replit brings structure, speed, and better decision-making to incident response with Rootly.
Matthew Iselin
How Recast Software built its entire incident practice on Rootly instead of buying three tools.
Brady Lamb