1. Define scope and business impact
List cloud accounts, subscriptions, regions, production workloads, identity systems, and critical data stores in scope. Identify the services that support customer access, payments, internal operations, or business continuity. Record system owners and dependencies before reviewing configuration.
Agree on what is out of scope and how findings will be handled. If an assessment requires access to production, define authorization, timing, and safeguards in advance.
2. Review identities and permissions
Inspect privileged users, roles, service identities, access keys, and federation paths. Look for unused accounts, overly broad permissions, long-lived credentials, and permissions that no longer match the job. Confirm that emergency access is controlled and tested rather than improvised during an outage.
Compare current access with the principles in the zero trust implementation guide.
3. Check exposure and network paths
Review public endpoints, storage access, administrative interfaces, firewall rules, and routes between workloads. Confirm that every internet-facing service has a business owner, a documented purpose, and an update plan. Check whether development or test environments can reach production data or credentials.
Exposure is not automatically a vulnerability, but unexplained exposure deserves a clear decision and owner.
4. Trace data, secrets, and logs
Map the data classes handled by each system and who can read, export, or delete them. Review where secrets are stored, how they rotate, and whether they can leak into build logs or repositories. Confirm that sign-ins, privilege changes, and security-relevant configuration updates produce logs that someone can investigate.
Do not collect or copy sensitive production data to perform a review unless the scope explicitly requires it and the handling plan is approved.
5. Test recovery
Review backup coverage, separation from production credentials, retention, and recovery instructions. A successful backup job does not prove a system can be restored to a usable state; test a representative recovery path and record timing, dependencies, and gaps.
Check whether recovery steps depend on the same identity system, cloud account, or administrator credentials that an incident could affect. Document who can initiate a restore and how the team will verify that restored data is current and usable. The right recovery objective depends on the system's role in the business, so agree on acceptable downtime and data loss with the owner.
6. Review monitoring and response
Confirm that important identity events, administrative changes, and service failures are logged with enough context to investigate. Identify the person or team that receives high-priority alerts and the vendor contacts needed to escalate an incident. Alert coverage without an owner can create noise rather than readiness.
Walk through what happens when a production credential is exposed or a critical cloud service becomes unavailable. Record where the runbook is incomplete, who has authority to make a containment decision, and which customer-facing teams need an update.
7. Prioritize findings and assign owners
Rank findings by business impact, exposure, and remediation effort. For every action, name an owner, due date, and evidence that will show the work is complete. Separate immediate containment from structural improvements, and state any accepted risk with the person accountable for that decision.
Black Riven's digital infrastructure consulting focuses on secure, reliable systems; a consultation can help define a review around your environment. For long-lived platforms, read how to modernize infrastructure without a disruptive rewrite.