Controls & mapping
Preventive/detective/corrective, owned, mapped.
Controls are the atoms of compliance. Understanding how they are categorized, owned, and mapped is what lets you build one coherent control set instead of a tangle of per-framework requirements.
Preventive, detective, corrective — and owned
Controls fall into three types by how they act. Preventive controls stop a bad outcome from happening (an SCP that blocks public buckets, admission policy that rejects privileged pods). Detective controls spot it after the fact (a Config rule that flags a public bucket, an alert on a new admin role). Corrective controls fix or contain it (auto-remediation, an incident runbook). A mature program layers all three. Just as important, every control needs an owner — the team accountable for it operating effectively — because an unowned control is one nobody maintains, tests, or can attest to when an auditor asks.
# One requirement — "no public S3 buckets" — realized as all three types:## PREVENTIVE SCP / admission policy denies making a bucket public# DETECTIVE Config rule + CSPM flags any bucket that becomes public# CORRECTIVE auto-remediation re-applies BlockPublicAccess; IR if exploited## Owner: the platform team. Evidence: policy runs + Config compliance history.
Control mapping and the shared control set
The single biggest efficiency in compliance is control mapping: recognizing that one technical control satisfies requirements across multiple frameworks, so you maintain a shared control set rather than duplicating effort. Enforcing MFA, encrypting data at rest, centralizing audit logs, and running least-privilege access each map to a dozen requirements across SOC 2, PCI, ISO, and NIST simultaneously. You build and evidence the control once, and a mapping table connects it to every framework in scope. This is what makes "compliant with several frameworks" achievable without several times the work — and compliance as code is what keeps that shared control set enforced and evidenced automatically.