When four frameworks apply to the same infrastructure, the instinct is to run four programmes. That is how you end up with four evidence collections, four sets of interviews and engineers who spend a quarter of the year answering questions.
Most of the underlying technical control is shared. Recognising which parts are shared, and being disciplined about the parts that are not, is most of the work.
What genuinely serves all four
Across the estate, these controls satisfied every regime with one implementation:
- Access control and least privilege, including how access is granted, reviewed and removed.
- Change management, meaning changes are reviewed, recorded and attributable to a person.
- Encryption in transit and at rest, with managed key rotation.
- Logging and monitoring sufficient to reconstruct what happened and when.
- Vulnerability management, with a defined path from discovery to remediation.
- Backup and recovery, tested rather than assumed.
If those are implemented once and implemented properly, you have covered the large majority of what any of the four will ask about. The remaining effort is evidencing them in each framework's vocabulary, which is a documentation exercise rather than an engineering one.
Where they genuinely differ
The divergences are few, specific, and where the real cost sits.
PCI DSS cares about scope in a way the others do not. The value is in shrinking the cardholder data environment so that most of your estate is out of scope entirely. That is an architectural decision, made early, and it does more for the cost of compliance than any control you can add later.
GDPR is about the data, not the system. It asks what personal data you hold, on what lawful basis, for how long, and whether you can locate and delete it for one individual. A perfectly secured system with no answer to those questions is compliant with nothing.
ISO 27001 wants a management system rather than a set of controls. Risk assessment, treatment decisions, internal audit, management review. You can have excellent security and fail this by not having the process wrapped around it.
SOC 2 is about evidence over a period. It is not enough that a control exists today; you must show it operated consistently across the observation window. This is the one that most rewards automated evidence collection, because manual collection over twelve months is where teams quietly fall behind.
Build to the strictest, with one caveat
The usual advice is to implement the strictest requirement everywhere and inherit the rest. That is right for controls whose cost does not scale with breadth: encryption, logging, access review.
Applying PCI-grade segmentation to the whole estate does not simplify compliance, it expands the scope you have to defend.
Where a requirement carries architectural cost, uniformity works against you. Segmentation is the clearest example: the point is to make most of the estate out of scope, and applying it everywhere achieves the opposite of what it is for.
Collect evidence once, automatically
The single highest-return investment was making evidence a byproduct of running the system. Access reviews generated from the identity provider, change records from the delivery pipeline, configuration state from the infrastructure code rather than from screenshots.
This turns audit preparation from a scramble into an export. It also removes the failure mode where a control was operating correctly but nobody kept proof, which is indistinguishable from the control not operating as far as an auditor is concerned.
One control set, four mappings
The structure that worked: a single internal set of controls, implemented once, with a mapping document per framework saying which of your controls satisfies which requirement.
Engineers work against one set of expectations. Auditors get an answer in their own language. When a fifth framework appears, it is a new mapping over mostly existing controls rather than another programme.
