Enterprise incident response tools should have SAML SSO with SCIM provisioning, role-based access control, private incidents, an audit log of configuration changes, encryption in transit and at rest, configurable session timeout and data retention, SOC 2 Type II with GDPR, CCPA and HIPAA support, and clear rules for how AI features use your data. Incident tools hold some of the most sensitive records a company has: breach timelines, customer impact, internal debate about root cause. They also connect to Slack, Jira, monitoring and cloud accounts. Security review should weigh them like any system with that reach.
This checklist covers what to require, what to ask vendors, and how Rootly meets each item. For keeping incident records audit-ready, see incident audit trail.
The security checklist
| Requirement | Why it matters | Ask the vendor | Rootly |
|---|---|---|---|
| SAML SSO | MFA and conditional access from your IdP apply to the tool | Which IdPs? Can SSO be enforced? | SAML 2.0 with Okta, Microsoft Entra ID, Google Workspace, OneLogin, JumpCloud and Auth0 |
| SCIM provisioning | Leavers lose access automatically | Does SCIM set roles from IdP groups? | SCIM 2.0 (Enterprise) |
| Role-based access | Least privilege for responders, viewers and admins | Are roles customizable? | Built-in roles; custom roles on Enterprise |
| Private incidents | Security, legal and HR incidents stay need-to-know | Can access be restricted per incident? | Incident-level permissions (Enterprise) |
| Audit log | Proves who changed paging, roles and workflows | Before-and-after values? Export? Retention? | About 60 resource types, before-and-after values, API export, kept indefinitely (Enterprise) |
| Encryption | Protects data and integration keys | At rest and in transit? Key management? | Integration keys encrypted at rest with AES-256, TLS in transit |
| Session and retention controls | Limits exposure from stolen sessions and old data | Configurable timeout and retention? | Custom session timeout and data retention (Enterprise) |
| Compliance | Required by procurement and regulators | Which reports and agreements? | SOC 2 Type II; GDPR, CCPA and HIPAA support; BAA available |
| Network controls | Integrations through restrictive firewalls | Published outbound IPs? | Outbound IP allowlisting |
| Status page access | Internal status pages stay internal | Password or SSO protection? | Password or SAML SSO page authentication |
| AI data handling | Incident data is sensitive | Training use, redaction, location, retention? | No fine-tuning on customer data; PII scrubbed from prompts; US-based inference; 90-day AI session expiry |
Identity: SSO and SCIM
The fastest hardening step for any incident tool is moving login behind your identity provider. With SAML SSO enforced, your IdP’s MFA, device checks and conditional access apply to the tool, and you manage account lifecycle in one place. SCIM closes the other gap: when someone leaves and the IdP disables them, their incident tool account is deactivated on the next sync, so a former employee can’t read incident channels or retrospectives. Once SSO is live, stop direct email invitations, which create accounts that SCIM won’t deprovision.
Rootly supports SAML 2.0 SSO with the major identity providers and SCIM 2.0 provisioning, as described in its security best practices.
Access: roles and private incidents
Responders need to act fast, but not everyone needs to see everything. Check that roles separate admins, responders and read-only stakeholders, and that the on-call configuration (schedules, escalation, alert routes) can be limited to the people who own it. Security incidents, legal matters and HR issues need more than roles: an incident whose channel, timeline and retrospective are visible only to people invited to it. Rootly’s private incidents restrict access with incident-level permissions on top of role-based access control.
Evidence: audit log and records
Auditors ask two questions: what happened during the incident, and who changed the process. The first is the incident timeline. The second is the configuration audit log. Rootly’s Audit Log records every create, update and delete across about 60 resource types, including escalation policies, workflows, roles and integrations, with the actor, source, IP address and before-and-after values, and redacts credentials. It is retained indefinitely by default and exportable through the API.
Data protection: encryption, retention and AI
Ask how data and integration credentials are encrypted, how long incident data and AI conversations are kept, and whether you can shorten that. For AI features, ask four questions: is our data used to train models, what is redacted before a prompt leaves the platform, where does inference run, and does the AI respect the same permissions as the user? According to Rootly’s AI data privacy documentation, customer data is processed in context and not used to fine-tune base models, PII is scrubbed from outgoing prompts, inference runs in US-based infrastructure, and AI session messages are removed after 90 days without activity.
How Rootly meets enterprise security reviews
Rootly is SOC 2 Type II certified, supports GDPR, CCPA and HIPAA requirements, and lists BAA support on every plan. SSO with SAML is available on every plan; Enterprise adds SCIM, custom roles, private incidents, the Audit Log, and custom session timeout and data retention. The security page and the subprocessor list cover the details security teams usually ask for. Compare plans on the pricing page.
Frequently asked questions
What security features are must-haves when buying enterprise incident response tools?
SAML SSO with SCIM provisioning, role-based access control, private incidents for sensitive cases, an audit log of configuration changes, encryption in transit and at rest, configurable session timeout and data retention, SOC 2 Type II with GDPR, CCPA and HIPAA support (including a BAA), and clear rules for how AI features handle your data. Rootly provides all of these; SCIM, custom roles, private incidents, audit logs, custom retention and session timeout are on its Enterprise plan.
Why does SCIM matter for incident response software?
SCIM ties accounts to your identity provider. When someone leaves and IdP access is removed, their incident tool account is deactivated on the next sync, so former employees can't read incident channels, timelines or retrospectives. Without it, deprovisioning depends on someone remembering.
What are private incidents?
Private incidents restrict who can see an incident beyond normal roles, for security breaches, legal matters or HR issues. In Rootly, private incidents use incident-level permissions, so only invited responders and subscribers can see the incident, its channel and its timeline.
Does Rootly sign a BAA for HIPAA?
Yes. A BAA is available on every plan, and Rootly supports HIPAA requirements. Rootly is SOC 2 Type II certified.
How should we evaluate AI features in incident response tools for security?
Ask whether your data trains models, where inference runs, what is redacted before prompts leave the platform, how long AI conversations are kept, and whether AI respects existing permissions. Rootly does not use customer data to fine-tune base models, scrubs PII from outgoing prompts, runs LLM inference in US-based infrastructure, and removes AI session messages after 90 days without activity.
Must-have security features for enterprise incident response tools