One piece of evidence, many frameworks: designing a unified control set without overclaiming
Unified control frameworks can remove a great deal of duplicated effort. They can also produce confident claims that collapse under an auditor’s first question. The difference lies in how you handle the parts of each framework that do not overlap.
- Published
- August 19, 2026
- Reading time
- 10 minutes
- Written by
- MarkTillson Assurance Practice
Take a mid-sized SaaS company selling to banks. In a single year it may be asked for a SOC 2 Type 2 report, an ISO/IEC 27001 certificate, a PCI DSS attestation for its payment flows, an answer on DORA contractual provisions from its EU customers, and a security questionnaire that maps to the NIST Cybersecurity Framework. Run each as a separate program and the same engineers will be asked for the same access review five times, in five formats, by five people.
The case for a unified control set (one set of internal controls, each mapped to the external requirements it helps satisfy) is obvious. The risk is less obvious. A mapping that says “control AC-04 satisfies SOC 2 CC6.2, ISO 27001 A.5.18 and PCI DSS 7.2.4” is a claim, and it is only true if the control as operated meets the most demanding of those requirements. This article is about making that claim stand up.
A worked example: the quarterly access review
Consider a common piece of evidence: a documented review of user access to production systems, performed each quarter by system owners, with removals actioned and tracked. Here is what four frameworks expect of something like it.
| Framework | Relevant requirement | What it specifically expects |
|---|---|---|
| PCI DSS v4.0.1 | 7.2.4 (with 7.2.5.1 and 8.2.6) | All user accounts and related access privileges, including third-party and vendor accounts, reviewed at least once every six months; inappropriate access addressed; management acknowledges access remains appropriate. Application and system accounts reviewed at a frequency set by targeted risk analysis. Inactive accounts removed or disabled within 90 days. |
| ISO/IEC 27001:2022 | Annex A 5.18 (with 5.15, 8.2) | Access rights provisioned, reviewed, modified and removed in line with the organization’s topic-specific policy; review frequency is the organization’s to define and justify within its ISMS. Privileged access rights restricted and managed. |
| SOC 2 (2017 Trust Services Criteria) | CC6.1–CC6.3 | Logical access is authorized, modified and removed based on roles and least privilege. The service auditor tests whether the described control operated effectively throughout the period, so frequency and evidence completeness matter. |
| NIST CSF 2.0 | PR.AA (Identity management, authentication and access control) | Outcome-based: access permissions are defined, managed, enforced and reviewed, incorporating least privilege and separation of duties. No prescribed frequency. |
The overlap is real: one well-run review process can support all four. But the differences are what determine whether the mapping holds.
- Scope of accounts. PCI DSS explicitly includes third-party and vendor accounts and treats application and system accounts separately. A review covering only employee accounts in the identity provider does not meet 7.2.4 or 7.2.5.1, however neatly it supports the others.
- Systems in scope. PCI DSS applies to the cardholder data environment and connected systems; SOC 2 to the systems within the described boundary; ISO/IEC 27001 to the ISMS scope. A single review must cover the union of those scopes, or the mapping is partial.
- Frequency. Quarterly comfortably exceeds PCI DSS’s six-month minimum, but if the ISMS policy says quarterly and one quarter is missed, the ISO auditor and the SOC 2 auditor will both report it. Your internal standard becomes the bar you are measured against.
- Evidence form. A SOC 2 auditor will sample instances across the period and look for completeness: every in-scope system, every quarter, every removal actioned. A screenshot of one review is not evidence of operating effectiveness.
The rule we apply: design to the strictest, map to each
A unified control should be designed to meet the strictest applicable version of each attribute (scope, frequency, approval and evidence retention) and then mapped to each framework with a note on anything that is framework-specific. Three consequences follow.
1. Mappings carry qualifiers
We record mappings as full, partial or supporting, with a sentence explaining any gap. “Partial: PCI DSS 7.2.5.1 requires a targeted risk analysis to set the review frequency for system accounts; see TRA-07.” That sentence is what keeps the mapping defensible when the PCI assessor arrives.
2. Some requirements have no partner
Every framework contains obligations with no meaningful equivalent elsewhere: PCI DSS’s payment-page script controls, DORA’s register of information and contractual provisions, ISO/IEC 27001’s management-review and internal-audit clauses, SOC 2’s system description. A unified program must carry these as framework-specific controls rather than forcing them into a shared one.
3. Certificates do not transfer
The most damaging overclaim is the suggestion that one assurance outcome satisfies another framework. An ISO/IEC 27001 certificate does not constitute a SOC 2 report; a SOC 2 report is not a PCI DSS Report on Compliance. Each is issued by a different type of body, against different criteria, with different scope. A unified control set reduces the effort of obtaining each; it does not make one a substitute for another.
For any mapping you are about to rely on, ask: “If the auditor for framework B read only this control description and this evidence, would they conclude their requirement is met?” If the answer is “mostly”, the mapping is partial. Record what is missing.
The evidence calendar is the real product
The mapping spreadsheet gets the attention, but the artifact that saves engineering time is the evidence calendar: a schedule of every recurring control activity, its owner, the systems it covers, the evidence it produces and where that evidence is stored. When the calendar is built from a unified control set, each activity happens once, to the strictest standard, and its evidence is filed once with tags for every framework it supports.
That is also the foundation for continuous assurance. When evidence is collected on schedule rather than assembled before each audit, the state of each control is visible all year, and an audit becomes a sampling exercise rather than a scramble.
What automation can and cannot do
Compliance automation platforms are good at collecting technical evidence (configuration states, user lists, ticket histories) and at tagging it against multiple frameworks. They are less good at the judgments that make a mapping true: whether the scope is complete, whether a review was substantive, whether an exception was properly approved. Treat platform-supplied mappings as a starting point to be reviewed by someone who knows each framework, not as a conclusion.
Getting started
- List the assurance outcomes you actually need in the next 24 months, and who is asking for each.
- Define one scope boundary per framework, then the union of systems that any unified control must cover.
- Choose a base control catalog (many organizations use ISO/IEC 27001 Annex A or NIST SP 800-53 as the spine) and write your own controls in your own words.
- Map each control with qualifiers, and list framework-specific obligations separately.
- Build the evidence calendar from the controls, not from the frameworks.
Key takeaways
- Design each control to the strictest applicable requirement for scope, frequency and evidence.
- Record mappings as full, partial or supporting, with the gap in words.
- Keep framework-specific obligations separate; not everything overlaps.
- One certificate never substitutes for another framework’s report.
- The evidence calendar, not the mapping spreadsheet, is where the time savings come from.
Sources
- PCI Security Standards Council, PCI DSS v4.0.1, June 2024, requirements 7.2.4, 7.2.5.1, 8.2.6.
- ISO/IEC 27001:2022, Annex A controls 5.15, 5.18 and 8.2.
- AICPA, 2017 Trust Services Criteria (with revised points of focus, 2022), CC6.1 to CC6.3.
- NIST, Cybersecurity Framework 2.0, February 2024, PR.AA category.
Our multi-framework compliance practice builds unified control sets that hold up in front of every assessor, our own QSAs included. One control, one evidence calendar, every framework you answer to. Ask us to map yours.
