Overview
This page walks Rootly administrators through the controls available for hardening a tenant against unauthorized access, lateral movement, and silent configuration drift. It is the recommended checklist when preparing Rootly for an enterprise security review, a SOC 2 or ISO 27001 audit, or onboarding a new organization. Every recommendation below is grounded in features Rootly ships today — links lead to the relevant configuration page. The order mirrors how most teams roll out hardening: identity first, then permissions, then API surface, then monitoring.Centralized Identity
SAML SSO plus SCIM provisioning so the IdP is the source of truth for who can log in and what role they hold.
Least Privilege
Custom roles and on-call seat controls scoped to job function — no blanket admin grants.
Scoped API Access
OAuth 2.0 over long-lived tokens, scoped permissions, and routine credential rotation.
Continuous Audit
Indefinite audit log retention with filterable change history across configuration, integrations, incidents, and workflows.
Centralize Identity
The fastest single hardening step for any Rootly tenant is moving authentication behind your IdP. Once SSO is enforced, you control account lifecycle, MFA, and conditional access from one place — Rootly inherits whatever your IdP enforces.Enable SAML SSO
Configure SAML 2.0 with your IdP (Okta, Azure AD, Google Workspace, OneLogin, JumpCloud, Auth0, or any SAML 2.0-compatible provider). See SSO for the service provider details and IdP-specific walkthroughs.MFA is enforced at the IdP layer, not in Rootly directly. Use the IdP’s conditional access policies to require MFA, device posture checks, or location restrictions before letting users land in Rootly.
Enable SCIM provisioning
Configure SCIM 2.0 so user creation, role assignment, and deactivation are driven by IdP group membership. See SCIM.SCIM is the most important control for deprovisioning: when an employee leaves and the IdP disables their account, SCIM automatically deactivates their Rootly account on the next sync — closing the gap where a manual admin would otherwise need to remember to revoke access.
Stop allowing direct invitations once SSO is live
With SSO enforced, prefer SCIM-driven provisioning (or Just-In-Time provisioning from the SAML assertion) over manual invite-by-email. Direct email invites create accounts that won’t be auto-deprovisioned when the user leaves the organization.See SCIM for full lifecycle provisioning and SSO for the SAML attribute mapping that drives Just-In-Time provisioning. (Rootly also supports manual invites via Inviting Users via Third-Party Integrations for Slack, Opsgenie, PagerDuty, and Splunk On-Call — useful for narrow cases, but not the right primitive for IdP-managed lifecycle.)
Apply Least Privilege
Rootly’s role model lets you scope what a user can do down to the action level. Use it — broad admin grants are the largest unforced security risk in most tenants.Define purpose-built roles (“Incident Responder”, “On-Call Operator”, “Auditor”) instead of granting full admin. See User Permissions for the available permission scopes.
Delegate team-scoped configuration to team admins instead of org-wide admins. Team admins can manage their team’s schedules, escalation policies, and members without touching org-level settings. See Configuring Teams.
On-call paging requires a separate seat type. Grant on-call seats only to users who actually take pages — users without a seat cannot be added to schedules, eliminating accidental paging exposure to non-responders.
Compliance and security reviewers should hold an Auditor role with read-only access to the audit log and configuration — never an admin role.
Lock Down API Access
Rootly exposes a public API plus OAuth 2.0 provider endpoints. Both deserve deliberate hardening.Prefer OAuth 2.0 Over Long-Lived API Tokens
For machine-to-machine integrations, use OAuth 2.0 rather than static API tokens. OAuth tokens have explicit scopes, short lifetimes, and can be revoked from a single place. Long-lived API tokens are appropriate only for narrow internal tooling, and should be rotated on a fixed cadence.Scope API Tokens Tightly
When an API token is necessary, scope it to the minimum permission set the integration needs. A token used by a Datadog → Rootly forwarder should not have the ability to modify escalation policies or user roles.Audit Outgoing Webhook Destinations
Outgoing webhooks post to URLs you supply. Review the webhook destinations in your tenant on a recurring cadence and remove ones pointing at decommissioned receivers — orphaned destinations accumulate over time and become exfiltration risks once their hosts change ownership.Turn On Continuous Audit
Rootly’s Audit Log captures every create, update, and delete across ~60 resource types with full before-and-after field values. It is the compliance evidence layer auditors look for.Familiarize Your Team With The Audit Log UI
Walk security and compliance reviewers through Configuration → Audit Log so they can self-serve “who changed X, when?” questions without filing tickets to the Rootly admins.
Use The JSON:API Export For Programmatic Review
The audit log is available via the audit log JSON:API endpoint for scheduled export — useful for backing up evidence into long-term storage your auditors already own, or for ad-hoc queries beyond what the UI filters expose.
Make High-Signal Changes Part Of Your Review Cadence
Review these events on a routine cadence: role assignments granting admin, API token creation, webhook destination changes, user deletion, escalation policy changes outside change-control windows. These are the events that precede or are part of most security incidents.
Control Session And Device Posture
Configure a default session timeout in your team settings. Shorter timeouts (8 hours or less for high-privilege roles) reduce the blast radius of a stolen session cookie or unlocked workstation.
Use your IdP’s conditional access (Okta, Microsoft Entra Conditional Access, Google Context-Aware Access) to gate Rootly access on device posture — managed device, current OS, antivirus running. Rootly inherits the gate; you don’t need to re-implement it.
Harden Third-Party Integration Hygiene
Each integration you connect is a potential blast-radius vector if its credentials leak. Routine hygiene:- Rotate integration credentials on a schedule. Most providers let you regenerate API keys without recreating the integration — schedule a quarterly rotation for high-privilege integrations (PagerDuty, Slack, GitHub, Datadog).
- Disable integrations you no longer use. A connected-but-unused integration is still attack surface. Review your integrations list each quarter and disable connections to systems your team no longer relies on. The Audit Log captures recent configuration changes to each integration, which helps confirm whether one has been actively maintained.
- Limit Slack workspace access. When configuring the Slack integration, install it as a specific workspace admin rather than a personal account — that way, the integration outlives any individual user’s tenure.
- Review integration scope grants. When connecting OAuth-based integrations (Google Workspace, Microsoft 365), confirm the requested scopes match what Rootly actually needs for the features you use.
Status Page And Public Surface
If you publish status pages, treat the public surface deliberately:- Use Status Page Authentication Methods — password protection or SAML SSO — on any status page that should not be world-readable.
- Confirm Public And Private Status Pages classifications match intent — a misclassified private page is a data exposure.
- Use a Custom Domain for branded status pages so DNS and TLS sit under your control.
Compliance Posture
Rootly maintains SOC 2 Type II and ISO 27001 certification. Auditors and customer security teams typically request the following artifacts during review:| Artifact | Where To Get It |
|---|---|
| SOC 2 Type II report | Contact support@rootly.com for the latest report under NDA |
| ISO 27001 certificate | Available on request through support |
| Subprocessor list | Maintained on rootly.com — request the current version through your account team |
| Data processing addendum | Available through your account team |
Frequently Asked Questions
Does Rootly support MFA directly, or only through SSO?
Does Rootly support MFA directly, or only through SSO?
MFA is enforced at the identity-provider layer. Once SAML SSO is configured, whatever MFA policy your IdP applies (TOTP, push, FIDO2/WebAuthn, certificate-based) is what controls Rootly login. There is no separate Rootly-native MFA setting — using the IdP’s MFA is the recommended pattern because it centralizes policy.
How long does Rootly retain audit log data?
How long does Rootly retain audit log data?
Audit log retention is unlimited by default — every create, update, and delete event is retained for the lifetime of your tenant. For long-term archival outside Rootly, use the audit log JSON:API endpoint to export events into compliance storage your auditors already own.
How do I rotate an API token without breaking integrations?
How do I rotate an API token without breaking integrations?
Create the replacement token first, deploy it to the consuming integration, verify traffic is flowing on the new token (visible in audit log events sourced from “API” with the new token’s identifier), then revoke the old one. The overlap window is the safe rotation pattern — never delete a token before its replacement is in use.
Are passwords and tokens visible in the audit log?
Are passwords and tokens visible in the audit log?
No. The audit log automatically redacts sensitive fields (passwords, API keys, OAuth tokens, signing secrets) in the UI and API responses. You see that the field changed, but not the value.
What's the right role for our compliance team?
What's the right role for our compliance team?
Create a custom Auditor role with read-only access to configuration, the audit log, and (optionally) incident records. Auditors should never hold an admin role — they need to read, not modify.
Next Steps
SSO Configuration
SAML 2.0 setup with Okta, Azure AD, Google Workspace, and other identity providers.
SCIM Provisioning
Automate user lifecycle from your IdP — the deprovisioning control most worth getting right.
Audit Log
Full change history across configuration, integrations, and incidents — filterable in the UI and exportable via the JSON:API.
User Permissions
Custom roles, team admins, and the permission scopes available for least-privilege design.