Separate the blast radius from recovery

Connect reachable resources with containment and restoration records.

When to use this guide

Use this when broad administrative, pipeline, or contractor access coexists with shared recovery dependencies.

Describe both what is reachable from a starting identity and what has demonstrably been restored.

1 / 3
Map starting privileges
Trace administrative permissions and trust relationships into production, other environments, and backups.
Evidence to retain
Starting privileges, reachable assets, and their owners.
2 / 3
Review containment and recovery prerequisites
Read the existing procedures for identifying containment targets and recovery data, settings, and connections.
Evidence to retain
Recovery targets, dependencies, and required permissions.
3 / 3
Separate backup from restoration evidence
Review authorized restoration exercises and distinguish usable restored scope from unverified scope.
Evidence to retain
Restore point, target, usability confirmation, and remaining constraints.

One administrative or CI identity can reach several environments.

Trace roles, connections, and assumable permissions through configuration records.

Backups exist, but restoration of the required service needs verification.

Compare the recovery scope with records of the latest authorized restoration exercise.

Credentials stolen in the earlier Okta incident were missed during rotation. They enabled access to self-hosted Atlassian systems and source code.

Stolen credentials for a contractor administrator account without MFA enabled a ransomware intrusion.

Selected examples. Each record retains its evidence status, unknowns, and sources.

Authorization: The decision about whether a caller may perform a particular action on a particular resource, separate from establishing their identity.; Does the decision still hold when the resource belongs to another user or organization?; Open the related inspection rule →
Restoration: Returning data and services to a usable state. Treat this separately from successfully creating a backup.; Is there evidence that the required scope was restored to a trusted state?; Open the related inspection rule →
Asset: A service, store, or administrative identity included in the review. Record its owner and purpose as well as its name.; Which environment and owner does this asset belong to?; Open the related inspection rule →

A permission path alone does not establish that a compromise occurred.
Do not turn read-only review into containment, privilege removal, or production restoration.

Keep reachability and recovery evidence distinct rather than reducing readiness to one score.

References and review dates

OWASP: Authorization Cheat Sheet ↗
Enforce Least Privileges; Validate the Permissions on Every Request
Center for Internet Security: CIS Critical Security Control 11: Data Recovery ↗
Overview: restore in-scope assets to a pre-incident and trusted state

Learning review 2026-11-12 · Catalog review 2026-11-09

Share these two rules and examples without expanding the scope. Checks without evidence remain unverified.

Check what was actually deployed
Connect the running version with the external code executed on its way to deployment.
Follow login and the session after it
Review MFA coverage separately from the mechanisms that stop an authenticated session.
Review secret handling without opening values
Map exposure paths and the process for invalidating old credentials after replacement.
Review exposure and data that remains
Review storage exposure together with the handling of retired environments and data copies.
Keep user and organization data separated
Connect resource authorization with the boundaries controlling reuse of generated responses.
Trace input into queries and file processing
Follow inputs from entry points to SQL construction and file storage or processing.
Set AI boundaries before delegating a task
Review destinations, action authorization, and traceable records at the execution boundary.