Compliance Strategy: How To Build a Multi-Framework Program

Key takeaways:

• Most startups pursuing SOC 2 and ISO 27001 simultaneously duplicate 60–80% of the underlying work by conducting separate risk assessments, policy libraries, and evidence collection, when a single integrated program would cover both.
• The most common multi-framework combinations for B2B SaaS startups are SOC 2 + ISO 27001 (US + EU markets), SOC 2 + HIPAA (HealthTech), and ISO 27001 + GDPR (EU-native or EU-expanding companies). Each pair has significant control overlap.
• The starting point is the same: one risk assessment, one policy library, and one evidence repository that maps to all frameworks simultaneously, instead of one per framework.
• A control crosswalk, a document that maps a single implemented control to multiple framework requirements, is the operational core of any multi-framework program and the most effective way to eliminate duplicate audit work.
• Working with a multi-framework auditor or consultant reduces total compliance cost by 30–50% compared to running each framework as a separate engagement.

‍

The most expensive compliance mistake I see startups make is treating each framework as a separate project.

A startup that built its SOC 2 program carefully and then started ISO 27001 as a new project ends up with two risk registers covering the same risks, two access control policies with slightly different wording, two sets of vendor due diligence records for the same vendors, and two separate evidence collection cycles for auditors who are largely looking at the same underlying controls. 

‍

Doing that has a cost that goes beyond the financial one. It costs the engineering and ops time that comes with running parallel compliance programs when one well-designed program would have served both.

‍

This post covers how to build that integrated program: the architecture decisions that matter, the control combinations that apply to the most common framework pairs, and the places where frameworks genuinely require separate work.

‍

Why Multi-Framework Programs Get Duplicated by Default

‍

The typical pattern goes like this: a startup builds its SOC 2 program when the first enterprise deal requires it. Twelve months later, a European prospect asks for ISO 27001 certification. The team treats ISO 27001 as a new project, assigns someone to manage it, and begins building it from scratch, not realizing that most of the foundation already exists.

‍

The result is two parallel compliance programs with 60–80% overlapping content. Access control is one of the clearest examples: SOC 2 and ISO 27001 both require access control policies, user provisioning processes, quarterly access reviews, and privileged access management. If those controls are already implemented and documented for SOC 2, there’s almost nothing new to build for ISO 27001, only a mapping to document.

‍

A multi-framework auditor or consultant designs the program to satisfy both frameworks simultaneously from the start. That typically reduces the total compliance cost by 30–50% compared to running two separate engagements. The reduction comes almost entirely from eliminating duplicated work on the overlapping controls.

The Most Common Multi-Framework Combinations

‍

The right level of integration depends on which frameworks you’re running and how much they genuinely overlap. Here’s how the most common pairs break down.

‍

SOC 2 + ISO 27001

‍

The most common combination for B2B SaaS startups selling into both US and European enterprise markets. SOC 2 is the standard US enterprise buyers expect, while ISO 27001 is the certification European and international buyers require.

‍

60–80% of controls are shared between the two frameworks. Access control, incident response, change management, vulnerability management, and vendor risk management all require essentially the same underlying controls. The difference is pretty much how they’re documented and what each auditor examines. 

‍

For a detailed breakdown of how these two frameworks align and where they diverge, check Is SOC 2 the same as ISO 27001?

‍

SOC 2 + HIPAA

‍

The standard combination for HealthTech startups handling protected health information (PHI) and selling to US enterprise healthcare buyers. 

‍

HIPAA’s Security Rule and SOC 2’s Security criteria share significant ground in access control, audit logging, incident response, and workforce training. 

‍

A startup that has built a solid SOC 2 Security program will find that most of the technical safeguards HIPAA requires are already in place. The net-new work is primarily in HIPAA’s Privacy Rule and the Business Associate Agreement infrastructure. For more on how these two frameworks relate, check SOC 2 vs HIPAA: Which Compliance Does Your Startup Need?.

ISO 27001 + GDPR

‍

This is a common combination for EU-native startups and US companies expanding into European markets. 

‍

ISO 27001’s control framework directly addresses GDPR’s technical and organisational measures, risk assessment, incident response, and vendor management, with a 60–70% overlap between what ISO 27001 requires and what GDPR’s security provisions demand. The ISO 27001 risk assessment feeds the GDPR Data Protection Impact Assessment process. 

ISO 27001’s access controls satisfy GDPR’s technical measures. And the incident response plan covers the 72-hour breach notification window. For the full picture of where they align and where they don’t, check GDPR and ISO 27001: How They Overlap for European Startups.

The Architecture of a Multi-Framework Program

‍

Regardless of which frameworks you’re running, the structural principle is the same: build the program once, map it to multiple frameworks, and collect evidence once rather than separately for each audit.

‍

A single risk assessment

‍

The risk of unauthorized access to customer data is the same regardless of whether you’re assessing it for SOC 2, ISO 27001, or HIPAA. A single risk register that identifies the risk, rates its likelihood and impact, and documents how it’s treated satisfies the risk assessment requirements of all frameworks simultaneously. The mapping to specific framework criteria is a documentation step.

‍

One policy library with multiple framework references

‍

An access control policy that references SOC 2, ISO 27001, and HIPAA in its scope section is a single document that satisfies three frameworks. 

‍

Writing three separate access control policies that say the same thing creates maintenance overhead with no compliance benefit. The policy is the same, and the mapping annotations make it multi-framework.

‍

One evidence repository with framework tags

‍

