Compliance Isn't a Checklist. It's Someone Else's Threat Model, Borrowed.
Ask most engineering teams what a compliance requirement is for, and the honest answer is: nobody's entirely sure, but the audit needs it checked. Compliance gets treated as a tax - paperwork bolted onto a system that was designed without it in mind, satisfied with the minimum documentation that gets the checkbox ticked.
That framing is backwards, and it's expensive in a specific, predictable way.
Where the Requirement Actually Came From
A regulatory requirement CBN's data localization rules, PCI-DSS's segmentation requirements, GDPR's breach-notification windows didn't appear out of bureaucratic instinct. Somewhere behind it is an incident, or a class of incidents, that the regulator has already seen happen at scale, across many institutions, over years. The checklist is the compressed, generalized output of someone else's threat model built from failures you haven't personally lived through yet, but that your system is just as exposed to.
Treating that as paperwork means re-deriving, the hard way, a lesson the regulator already paid for on your behalf.
The Question That Actually Matters
If this requirement disappeared tomorrow, what specific failure would become possible again?
If an engineering team can't answer that for a given compliance control, they're implementing it as theater satisfying an auditor without closing the actual gap. And theater compliance has a specific failure mode: it passes the audit and fails in production, because the control was built to be inspected, not to work.
What Changes Once Compliance Is Read as a Threat Model
Data localization requirements stop being an annoying deployment constraint and start being a reasonable reaction to what happens when a foreign-hosted system becomes unreachable or subpoenable during a dispute your business didn't choose to be part of.
Segregation of duties stops being a bureaucratic approval chain and starts being a specific defense against the single-actor fraud pattern that shows up, repeatedly, in every post-mortem the requirement was built from.
Audit logging requirements stop being "logs we keep because we're told to" and start being the forensic record that determines whether an incident is a contained bug or an uncontained breach, six months from now, when someone finally asks "since when has this been happening?"
Each of these, read this way, becomes an engineering requirement with a clear rationale which means engineers can implement it well instead of implementing it minimally.
Where This Goes Wrong in Fast-Moving Markets
Startups building into regulated spaces fintech infrastructure, payments middleware, health data often meet compliance for the first time as an obstacle between them and a launch date, introduced by a regulator that feels disconnected from the product reality. That's a real tension, and pretending otherwise doesn't help anyone. But the teams that treat the requirement as adversarial paperwork end up building the control twice: once badly, to pass the audit, and once properly, after the incident the control was supposed to prevent actually happens.
The teams that read the requirement as a borrowed threat model build it once, and it holds.
The Decision, Not the Documentation
None of this requires an outside compliance consultant to translate every regulation into engineering language on day one - though it helps. What it requires is a standing habit: when a compliance requirement lands on an engineering team's desk, the first question is "what failure is this actually defending against," not "what's the minimum that satisfies it."
Get that habit right, and compliance work becomes engineering work with unusually good documentation of the failure mode it prevents. Skip it, and you're one incident away from finding out the checklist was right all along.
// keep going
Want this kind of thinking applied to your stack?
An appraisal is the fastest way to find out where your architecture is quietly costing you.