Domain-to-framework crosswalk
A domain-to-framework crosswalk is the many-to-many map between what the assessment observed technically and the control catalogs your organization is measured against. Because a single root cause — an over-broad role, an unencrypted store, a logging gap — almost never lives under one requirement, the crosswalk records every control in every in-scope framework that a finding produces evidence for, and, read the other direction, every finding that bears on a given control. That two-way view is what lets you deduplicate remediation, plan by leverage, and see the negative space where a control has no supporting evidence at all. It is built on top of the finding-to-evidence work elsewhere in this domain, but it is a distinct artifact: not a longer list, but a relationship graph you can plan an audit and a remediation quarter from at the same time. We keep it read-only and descriptive — it shows relationships and coverage, never a certification the assessment cannot grant.
Overview
What this check looks like in practice
The five technical domains — identity, data, network, logging, and configuration — rarely map one-to-one onto a single framework. A single identity gap can touch access-control requirements in CIS, SOC 2, HIPAA, and PCI at the same time. The crosswalk shows, for each finding, every framework and control it produces evidence for, so you can plan remediation by impact instead of fixing the same issue once per audit.
Why it matters
Auditors and insurers keep separate control sets, so the same misconfiguration can surface in a SOC 2 examination, a PCI DSS ROC, and a HIPAA review independently — and when each framework owner assumes another team closed it, real gaps live in the seams between programs. An attacker does not care which framework owns a control; they exploit the root cause once, while your teams may be paying to remediate it three times or not at all. The crosswalk collapses that duplication into one prioritized body of work and makes the coverage gaps explicit, so effort follows leverage instead of audit calendars. It is also where mapping discipline matters most: a crosswalk that quietly treats a missing finding as a passed control, or maps to a superseded framework revision, produces false assurance that does not survive an auditor's scrutiny. We describe which controls each finding touches and which controls we observed no evidence for — not whether you are compliant, which remains your auditor's determination.
What we assess
What we look for
- Whether each finding carries the specific control identifier in every framework it touches — for example SOC 2 CC6.1, PCI DSS Req. 7.2, ISO 27001:2022 A.8.2, HIPAA 164.312(a)(1) — rather than only a framework name
- Whether the mapping preserves true many-to-many relationships: one finding tied to many controls, and one control supported by many findings, instead of forcing each issue under a single owner
- Whether remediations are deduplicated so a single fix that satisfies several controls is counted once and ranked by how many control requirements it clears
- Whether the crosswalk distinguishes technical controls the read-only assessment can directly observe from governance, process, or policy controls that require interview or document evidence
- Whether coverage negative space is explicit — naming which framework controls the assessment produced no evidence for — so silence is never mistaken for a pass
- Whether mappings reconcile to native tooling control IDs (AWS Security Hub, Defender for Cloud regulatory compliance, Security Command Center) instead of a parallel taxonomy that conflicts with them
- Whether the crosswalk is pinned to the framework revision in force — PCI DSS v4.0.1, the 2017 SOC 2 Trust Services Criteria, ISO 27001:2022, NIST CSF 2.0 — so mappings are not stale against a superseded version
- Whether overlapping requirements are sequenced so the highest-leverage fixes, those clearing the most controls across frameworks, are scheduled first
Across your clouds
AWS, Azure & Google Cloud
AWS
We anchor each mapping to AWS-native control IDs — Security Hub's CIS AWS Foundations Benchmark, PCI DSS, and NIST 800-53 standards, AWS Config conformance-pack control names, and AWS Audit Manager's SOC 2, HIPAA, and PCI framework libraries — then extend the crosswalk across the frameworks those tools do not cover, so the report reconciles with what your account already reports instead of competing with it.
Azure
In Azure we align mappings to the built-in initiatives behind Defender for Cloud's regulatory compliance dashboard — the Microsoft cloud security benchmark, PCI DSS, SOC 2, ISO 27001, and NIST 800-53 initiative definitions carried in Azure Policy — and carry each Entra ID, Storage, or Defender finding across to the additional frameworks those initiatives do not represent.
Google Cloud
For Google Cloud we tie findings to Security Command Center's compliance mappings — CIS GCP Foundation Benchmark, PCI DSS, NIST 800-53, and ISO 27001 — and, where Assured Workloads defines a control package, reconcile against it before crosswalking to the frameworks SCC does not enumerate.
Example finding
Unencrypted RDS snapshot mapped to five data-protection controls across four frameworks — with one control left as an explicit coverage gap
Risk: The single misconfiguration produces evidence for CIS data-protection guidance, SOC 2 CC6.7, PCI DSS Req. 3, and HIPAA 164.312(a)(2)(iv); remediated per-audit it gets fixed several times, and the related key-management policy control — which a read-only scan cannot observe — silently reads as covered when it was never assessed.
Fix: Record the finding once against every control it touches, flag the key-management policy control as needing process evidence rather than treating its absence as a pass, and remediate the encryption gap a single time so one change refreshes the evidence for all four frameworks.
Remediation
How to close it
- 1 Sort the crosswalk by how many controls each finding clears and start with the highest-leverage fixes, so a single least-privilege or encryption change retires several requirements across frameworks at once.
- 2 Assign one owner per root-cause finding rather than one owner per framework, so the same issue is not remediated multiple times or dropped in the seam between framework owners.
- 3 Reconcile the crosswalk against your native compliance tooling — Security Hub, the Defender for Cloud regulatory compliance dashboard, Security Command Center — so control IDs match and evidence lines up with what the platforms already report.
- 4 Separate the technical fixes from the governance and process controls flagged as needing document or interview evidence, and route those to the policy owner instead of the cloud team.
- 5 Treat the explicit coverage gaps as their own backlog — commission the missing process evidence or scope a follow-up review rather than letting an unobserved control read as satisfied.
- 6 Re-test after remediation so the evidence each mapped control points to is current before an audit, cyber-insurance questionnaire, or board update relies on it.
Compliance evidence
Questions
How is the crosswalk different from the framework-mapped findings I already get?
Mapping ties each finding to the controls it relates to. The crosswalk is the cross-framework, two-way view: it shows every framework a single finding touches at once and, read the other direction, every finding that bears on a given control — so you can deduplicate remediation and plan by leverage instead of fixing the same root cause once per audit.
What if a finding maps to controls in frameworks we are not audited against?
We map to the frameworks your industry answers to. Where a finding also touches a framework you do not currently hold, we can note it as latent coverage so a future SOC 2 or PCI effort starts with evidence already in hand — without inflating the core report or implying an obligation you do not have.
Can the crosswalk tell us a control is satisfied?
It shows which findings produce evidence toward a control and which controls we observed no evidence for. It cannot mark a control satisfied or certify compliance — that is an auditor's determination — and it never treats the absence of a finding as proof that a control is met.
More in framework mapping
See where you stand
A health check finds and prioritizes real exposure. It is not a certification or a promise you will never be breached — closing the findings is what changes your risk.
Related domain surfaces
The rest of what we assess
The same read-only assessment covers every domain — see what else it looks at.
