CMMC, SOC 2, ISO 27001: Why Multi-Framework Compliance Is Getting Harder

The main challenge isn’t just that there are more frameworks. Now, each framework updates on its own schedule, and none of them coordinate with each other.

Five frameworks, five release calendars, no changelog

On 13 July 2026, the Department of War suspended CMMC Phase II, which had been scheduled to start appearing in contracts on 10 November 2026, along with the third-party assessment requirements that came with it. Phase I self-assessment obligations stayed exactly where they were. If you had budgeted for a C3PAO assessment this year, that line item is now indefinite. If you had told a defense-adjacent client they needed certification by November, you get to make a second call.

CTOs will see this as a dependency management issue. You have five external dependencies, each updated by different groups on their own timelines. There’s no shared changelog or clear way to track what’s outdated. One framework even released a major update at the last minute. Your compliance team has to manage all this without a central tracking tool.

That’s the real reason multi-framework compliance is tougher now, even if vendors don’t say it. People often blame the growing number of frameworks, but that’s only increased a little. MSPs working with healthcare, finance, and defense have managed several standards for years. What’s changed is how often the frameworks update. Each version change means redoing work and collecting new evidence, which drives up costs.

Adding a new framework is a one-time expense. But each time a framework changes its version, you face new costs, and these are rarely planned for.

What actually changed in the last twenty-four months

If you put all the changes on one timeline, it’s much easier to see how quickly things are moving than when you’re dealing with them one by one.

In just two years, five standards have seen six major changes, each on its own schedule. Two of these happened after organizations had already set their budgets and told clients what to expect. None of the changes were announced in a way your compliance lead would usually notice, because there isn’t a standard channel for these updates.

It’s important to realize that changes don’t always make things stricter. PCI DSS and ISO 27001 did get tougher as expected, but CMMC actually relaxed its requirements without warning. If you always assume requirements will get stricter, you might waste time and money. Some organizations worked hard for CMMC certification, only to see the process change again.

Controls converge. Evidence does not

This next point often surprises people who have only reviewed the control catalogs.

At the control layer, these frameworks agree far more than they differ. Access control, encryption, logging, change management, incident response, vendor risk, training. Implement multi-factor authentication properly, and you have moved the needle on SOC 2, ISO 27001, CMMC, PCI DSS, and HIPAA at once. That convergence is real; it is the basis of common control frameworks, and we have written separately about how cross-framework control mapping works in practice.

But everything after the control itself doesn’t match up. You might have the same safeguard, but you’ll need five different types of proof, five different assessors, and five different timelines.

So, even though the MFA rollout meets all five frameworks, the proof you need for each one is different. SOC 2 needs evidence from a specific time period, so a screenshot from today won’t work for a period that ended in March. ISO wants the ISMS record showing the decision, review, and audit. PCI needs a QSA to validate within your defined scope. CMMC requires a score and a named official to sign off, which is a different kind of signature under the False Claims Act. HIPAA doesn’t ask for proof until something goes wrong, and then it wants everything.

You might have one control, but you still need five different proofs. The mapping issue is mostly solved, but the evidence problem is still there.

The scope problem nobody maps

Underneath the evidence problem is something even harder to standardize: what each framework actually covers.

PCI DSS scopes to the cardholder data environment and anything that can affect its security. HIPAA scopes to electronic protected health information wherever it lives. CMMC scopes to controlled unclassified information. ISO 27001 scopes to whatever you declared in your ISMS scope statement, which is a document you wrote. SOC 2 scopes to the system description, which is also a document you wrote. Five different scoping logics applied to one set of infrastructure, two of them defined by you and three of them defined for you.

In practice, a control might be fully compliant under one framework but not even apply under another. For example, segmenting a network to keep a server out of PCI scope doesn’t remove it from HIPAA scope if it holds ePHI. Teams often find this out when a new framework is added, and the mapping they thought was complete actually covers a different set of systems.

This is why saying “we are already SOC 2 compliant” isn’t as strong as it sounds. It just means certain controls worked during a specific period, within a system description your organization wrote. It doesn’t guarantee that the boundaries match what your client needs.

Scope is another hidden reason why framework updates cost more than expected. For example, when ISO 27001 moved from the 2013 to the 2022 edition, Annex A changed from 114 controls in 14 domains to 93 controls in 4 themes. The security expectations stayed about the same, but the structure changed. This meant every statement of applicability, mapping table, and piece of evidence had to be updated. Even if there are no new requirements, a revision can still take months, and budget owners will want an explanation.

Why this compounds for a provider

All of this describes just one organization managing its own compliance. For an MSP or MSSP handling a whole portfolio, the math gets even tougher.

