Have PIPEDA? You already run 82% of GDPR.
If your company already operates PIPEDA, about 82% of the control areas GDPR requires are ones you already run (18 of 22), leaving roughly 4 net-new control areas to add. That is control-area reuse from one shared control layer - not a certification percentage. The framework-specific requirements and evidence inside each shared area are separate work.
The direction that flatters PIPEDA. Its principles cover most of what GDPR asks for at the control level, but the net-new areas are the ones with teeth - DPIAs, international transfer safeguards, and a records-of-processing register in GDPR's specific form.
If you already have PIPEDA, you operate
- GDPR: you already operate 82% of its control areas (18 of 22), with 4 net-new.
- SOC 2: you already operate 48% of its control areas (27 of 56), with 29 net-new.
- HIPAA: you already operate 47% of its control areas (14 of 30), with 16 net-new.
- ST4S: you already operate 46% of its control areas (19 of 41), with 22 net-new.
- ISO 27001: you already operate 44% of its control areas (22 of 50), with 28 net-new.
- CMMC 2.0: you already operate 43% of its control areas (15 of 35), with 20 net-new.
- CPCSC: you already operate 43% of its control areas (15 of 35), with 20 net-new.
- PCI DSS 4.0: you already operate 43% of its control areas (17 of 40), with 23 net-new.
- CIS Controls v8.1: you already operate 38% of its control areas (11 of 29), with 18 net-new.
- ISO/IEC 42001: you already operate 19% of its control areas (3 of 16), with 13 net-new.
- NIST AI RMF: you already operate 8% of its control areas (1 of 13), with 12 net-new.
- EU AI Act: you already operate 0% of its control areas (0 of 10), with 10 net-new.
Collect once, comply many
Security frameworks like SOC 2, ISO 27001, HIPAA, PCI-DSS and CIS overlap heavily, so the work you do for one carries most of the way to the others. That is the whole point of a shared control layer: implement a control and collect its evidence once, and it counts toward every framework it satisfies.
The AI-governance frameworks are the honest exception. The EU AI Act, ISO 42001 and NIST AI RMF are about the AI system itself, which your cloud and security controls do not cover, so the overlap is genuinely low. Proofsteady shows that plainly instead of inflating the numbers.
Cross-framework overlap, explained
If I have PIPEDA, how much of GDPR do I already cover?
About 82% of GDPR's control areas are ones you already operate for PIPEDA (18 of 22), leaving roughly 4 net-new control areas to add. This is control-area reuse from a shared control layer, not a certification percentage - the framework-specific requirements and evidence inside each shared area are separate work. The direction that flatters PIPEDA. Its principles cover most of what GDPR asks for at the control level, but the net-new areas are the ones with teeth - DPIAs, international transfer safeguards, and a records-of-processing register in GDPR's specific form.
How much overlap is there between SOC 2 and ISO 27001?
A lot, at the control level. Both rest on the same security foundation - access control, encryption, monitoring, change management - so most of the control areas you build for SOC 2 are ones ISO 27001 also needs, leaving only a handful of net-new areas. The catch: the specific requirements and evidence inside each shared area still differ, so a granular control-by-control mapping shows a lower number than the control-area reuse the tool displays.
Can I reuse the same controls and evidence across frameworks?
Yes. Proofsteady maps every framework to one shared control layer, so a control you implement (and the evidence you collect for it) counts toward every framework it satisfies. You do the work once and it proves many frameworks at the same time.
How is this different from a rough overlap estimate?
It's computed, not eyeballed. Proofsteady derives the numbers from the actual framework-to-control mappings behind the product, so you get a consistent control-area reuse and net-new count for each pair instead of a rule-of-thumb range. It's a planning figure that reflects our control mappings, not a guarantee you'd pass a given framework's audit.
Why is the overlap higher than a control-by-control mapping (for example, ~50-60% between CMMC and PCI DSS)?
Because we measure different things. Published crosswalks compare frameworks requirement by requirement, where the specific wording and scope diverge, so they land around 50-60%. This tool measures control-area reuse - how many of the broad control areas one framework needs are ones you already operate for another - which runs higher because a single control (like access control) satisfies many frameworks at once. Both are correct: control-area reuse tells you how much of your program carries over, while the requirement-level mapping tells you how much per-requirement tailoring and evidence work remains. We lead with reuse and net-new, and flag that the granular work inside shared areas is separate.
Why do the AI frameworks (EU AI Act, ISO 42001, NIST AI RMF) show little overlap?
Because they genuinely are different work. AI-governance frameworks are about the AI system itself - its risk management, data governance, human oversight, and robustness - which your cloud and security controls do not cover. Proofsteady shows that honestly instead of inflating the overlap, and ships a dedicated AI-governance control family for the net-new work.