Skip to main content

​
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 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.
1

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.
2

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.
3

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.
​
recommended
Define purpose-built roles (“Incident Responder”, “On-Call Operator”, “Auditor”) instead of granting full admin. See User Permissions for the available permission scopes.
​
recommended
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.
​
separate access plane
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.
​
for compliance
Compliance and security reviewers should hold an Auditor role with read-only access to the audit log and configuration — never an admin role.
Run a quarterly review of admin role assignments. The Audit Log records every role change with before-and-after values, making this a five-minute filter exercise rather than a manual cross-check.

​
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.
1

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.
2

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.
3

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

​
team setting
Configure a default session timeout in your team settings. Shorter timeouts (8 hours or less for high-privilege roles) reduce the scope of impact of a stolen session cookie or unlocked workstation.
​
upstream control
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:

​
Compliance Posture

Rootly maintains SOC 2 Type II. Auditors and customer security teams typically request the following artifacts during review: For tenant-side compliance evidence (who has access, what changed, when), the Audit Log is the system of record — its filterable change history and JSON:API export are designed to satisfy “demonstrate continuous monitoring” controls.

​
Frequently Asked Questions

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.
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.
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.
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.
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.

Audit Log

The visibility layer — every change to sensitive configuration surfaces here.

Webhooks

Route incident, alert, workflow, and status-page events to external systems — periodically review destinations for orphans.

Configuration Overview

The umbrella page covering incident properties and configuration surface.