Most teams meet CloudSecOps the same way: a scanner dumps four hundred findings into a shared channel, nobody knows who owns what, and the whole thing quietly goes stale. This how-to is for operators who want to avoid that. It lays out a ninety-day sequence you can follow account by account, with a clear job for each stretch, and it keeps the moving parts small enough that one tired engineer can run them.

Before the steps, a quick word on terms. CloudSecOps is a young label rather than a standards-body definition. The Ops Atlas entry on CloudSecOps at xOps School frames it as the routine upkeep of cloud controls, logging and response, and it is upfront that the framing is editorial. Treat the steps below as a working method, not a certification syllabus.

Step 1: Pick the boundary before you pick a tool

Write down which accounts, subscriptions or projects are in scope and who is the human owner of each. This sounds trivial and it is where most efforts stumble. If you cannot name an owner for an account, that account is your first finding. Keep the list in version control so that changes to it show up in review.

Also note what is out of scope on purpose. Pipeline scanning, endpoint hardening and audit paperwork are neighbouring jobs. They matter, but mixing them into this effort in week one is how a clean project turns into a swamp. The Atlas draws the same line: configuration state in the running cloud is the focus, and the paperwork is something this work feeds with evidence.

Step 2: Days 1 to 30, get eyes on everything

Your first month is about visibility, not enforcement. Three jobs belong here.

1. Central logging. Send audit logs from every account into one archive that the people who administer those accounts cannot edit or delete. If an attacker or a well-meaning admin can erase the trail, the trail is decoration.
2. Continuous scanning. Turn on a posture scanner and let it run. An open-source option such as Prowler is enough to start, and it keeps you from signing a contract before you know what you need.
3. A key inventory. List every encryption key and who depends on it. You are not rotating anything yet; you are learning what exists.

Check your log defaults while you are here. On AWS the console event history only reaches back ninety days, and object-level data events stay disabled until you switch them on at extra cost. Azure’s activity log holds ninety days too, and Entra sign-in logs are kept for seven days on the free tier, longer on paid tiers, with no backfill for the days you missed. Google keeps data-access logs switched off for nearly every service except BigQuery. If you want a year of history, you have to build it deliberately, and building it later does not recover the gap.

Step 3: Days 31 to 60, make every finding someone’s job

A finding with no owner is a rumour. In month two, give each critical finding a named owner within one working day of it appearing, and attach a deadline that matches severity. The goal is not zero findings. The goal is that nothing sits unclaimed.

Open an exception register at the same time. Some findings are legitimate trade-offs, and a register lets you accept them on purpose: who approved it, why, and when it expires. Cap every exception at ninety days. When one comes up for renewal, somebody has to look at it again instead of letting it fossilise.

Closure needs a rule too. A ticket comment saying “fixed” is not closure. Rescan, and close only when the scanner agrees. This one habit prevents the awkward quarter where a dashboard says all green and a reviewer finds the same public bucket still sitting there.

If you have been following our notes on cutting alert noise with smarter tooling, the same discipline applies: fewer, better-owned signals beat a firehose every time.

Step 4: Test a guardrail somewhere safe first

This is where the second half of month two goes. Pick one low-risk organisational unit, a sandbox or a test group of accounts, and apply a preventive guardrail there, such as a service control policy that blocks disabling the audit trail. Watch what breaks for a week.

There is a catch worth knowing on AWS. Service control policies do not apply to the management account or to service-linked roles, and unlike Azure’s DoNotEnforce mode or Google’s dry-run organisation policies, they have no evaluate-only setting. You cannot “preview” a deny. That is exactly why a test group matters: the test group is your preview.

Step 5: Days 61 to 90, enforce, rehearse and report

Month three turns the lights from amber to red, carefully.

• Enforce by group. Roll the tested guardrails out one organisational unit at a time, starting with the quietest. Never start with a deny-everything rule at the root; teams that do this usually spend the next week writing exceptions.
• Run a game day. Simulate one believable cloud incident, such as an exposed key or a disabled log source, and see whether detection and response work. Write down what was slow.
• Publish a scorecard. One page, once a quarter, with a handful of honest numbers.

The numbers worth putting on that scorecard

Keep to a few measures. Guardrail coverage is the share of active accounts under the current policy set; if forty-five of forty-eight accounts are covered, that is 93.8 percent, and the three stragglers are your to-do list. Exception debt is expired exceptions divided by open ones. Median time to close a critical finding is useful, but report it next to the open findings’ 50th and 90th percentile ages, because a friendly median can hide a stubborn tail.

Be suspicious of tool pass rates. Some platforms mark a control as passed when a finding has been suppressed, so a rising green percentage can mean people got better at suppressing, not at fixing.

Automation: where to say yes and where to say no

Automate prevention freely. A guardrail that stops a public bucket being created costs nothing when it never fires. Fix things automatically only when the change can be undone, the diagnosis is solid, and the blast radius is tiny. Keep scripts away from deleting data, and away from rotating any credential something is still using. An overeager auto-fix at three in the morning can do more damage than the finding it was chasing.

That caution echoes our earlier piece on why prediction tools still need human checks: automation earns trust slowly and loses it quickly.

A rhythm you can keep

Once the ninety days are done, settle into a cadence rather than a project. Scans run continuously. Critical triage happens daily. Exceptions get a weekly look. Guardrails and benchmark versions are reviewed monthly, and a game day lands each quarter. If you cannot sustain a step, cut the frequency before you cut the step.

One last honesty check: if your estate is one or two accounts run by a single team, this whole structure may be more than you need. Microsoft’s guidance for estates that small is to fold the platform and security roles into one. Do the simple thing, keep the logs safe, and grow into the rest.