Compliance Frameworks
Externally defined control sets — SOC 2, ISO 27001, PCI DSS and others — whose architectural impact is scope, evidence and segmentation.
Definition
A compliance framework is a set of controls an organisation asserts it operates, verified by an auditor. The architectural questions are not "are we secure" but what is in scope, how is scope reduced, and how is evidence produced automatically.
The three things that matter architecturally
1. Scope reduction is the highest-value design move. Every system in scope must be controlled, evidenced and audited, and that cost is recurring. Segmenting so that only a small, well-defined portion handles regulated data can reduce the audit surface by an order of magnitude.
The canonical example is card data: tokenising at the edge so that card numbers never enter your systems removes most of the PCI DSS burden. The architecture decision — outsource card handling to a provider and store only tokens — is worth more than any number of controls applied to a larger scope.
2. Evidence must be automatic. Auditors want proof that a control operated throughout the period, not that it exists today. If evidence is gathered by screenshots and spreadsheets, compliance consumes engineering time every year forever. If access reviews, change approvals, vulnerability scans and backup tests emit structured evidence as a side effect of normal operation, the audit is an export.
This is the difference between compliance as a project and compliance as a property of the platform.
3. Controls belong in the platform, not in each team. Encryption, logging, access control, change management and backup should be provided by the paved road, so that using the standard deployment pipeline makes a service compliant by construction. Where each team implements controls independently, each team is separately audited and separately fails.
Where frameworks differ in architectural impact
| Framework | Dominant architectural implication |
|---|---|
| SOC 2 | Evidence of operating effectiveness over a period; change management and access review |
| ISO 27001 | A management system — risk assessment and treatment, documented and reviewed |
| PCI DSS | Segmentation and scope reduction around cardholder data |
| HIPAA | Access control, audit logging and encryption for health information |
| Sector rules | Residency, resilience testing, exit plans, regulator notification |
Failure scenarios
- Everything in scope because nothing was segmented.
- Evidence collected manually, so the audit is a quarter of engineering time.
- Controls documented but not enforced, discovered when a sample fails.
- A compliance boundary that does not match a technical boundary, so the assertion cannot be demonstrated.
- Treating certification as security. They overlap and are not the same thing.
Interview question
"How would you reduce PCI DSS scope for an e-commerce platform, and what does that cost you?"