A content management system is rarely just a website anymore. Behind a typical CMS sit object storage for media, a managed database, a content delivery network, a build pipeline and several service accounts holding keys to all of it. Each piece is configured in a cloud account, and each configuration is a place where a small error can expose editors’ data or let a stranger publish pages. CloudSecOps means keeping that web of settings honest once the launch party is over. The ten steps below follow the order a CMS team would naturally meet them, each backed by a source figure.
Step 1: Draw the control plane around your site
List every cloud account that touches the CMS: production, staging, the one a former agency set up, and the one that hosts backups. For each, write down the owner and purpose. This is not busywork. The Atlas describes the first goal as visibility, a state where every critical finding has an owner within a day. You cannot assign owners to accounts you have not counted. If your site structure is still being planned, a structural guide to the pages a business site needs offers a similar inventory habit for content.
Step 2: Turn on organisation-wide logging first
Before changing any rule, make sure you can see changes. Send audit logs from all accounts into one archive, preferably in a separate account that CMS administrators cannot edit. Then check retention. According to the Atlas entry on CloudSecOps, AWS retains roughly a quarter of a year of management events and charges extra to record object-level activity, Azure keeps 90 days of activity logs, and Entra sign-in logs last seven days on the free tier or 30 on paid tiers without backfilling earlier time. For a CMS, data events matter, because they show who read or changed objects in your media bucket.
Step 3: Choose a benchmark and record its version
Pick a published baseline for your cloud, such as the CIS Foundations Benchmarks, and write down the exact version. The Atlas’s October 2026 notes show Azure on a 6.x release, Google Cloud on 5.x and AWS furthest ahead on 7.x, so check the current number before you quote it. Recording the version matters because scanning tools sometimes lag: the notes mention a vendor posture service that supports an older AWS release and checks Azure against version 4.0. A result that says “compliant” is only meaningful if you know which version produced it.
Step 4: Run a scan and triage by exposure
Use a commercial posture service or the open-source Prowler, which the Atlas lists as Apache 2.0 licensed. Sort findings by exposure rather than count. For a CMS, rank in this order:
- Public storage holding uploads, backups or database exports.
- Administrator logins without a second factor.
- Long-lived keys embedded in deployment scripts.
- Overly broad roles attached to the application servers.
Assign each an owner and a due date. Confirm closure by scanning again, not by reading a comment in the tracker.
Step 5: Inventory keys and know the deletion delay
The CMS likely encrypts its database and media with managed keys. List them and check who may schedule deletion. Per the Atlas, a deleted key sits in a grace window before it is truly gone: a week up to a month on AWS (a month by default), a week up to three months in Azure’s vault with purge protection, and a month in Google’s key service. Remember, too, that rotation does not change the protection of data already encrypted under a key, so do not rely on it as a substitute for tight access.
Step 6: Add guardrails in stages
Preventive rules are the strongest control, and also the easiest to get wrong. Block the dangerous actions you found in step 4, such as making storage public, but roll the rule out to a test group first. The Atlas points out that AWS organisation policies have no evaluate-only mode, while Azure and Google do offer dry-run options. Also note that some account types are exempt from those AWS policies, so protect them by other means.
Step 7: Handle console edits and code together
CMS teams often fix an urgent problem by clicking in the console, and then the infrastructure code reverts it at the next deployment. The Atlas names this reversion as a recurring failure mode. Make every manual change a pull request within the same day, so the repaired setting survives. Similarly, if you exempt a role by name from a rule, make sure nobody can create a role with that name.
Step 8: Record exceptions with an expiry
Some findings will be accepted for a time, for instance a legacy plugin that needs wider access. Record the reason, the owner and an end date no longer than 90 days. Review the register weekly. If an exception is renewed twice without progress, treat it as a failing item rather than a settled one.
Step 9: Measure with figures that resist gaming
Four numbers are enough: guardrail coverage (accounts that fall under today’s rule set, over all accounts in use), detection coverage (account and Region pairs with logging divided by all pairs), median time that closed critical findings stayed open, and exception debt (how many granted exceptions have lapsed, relative to those still open). The Atlas shows a worked example of 45 of 48 accounts, or 93.8 percent, and 186 of 192 pairs, or 96.9 percent. Pass-rate percentages from a scanner are easy to inflate by suppressing findings, so do not lead with them.
Step 10: Rehearse once a quarter
Rehearsals do not need to be dramatic. A one-hour tabletop is enough: someone describes a plausible event, the team checks which logs would show it, who would be called and which switch they would flip first. Capture the gaps in writing and feed them into the next month’s review. The aim is a calmer team on the day something truly goes wrong, plus a short list of improvements that costs almost nothing to collect.
Run a short exercise, such as a stolen editor login publishing a defaced page, and see whether the logs tell the story. If the team cannot reconstruct events, fix retention before anything else. Finally, if your service pages need work while you tidy the platform, an explanation of how effective service pages turn visits into enquiries pairs well with this work.
The sequence above takes about a quarter to complete for a modest CMS estate. If you run only one account and one team, fold the steps into your usual release routine instead of creating a separate function.
