One Defender Alert, Seven Frameworks: Cross-Mapping in Practice

Picture this. A compliance analyst opens a browser with seven tabs. Tab one: SOC 2 control spreadsheet. Tab two: ISO 27001 Annex A tracker. Tab three: NIST CSF mapping document. Tab four: CMMC assessment worksheet. Tab five: PCI DSS v4.0.1 requirements. Tab six: HIPAA Security Rule evidence log. Tab seven: EU AI Act compliance register.

She's looking at the same Defender for Cloud baseline compliance finding in all seven tabs. The finding says the same thing in every tab: a security baseline configuration meets the expected standard. But she needs to document it seven times, in seven formats, with seven different control references.

Same signal. Same evidence. Seven times the work.

This is what cross-framework compliance looks like without relationship mapping. And it's how most organizations operate today.

The signal

Let's get specific. Defender for Cloud continuously evaluates resources against security baselines. When a baseline assessment completes, it produces a compliance signal: a structured finding that says whether a specific resource configuration meets the requirement.

Take a concrete example: Defender for Cloud evaluates your Azure subscription's identity configuration and finds that MFA is enforced for all privileged accounts via Entra ID Conditional Access. The compliance signal includes the resource scope, the policy definition, the compliance state, and the evaluation timestamp.

That's one signal. One data point. One piece of evidence.

Now let's trace where that single signal matters across seven frameworks.

The mapping

Notice the variation. The STRM relationship isn't the same for every framework. CMMC and ISO 27001 map as equivalent, meaning the Defender signal fully satisfies the requirement. PCI DSS maps as overlap at 78% strength because PCI has additional requirements specific to the cardholder data environment that a general MFA policy doesn't fully address. EU AI Act maps as overlap at 72% because its access control requirements are specific to AI system components, not general infrastructure.

This granularity is the point. A flat "yes, this maps" would over-credit some frameworks and under-credit others. Typed, strength-rated relationships tell you exactly where you have full coverage and where you have gaps to close.

What happens in a traditional GRC tool

The analyst in our seven-tab scenario does roughly this:

1. Takes a screenshot of the Defender for Cloud finding (or exports a PDF).
2. Opens the SOC 2 evidence tracker. Uploads the screenshot. Maps it to CC6.1. Writes a note explaining why this satisfies the control. Marks it "collected."
3. Opens the ISO 27001 tracker. Uploads the same screenshot. Maps it to A.8.5. Writes a slightly different note because the control language is different. Marks it "collected."
4. Repeats for CMMC, PCI DSS, HIPAA, GLBA, and EU AI Act.
5. Each framework assessment reviews the evidence independently. Five of the seven reviewers look at the same screenshot and make the same "satisfies/doesn't satisfy" determination independently.

Total time: 2-4 hours for one signal across seven frameworks. And this is a simple case, one finding, one control per framework. A typical audit involves hundreds of evidence items across dozens of controls.

Multiply that by the number of Defender findings, Sentinel alerts, Purview classifications, and Azure Policy compliance states that matter for compliance. The work isn't hard. It's just absurdly repetitive.

What happens in Kyudo

The same signal flows through a fundamentally different process.

Step 1: Ingestion. Kyudo's integration with Microsoft Defender for Cloud pulls the baseline compliance signal automatically via API. No screenshot. No export. No analyst. The raw signal (JSON structure with resource details, compliance state, policy reference, and evaluation timestamp) enters the Evidence Hub.

Step 2: Hashing and provenance. The Evidence Hub computes a SHA-256 hash of the raw signal, records the collection timestamp, source API endpoint, and tenant context. The evidence artifact is now tamper-evident with full provenance.

Step 3: Control mapping. The Compliance Graph knows which SCF control this Defender signal attests to. The STRM Engine has pre-computed the relationships between that SCF control and every framework requirement across all active frameworks.

Step 4: CMCAE assessment. The Continuous Multi-Framework Control Assessment Engine evaluates the signal against all seven framework controls simultaneously. It doesn't just check "maps/doesn't map." It evaluates the signal's content against each requirement's specific criteria, weighted by the STRM relationship strength.

For the equivalent relationships (CMMC AC.L2-3.1.1 at 95%, ISO 27001 A.8.5 at 92%, GLBA 314.4(c)(5) at 88%), the signal receives full or near-full credit. The evidence directly demonstrates what the control requires.

For the overlap relationships (PCI DSS 8.4.2 at 78%, EU AI Act Art. 9(4)(b) at 72%), the signal receives partial credit. CMCAE flags the specific gap: PCI requires MFA specifically for cardholder data environment access (not just privileged accounts generally), and the EU AI Act requires access controls specific to AI system components. The analyst sees exactly what additional evidence is needed to close the gap.

