Compliance Frameworks & Master Cheat Sheet

Table of Contents#

1. Why SREs Need to Understand Compliance
2. Compliance vs Security — Not the Same Thing
3. SOC 2
4. ISO 27001
5. PCI-DSS
6. GDPR and HIPAA — A Quick Contrast
7. How DevSecOps Tooling Maps to Compliance Controls
8. Audit Evidence — What Auditors Actually Want
9. A Real-World Use Case: PCI-DSS for an E-Commerce Checkout
10. A Real-World Use Case: SOC 2 for a SaaS Startup
11. Master Cheat Sheet: Every Tool in This Series
12. Master Cheat Sheet: One-Line Commands
13. Master Cheat Sheet: STRIDE, OWASP Top 10, CAP/SLSA Quick Recall
14. Common Mistakes
15. Worked Practice Problems
16. Series Summary — The Complete DevSecOps Picture

---

Why SREs Need to Understand Compliance#

You don't need to be a compliance expert to work in SRE/DevSecOps — but you'll constantly work alongside compliance requirements, and interviewers regularly probe whether you understand how technical controls actually map to the compliance frameworks a business is legally or contractually obligated to meet.

Diagram

The simplest possible framing: compliance frameworks are essentially checklists that say "prove you're doing good security practices" — and everything covered in this DevSecOps series (scanning, least privilege, secrets management, supply chain integrity) is exactly the substance that satisfies those checklists. Compliance isn't a separate discipline bolted on top of DevSecOps — it's largely DevSecOps practices, formalized and audited.

---

Compliance vs Security — Not the Same Thing#

A genuinely important distinction, and a favorite "gotcha" framing in interviews.

Diagram

A strong, senior-level interview line: "Compliance and security overlap heavily but aren't identical — you can pass a compliance audit with checkbox-driven controls that don't meaningfully reduce real risk, and conversely you can be genuinely secure without ever pursuing a specific certification. I treat compliance requirements as a useful forcing function and a shared vocabulary with auditors/customers, but I design for actual security first, and compliance evidence falls out of doing that well — not the other way around."

---

SOC 2#

SOC 2 (System and Organization Controls 2) is the most commonly referenced compliance framework for B2B SaaS companies, especially in the US — an independent auditor's report confirming a company follows defined controls across some or all of five Trust Service Criteria.

Diagram

Type I vs Type II — A Commonly Tested Distinction#

Diagram

Interview-ready line: "Type I answers 'do the controls exist, on paper, right now?' Type II answers 'did they actually work, continuously, over the past 6-12 months?' — which is why most serious enterprise customers specifically require Type II, not Type I. This distinction matters practically because it changes what evidence engineering needs to continuously produce (ongoing logs and records, not a one-time snapshot)."

---

ISO 27001#

ISO 27001 is the dominant international information security management standard (much more globally recognized outside the US than SOC 2, which is more US-centric).

Diagram

The key conceptual difference from SOC 2 worth naming: SOC 2 is fundamentally "prove you follow a fixed set of trust criteria." ISO 27001 is fundamentally "prove you have an ongoing system for identifying and managing risk, and select/implement the specific controls that risk assessment says you need" — it's more process-and-risk-management-centric, rather than a fixed checklist.

---

PCI-DSS#

PCI-DSS (Payment Card Industry Data Security Standard) applies specifically to any organization that stores, processes, or transmits credit card data — this is the single compliance framework most directly and concretely tied to hands-on engineering practices, making it a favorite interview topic.

Diagram

A genuinely important, commonly-tested concept: network segmentation as a scope-reduction strategy. PCI-DSS compliance requirements apply to your entire "cardholder data environment" (CDE) — but a well-architected system can dramatically shrink how much of the infrastructure falls "in scope" by properly isolating (via network policies, from Part 3) the specific components that actually touch card data from everything else.

Diagram

A strong interview answer: "The single highest-leverage architectural decision for PCI-DSS compliance is network segmentation — isolating the components that actually touch cardholder data so that most of your infrastructure falls outside the compliance boundary entirely. This directly reuses the Kubernetes NetworkPolicy and least-privilege concepts from Part 3, applied specifically to reduce audit scope, not just to reduce security risk."

---

GDPR and HIPAA — A Quick Contrast#

Two more frameworks worth being able to distinguish at a glance, since they're commonly confused or conflated.

A great, concrete interview example for GDPR's "right to be forgotten": "If a user requests deletion under GDPR, that's not just a database row delete — it has to actually propagate to backups, logs, caches, analytics pipelines, and any downstream system that received a copy of that data. Designing for genuine, complete data deletion across a distributed system is a real, non-trivial engineering problem, not just a legal checkbox."

---

How DevSecOps Tooling Maps to Compliance Controls#

A single, consolidated table tying the entire five-part series back to compliance — genuinely useful to have memorized as a synthesis answer.

---

Audit Evidence — What Auditors Actually Want#

A genuinely practical, often-overlooked point: passing an audit isn't about doing the right things — it's about being able to prove, with evidence, that you did them, continuously, over time.

Diagram

