Compliance & governance
Every framework on this page is asking a version of the same question: can you prove, with evidence, that your controls actually work the way you say they do? This page maps the five frameworks a working DevSecOps engineer runs into most often — what each one covers and who needs it — then covers the shift from a once-a-year manual audit to "compliance as code," where evidence is collected continuously instead of reconstructed under deadline pressure. This is a conceptual map for engineers, not legal advice; scope and applicability calls still belong to your legal and compliance team.
An old-style compliance audit is like a fire marshal visiting your building once a year: they check that the extinguishers are charged and the exits aren't blocked, hand you a certificate, and leave. Nothing stops someone from wedging a fire door open the next morning — nobody will notice until next year's visit. Continuous compliance is swapping that annual walkthrough for smoke detectors wired into every room: they're checking the same things — is this exit still clear, is this extinguisher still charged — every minute of every day, and they scream the moment something drifts out of spec instead of waiting twelve months to find out.
Compliance is an engineering problem now
Compliance used to live entirely with legal and a compliance officer who ran a spreadsheet once a year. That model breaks down the moment your infrastructure is defined in code and your controls are enforced by pipelines instead of people, because the evidence an auditor wants — who has access to what, is encryption enabled, are vulnerability scans running, was that change reviewed — now lives in git history, IAM policies, and CI logs, not in a binder. A DevSecOps engineer doesn't own the legal interpretation of any framework below, but increasingly does own building and operating the systems that generate the proof an auditor accepts.
That's also why this topic sits in the same group as cloud security posture and policy as code rather than off in a separate legal track: the tooling is largely the same tooling, pointed at a slightly different question. A CSPM rule that flags a public S3 bucket is a security finding and, simultaneously, evidence against a specific audit control — the two are not separate systems doing separate work.
The five frameworks you'll actually meet
These aren't the only frameworks that exist, but they're the ones that show up repeatedly in B2B SaaS, healthcare, fintech, and any org selling into the EU:
| Framework | What it covers | Who typically needs it |
|---|---|---|
| SOC 2 | An AICPA audit of your controls against one or more Trust Services Criteria — Security (mandatory), plus any of Availability, Confidentiality, Processing Integrity, and Privacy you opt into. | B2B SaaS companies selling to enterprise customers who require a report before signing. |
| ISO 27001 | An international standard for an Information Security Management System (ISMS) — the process by which you identify risks and select controls, audited against the 93 Annex A controls in the 2022 revision. | Companies selling internationally, especially into EU/APAC enterprise and government buyers who treat it as the default bar. |
| PCI-DSS | Twelve requirements for protecting cardholder data (the primary account number and related fields) anywhere it's stored, processed, or transmitted. | Any organization that stores, processes, or transmits payment card data, mandated by the card brands via the PCI Security Standards Council. |
| HIPAA | US federal rules — the Privacy Rule and Security Rule — for protecting Protected Health Information (PHI), including required administrative, physical, and technical safeguards. | US healthcare providers, health plans, and clearinghouses ("covered entities"), plus any vendor handling PHI on their behalf ("business associates"). |
| GDPR | An EU regulation governing personal data of EU residents: lawful basis for processing, data subject rights, and mandatory breach notification. | Any organization processing EU residents' personal data, regardless of where the organization itself is located. |
A few distinctions worth having precise, because they change what "compliant" actually means in practice. SOC 2 comes in two report types: a Type I attests that controls were designed appropriately as of a single date; a Type II attests that those controls actually operated effectively over an observation window, typically 6-12 months — enterprise buyers almost always ask for Type II specifically, because Type I only proves a control existed on paper for one day. ISO 27001 certification runs on a three-year cycle with annual surveillance audits in between, so it's a standing commitment, not a one-time project. PCI-DSS applies a merchant-level system based on annual transaction volume that determines whether a self-administered Self-Assessment Questionnaire is enough or whether you need an on-site assessment from a Qualified Security Assessor — most engineering teams reduce this burden by keeping cardholder data out of their own systems entirely and tokenizing through a processor like Stripe. HIPAA has no formal "certification" to earn at all; there's no HIPAA-certified badge, only a Security Rule risk analysis and safeguards you implement and can be audited against by HHS's Office for Civil Rights, usually after a complaint or breach. GDPR gives individuals enforceable data subject rights — access, rectification, erasure ("right to be forgotten"), and portability — and requires notifying the relevant supervisory authority within 72 hours of becoming aware of a personal data breach, with fines that can reach 4% of global annual revenue or €20 million, whichever is greater.
A clean SOC 2 report or an ISO 27001 certificate is an attestation that specific controls existed and were followed during an audit period — it is not a guarantee that your systems are free of vulnerabilities. Auditors sample evidence and test control design and operation; they don't run a penetration test against your production stack as part of a standard SOC 2 engagement. Treating "we passed our audit" as equivalent to "we are secure" is a common and dangerous conflation — pair every compliance program with the actual security work covered elsewhere in this course, starting with what DevSecOps changes and SAST, DAST & SCA, not instead of it.
Compliance as code: continuous evidence collection
The core idea behind "compliance as code" is to stop treating evidence as something a human gathers under deadline pressure and start treating it as a byproduct of systems that already run continuously. This is the same policy-as-code idea covered on IaC security and policy as code — a rule like "no S3 bucket may be public" or "every EC2 instance must have disk encryption enabled" gets written once, as a machine-checkable policy (an OPA/Rego rule, a Sentinel policy, a custom Config rule), and then evaluated automatically on every infrastructure change and on a recurring schedule against everything already deployed. Each evaluation produces a timestamped pass/fail record. That record is the evidence — nobody has to remember to take a screenshot.
Platforms purpose-built for this — Vanta, Drata, Secureframe, and similar tools, covered in more detail on the tooling landscape page — connect via API to your cloud provider, identity provider, version control system, and HR system, and continuously pull the same category of signal a CSPM tool already collects: is MFA enforced org-wide, is encryption at rest enabled on every data store, are access reviews happening on schedule, did every production change go through code review. The insight worth internalizing is that a well-run CSPM and a well-run continuous-compliance program are frequently reading the exact same underlying signals for two different audiences — one for a security engineer's dashboard, one mapped against a specific framework's control list.
One control, implemented once in code, can satisfy several frameworks simultaneously if you maintain a mapping — a single "MFA is enforced for all privileged access" check can serve as evidence for a SOC 2 criterion, an ISO 27001 Annex A control, and a PCI-DSS requirement at the same time. Building five separate manual processes for five frameworks is redundant work; building one automated control and mapping it five ways is not.
Point-in-time audits vs. continuous monitoring
The older model — still the default at plenty of organizations — treats an audit as an annual event: weeks beforehand, someone compiles screenshots, exports access-review spreadsheets, and reconstructs six to twelve months of history to prove controls were followed, often called the "audit fire drill." It's expensive in engineering time, it's stressful, and it's structurally weak: a control that silently drifted out of compliance in month three — an engineer temporarily disabling MFA to debug something, a security group opened for a demo and never closed — can go completely unnoticed until the next audit surfaces it, if it surfaces at all.
Continuous evidence collection closes that gap on both ends. Operationally, the same automated checks that generate audit evidence also alert in near real time when a control drifts, so the MFA-disabled example above gets caught in hours, not eleven months later. And at audit time, instead of reconstructing history from memory and spreadsheets, you hand the auditor a continuous, timestamped stream of control evaluations they can sample directly — which is both a more credible evidence trail and dramatically less work to assemble. This is why continuous compliance is genuinely both more secure and less painful: the security benefit and the audit-effort benefit come from the same underlying change, not from a trade-off between them.
Where this fits in your pipeline
In practice, continuous compliance isn't a separate system bolted onto your infrastructure — it's a consumer of controls you're already running for security reasons. Policy-as-code gates in CI/CD that block a non-compliant Terraform plan from merging are also compliance evidence that the control was enforced at change time, not just at audit time. A CSPM continuously scanning your cloud accounts is also feeding a compliance platform's evidence stream. The practical checklist for standing this up — mapping controls to frameworks, wiring evidence collectors to your CI/CD and cloud accounts, and assigning an owner for each control — is covered in the working checklist for this course. The engineering lesson to take from all five frameworks above isn't "learn five separate audit processes" — it's "build controls once, as code, and let every framework you need read from the same evidence."
1. What's the practical difference between a SOC 2 Type I and Type II report, and which one do enterprise buyers usually insist on? 2. Which of the five frameworks applies purely because you handle payment card data, and who sets its requirements? 3. Under GDPR, how long do you have to notify the relevant supervisory authority after discovering a personal data breach? 4. Why does continuous evidence collection catch a problem like an accidentally-disabled MFA requirement faster than an annual audit would?
Check your answers
- A Type I report attests that controls were designed appropriately as of a single point in time; a Type II report attests that those controls actually operated effectively over an observation window, typically 6-12 months. Enterprise buyers usually insist on Type II because Type I only proves a control existed on paper for one day, not that it was actually followed.
- PCI-DSS, mandated by the card brands (Visa, Mastercard, Amex, Discover) through the PCI Security Standards Council — it applies to any organization that stores, processes, or transmits cardholder data.
- 72 hours from becoming aware of the breach.
- Because the same automated policy checks that generate compliance evidence run continuously and alert in near real time, so a drifted control is flagged within hours of the change, rather than sitting undetected until the next scheduled audit surfaces it up to a year later.