One Control, Many Frameworks: The Case for Unified Control Architecture

Somewhere right now, a compliance analyst is maintaining a SOC 2 control spreadsheet. A second spreadsheet covers ISO 27001. A third covers CMMC. All three live in different folders, follow different naming conventions, and were built by different people who have since left the company.

Then the EU AI Act lands on the CISO's desk. Time to start spreadsheet number four.

The painful part isn't the new framework. It's the realization that about 60% of those controls overlap. The same intent, worded differently, scattered across four separate documents that don't talk to each other. Every quarterly review means reconciling the same control logic in four places. Every audit means collecting the same evidence four times.

This is the default operating model for most mid-market compliance teams. It doesn't scale. It never did.

Framework proliferation isn't slowing down

Let's count what's happened in the last 18 months. The EU AI Act entered enforcement. DORA went live for financial entities. PCI DSS v4.0.1 replaced v3.2.1 with 64 new requirements. CMMC moved from theoretical to contractual, with the DoD requiring certification for contract awards. States keep passing privacy laws. Regulators keep publishing guidance.

The pattern is clear: organizations are adding frameworks faster than they can hire people to manage them.

A typical mid-market company with government contracts, healthcare data, and payment processing now answers to five or six frameworks simultaneously. Each framework has its own control taxonomy, its own language, its own evidence expectations. The traditional approach (one spreadsheet per framework, one analyst per spreadsheet) breaks at three frameworks. At five, it's a staffing crisis disguised as a compliance problem.

The question isn't whether you need to support multiple frameworks. You already do. The question is whether your control architecture treats them as isolated silos or as a connected system.

The overlap nobody quantifies

Take a concrete example. You enforce multi-factor authentication through an Entra ID Conditional Access policy. That single technical control satisfies requirements in every framework you answer to, but each framework calls it something different:

Seven frameworks. One policy. One piece of evidence. But if your GRC tool stores controls in separate tables per framework (and most do), you're collecting that Conditional Access policy configuration seven times, reviewing it in seven separate control assessments, and presenting it to auditors in seven different packages.

That's not compliance rigor. That's wasted motion. We walk through this exact scenario in detail in One Defender Alert, Seven Frameworks.

What a meta-framework actually is

The concept isn't new. The Secure Controls Framework (SCF) has been mapping control relationships across regulatory frameworks for years. What's new is taking meta-framework thinking seriously as an architectural principle rather than treating it as a reference PDF you download and never open.

SCF defines 1,470+ controls that span 80+ frameworks. Each SCF control represents a distinct compliance intent. Each framework requirement maps to one or more SCF controls. The mapping isn't approximate, it's structural. When SOC 2's CC6.1 and ISO 27001's A.9.4.2 both map to the same SCF control, that's a statement about semantic equivalence, not a loose association.

This matters because it transforms framework management from a per-framework staffing problem into a graph problem. You don't maintain separate control libraries. You maintain one authoritative registry where each control has typed, scored relationships to every framework it satisfies.

Add a new framework? You don't start from scratch. You map its requirements to existing SCF controls. Where mappings exist (and for most operational frameworks, 40-70% of requirements map to controls you already manage), your existing evidence and assessment history carries forward automatically.

That's not aspirational. It's mathematical.

Relationship semantics matter more than mapping counts

Here's where most multi-framework tools fall short. They'll tell you they "support" SOC 2 and ISO 27001. They'll even show you both frameworks in the same dashboard. But supporting a framework and reasoning across frameworks are fundamentally different capabilities.

