Most trust teams maintain evidence for multiple frameworks but collect it separately — an access control list gets built once for SOC 2, once for ISO 27001, and once more for NIST CSF. The evidence is the same. The collection effort triples because the mapping between frameworks is maintained in someone's head instead of a living document.
Why the Same Control Gets Re-Evidenced Per Framework
Framework-specific language is the most common reason. SOC 2 calls it a "control activity." ISO 27001 calls it an "annex control." NIST CSF calls it a "protect function subcategory." The words differ, but the underlying access review, change ticket, or incident record is the same artifact.
Three forces drive duplicate evidence collection:
| Force | Example | Impact |
|---|---|---|
| Framework-specific language | SOC 2 CC 6.1 vs ISO 27001 A.9 vs NIST CSF PR.AC | Same control, different label, collected separately |
| Scope differences | SOC 2 covers a service, ISO 27001 covers an organisation | Evidence may need context adjustment but not re-creation |
| Evidence-burden variation | SOC 2 requires quarterly access reviews; NIST CSF is outcome-descriptive | The depth differs, the underlying evidence does not |
The result is a familiar cycle: the SOC 2 audit starts, evidence gets collected. The ISO 27001 audit starts six months later, the same evidence gets collected again — often from the same system owners, who wonder why last year's artifacts are not acceptable.
A Real Crosswalk: Evidence to SOC 2 to ISO 27001 to NIST CSF
Take one concrete control — logical access management — and trace it across frameworks. The evidence you already keep (access review logs, user provisioning tickets, role-change approvals) maps directly to all three:
| Evidence artifact | SOC 2 | ISO 27001:2022 | NIST CSF 2.0 |
|---|---|---|---|
| Quarterly access review log | CC 6.1 (logical access) | A.8.2 (privileged access rights) | PR.AC-04 (access permissions) |
| User provisioning / deprovisioning tickets | CC 6.1, CC 6.2 | A.8.3 (information access restriction) | PR.AC-03 (user access management) |
| Role-change approval records | CC 6.1 | A.8.2 (access rights) | PR.AC-04 (access permissions) |
| Password policy and enforcement evidence | CC 6.1 | A.8.5 (secure authentication) | PR.AC-07 (authentication) |
| MFA configuration and usage logs | CC 6.2 | A.8.5 (secure authentication) | PR.AC-07 (authentication) |
| Vendor access review records | CC 3.2, CC 6.1 | A.5.19 (supplier relationships) | PR.AC-05 (remote access) |
One evidence collection — six artifacts — satisfies control requirements across all three frameworks. The key is maintaining the mapping explicitly rather than collecting the same artifact three times.
Where Mappings Legitimately Differ
Not every control maps cleanly across frameworks. Knowing where the differences are prevents over-claiming during an audit.
SOC 2 is organised around the Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality, Privacy). The controls are described as points of focus under each criterion. ISO 27001:2022 is structured as four themes (A.5–A.8) with 93 control statements. NIST CSF 2.0 is organised as six functions (Govern, Identify, Protect, Detect, Respond, Recover) with categories and subcategories.
The differences that matter for evidence mapping:
- SOC 2 CC 3.2 (communicates responsibilities) has no direct ISO 27001 equivalent — it maps roughly to A.5.2 (information security policy) and A.7.4 (awareness) but the evidence burden differs
- NIST CSF RS.CO (respond — communications) spans multiple ISO 27001 annex controls because incident communication covers a broader scope than ISO 27001's incident management requirements
- SOC 2 CC 7.1 (system monitoring) aligns with ISO 27001 A.8.15 (monitoring) but NIST CSF DE.CM (continuous monitoring) casts a wider net that includes physical monitoring and third-party observation
When mapping between frameworks, the correct approach is to describe the mapping as directional — "this evidence supports the intent of both controls" — rather than claiming a perfect equivalence. An auditor who sees a forced mapping will push back. One who sees a reasoned crosswalk with noted differences will accept it.
Maintaining It as Frameworks Change
Framework guidance is not static. SOC 2 criteria get updated by AICPA. ISO 27001 is on a regular revision cycle. NIST CSF 2.0 was published in February 2024, replacing the 1.1 framework.
A crosswalk that was accurate last year may have gaps this year. The maintenance workflow is straightforward:
- When a framework updates, identify which controls changed (added, removed, reworded)
- Trace each change to the crosswalk — does the updated control still map the same way?
- Re-map where the intent shifted — a control that was split may need additional evidence
- Document the change — note the framework version and the mapping decision date
The discipline matters more than the frequency. A crosswalk reviewed twice a year — before each major audit cycle — stays current enough for annual audits. One that is built and never reviewed becomes a liability by year two.
FAQ
Can I certify SOC 2 and ISO 27001 with the same evidence?
Yes, for controls that cover the same intent. Logical access, change management, incident response, and vendor management produce evidence that satisfies both frameworks. The caveat is scope: SOC 2 covers a defined service, while ISO 27001 covers the organisation. Evidence that applies to the service may need additional context to support the broader ISMS scope.
What happens when NIST CSF updates?
NIST CSF 2.0 added the Govern (GV) function and introduced a new set of categories. If your crosswalk was built against 1.1, the Govern function controls — risk management strategy (GV.RM), organisational context (GV.OC), and oversight (GV.OV) — require fresh mapping. The Protect and Detect functions carried forward with minor rewording, so existing mappings remain largely valid.
Do auditors accept cross-mapped evidence?
Most auditors do, provided the mapping is documented and the evidence matches the control requirement it supports. The key is transparency: the crosswalk should show which evidence supports which framework control, and note where the mapping is directional rather than exact. An auditor who sees a reasoned crosswalk with noted differences is more likely to accept it than one who sees a blanket "this covers everything" claim. The same principle applies when scoping an audit from existing evidence — documented traces build trust.
How often should I update my crosswalk?
At minimum, before each annual audit cycle. If you operate on a two-year recertification schedule, review the crosswalk mid-cycle as well. The trigger events are framework updates (AICPA guidance changes, ISO 27001 revisions, NIST CSF releases) and significant control changes (new systems, decommissioned processes, updated policies).
One evidence collection, mapped deliberately across frameworks, produces more credible output than the same evidence collected three times in isolation. In Compass by Truvara, the framework-crosswalk grid links one evidence set across SOC 2, ISO 27001, NIST CSF, and other pre-loaded frameworks — each mapping proposed as a pending change so you review the relationship before it becomes part of your audit record. The mapping is proposed; accepting one as audit-valid remains your call. Join the waitlist.