Teams running SOC 2 and ISO 27001 in the same year often collect the same screenshot twice, rename it, and file it in two folders. SOC 2 ISO 27001 control mapping, as we deliver it, is one evidence object with two control pointers: Trust Services Criteria on one side, Annex A on the other. The PBC list becomes a view, not a second hunt.
We are not an ISO certification body and we do not issue a SOC 2 report. We build the store and the map that both assessors can pull from. The AICPA SOC 2 TSC and ISO/IEC 27001 Annex A overlap hard on access, logging, change, and vendor management. They do not overlap perfectly. The map has to say so.
Why SOC 2 ISO 27001 Control Mapping Beats Two PBC Lists
A typical dual-framework week:
- SOC 2 asks for CC6.1 / CC6.2 / CC6.3 access samples
- ISO asks for A.5.15 / A.5.18 / A.8.2 access samples
- Two coordinators email two owners for the same Okta export
The owners send two slightly different CSVs. One is stale. Fieldwork burns a day on the diff. Evidence freshness tracking would have flagged the stale file. Mapping would have prevented the second request.
Collect once. Map many. That is the whole product.
The Object Model We Ship
An evidence record is not a filename. It is:
artifact_id, hash, collected_at, ttl, source_systemowners[]maps[]—{framework, control_id, notes}sample_window— which Type 2 or ISO period it covers
evidence = {
"artifact_id": "okta-term-export-q3",
"source": "okta.system_log + hris.terms",
"collected_at": ts,
"ttl_days": 90,
"maps": [
{"framework": "SOC2_TSC", "control": "CC6.3", "notes": "access removal sample"},
{"framework": "ISO27001", "control": "A.5.18", "notes": "access rights review / removal"},
],
}
When a control has no twin, the map says unique. Examples we keep explicit:
- SOC 2 availability / processing-integrity criteria that do not have a one-line Annex A twin
- Annex A physical / supplier clauses that are not in a typical SaaS SOC 2 scope
Forcing a fake twin is how you get an auditor asking why the screenshot does not match the clause. We would rather show a short unique list than a pretty matrix of stretched analogies.
What We Collect Once
The first wave is the overlapping middle — the same families we already automate:
- Access provisioning, recertification, removal (CC6.1, CC6.2, CC6.3)
- Change and CI identity (OIDC deploy roles, not standing keys)
- Logging and retention on in-scope systems
- Vendor / subservice inventory
- Internal-tool adapters from SOC 2 evidence for internal tools
Each artifact is generated by a job, not pasted from a laptop. The map is configuration. Adding ISO to a shop that already has SOC 2 jobs should be mostly map rows, not a second collection army.
Gap analysis automation tells you which internal systems are missing from this store. Mapping without that scan just dual-files the systems you already liked.
Type 2 Windows Versus ISO Periods
SOC 2 Type 2 is operating effectiveness over an observation window. ISO surveillance is a different calendar. An artifact that is valid for both has a window intersection. An artifact that is only a point-in-time config screenshot is flagged as Type 1-shaped — useful, not sufficient for the whole Type 2 window. That distinction lives in SOC 2 Type 1 vs Type 2 evidence. The map must not pretend a single screenshot covers a nine-month ISO period.
We store the window on the record. Exports to each assessor filter by their period. That is the opposite of "zip the whole Drive folder."
Tradeoffs
A published crosswalk is a starting point, not the control. Vendor-neutral mappings drift when Annex A clause text and your TSC report language diverge. We maintain your map, versioned, with a reviewer (GRC owner) on changes.
Over-mapping creates false confidence. If five Annex A controls point at one vague "security policy PDF," neither assessor is served. We require a note that says what in this artifact satisfies the clause.
Under-mapping creates duplicate work. If two nearly identical logs are collected because nobody tagged the first, we merge and retire the duplicate.
The ceiling: this is a store plus a matrix, not a GRC product. If you already have a platform, we write the custom objects and the control tags into it. If you do not, a boring database and a folder with manifests is enough for mid-market volume.
What the Assessor Gets
Two views, one store:
- SOC 2 PBC: TSC id → artifacts in window
- ISO PBC: Annex A id → artifacts in window
- Coverage report: controls with zero artifacts, controls with only stale artifacts, controls marked unique
We do not sit in the audit meeting unless asked. We make the packet so your compliance manager is not hunting Slack.
This is security automation on evidence, not a second policy binder. It also needs full-stack development when the artifact source is an internal app with no export.
Ask us what your GRC platform is not covering: rutagon.com/contact · 907-841-8407 · contact@rutagon.com.
Frequently Asked Questions
Can one screenshot satisfy both SOC 2 and ISO 27001?
Sometimes. Only if the artifact actually speaks to both clauses and is still in date for both windows. The map records that claim. We do not stamp every file with every control id.
Do you implement ISO 27001 for us?
We implement the evidence collection and mapping engineering. Certification and the management-system consultancy sit with your auditor and, if you have one, your vCISO. See vCISO vs boutique engineering.
What if our GRC tool already has a SOC 2 to ISO crosswalk?
Use it for the standard vendors. We still map your custom artifacts. Crosswalks do not know your support console.
How often does the map change?
When you add a system, drop a system, or an assessor rejects a mapping note. We version the map. Silent edits are how an outdated matrix lies.
Does this reduce audit cost?
It reduces duplicate collection and last-week scrambles. It does not replace the audit fee. The value is engineering hours and failed-control risk, not a promise about the firm's invoice.