SOC 2, HIPAA, CMMC: One Control Set, Three Audiences

Plenty of mid-market companies carry more than one compliance obligation at the same time. A healthcare software vendor selling into hospitals needs SOC 2 for its customers and HIPAA for the data. A manufacturer in the defense supply chain needs CMMC, and often SOC 2 as well because its commercial customers ask for it. Treated as three separate projects, that is three times the work, three sets of evidence, and three chances to burn out your team. Treated correctly, it is one strong control set presented to three different audiences.

This is the case for building once and attesting many. It starts with seeing what these frameworks actually share.

What each framework is really for

The frameworks feel different because they answer to different masters, not because the security underneath them is different.

• SOC 2 is built on the AICPA Trust Services Criteria. Its audience is your customers. It exists so a business buying your software can trust that you handle their data responsibly, and it is flexible by design: the security criteria are required, and you choose which additional criteria (availability, confidentiality, processing integrity, privacy) apply, with an auditor exercising judgment.
• HIPAA is federal law. Its Security Rule sets administrative, physical, and technical safeguards for electronic protected health information, and its audience is the government, specifically the HHS Office for Civil Rights, which enforces it. The data type, not the customer, triggers the obligation.
• CMMC is a contractual gate for the defense industrial base. Level 2 aligns to NIST SP 800-171, a set of 110 security requirements across 14 control families, and its audience is the Department of Defense. It protects controlled unclassified information, and unlike the other two, it can require a certification you pass before you are allowed to win the work.

Where they overlap, which is most of the way

Read the three side by side and the same controls appear in all of them, worded differently. Access control and least privilege. Multi-factor authentication and strong identity. Audit logging and monitoring. Risk assessment. Incident response. Encryption of data at rest and in transit. Configuration and change management. Security awareness training. Vendor and third-party oversight.

None of these is unique to healthcare, or to the defense supply chain, or to SaaS. They are the fundamentals of a competent security program. A company that enforces MFA, logs and reviews access, encrypts sensitive data, runs a real risk assessment, and can execute an incident-response plan has already done the substantive work that all three frameworks are asking about. What differs is the paperwork wrapped around that work.

Where they genuinely diverge

The overlap is large, but it is not total, and the differences are exactly where single-framework thinking gets teams in trouble.

• Scope. HIPAA cares only about protected health information. CMMC cares about controlled unclassified information and draws a boundary around the systems that touch it. SOC 2 covers whatever system you put in scope for your customers. The same control can be in scope for one framework and out of scope for another.
• Proof. SOC 2 produces an auditor's report over a review period. CMMC Level 2 can require a formal assessment and certification. HIPAA has no certificate at all: you are compliant until OCR investigates a complaint or a breach and decides otherwise.
• Rigidity. SOC 2 gives you and your auditor latitude. NIST 800-171 under CMMC is far more prescriptive: the 110 requirements are the 110 requirements. HIPAA sits in between, with some specifications required and others "addressable," which does not mean optional.

How to build once and satisfy all three

The move is to make your controls the source of truth and treat each framework as a different report drawn from it.

• Anchor to the strictest applicable framework. If you carry CMMC, its prescriptive requirements set a high floor that covers most of what SOC 2 and HIPAA want anyway. Build to the demanding standard once rather than to the loosest one three times.
• Maintain one control set, mapped many ways. Implement each control once and record which framework requirements it satisfies. A single MFA enforcement covers a SOC 2 criterion, a HIPAA technical safeguard, and a NIST 800-171 requirement at the same time.
• Collect evidence once. The proof that MFA is enforced is the same artifact regardless of who is asking. Gather it once and present it to each audience in the form they expect, rather than running three separate evidence hunts a year.
• Track the deltas deliberately. Keep a short list of the requirements that are genuinely framework-specific, the CMMC scoping boundary, the HIPAA-specific documentation, and manage those as the exceptions they are, not as three whole programs.

Done this way, a second or third framework is a mapping exercise and an evidence-formatting exercise, not a second or third security program. The team builds the controls that actually reduce risk, and the certifications become a byproduct of having done the real work rather than the reason for doing it.

If you are weighing which frameworks apply to you in the first place, our guide on ISO 27001 versus SOC 2 is a useful companion for the "which one, and why" question that comes before the crosswalk.

Frequently Asked Questions

Do SOC 2, HIPAA, and CMMC share the same controls?

Largely, yes. All three require the security fundamentals: access control, multi-factor authentication, audit logging, risk assessment, incident response, encryption, and vendor oversight. They differ mainly in scope, in how compliance is proven, and in how prescriptive the requirements are, not in the underlying security work.

If I have CMMC, am I close to SOC 2 and HIPAA?

You are a long way there. CMMC Level 2 aligns to NIST SP 800-171's 110 requirements, which is a demanding and prescriptive control set that covers most of what SOC 2 and HIPAA also ask for. Building to that floor once means the remaining work for the other frameworks is mostly scoping, documentation, and formatting evidence for a different audience.

Can one set of evidence satisfy multiple frameworks?

Yes. The artifact proving a control operates, for example a report showing MFA enforced on all administrative accounts, is the same regardless of which framework is asking. The efficient approach is to maintain one control set, map each control to the framework requirements it satisfies, and collect the evidence once.

What is the biggest mistake teams make with multiple frameworks?

Running them as separate projects. That triples the effort and creates conflicting evidence. The bigger mistake underneath it is ignoring the genuine differences, especially CMMC's scoping boundary and HIPAA's specific documentation, which do need dedicated attention even when the core controls overlap.