Step 5: Status update. Controls Hub updates the assessment status for all seven framework controls. The maturity score for each control reflects the new evidence. The evidence freshness clock starts. The Compliance Graph records the relationship between this specific evidence artifact and every control it attests to.

Total time: seconds. Automated. No tabs. No copy-paste. No duplicate uploads.

The gap identification problem

Cross-framework mapping isn't just about saving time. It's about precision in gap identification.

When CMCAE finds an overlap at 78% with PCI DSS 8.4.2, it tells you exactly what's missing: the Defender signal covers privileged Azure accounts, but PCI requires MFA for all cardholder data environment access, including application-level authentication that Entra Conditional Access doesn't cover. That gap is specific and actionable.

In the traditional model, this analysis happens in someone's head during evidence review. Different analysts reach different conclusions. Nobody documents the reasoning. In Kyudo, the gap is structural, a typed edge in the Compliance Graph with a defined reason and a specific path to closure.

Why STRM relationships aren't just nice-to-have

You might be thinking: "We do cross-framework mapping. We have a spreadsheet that maps SOC 2 controls to ISO 27001 controls."

That spreadsheet probably says CC6.1 "maps to" A.8.5. It doesn't say whether the relationship is equivalent, subset, superset, or overlap. It doesn't say what the strength is. It doesn't say what additional evidence is needed when the relationship is partial.

That distinction matters. When STRM says CMMC AC.L2-3.1.1 is equivalent to ISO 27001 A.8.5 at 92%, you can credit the same evidence with high confidence. When it says MFA enforcement overlaps with PCI DSS 8.4.2 at 78%, the 22% gap is specific (CDE scope, application-layer authentication) and you know exactly what to collect next. A flat mapping spreadsheet treats both scenarios identically: "maps to." That's why organizations using spreadsheet-based mapping still over-collect for some frameworks and under-collect for others.

The compounding effect

The Defender baseline signal is one signal. Kyudo's Microsoft integrations cover Defender XDR, Sentinel, Purview, Entra ID, Azure Policy, and Security Copilot via Microsoft Graph API. Multi-cloud adds AWS (Config, Security Hub, CloudTrail, IAM Access Analyzer) and GCP (Security Command Center, Cloud Logging, Org Policies). Each integration produces dozens to hundreds of compliance-relevant signals.

The math compounds: 100 signals across 7 frameworks would traditionally require 700 evidence collection and mapping events. With CMCAE, it's 100. The unified control architecture makes this a processing problem rather than a staffing problem.

The trust question

Automated cross-framework assessment raises an obvious concern: how do you trust the results?

Kyudo splits this into two layers. Layer 1 (deterministic) handles all scoring, validation, and crosswalk logic with rule-based processing. No AI in the path. Same input, same output, every time. If the system says a Defender signal satisfies CMMC AC.L2-3.1.1 at 95% strength, that's a calculation you can audit and reproduce.

Layer 2 (advisory) handles natural language outputs: gap explanations, evidence suggestions, policy draft language. These use AI, and every output carries a confidence score with citations back to specific Compliance Graph nodes. The deterministic layer makes the compliance decisions. The advisory layer helps humans understand and act on them.

"Different frameworks have different evidence requirements"

Correct. SOC 2 CC6.1 and PCI DSS 8.4.2 do have different evidence expectations, even though both address access control. Cross-framework mapping doesn't mean treating all frameworks as identical. It means understanding precisely where they agree, where they diverge, and how much additional work the divergence requires.

STRM models this directly. An overlap at 78% means "here's the 78% that's covered, and here's the 22% that isn't, with a specific reason and path to closure." You collect once where frameworks agree and focus manual effort on the gaps where they don't. For a typical seven-framework organization, agreement covers 60-70% of control requirements. Your team works on the 30-40% that's genuinely different.

Your Monday morning checklist

1. Pick one Defender finding. Open Defender for Cloud, find a baseline compliance signal, and count how many framework controls it's relevant to. If you're manually mapping it to fewer than three frameworks, you're leaving coverage on the table.

2. Check for duplicate evidence. Search your evidence repository for the same artifact uploaded to multiple framework folders. Each duplicate represents wasted analyst time and a reconciliation risk.

3. Assess your gap precision. When a piece of evidence partially satisfies a control, does your system tell you specifically what's missing? Or does it just flag "needs review"?

4. Calculate your collection multiplier. Take the total number of evidence items across all frameworks and divide by the number of unique artifacts. If the ratio is above 2:1, more than half your evidence work is duplication.

5. Test cross-framework propagation. Update one piece of evidence and check whether the assessment status changes across all mapped frameworks automatically. If it doesn't, you're running parallel compliance programs.

---

Kyudo's CMCAE engine processes each signal once against every applicable control across 80+ frameworks. One evidence artifact. Seven framework attestations. Typed gaps where the mapping is partial.

Book a demo to see cross-framework mapping live in your Azure tenant.