The relationship between SOC 2 CC6.1 and ISO 27001 A.9.4.2 isn't binary. It's not just "related" or "not related." The relationship has a type (equivalent, subset, superset, partial overlap) and a strength (how much evidence collected for one actually satisfies the other). Getting this wrong means either over-crediting (assuming full satisfaction when only partial overlap exists) or under-crediting (re-collecting evidence that's already sufficient).

NIST IR 8477 formalizes this with Set Theory Relationship Mapping (STRM). STRM defines five relationship types between control requirements:

• Equivalent: The requirements are semantically identical. Evidence for one fully satisfies the other.
• Subset: Requirement A is fully contained within Requirement B. Satisfying B automatically satisfies A, but not the reverse.
• Superset: The inverse of subset. Requirement A fully contains Requirement B.
• Overlap: The requirements share some common ground but each has unique elements. Evidence may partially satisfy both, with gaps.
• Disjoint: No meaningful relationship. Common in framework pairs that address different domains entirely.

Most GRC tools treat cross-framework mapping as a flat lookup table: Control A "relates to" Control B. No type. No strength. No directionality. That's a contact list, not a knowledge graph.

The difference between a lookup table and a knowledge graph

Consider what happens when you get a new Defender for Cloud compliance signal. In a traditional GRC tool, an analyst manually maps that signal to a specific control in a specific framework. If the organization answers to seven frameworks, someone has to make that mapping decision seven times (or, more realistically, makes it once for the primary framework and forgets the other six).

In a unified control architecture built on a knowledge graph, the signal enters the system once. The Compliance Graph knows which SCF control that signal attests to. STRM relationships connect that SCF control to every framework requirement it satisfies, with typed and strength-rated edges. The Continuous Multi-Framework Control Assessment Engine (CMCAE) evaluates the signal against all applicable controls simultaneously.

One signal in. Seven framework assessments updated. No analyst in the loop for the mapping decision, because the mapping is structural, not manual.

This is what "define once, attest everywhere" means in practice. It's not a tagline. It's an architecture.

How Kyudo implements unified control architecture

Kyudo's Controls Hub serves as the authoritative control registry. Every control lives in one place, scored 0-100, with explicit relationships to every framework it satisfies. There are no shadow spreadsheets, no per-framework copies, no reconciliation exercises.

Here's how the pieces fit together:

Controls Hub: The single source of truth. 1,470+ controls mapped across 80+ frameworks. Each control has a maturity score (five levels: Documented, Implemented, Operating, Proven, Optimized), a completeness score, and a freshness indicator. You manage controls once. The framework mappings are properties of the control, not separate objects.

STRM Engine: Mathematical relationship mapping per NIST IR 8477. Every cross-framework relationship has a type and a strength rating. When you ask "does my ISO 27001 evidence satisfy this CMMC requirement?", the STRM Engine gives you a precise answer, not a guess.

CMCAE (Continuous Multi-Framework Control Assessment Engine): When new evidence enters the system (a Defender alert, an Azure Policy compliance state, an Entra configuration snapshot), CMCAE evaluates it against all applicable controls across all active frameworks simultaneously. A single evidence artifact can attest against multiple frameworks in one assessment event.

Compliance Graph: The knowledge graph connecting controls, evidence, risks, policies, frameworks, and vendors. Every relationship is typed and traversable. An auditor can trace from a framework requirement to its mapped control, to the evidence that satisfies it, to the source system that produced that evidence, in a single query.

The result: when you add a new framework (say your board decides you need ISO 42001 for AI governance), you don't start a new project. You activate the framework mapping in Controls Hub. Existing controls that map to ISO 42001 requirements inherit their current evidence and assessment status. CMCAE identifies which requirements are already covered and which have gaps. Your compliance team focuses on the gaps, not on re-documenting what's already proven.

"We already have a multi-framework GRC tool"

Fair. Most enterprise GRC platforms advertise multi-framework support. The question is what "support" means.

Open your current tool. Navigate to your SOC 2 control for access management. Now navigate to your ISO 27001 control for access management. Are they the same object or two different objects? If you update the evidence on one, does the other know? If you mark one as "operating," does the other reflect that?

In most tools, the answer is no. Multi-framework "support" means the vendor loaded both framework templates into the system. Each framework lives in its own table. Each control is a separate row. The mapping between them (if it exists at all) is a static reference field that nobody maintains.

That's not unified control architecture. That's two spreadsheets in one database. This is part of why legacy GRC is structurally failing.

The test is simple: when a single piece of evidence satisfies controls across three frameworks, does your tool store it once and propagate the assessment, or does it require three separate evidence uploads and three separate reviews? If it's the latter, your tool lists frameworks. It doesn't reason across them.

What this means for audit readiness

Kyudo defines audit readiness as 90%+ of controls at Maturity Level 3 (Operating) or above. Level 3 means signals are flowing, monitoring is active, and the control isn't just documented but demonstrably working. Below Level 3, you're relying on documentation that may or may not reflect reality.

In a unified control architecture, audit readiness isn't measured per framework. It's measured across the control registry. If a control is operating at Level 3 for ISO 27001, it's operating at Level 3 for every framework that maps to it. Your SOC 2 audit prep doesn't start with "which controls need evidence." It starts with "which controls have dropped below Level 3 since last quarter," and the answer is the same regardless of which auditor is asking.

Evidence freshness reinforces this. Every evidence artifact in Kyudo has a freshness score: green (collected within 7 days), yellow (8-30 days, aging), red (over 30 days, stale, no credit). Stale evidence gets no credit in any framework assessment. This isn't a policy choice, it's a scoring rule. When evidence ages out, every control it attests to across every framework reflects the gap simultaneously.

No more discovering in week two of audit prep that your SOC 2 evidence is current but your ISO 27001 evidence for the same control expired three months ago. They're the same evidence. One freshness score. One status.

The math on framework expansion

Let's put numbers to this. A mid-market company answering to three frameworks with 200 controls each manages 600 control assessments per year. Add a fourth framework (another 200 controls), and the traditional model adds 200 more assessments, bringing the total to 800. Linear scaling. Every new framework adds proportional work.

With unified control architecture and a 60% overlap rate, those four frameworks map to roughly 320 unique SCF controls (not 800). Adding the fourth framework doesn't add 200 assessments, it adds the 80 controls that are genuinely new (40% of 200). That's a 60% reduction in marginal work per additional framework.

At five frameworks, the math gets even better. Overlap compounds. The fifth framework's 200 requirements might only add 50 net new controls, because the common operational controls (access management, logging, encryption, incident response, change management) are already covered by the first four.

This is why unified control architecture isn't just an efficiency play. It's the only model that lets compliance teams absorb new regulatory requirements without proportional headcount growth.

Maturity scoring across frameworks

Kyudo scores every control 0-100 across five maturity levels:

• Level 1 (Documented): A policy exists but isn't enforced. Gets minimal credit. An auditor will note the policy but flag the lack of operational evidence.
• Level 2 (Implemented): The control is deployed but not yet consistently monitored. Better than documented, but gaps are likely.
• Level 3 (Operating): Signals are flowing. Monitoring is active. This is the audit minimum. Most frameworks require demonstrated operation, not just implementation.
• Level 4 (Proven): Tested and validated through exercises, incidents, or formal assessments. Evidence of effectiveness, not just existence.
• Level 5 (Optimized): Continuously improving based on metrics and feedback. Few controls reach this level, and that's fine.

Because maturity is measured at the control level (not the framework level), a control's maturity score applies everywhere it maps. You don't have a Level 3 MFA control for SOC 2 and a Level 1 MFA control for CMMC. You have a Level 3 MFA control. Period.

This eliminates the common failure mode where a compliance team invests heavily in one framework's controls while neglecting the overlapping controls for another framework. In Kyudo, investing in a control invests in every framework it serves.

Two layers of trust

A reasonable concern with automated cross-framework mapping: how do you trust that the system got the mapping right?

Kyudo separates this into two layers. Layer 1 is deterministic: scoring, validation, crosswalk calculations, and evidence matching all use rule-based logic. Same input, same output, every time. No AI in the path. When STRM says two controls have an "equivalent" relationship with 95% strength, that's a mathematical assertion based on defined criteria, not an LLM's opinion.

Layer 2 is advisory: natural language summaries, policy drafting suggestions, and gap analysis narratives use AI, but every output includes confidence scores and citations back to specific Compliance Graph nodes. An analyst can trace any AI-generated recommendation to the underlying data. If the AI says "this Defender signal partially satisfies HIPAA 164.312(d)," the citation shows exactly which STRM relationship and which evidence attributes support that statement.

The deterministic layer handles the decisions. The advisory layer handles the explanations. You don't have to trust a language model to trust your compliance posture.

Your Monday morning checklist

If you're maintaining separate control libraries per framework, here's where to start:

1. Inventory your overlap. Pull your SOC 2 and ISO 27001 control lists side by side. Count the controls that address the same intent (access management, logging, encryption, incident response, change management, vendor management). If you find less than 40% overlap, look again. You missed some.

2. Identify your reconciliation cost. How many hours per quarter does your team spend reconciling control status across frameworks? How many times has an auditor found inconsistencies between your SOC 2 and ISO 27001 evidence for the same control? That's the cost of siloed architecture.

3. Test your current tool's cross-framework reasoning. Upload one piece of evidence and see if it propagates across framework assessments automatically. If it doesn't, you're running parallel compliance programs, not a unified one.

4. Map your framework expansion timeline. Which frameworks are you adding in the next 12 months? EU AI Act? CMMC? DORA? Each one multiplies your current workload under the siloed model. Under unified control architecture, each one adds only the delta.

5. Assess your maturity distribution. What percentage of your controls are at Maturity Level 3 (Operating) or above? If it's below 90%, you're not audit-ready regardless of how many frameworks you support.

Readiness is not an audit activity. It is an operating discipline.

---

Kyudo's Controls Hub maps 1,470+ controls across 80+ frameworks using STRM relationship semantics. One control registry. One evidence pipeline. Every framework.

Book a demo to see unified control architecture in your Azure tenant.