The expensive mistake in compliance is not missing a requirement. It is treating each framework as a separate programme. Organisations end up running three overlapping projects, buying duplicate tooling, and producing three sets of documentation describing the same controls.
Almost every framework that applies to a small or midsize organisation is built on the same underlying control concepts. The work is largely shared. The evidence is largely shared. What differs is the wrapper.
What actually triggers each framework
| Framework | Triggered by | Who enforces it |
|---|---|---|
| FAR 52.204-21 | Essentially any federal contract | Contracting officer |
| NIST SP 800-171 / DFARS 7012 | Handling Controlled Unclassified Information | DoD, via DIBCAC audits |
| CMMC | DoD contracts, layered on NIST 800-171 | Third-party or government assessment |
| CJIS Security Policy | Any access to criminal justice information | State CJIS systems agency |
| HIPAA | Protected health information | HHS Office for Civil Rights |
| PCI DSS | Handling card payments | Your acquiring bank and the card brands |
| SOC 2 | Nobody. Customers ask for it | Your auditor, commercially |
That last row matters. SOC 2 is not a regulation. It is a commercial assurance report you commission because buyers want it. Treating it as a legal obligation leads organisations to pursue it before they need to.
Where the frameworks overlap
Certain controls appear in essentially every framework, and doing them once satisfies many requirements at once:
- Multi-factor authentication and access control — in all of them
- Logging and log review — in all of them, and the most commonly failed
- Encryption in transit and at rest — universal
- Vulnerability management and patching — universal
- Incident response with a tested plan — universal
- Access removal on departure — universal, and routinely broken
- Asset inventory — implied everywhere, formally required in most
If you are starting from close to nothing, implementing those seven properly gets you a long way into any framework you are later assessed against. That is the case for treating compliance as one programme.
How to sequence the work
- Inventory your data and its origin. What you hold, where it came from, and what obligation arrived with it.
- Identify only the frameworks actually triggered. In writing, with the contract or regulation cited. Do not add frameworks defensively.
- Build one control set covering the union of what applies, with the shared controls implemented once.
- Maintain one evidence library, tagged by framework, rather than separate document sets.
- Assess against the strictest applicable and map down to the others.
Step two is where consultants add or destroy the most value. A firm that adds frameworks you are not subject to has increased their scope and your cost without reducing your risk.
- Data and its origin trigger frameworks, not your industry.
- SOC 2 is commercial assurance, not a regulation. Do not treat it as mandatory.
- Seven controls appear in every framework. Do those once, properly.
- One control set and one evidence library, tagged by framework. Not three programmes.
What compliance consulting should include
Scoping, gap analysis against the applicable control set, a ranked remediation roadmap, technical implementation, documentation, and sustained governance. If a proposal stops at the roadmap, somebody still has to do the technical work — confirm who before you sign.
Compliance also decays. Staff leave, systems change, configurations drift. Whatever you build needs an owner and a review cycle, or you will re-do the assessment in two years and find yourself back where you started.
Where to go next
For the DoD side, see CMMC requirements explained and CMMC levels. For public sector, cybersecurity for local government covers CJIS scope. Our Navigate Compliance page covers the frameworks we govern in delivery.
Frequently asked questions
Which IT compliance framework applies to my organisation?
It depends on the data you hold and where it came from, not your industry. Federal contracts trigger FAR 52.204-21. Controlled Unclassified Information triggers NIST SP 800-171 and DFARS 252.204-7012. Criminal justice data triggers CJIS. Protected health information triggers HIPAA. Card payments trigger PCI DSS.
Is SOC 2 a legal requirement?
No. SOC 2 is a commercial assurance report you commission because customers ask for it, not a regulation enforced by anyone. Treating it as a legal obligation leads organisations to pursue it earlier and more expensively than they need to.
Do overlapping frameworks mean duplicate work?
They should not. Multi-factor authentication, access control, logging and log review, encryption, vulnerability management, incident response, access removal on departure and asset inventory appear in essentially every framework. Implement those once and maintain a single evidence library tagged by framework.
What should IT compliance consulting include?
Scoping, gap analysis against the applicable control set, a ranked remediation roadmap, technical implementation, documentation, and sustained governance. If a proposal stops at the roadmap, confirm who performs the technical work before signing.
Keep exploring
Ready for a clear path forward?
Start with a Navigate Clarity Conversation. A free 30 minute review of where you stand and what to do first.
Start with a Clarity Conversation