For the engagement owner. A healthy central dashboard does not establish control coverage in every account or workload.
Map the hierarchy before collecting settings
Cloud controls can exist at organisation, account, project, subscription and workload levels. Start with a dated inventory and explain which controls are inherited and which remain local. Identify production services, regions, provider-managed components and important exceptions. Without that map, an assessor can inspect a correct central setting and still miss an account outside the intended boundary. State the selected accounts and workloads in the report, including why they were chosen and what remains unassessed.
Read diagram text
- Organisation
- Inherited requirements and guardrails.
- Account
- Local settings and exceptions.
- Workload
- Service-specific implementation.
Check logging coverage as a configuration question
For selected accounts, review whether the required trail or logging configuration is present, enabled and directed to the intended destination. Compare the configuration with the agreed logging requirement. Then examine available evidence of delivery, retention and ownership if those objectives are in scope. Keep these conclusions distinct. A configured trail does not by itself prove every event was retained; an available log does not establish complete detection coverage. Document unavailable historic records and the resulting limits instead of silently assuming continuity.
Use a consistent change population
A cloud change review should begin with a defined production-change population and period. Link selected deployments to approval records, review conditions and resulting configuration. Timestamps matter when the criterion requires approval before release. An approval recorded after deployment may be a valid emergency process or an exception, depending on the agreed rule and supporting evidence. Do not decide from a ticket label alone. Record the relevant sequence and ask the owner to resolve missing or contradictory context.
Read diagram text
- Configured
- Required sources are enabled.
- Delivered
- Evidence reaches the intended destination.
- Used
- Ownership and review are demonstrated.
Treat recovery as a service dependency
Backup configuration, successful job status and recoverability answer different questions. Identify critical services and their dependencies, then review what restore exercises actually demonstrated. Evidence should show the restored component, validation performed, elapsed time, access requirements and remaining limitations. A snapshot job marked successful cannot establish that an application can be restored within its business objective. If a live exercise is proposed, scope its safeguards and approval separately from the read-only audit.
Read diagram text
- Request
- Reason and affected service.
- Approval
- Decision before release or valid exception.
- Deployment
- Observed change and result.
Report coverage alongside risk
Use a matrix that connects accounts and services to controls, evidence and limitations. Distinguish a repeated design problem from a local exception so management can select the right remediation owner. Avoid implying provider certifications resolve customer configuration issues. The organisation still needs an accountable process for its own permissions, workloads and evidence. Related guidance from the same Atlant Security portfolio: cloud and delivery-system attack boundaries and cloud responsibility boundaries. Use these when an audit recommendation needs a separately scoped technical test or a clearly owned operational improvement.
Prepare a useful first conversation
Use the audit scoping brief builder to record your objectives, control areas, platforms and evidence period. Review its draft before sending it to Atlant Security through the contact form. You can attach an NDA or RFP for human review. Begin with non-sensitive context and approximate counts; confidential control evidence belongs in an agreed secure channel. The brief does not authorise system access, accept an NDA or establish an assurance opinion.
Read diagram text
- Backup
- A copy was created.
- Restore
- Selected components were recovered.
- Service
- Business usability was validated.
Primary sources
- Atlant Security IT security audit
- NIST Cybersecurity Framework
- NIST SP 800-53A assessment methodology
General information, not a compliance opinion. Confirm legal applicability and security service requirements for your entity and jurisdiction.
This guide and the related sector publications linked above are published by Atlant Security. Technical examples are planning examples, not claims about completed client tests.
Published by Atlant Security. Sources, editorial policy and corrections.