A concrete, practical interview line: "A common gap teams hit isn't that the control doesn't exist — it's that nobody kept evidence it was actually followed. If your access review process isn't documented (who reviewed, when, what they found), an auditor has no way to confirm it happened even if it genuinely did. This is exactly why mature teams treat compliance evidence generation as an automated byproduct of good tooling — e.g., every RBAC change is already in version-controlled git history with an audit trail, rather than a manual, easy-to-forget process."

---

A Real-World Use Case: PCI-DSS for an E-Commerce Checkout#

A full, worked scenario tying everything together.

Diagram

The single strongest, most practical engineering lesson from this scenario: the cheapest way to comply with PCI-DSS is often architectural — avoid ever touching raw cardholder data in the first place (using tokenization via a PCI-compliant processor) — rather than trying to build and audit a fully PCI-compliant system yourself. This is a genuinely strong, senior-level answer to "how would you architect a compliant checkout flow."

---

A Real-World Use Case: SOC 2 for a SaaS Startup#

Diagram

Why this scenario is worth having ready: it demonstrates that pursuing a compliance certification is, in practice, largely a project of actually implementing the DevSecOps practices from Parts 1-5 of this series, then formalizing evidence collection around them — reinforcing the "compliance is largely DevSecOps, formalized" framing from the start of this tutorial.

---

Master Cheat Sheet: Every Tool in This Series#

A single consolidated reference table — genuinely useful both for interview prep and as a real, practical bookmark.

---

Master Cheat Sheet: One-Line Commands#

Copy
# --- SAST ---
semgrep --config=p/security-audit --error .

# --- SCA ---
npm audit --audit-level=high
pip-audit
snyk test

# --- Container image scanning ---
trivy image --exit-code 1 --severity CRITICAL,HIGH myapp:latest

# --- Secret scanning ---
gitleaks detect --source . --verbose
trufflehog git file://. --only-verified

# --- IaC scanning ---
tfsec .
checkov -d .

# --- SBOM generation ---
syft myapp:latest -o cyclonedx-json > sbom.json

# --- Artifact signing / verification ---
cosign sign myregistry.io/myapp:latest
cosign verify myregistry.io/myapp:latest

# --- Kubernetes RBAC auditing ---
kubectl auth can-i delete secrets --as=system:serviceaccount:ns:sa-name -n ns

# --- DAST (staging only, never production) ---
docker run -t zaproxy/zap-stable zap-baseline.py -t https://staging.example.com

---

Master Cheat Sheet: STRIDE, OWASP Top 10, CAP/SLSA Quick Recall#

Diagram

---

Common Mistakes#

---

Worked Practice Problems#

Problem 1: A startup wants to sell to enterprise customers who require SOC 2 Type II. They currently have decent security practices but no formal documentation or evidence trail. How long should they expect this to take, and why can't they get it faster?

Answer: SOC 2 Type II specifically requires demonstrating that controls operated effectively over a sustained observation period — typically 6-12 months — so there's no way to shortcut this with better documentation alone; the auditor needs to see evidence the controls were actually followed continuously over that real time window, not just designed correctly on day one. They could pursue a SOC 2 Type I report faster (a point-in-time design assessment) as an interim step, but most enterprise customers specifically require Type II for the stronger assurance it provides.

Problem 2: An e-commerce company is deciding whether to build their own PCI-DSS-compliant card storage system or use a third-party processor with tokenization. What's the strongest engineering argument for tokenization?

Answer: Tokenization means raw cardholder data never touches the company's own infrastructure at all — it flows directly from the customer's browser to the compliant processor, and the company's systems only ever handle a non-sensitive token. This dramatically shrinks the PCI-DSS compliance scope (often down to the simpler SAQ A self-assessment tier instead of the full standard), meaning far less infrastructure needs to meet the complete set of PCI controls, less audit surface area, and significantly less risk exposure if any other part of the system is ever compromised — since there's no actual card data present to steal in the first place.

Problem 3: During a SOC 2 audit, the auditor asks for evidence that access to production databases is reviewed quarterly. The team confirms they do this reliably every quarter, but has no records of it. What's the actual gap, and how would you fix it going forward?

Answer: The gap isn't the practice itself — it's the complete absence of evidence that the practice actually happened, which from an auditor's perspective is indistinguishable from the practice never having occurred at all. Fix: formalize the review as a documented, trackable process — e.g., a ticket created each quarter with the reviewer, date, and findings recorded, or better, an automated report generated from the actual RBAC/IAM configuration showing exactly who had access and confirming it was reviewed, stored somewhere durable and easily exportable for future audits.

---

Series Summary — The Complete DevSecOps Picture#

This closes out the full six-part DevSecOps series. The complete arc:

Diagram

The single most important takeaway to carry into an interview: DevSecOps is not a list of tools to memorize — it's a layered, defense-in-depth discipline where each layer (code, dependencies, containers, secrets, pipeline, compliance) catches what the layers before and after it structurally cannot. A strong candidate can walk through this entire pipeline end-to-end, naming the specific threat each stage addresses and the specific tool category that addresses it — exactly as demonstrated in the "Secure Pipeline Blueprint" diagram in Part 5.

See questions.md in this folder for the full interview question bank covering all six parts of this series.