Disconnecting an integration safely

When to disconnect

Reasons to disconnect (not an exhaustive list):

• You are retiring the source system from your stack entirely
• You are switching to a different provider that offers the same signal (Okta to Microsoft Entra, CrowdStrike to SentinelOne, etc.)
• The integration's OAuth scopes were tightened on the source side and you prefer to revoke rather than re-approve
• You are winding down a client tenant
• You are temporarily pausing data collection for compliance reasons (rare)

If you just want to stop syncing briefly without fully disconnecting, use Pause Sync instead of Disconnect. Paused integrations keep their credentials and configuration; they just don't run on schedule until you unpause.

What stays and what goes

Disconnecting preserves your audit trail. Specifically:

In short: historical data stays, future collection stops, credentials are purged. Your risk register and framework assessments still reflect what the integration produced up to the moment of disconnect, with timestamps intact for audit purposes.

The disconnect flow

1. 1
   Open Integrations, click the integration you want to disconnect, click Disconnect.
2. 2
   Radius360 shows you the consequences: how many pieces of evidence came from this integration, how many risks, how many incidents, and which controls will need alternate evidence to stay satisfied.
3. 3
   Confirm the disconnect. Credentials are purged immediately, future syncs are cancelled, and the integration moves to Disconnected status.
4. 4
   Optionally, revoke on the source side as well (recommended; see below).

Revoking on the source side

Disconnecting in Radius360 stops us from using the credentials. It does not automatically revoke them on the source system. For defense-in-depth, also revoke on the source side:

• OAuth-based integrations (Okta, Microsoft 365, Google Workspace, etc.). Revoke the Radius360 application's consent in the source system's admin console. This invalidates any tokens we might still be holding.
• AWS. Delete the IAM role we assumed. The CloudFormation stack that created it can be deleted; the role and its trust policy go with it.
• API-key based integrations. Rotate or delete the API key in the source system.

Replacing an integration

When switching from one source to another (Okta to Microsoft Entra, for example), don't disconnect the old one until the new one is Connected and has completed its first sync. That way:

• Controls stay satisfied during the switchover (both integrations are feeding evidence momentarily)
• You can compare the two sources' evidence to spot gaps
• Open risks from the retiring integration don't go orphaned

Once the new integration is healthy, disconnect the old one as normal. Evidence from the old source is preserved; control satisfaction shifts to the new source automatically.

Audit-period considerations

During an active audit, disconnecting an integration that feeds audit-in-scope controls creates visible churn an auditor will ask about. Best practices:

• Avoid disconnecting mid-audit-period unless there's a specific reason (compromise, compliance requirement, cost)
• If you must disconnect, document the reason in the integration's notes field. The audit export captures this note.
• If you're replacing with another source, do the replacement (not just a disconnect). Auditors are fine with "we switched tools"; they're not fine with "we stopped collecting evidence."

Related reading: Troubleshooting sync failures, Integrations overview.