Every spacecraft team eventually learns that the satellite is only half the system. The other half sits on the ground: command links, flight rules, telemetry archives and the people who are allowed to send instructions. Cloud estates have the same shape. The machines come and go, but the control plane, meaning the accounts, roles, keys and logs that govern them, decides whether a mistake stays small. That is the territory of CloudSecOps, and this audit checklist borrows a mission-operations mindset to walk through it.
A short note on terminology before the checklist. According to the Ops Atlas entry on CloudSecOps, the label is an emerging trade-press term and no standards body has formally defined it, so teams are free to adapt it. Treat what follows as a working audit, not a certification.
Why a mission-control lens fits
Consider how a crew handles a spacecraft passing through its distinct flight phases. Each phase has go/no-go criteria, a named owner and a recorded decision. Nothing is left to whoever happens to be on console. A well-run cloud environment asks for the same discipline: every sensitive configuration has an owner, every change leaves a trace, and every exception has an end date.
Orbits matter here too. A craft in a fixed geostationary slot looks calm from the ground, yet operators still watch for drift and correct it with small, planned burns. Cloud configuration drifts in the same quiet way. Someone widens a permission to fix a Friday outage and nobody narrows it again. The audit below is built to catch that sort of slow slide.
Audit block 1: who may command the platform
Start with identity, because a stolen command credential is worth more than any software flaw. Work through these items with the person who administers your accounts:
- Write down each person and each automated service able to alter permissions or remove resources. Anything you cannot explain gets flagged.
- Check that multi-factor sign-in is enforced for all of them. The Atlas points to a 2024 credential-theft campaign in which investigators traced every incident to customer logins that lacked a second factor and had not been rotated.
- Confirm that long-lived access keys are inventoried, dated and owned by a named team.
- Look for roles whose names are exempt from restrictions. An exemption by name is only safe if nobody else can create or edit a role with that name.
Audit block 2: guardrails and where they stop
Guardrails come in three flavours: preventive rules that block an action, detective rules that notice it, and responsive rules that react. A balanced estate uses all three. Ask these questions:
- Which preventive controls are active across the whole organisation, and which only cover a few accounts?
- Do any of them have an evaluate-only mode? On some platforms they do; the Atlas notes that AWS service control policies do not, which is why a small test group of accounts should receive every new restriction first.
- Which identities sit outside the guardrails entirely? The management account and service-linked roles are exempt from those AWS policies, so they deserve extra manual scrutiny.
- Was a blanket deny rolled out on day one? Teams that did this usually broke deployments and then granted broad exceptions to recover.
Audit block 3: the flight recorder
Spacecraft telemetry is stored where the flight team cannot quietly edit it, and cloud audit logs should follow that rule. Check that logs from every account flow into one archive that workload administrators cannot alter. Then check retention, because defaults are shorter than most people assume. The Atlas lists a 90-day event history on AWS with data-level events switched off unless you pay for them, a 90-day activity log on Azure, and a seven-day sign-in history on the free Entra tier.
One incident in the Atlas makes the point sharply. In a 2023 email-service intrusion, a review board found that the affected agency could not see activity from before its logging window began, and recommended that fuller logs with six months of retention be offered by default. The lesson is simple: you cannot investigate what you never recorded.
Audit block 4: keys and secrets
Encryption keys are the equivalent of launch authentication codes. Inventory them, note who can use and who can schedule deletion, and review the deletion waiting period. The Atlas reports waits of 7 to 30 days on AWS, 7 to 90 on Azure with purge protection, and 30 on Google. One caution it raises is worth repeating: rotating a key does not change what that key already protects, so do not treat rotation as a substitute for access control.
Audit block 5: findings, owners and proof
Posture scanners, whether commercial or an open-source tool such as Prowler, produce lists. Lists are not safety. Apply these acceptance rules from the Atlas:
- Every finding gets an owner within one working day.
- Closure is confirmed by rescanning, not by a comment on a ticket.
- Exceptions expire, and 90 days is the ceiling.
- Be wary of pass-rate dashboards, because a control can show as passed when its findings have merely been suppressed.
A rhythm you can actually keep
The Atlas proposes a cadence that maps neatly onto a mission calendar: continuous scanning, daily triage of critical items, a weekly exception review, a monthly look at guardrails and benchmark versions, and a quarterly game day where the team rehearses a control-plane incident. If that feels heavy, start with the weekly review alone and add the rest once it holds.
Before you start: gather the paperwork
Set aside an hour to collect the documents the audit will lean on: an account list showing which team owns each account, the current guardrail set, the most recent scanner export and the exception register, if one exists. Mission teams call this the pre-brief, and it prevents the most common audit failure, which is arguing about what the environment looks like instead of examining it. If any of those four items does not exist, that absence is your first finding.
Scoring your audit
Award one point per block in which every line earns an unqualified yes. Four or five points suggest a stable footing. Two or three means you have visibility but gaps in enforcement. Below that, spend the next month on logging and an owner list before buying any new tool. Re-run the audit each quarter and record the date, the benchmark version you compared against and any exceptions that were renewed rather than closed, since renewal without closure is the clearest sign of regression.
Finally, keep scope honest. If your organisation runs one or two accounts under one team, a lightweight version of this checklist, folded into ordinary platform work, is enough. A separate CloudSecOps function pays off as the number of accounts and teams grows.