Evidence you can reuse across SOC 2, ISO 27001 and PCI DSS
Organisations with three audits often collect the same screenshots three times. Most evidence can serve all three, if you collect it with the strictest auditor in mind.
An organisation with SOC 2, ISO 27001 and PCI DSS can easily spend more time answering evidence requests than running controls. Each auditor asks for "the access review", "the vulnerability scans", "the incident test", in slightly different formats and for slightly different periods. Most of that evidence is the same. The trick is to collect it once, in a form that satisfies the most demanding of the three.
Why the overlap is large
The three frameworks share most of their security subject matter. Going from ISO 27001 to SOC 2, for example:
Of the 61 SOC 2 criteria, 41 (67%) map to something in ISO 27001, 0 are only loosely related and 20 have no mapping in our data. Open the gap report →
And from ISO 27001 to PCI DSS, the overlap is smaller but still substantial in governance and process:
Of the 260 PCI DSS requirements, 77 (30%) map to something in ISO 27001, 76 are only loosely related and 107 have no mapping in our data. Open the gap report →
Where requirements map, the evidence usually overlaps too.
Evidence that serves all three
| Evidence | SOC 2 | ISO 27001 | PCI DSS |
|---|---|---|---|
| User access reviews (with sign-off and changes made) | CC6.2, CC6.3 | A.5.18 | 7.2.4 (every six months) |
| Joiner and leaver tickets with approvals | CC6.2 | A.5.16, A.5.18, A.6.5 | 8.2.4, 8.2.5 |
| Change tickets with review, testing and approval | CC8.1 | A.8.32 | 6.5.1, 6.5.2 |
| Vulnerability scan results and remediation | CC7.1 | A.8.8 | 11.3.1, 11.3.2, 6.3.3 |
| Penetration test reports and retests | CC4.1, CC7.1 | A.8.8 | 11.4.1 to 11.4.4 |
| Incident register and response test | CC7.3 to CC7.5 | A.5.24 to A.5.27 | 12.10.1, 12.10.2 |
| Security awareness training records | CC1.4, CC2.2 | A.6.3 | 12.6.1 to 12.6.3 |
| Supplier due-diligence records | CC9.2 | A.5.19 to A.5.22 | 12.8.1 to 12.8.5 |
| Backup restore tests | A1.2, A1.3 | A.8.13 | 9.4.1.1, 12.10.1 |
| Risk assessment and its review | CC3.1 to CC3.4 | 6.1.2, 8.2 | 12.3.1 |
Collect to the strictest standard
- Frequency: PCI DSS often sets the fastest cadence (six-monthly access reviews, quarterly scans). Run controls at PCI's frequency and the others are satisfied.
- Period: SOC 2 Type II samples across the whole observation period. Keep evidence continuously, not just before audits.
- Completeness: ISO auditors may ask how you know the population is complete. Keep the full list (all leavers, all changes), not just the examples you'd choose.
- Provenance: system-generated evidence (exports, logs, tickets with timestamps) beats screenshots of a screen someone arranged.
A simple structure
One evidence store, organised by control rather than by framework. Each control folder holds the evidence for each period, named consistently, with a short index saying which framework requirements it serves. When an auditor asks for "evidence of 7.2.4", you look up the control, not the framework.
Key takeaways
- Most evidence (access reviews, change tickets, scans, incident records, training) serves SOC 2, ISO 27001 and PCI DSS at once.
- Collect to the strictest standard: PCI's frequencies and SOC 2's continuous period.
- Organise evidence by control, not by framework, with an index of what each item satisfies.
- A few items don't transfer, notably ASV scans and ISO management-system records.
What doesn't transfer
- PCI-specific scans: external scans must be by an Approved Scanning Vendor.
- PCI targeted risk analyses for flexible-frequency requirements.
- ISO management-system records: internal audit reports, management review minutes and corrective action logs are ISO-specific (though SOC 2 auditors appreciate them).
- SOC 2 system description: your own narrative of the system in scope.
Our post on one control set for SOC 2 and ISO 27001 covers designing the controls; the gap analysis lists the mappings between any two frameworks.
Questions
Can the same evidence be used for SOC 2 and ISO 27001?
Usually, yes. Both look for proof that controls operate: tickets, reviews, scan results, training records. SOC 2 Type II needs samples across its whole observation period, so collect continuously.
What evidence does PCI DSS need that SOC 2 doesn't?
Evidence of PCI-specific frequencies and settings: quarterly internal and ASV external scans, six-monthly access and firewall rule reviews, targeted risk analyses, and cardholder-data-specific configurations.
How long should audit evidence be kept?
At least until the next audit cycle closes, and longer where a framework or law requires it; PCI DSS, for example, requires 12 months of audit log history.
Data as of 2026-10-27: numbers in this post are computed from the current crosswalk and update when it changes. Crosswalk a published crosswalk (NIST, ENISA, CIS, PCI SSC) makes the link · Editorial ControlMapping's judgement where no crosswalk exists; the reason is shown · only shares a CSF 2.0 outcome: worth checking, not a mapping · No mapping in our data nothing mapped in our data; often new work, but check the coverage notes. Not compliance advice.
Related posts
Analysis · 2026-10-27APRA CPS 234 and ISO 27001: what your ISMS covers and what APRA addsAn ISO 27001 ISMS covers nearly every paragraph of APRA's CPS 234, yet APRA adds Board duties, third-party assurance and strict notification deadlines.
Analysis · 2026-10-13MFA requirements compared across 11 security frameworksWhich frameworks require MFA, for whom and how strictly: PCI DSS, CMMC, NIS2, Essential Eight, ISO 27001, SOC 2 and HIPAA compared side by side.
Analysis · 2026-09-15Encryption requirements compared: what frameworks specify and what they leave to youHow ISO 27001, PCI DSS, CMMC, HIPAA, GDPR and NIS2 treat encryption at rest, in transit and key management, with the requirement IDs.