Comply Once, Prove Many: Reusing Evidence Across Frameworks

Most of the work for your second framework is already done, and the reason is that frameworks disagree about vocabulary far more than they disagree about controls. Access reviews, encryption, change approval, vendor assessment, incident response, backup testing and awareness training sit in every one of them under different names and different numbering. Our ISO 27001 versus SOC 2 comparison walks through where those two frameworks meet and where they diverge, and why the sequenced path (one framework, then the second on top of it) costs less than running both as separate programs.

The mechanism that unlocks it is not a platform feature. It is a decision you make on day one: run one control set, collect each piece of evidence once, and tag that artifact to every requirement it satisfies at the moment you collect it. Do that and each added framework buys you a report. Skip it and you pay for the same program twice, in the same year, with the same people.

Key takeaways

• Frameworks disagree about vocabulary far more than they disagree about controls, so most of the work for your second framework is already done.
• The mechanism is a day-one decision, not a platform feature: run one control set, collect each artifact once, and tag it to every requirement it satisfies at the moment you collect it.
• Organise the register around your controls, never around a framework's numbering. Retro-tagging a year of artifacts is a project; tagging at collection is a dropdown.
• What never transfers is ISO 27001's management-system machinery (clauses 4 through 10), SOC 2's system description, HIPAA's regulatory specifics, and the examination itself.
• Overlap reduces preparation, not attestation. Your internal hours fall sharply; the second examiner's fee does not.

What "one control set" actually means

Companies that end up paying twice almost always got there the same way. SOC 2 came first, so the evidence got organised around the Trust Services Criteria: folders named CC6.1, CC7.2, CC8.1. Then a European customer asked for ISO 27001, and the ISMS work started from a blank page, with a new folder structure named after Annex A, and the same access reviews were collected a second time into a different place.

The alternative costs nothing extra the first time. Organise around your controls, not around a framework's numbering. You have a control called "quarterly user access review". It is one control, with one owner, one cadence, and one evidence artifact per quarter. That artifact carries tags: it supports the SOC 2 criteria on logical access, ISO 27001 Annex A access control requirements, and the HIPAA Security Rule's information access management and review requirements. When your ISO auditor asks for evidence of access review, you do not collect anything; you filter.

Three practical consequences follow, and they are the whole discipline:

• The control register is the system of record, not the framework checklist. Each row is a control, an owner, a cadence, and an evidence location. Framework mappings are columns on that row.
• Tags go on at collection time. Retro-tagging a year of artifacts is a project. Tagging at collection is a dropdown.
• A framework's unique requirements are additions to the register, never a parallel register. When ISO 27001 requires an internal audit programme and SOC 2 does not, that becomes one new row, not a new system.

Our public framework mapping resource exists for exactly this exercise: it pivots controls between frameworks through NIST SP 800-53, so you can see which of your existing controls already answer a requirement in the framework you are adding, and which do not.

What genuinely transfers

Working from the middle of the map outwards, the reusable core is larger than most people expect.

Identity and access. Provisioning and deprovisioning records, periodic access reviews, privileged account inventories, MFA enforcement evidence. Every framework in this space wants these, and the artifacts are identical.

Change management. The population of production changes, approvals, testing evidence, and the emergency change path. Same artifacts, different requirement numbers.

Vulnerability management and testing. Scan output, remediation records, the annual penetration test report. Note that a HIPAA-scoped or PCI-scoped test may need different scope than a SOC 2-scoped one, so the report transfers only if the scope covers both.

Vendor and third-party management. The inventory, the tiering, the assessments, the collected reports. One programme satisfies the vendor requirements of SOC 2, ISO 27001, HIPAA, and most privacy regimes at once.

People controls. Background checks, awareness training completion, policy acknowledgment, onboarding and offboarding records.

Resilience. Backup configuration, restoration testing, business continuity and disaster recovery plans and their test records.

Incident response. The plan, the tabletop or live exercise record, and the incident tickets with timelines.

What never transfers, and why

This is the part vendor content leaves out, and it is where second-framework budgets get blown.

Management-system machinery. ISO 27001 is a management system standard, and its clauses 4 through 10 have no SOC 2 equivalent at all: context and interested parties, a documented risk assessment and treatment methodology, the Statement of Applicability, measurable objectives, an internal audit programme under clause 9.2, and management review. None of your SOC 2 evidence answers any of it. This is the single largest cost in a SOC 2-to-ISO 27001 move, and it is documentation and governance work rather than engineering work.

The system description. SOC 2's Section 3 narrative is a SOC 2 artifact. Nothing else asks for it in that form.

