An engineer who builds a payment API to a genuinely high security bar can still fail a PCI DSS assessment, because a compliance standard is not the same thing as good security practice — it is a specific, auditable set of obligations an assessor checks against documented evidence, and an engineer's private confidence that the system is secure is not evidence an auditor can sign off on. The gap between "we built this carefully" and "we can demonstrate exactly how, with logs, policies and access records an outside party can independently verify" is where most compliance work actually lives, and it is a gap engineers who have only ever thought about security in technical terms consistently underestimate.
This lesson covers what an engineer actually has to build to support three of the standards an API handling payments, personal data, or enterprise customer data most commonly encounters — PCI DSS, GDPR, and SOC 2 — at the level of the concrete engineering obligation each one creates, not at the level of citing specific clause numbers or requirement identifiers. Every specific number, article reference, or control identifier mentioned in passing here should be treated as needing verification against the current published standard before it is relied on for an actual compliance program; standards are versioned, updated, and interpreted by auditors in ways a lesson written at one point in time cannot track, and getting a specific number wrong in front of an assessor is a credibility problem an engineer does not want to create for their own team.
Analogy🏏Cricket
🏏 Think of it like cricket: A domestic bowler with a genuinely legal, clean bowling action can still be reported for an illegal action if their club never submitted the biomechanical testing footage the governing body actually requires to certify it — the bowler being confident their action is fine is not the same thing as the bowler having the specific documented evidence a review panel needs to independently confirm it. A club that assumes a bowler's action is obviously legal because nobody in a hundred matches has ever complained about it, and never bothers with the formal testing process, is one bad-faith complaint away from a suspension the evidence trail could have prevented entirely. The testing process does not make the action more legal than it already was — the action's legality was never in question technically. What the testing process provides is a specific, standardized form of proof an outside panel can check without having to trust the bowler's, or the club's, own word for it. Just as a legal bowling action still needs the specific certified testing evidence a panel requires, a secure API still needs the specific documented evidence an auditor requires. Just as the biomechanical report is not a description of the action but a standardized, checkable artifact about it, a compliance control is not a description of good security practice but a standardized, checkable artifact about it. The insight is that compliance and security answer genuinely different questions — one asks whether a system is actually protected, the other asks whether that protection can be independently verified by someone who was not there when it was built — and an engineering team needs both, because a correct answer to only one of them still fails the review that asks the other.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.