Skip to main content
OpsRoadmaps
Security, Risk & Governance OpsLast reviewed 2026-09-20

CloudSecOps

Cloud security operations: keeping posture, identity and workload configuration correct across accounts — guardrails that prevent drift instead of dashboards that report it.

Overview

Read the full CloudSecOps guidance
WHAT IT IS. Cloud security operations is the continuous business of keeping a cloud estate configured the way you intended: identities scoped, networks closed, data stores private, and workloads running with permissions someone can justify. The unit of work is not a vulnerability; it is a misconfiguration that a person or a pipeline introduced and that nothing caught. WHY IT EXISTS. Cloud makes provisioning fast and revocation slow. Permissions accumulate because removing one risks breaking something nobody can name, and an environment that started tidy is, two years later, a graph of roles nobody understands. Posture tooling arrived to report this, and reporting alone changed very little — the findings backlog grows faster than anyone drains it. This area exists to shift the work left of the finding: guardrails that make the wrong shape impossible or short-lived. WHEN TO USE IT. From the second account onward. A single hand-built account can be reasoned about; a landing zone with many accounts, several teams and shared networking cannot. If you use infrastructure as code — see /gitops — the leverage is highest, because prevention can live in the same pipeline that creates the resource. WHO OWNS IT. A cloud platform or security engineering group owns guardrails, baselines and the exception process; the teams that own a workload own its findings. That split fails when guardrails land without a migration path, so the owning group also owns the cost of change. Exceptions must have an expiry date and a named approver, or they become the new baseline. WHAT GOOD LOOKS LIKE. Preventive controls outnumber detective ones: service control policies, deny-by-default network posture and typed infrastructure modules that cannot express the dangerous variant. Public exposure of a data store is impossible rather than alerted on. Identity is reviewed on a cadence, with unused permissions removed automatically after a grace period. Every guardrail exception carries an owner and a date. Findings are triaged by blast radius, not by the vendor's severity colour, and the backlog trend is flat or falling. HOW TO IMPLEMENT. Inventory accounts and owners first — you cannot secure an estate you cannot enumerate. Turn on the provider's baseline detections and resist tuning for a fortnight while you learn the noise. Pick the three misconfigurations with the worst blast radius and make them structurally impossible, using policy and paved-path modules rather than documentation. Add drift detection so a hand-edit in the console is visible. Automate permission right-sizing from observed usage, with a review step. Then measure time-to-remediate by severity and publish it to the teams that own the fixes; pair with /devsecops so the same standard applies before deployment. HOW TO ASSESS YOURSELF. How long does a publicly exposed bucket survive in your estate — and do you know, or are you guessing? What fraction of your findings are prevented rather than reported? Can you list every guardrail exception and its expiry? Score yourself at /assess, and use the cloud pass in /checklists before your next account goes live.

Capabilities

  • Cloud identity governance

    Keeping cloud permissions proportionate to use: right-sizing from observed behaviour, expiring unused access, and reviewing privileged roles.

  • Cloud posture management

    Continuously comparing the deployed cloud estate against an intended baseline, and triaging the differences by blast radius.

  • Exception lifecycle

    Time-boxed, approved, reviewed deviations from a control or guardrail — with expiry enforced so exceptions cannot silently become the baseline.

  • Preventive guardrails

    Controls that make an unsafe configuration impossible or short-lived — policy, paved-path modules, deny-by-default — rather than reporting it after the fact.

  • Security incident response

    Containing, eradicating and recovering from a confirmed intrusion using a rehearsed process with named decision authority.

  • Security telemetry coverage

    Knowing which assets emit which signals, and where the blind spots are, so detection gaps are a known quantity rather than a surprise.

Practices

  • Access review cadence

    A recurring, evidence-producing review of who holds which access, with removal as the default for unused entitlements.

  • Detection tuning review

    A recurring review of the detection funnel — signals, alerts, true positives — where rules that never fire truly are deleted rather than kept for comfort.

  • Guardrail exception review

    A standing review of live exceptions against their expiry dates, where renewal requires the original justification to still hold.

Metrics

  • Alert false-positive rate

    Share of raised alerts that turn out to be benign — the direct tax on the scarcest resource, analyst attention.

    Unit: percent. Good direction: down.

  • Critical misconfiguration exposure time

    How long a high-blast-radius misconfiguration, such as a publicly reachable data store, survives in the estate.

    Unit: hours. Good direction: down.

  • Expired exceptions in force

    Number of control or guardrail exceptions past their expiry date but still relied upon — the clearest signal that governance has stopped closing loops.

    Unit: count. Good direction: down.

  • Preventive control ratio

    Share of findings prevented by policy or paved path versus reported after the fact — the shift-left number that actually matters.

    Unit: percent. Good direction: up.

Tools

  • Checkov

    Static analysis for infrastructure as code, catching an unsafe configuration in review rather than in the estate.

    Visit site ↗

  • CloudQuery

    Extracts cloud and SaaS configuration into a database, giving compliance evidence and asset inventory a queryable source of truth.

    Visit site ↗

  • Open Policy Agent

    A general policy engine for expressing guardrails as code and enforcing them consistently across pipelines and clusters.

    Visit site ↗

  • Prowler

    Open-source cloud security assessment that checks an account against provider and CIS baselines and reports by severity.

    Visit site ↗

  • Steampipe

    Queries live cloud and SaaS configuration as SQL, which makes posture and evidence questions answerable without bespoke scripts.

    Visit site ↗

  • osquery

    Exposes operating-system state as SQL tables, which turns endpoint and host telemetry questions into queries.

    Visit site ↗

Architecture patterns

Reference architectures and their trade-offs live in the blueprints library.

Maturity

  1. L1 ReactiveAccounts and owners are enumerablerequired stage

    Every cloud account is inventoried with a named owner; nobody discovers an account during an incident.

  2. L2 RepeatableBaseline detections are enabled estate-widerequired stage

    Provider-native security services and a posture baseline run across all accounts, not only the production one.

  3. L3 StandardizedHigh-blast-radius misconfigurations are prevented

    The worst configurations are structurally impossible through policy or paved-path modules rather than reported after creation.

  4. L4 MeasuredIdentity is right-sized from observed use

    Unused permissions expire automatically after a reviewed grace period, and privileged roles are reviewed on a cadence.

  5. L5 OptimizedExposure time is measured and falling

    Time-to-remediate by severity is published to owning teams, drift from code is detected, and the finding backlog trend is flat or down.

Maturity for cloudsecops is measured, not guessed — every score traces to your answers. See how maturity is scored.

Put it to work

Assess your CloudSecOps maturity

Turn gaps into a roadmap

Generate a prioritized, effort-aware improvement plan from your results.

Grab the operating checklists

Repeatable checklists for the ceremonies this discipline runs.

Browse the runbooks

Step-by-step responses for when this area catches fire.

Related Ops disciplines

Sources