Regulatory specifics. HIPAA wants business associate agreements, a documented risk analysis in the Security Rule's own terms, and the breach notification machinery. A SOC 2 report does not produce any of those, which is why "we have SOC 2, so we are HIPAA compliant" is false in both directions.

The examination itself. Overlap reduces preparation, not attestation. Each framework's report costs what it costs, because a different independent party has to do a different piece of work. When people are disappointed by the economics of a second framework, this is almost always why: they expected the audit fee to fall, and what actually falls is the number of internal hours before it.

Scope mismatches. A control that covers your production environment satisfies a framework scoped to production. If the second framework's scope includes your corporate IT, your data centre, or a second product, the evidence does not stretch to cover it no matter how it is tagged.

What the overlap is worth, honestly

Two numbers, both already published on this site, and neither of them restated here as anything new.

SOC 2 and ISO 27001 overlap substantially in control content, but we do not put a percentage on it and neither does any standards body; our ISO 27001 versus SOC 2 comparison explains why the percentages in circulation do not survive checking. What matters more than the size of the overlap is where the residue sits, and it is not evenly distributed: it is concentrated in the management-system clauses above, which is the expensive end.

Sequencing the two rather than running them independently costs less on total programme cost, not on the audit fee. We publish no percentage for the saving, because it depends on how much of the first framework's control set the second one reuses in your scope.

Where does the saving actually come from? Almost entirely from internal hours. Our SOC 2 cost breakdown puts first-audit manual preparation at 300 to 500 internal hours. The second framework, run against an existing control register with tagged evidence, does not repeat those hours; it adds the framework-specific ones. If you want to sanity-check a quote for a second framework, use the budget planner and then ask the vendor which of the line items they consider net-new versus reused. A firm that cannot answer that question control by control has not done this before.

The order that makes reuse cheapest

Not every sequence is equally efficient, and the reason is the management-system asymmetry above.

Going SOC 2 first and adding ISO 27001 means your controls exist and your evidence habits are formed, and the ISO work is mostly documentation: risk methodology, Statement of Applicability, internal audit, management review. Going ISO 27001 first and adding SOC 2 means the governance machinery already exists, and SOC 2 becomes mostly a scoping decision plus a system description plus an examination. Both work. Which is cheaper for you depends on which is already partly built.

What is genuinely inefficient is running both from zero simultaneously with two different providers and two different evidence structures, which we still see, usually because two customers asked in the same quarter and two projects got started in parallel. If both are truly needed at once, run one control register and one evidence store, and let the two examinations draw from it.

Where Top Floor fits

Multi-framework scope is the case where outside help earns its fee most clearly, and we will say the reverse just as plainly: if you hold one framework, your scope is stable, and someone internal owns the control register, adding a second framework is a documentation project you can run yourself. Where compliance as a service pays for itself is when the register does not exist, when three frameworks are in flight against different customer deadlines, or when the tagging discipline keeps losing to the roadmap. The framework mapping resource is free and public precisely because the mapping is not the hard part. The habit is.

Frequently asked questions

How much do SOC 2 and ISO 27001 overlap?

Substantially, across the control domains that matter most: access management, encryption, incident response, vendor management, change management, business continuity and awareness training are core to both. We do not publish a single overlap percentage, because no defensible one exists at the control level: SOC 2's criteria and ISO 27001's clauses are structured too differently to divide one by the other. The difference is structural: ISO 27001 is a management system standard, so its clauses 4 through 10 require a documented risk methodology, a Statement of Applicability, an internal audit programme and management review, none of which SOC 2 asks for. That residual is where the second framework's real work sits.

Does a SOC 2 report make us HIPAA compliant?

No. A SOC 2 report is an opinion on controls you selected against the Trust Services Criteria; HIPAA is a regulation with its own required artifacts, including business associate agreements, a risk analysis in the Security Rule's terms, and breach notification procedures. Much of the underlying control evidence is reusable, which is the useful part, but the report itself does not substitute for the regulation's own documentation, and a covered entity asking for HIPAA assurance is not asking for your SOC 2.

Will our second audit be cheaper?

Your preparation will be substantially cheaper; the examination fee usually will not be. Overlap reduces internal hours, remediation work, and evidence collection, which is where most of the first framework's cost sits. It does not reduce the independent work a different examiner or certification body has to perform. When you evaluate a quote for a second framework, ask the provider to identify, control by control, what they consider reused versus net-new.

When should we tag evidence to multiple frameworks?

At collection time, always, even if you only hold one framework today. Adding a tag to an artifact as you file it costs seconds; reconstructing a year of artifacts and mapping them retroactively is a project that competes with the deadline that prompted it. If you expect ever to add a framework, organise the evidence store around your controls rather than around one framework's numbering, and keep the framework references as attributes of each control.