Compliance frameworks an engineer actually encounters: SOC 2, ISO 27001, and PCI-DSS

Every framework in this lesson works the same basic way: an organization implements a defined set of security controls, and an independent third-party auditor examines evidence that those controls are genuinely in place and actually being followed — not just documented on paper. None of these frameworks invent new security techniques; each is a structured way of requiring and verifying the practices this whole curriculum has already covered, consistently.

SOC 2 is an audit report (not a certification in the strict sense) confirming an organization's controls around security, availability, processing integrity, confidentiality, and privacy — organized around five "trust service criteria." A typical enterprise customer evaluating a SaaS vendor asks for a current SOC 2 report specifically because it's the industry-standard way of getting real assurance about a vendor's security practices without auditing that vendor's infrastructure themselves. For an engineer, SOC 2 evidence requests translate directly into things this domain and Web Security have already covered concretely: access logs proving least-privilege access control, evidence of a working incident-response process, proof that code changes go through actual review before deployment.

ISO 27001 certifies an organization's entire information security management system (ISMS) — the ongoing process of identifying risks, choosing controls to address them, and continuously reviewing whether those controls are still working, rather than one fixed checklist of specific technical requirements. It's broader in scope than SOC 2 (covering organizational policy and risk-management process, not just technical controls) and is more commonly required by customers and partners outside the US, particularly across Europe and Asia. For most day-to-day engineering purposes, the controls an ISO 27001 program actually asks for overlap heavily with SOC 2's — the real distinguishing factor is how the certification process itself works and which audiences recognize it.

PCI-DSS (Payment Card Industry Data Security Standard) is fundamentally different from the previous two in one important way: it's not optional or customer-requested, it's contractually required by the payment card networks (Visa, Mastercard, etc.) for any organization that stores, processes, or transmits cardholder data at all. Payments & Financial Systems' own domain already established the practical escape hatch most real products use — letting a payment processor's hosted fields or tokenization handle raw card numbers directly, so the application itself never touches unencrypted card data and falls into a dramatically smaller PCI-DSS compliance scope than one that does.

An engineer building a payment flow who doesn't understand this distinction can accidentally expand an entire company's compliance scope dramatically — by, for instance, logging a raw card number during debugging, or building a custom card-entry form that passes raw numbers through the application's own backend instead of directly to the processor — turning what should be a narrow, simple compliance boundary into a sprawling one covering systems that never needed to be in scope at all.

None of these frameworks requires inventing anything beyond what this curriculum has already covered — access control, secrets management, logging and monitoring, secure code review, incident response, data minimization. The actual skill worth having is recognizing, the moment a compliance requirement or an audit evidence request comes up, which existing technical practice it's actually asking to verify, rather than treating "compliance" as an entirely separate, unfamiliar category of work handled by someone else.