1. Version changes multiply by the number of clients, not just the number of frameworks. When ISO 27001:2013 expired, every client certified under it had to transition on their own schedule. One change in the standard turned into twenty separate projects.
2. You also take on the job of communicating changes. Someone has to tell each defense client that the CMMC assessment they planned for is now suspended, explain what still applies, and do it without making the previous advice seem wrong. This conversation happens with every affected client, and you can’t bill for it.
3. Most clients need more than one framework. For example, healthcare clients who process card payments need both HIPAA and PCI DSS. A defense subcontractor working with enterprises needs CMMC and SOC 2. Each combination creates its own overlap, which is where duplicated work happens.
4. Your own compliance status matters too. If you have a SOC 2 report while managing clients under four other standards, you’re both a subject and an administrator of compliance, each on different schedules.

Here’s an example. A twenty-client MSP has eight clients on ISO 27001, six on SOC 2, four on HIPAA, and three on PCI DSS, with some overlap. When the ISO transition deadline arrives, all eight ISO clients need to transition, each on their own certification date and with different certification bodies. Annex A has changed from 114 controls to 93 across four themes. If each program was built separately, that’s eight restructuring projects. If they were built as views over one control set, it’s just one remap and eight confirmations. The difference isn’t just about efficiency; it’s about whether the work can be finished in a year.

This isn’t a reason to do less work. It’s a reason to stop treating the framework as the main unit of work, since frameworks are what keep changing.

What holds up under version churn

Three architectural choices survive a framework revision. Everything else gets redone.

• First, use a control-first structure, treating frameworks as views over a single control set. Keep one set of controls for the organization, and let each standard select from it. When a framework updates, you just remap the view instead of rebuilding everything. When a client adds a new standard, you only need to find the gaps, not start from scratch. We explain how to do this in our article on cross-framework control mapping.
• Second, collect evidence with clear lineage, and do it continuously. Evidence should show what it proves, when it was valid, and which control it supports. Collecting evidence at a single point in time doesn’t work for SOC 2’s observation window or for HIPAA’s retrospective checks, since you can’t recreate past data. Automated collection from source systems is the only way this works across a portfolio.
• Third, define the scope once for each client and keep it versioned. Document what assets you have, where regulated data is stored, and where each framework’s boundaries are. Keep this under change control. When a framework updates its scope rules, you can compare the changes instead of starting over.

The key point is that all three strategies separate your work from any one framework’s release schedule. You can’t force standards bodies to coordinate, but you can stop building your program as if they will.

Where Regentra fits

There is one control set, with nine frameworks acting as views over it.

Regentra’s compliance engine is built control-first. The Common Control Framework holds a single implementation of each control. It maps it across every standard it satisfies, so nine frameworks share one control set rather than nine parallel programs. HIPAA, SOC 2, NIST CSF 2.0, ISO 27001:2022, CMMC 2.0, PCI DSS 4.0.1, GDPR, FTC Safeguards, and the proposed HIPAA 2026 update, with the proposal labeled as proposed so nobody mistakes it for an obligation.

Evidence is collected continuously from Microsoft Entra ID, AWS, and GCP, not just in the two weeks before an assessment. This makes it possible to have solid evidence for observation windows. Since each client is an isolated tenant, you can apply framework changes across the whole portfolio from one place, instead of updating twenty spreadsheets for twenty certification cycles.

New frameworks are added to the platform at no extra cost. This is more important than it seems when six major changes happen in just two years.

Sources

• U.S. Department of War, “Forging the Arsenal of Freedom: Department of War Suspends CMMC Phase II Requirements,” 13 July 2026, and DoW CIO memorandum 26-P-1023 — Phase II and associated third-party assessment requirements suspended; Phase I self-assessment requirements remain in force. war.gov
• U.S. Department of Defense, CMMC Program, 32 CFR Part 170; acquisition rule effective 10 November 2025 commencing Phase 1.
• PCI Security Standards Council, PCI DSS v4.0.1 — 51 future-dated requirements from v4.0 became mandatory and subject to validation in all assessments from 31 March 2025.
• ISO/IEC 27001:2022 — three-year transition from the 2013 version closed 31 October 2025; 2013 certificates expired or withdrawn at that date. Annex A restructured from 114 controls across 14 domains (2013) to 93 controls across 4 themes (2022).
• NIST, Cybersecurity Framework 2.0, February 2024 — Govern (GV) added as a sixth core function.
• HHS Office for Civil Rights, HIPAA Security Rule Notice of Proposed Rulemaking (RIN 0945-AA22), 6 January 2025 — proposed, not finalized; moved to the Unified Agenda long-term actions list with anticipated final action July 2027.
• AICPA, SOC 2 Type II reporting — operating effectiveness tested across an observation period, commonly three to twelve months, with the auditor sampling from a population of dated artifacts.

Frequently asked questions

Related reading

• Understanding cross-framework control mapping
• Point-in-time audit prep vs continuous audit readiness
• Audit readiness reporting

Next step: See how frameworks map together →

‍