A quarterly access review completed in Q1 produces one set of evidence: the dated log showing which accounts were reviewed, which were flagged, and what changed. That same evidence satisfies SOC 2, ISO 27001, and HIPAA requirements. 

‍

Collect it once, tag it to the relevant framework criteria, and point all three auditors to the same artifact. 

‍

Building a Control Crosswalk

‍

A control crosswalk is a table that maps each implemented control to the specific criteria it satisfies across multiple frameworks. It’s the operational core of any multi-framework program and the artifact that most effectively eliminates duplicate audit work, because it makes the mapping explicit for every auditor.

‍

That way, there’s no need to independently verify which controls satisfy each framework's requirements.

‍

Here’s an example of what a crosswalk looks like for three commonly shared controls:

‍

‍

The crosswalk works in both directions. If you’re adding a second framework to an existing programme, it tells you which controls you already have that satisfy the new framework’s requirements, and which requirements have no existing control mapped to them, meaning they represent net-new work. That gap list becomes the implementation scope for the second framework.

‍

Most compliance automation platforms (like Vanta, Drata, and Secureframe) support multi-framework tagging natively, which automates the crosswalk at the evidence level. The strategic design decisions, such as which controls to implement, how to structure the policy library, and how to scope the risk assessment, still need to be made once, deliberately, before the platform is configured.

‍

What You Still Have to Do Separately

‍

Integrated programs reduce duplicated work on shared controls. But, of course, they don’t eliminate work that’s genuinely unique to each framework. 

‍

Being clear about what the overlap doesn’t cover is important for scoping the effort realistically.

SOC 2

‍

• Defining and documenting your system description and Trust Services Criteria scope.
• Selecting and engaging an AICPA-licensed CPA firm. 

‍

The Type 2 observation period and the resulting audit report are specific to SOC 2 and have no equivalent in ISO 27001 or HIPAA.

‍

ISO 27001

‍

• The Statement of Applicability (document each of the controls as applicable or excluded, with justification).
• The formal internal audit programme.
• The management review process.
• The certification by an accredited certification body. 

‍

These are structural requirements of the ISO 27001 management system that SOC 2 doesn’t require. Check our guide to the Statement of Applicability for a detailed walkthrough.

‍

HIPAA

‍

• Business Associate Agreements with every vendor that handles PHI. 
• Privacy Rule compliance: data subject rights, Notice of Privacy Practices, and minimum necessary standard. 
• Breach Notification Rule: documented procedures for notifying affected individuals and HHS within required timeframes. 

‍

These are legal obligations specific to HIPAA with no direct equivalent in SOC 2 or ISO 27001.

‍

GDPR

‍

• Lawful basis for each processing activity. 
• Data subject rights procedures (access, erasure, portability, objection). 
• Privacy notices. 
• Data transfer mechanisms for cross-border transfers (SCCs, adequacy decisions). 

‍

These go beyond what ISO 27001’s technical controls cover and require separate GDPR-specific work regardless of certification status.

‍

The shared controls across all four cover the security and risk management layer. What’s unique to each framework is either the management system structure (ISO 27001), the attestation format and audit mechanics (SOC 2), or the legal and privacy obligations (HIPAA and GDPR). Building one integrated security program handles the first, while the others require dedicated attention.

‍

Building a Program That Satisfies All Your Frameworks

‍

At SecureLeap, we design the control architecture once, map it to all relevant frameworks, and coordinate the audit cycles so evidence collected for one framework feeds the others. 

‍

That way, our clients pursuing SOC 2 and ISO 27001 simultaneously, often with HIPAA or GDPR in the mix, have it all covered.

‍

The result is a compliance programme that costs less and stays current, instead of separate projects drifting at different rates.

Want to know what that would look like for the frameworks you’re pursuing? Book a free 30-min call or send us an email.

FAQ: Frequently asked questions

‍

Can I use the same controls for SOC 2 and ISO 27001?

‍

Yes, for the majority of controls. SOC 2 and ISO 27001 share 60–80% of their underlying security controls, particularly in access control, incident response, change management, and vendor risk management. A control implemented for one framework is typically already satisfying the equivalent requirement in the other. The net-new work when adding the second framework is primarily in the framework-specific structural requirements: the Statement of Applicability and internal audit programme for ISO 27001, and the system description and audit format for SOC 2.

What is a compliance framework crosswalk?

‍

A crosswalk is a document or table that maps each implemented security control to the specific criteria it satisfies across multiple compliance frameworks. Building a crosswalk makes the shared coverage explicit, tells you exactly which controls cover which requirements, and identifies the gaps that represent genuine net-new work when adding a framework.

‍

Should I pursue SOC 2 or ISO 27001 first?

‍

It depends on where your customers are. SOC 2 is the standard North American enterprise buyers expect, while ISO 27001 is the certificate European and international buyers require. If you sell primarily into US markets, SOC 2 first. If you sell into European or international markets, ISO 27001 first. If you sell into both, building a program that addresses both simultaneously from the start is more efficient than completing one and then adapting to the other. For a detailed decision framework, check Is SOC 2 the same as ISO 27001?

‍

Can compliance automation platforms handle multi-framework programs?

‍

Yes. Platforms like Vanta, Drata, and Secureframe support multi-framework tagging natively. A single control can be mapped to multiple frameworks, and evidence collected once is automatically referenced for all relevant audits. The platform handles the evidence logistics, while the strategic design decisions still need to be made deliberately before the platform is configured. Configuring a platform around a poorly designed program only automates the duplication.

‍