Common Control Framework: Map SOC 2, ISO 27001 and HIPAA Once

A common control framework (CCF) is a single set of controls mapped to every compliance framework you follow. Instead of running SOC 2, ISO 27001, HIPAA and GDPR as separate projects, you implement each control once and show auditors how it satisfies each standard. For a small company adding a second or third framework, it is the biggest time saver available.

Related guides: Mapping SOC 2 and ISO 27001 common criteria · SOC 2 Trust Services Criteria · ISO 27001 Annex A controls · Audit fatigue and how to fix it

Key takeaways

• A common control framework lets one control satisfy many requirements across SOC 2, ISO 27001, HIPAA, GDPR, PCI DSS and others.
• Most security frameworks overlap heavily on access control, change management, logging, incident response, vendor management and risk assessment.
• Build it around your own controls, written in your language, then map them outward to each framework.
• Public reference frameworks such as the Secure Controls Framework and NIST mappings can speed up the mapping.

---

Why use a common control framework?

Without a CCF, each new framework brings a new spreadsheet, new policies, new evidence requests and new owners. Engineers answer the same question for different auditors, and evidence goes stale in one place while being updated in another. With a CCF:

• Each control has one owner, one procedure and one evidence trail
• A new framework becomes a gap analysis, not a new program
• Auditors see consistent evidence, and customers get consistent questionnaire answers
• You can see at a glance which controls support which certifications

How frameworks overlap

Control area	SOC 2	ISO 27001:2022	HIPAA Security Rule	GDPR
Risk assessment	CC3	Clause 6.1, 8.2	164.308(a)(1) risk analysis	Article 32, 35
Access control and MFA	CC6.1 to CC6.3	A.5.15 to A.5.18, A.8.5	164.312(a), (d)	Article 32
Access reviews	CC6.2, CC6.3	A.5.18	164.308(a)(4)	Article 32
Encryption	CC6.1, CC6.7	A.8.24	164.312(a)(2)(iv), (e)	Article 32
Logging and monitoring	CC7.2	A.8.15, A.8.16	164.312(b)	Article 32
Change management	CC8.1	A.8.32	164.312(c)(1) integrity (indirect)	Articles 25, 32
Incident response	CC7.3 to CC7.5	A.5.24 to A.5.28	164.308(a)(6)	Articles 33, 34
Vendor management	CC9.2	A.5.19 to A.5.22	164.308(b) business associates	Article 28
Business continuity	A1.2, A1.3	A.5.29, A.5.30	164.308(a)(7)	Article 32
Security training	CC1.4, CC2.2	A.6.3	164.308(a)(5)	Articles 32(4), 39(1)(b)

The mappings are approximate and should be confirmed for your scope, but they show how much work one well-run control can cover.

How to build a common control framework

1. Start from your primary framework

Use the framework you implemented first, often SOC 2 or ISO 27001, as the base. Its controls are already running.

2. Rewrite controls in your own words

Write each control as a clear statement of what your company does, for example "All production access requires SSO with MFA and is reviewed quarterly by the system owner." Avoid copying framework text.

3. Give each control an ID, owner and frequency

Use your own IDs, such as AC-01, with a named owner, how often it runs and the evidence it produces.

4. Map to each framework

Link each control to the requirements it satisfies in every framework. One control often maps to several requirements, and one requirement to several controls.

5. Run a gap analysis for new frameworks

When you add HIPAA or ISO 27001, map its requirements to your existing controls. Only the unmapped requirements need new work. These are often management system clauses for ISO 27001, or business associate agreements and PHI-specific rules for HIPAA.

6. Collect evidence once

Store evidence against the control, not the framework. Auditors for each standard then sample from the same evidence.

7. Maintain the mapping

When a framework is updated, as ISO 27001 was in 2022 and PCI DSS in version 4, update the mapping rather than rebuilding controls.

Reference frameworks that help

• Secure Controls Framework (SCF): a free, open meta-framework mapping hundreds of controls to many laws and standards
• NIST SP 800-53 and NIST CSF: often used as the hub for mappings, especially for US government work
• Official mappings: for example the AICPA mapping of the Trust Services Criteria to ISO 27001, and HHS crosswalks from HIPAA to NIST

These give you a starting point. Your CCF should still be written around how your company works.

How much effort a CCF saves

For a SaaS company that already holds SOC 2, adding ISO 27001 through a CCF is a fraction of the effort of starting from scratch, because most technical controls are already in place and mapped. The remaining work is mostly the ISMS clauses, the Statement of Applicability and a few extra controls. Adding HIPAA is often smaller still for a company with SOC 2, focusing on PHI handling, business associate agreements and HIPAA-specific documentation.

Example of a mapped control

Field	Value
Control ID	AC-04
Control	Access to in-scope systems is reviewed quarterly by system owners, and access no longer needed is removed within five business days
Owner	Head of IT
Frequency	Quarterly
Evidence	Signed access review export per system, tickets for removals
SOC 2	CC6.2, CC6.3
ISO 27001:2022	A.5.18
HIPAA	164.308(a)(4)(ii)(C)
GDPR	Article 32(1)(b)
PCI DSS v4.0	Requirement 7.2.4

One control, one review per quarter, and five frameworks covered.

Adding a new framework with a CCF

When a customer asks for a new standard, list its requirements, map each one to your existing controls, and mark it as covered, partly covered or missing. Write new controls only for the gaps, assign owners, and attach the new framework to existing evidence. The result is a clear project plan and a realistic timeline you can share with the customer.

Common mistakes

• Keeping separate control lists per framework and syncing them by hand
• Mapping at too high a level, such as "access control", so auditors cannot follow it
• Copying a large reference framework wholesale, with hundreds of controls nobody runs
• Forgetting to update mappings when a framework changes

How SecureSlate helps

SecureSlate is built around a common control set mapped to SOC 2, ISO 27001, HIPAA, GDPR, ISO 42001, PCI DSS, NIST CSF and more. Multi-framework compliance means one control, one owner and one piece of evidence count toward every framework you need.

FAQ

What is a common control framework?

It is a single, unified set of controls that an organization maps to all the compliance frameworks it follows, so each control is implemented and evidenced once.

Is the Secure Controls Framework the same as a common control framework?

The SCF is a public meta-framework you can use as a starting point. Your own common control framework is the set of controls your company actually runs, mapped to the standards you need.

How much do SOC 2 and ISO 27001 overlap?

Heavily. Most technical and operational controls are shared. ISO 27001 adds management system requirements, such as internal audit and management review, and a Statement of Applicability.

When should a company build a common control framework?

As soon as it plans a second framework. Building it at that point is far easier than merging two separate programs later.

---

How many controls should a common control framework have?

For a small SaaS company covering SOC 2, ISO 27001 and HIPAA, around 100 to 150 well-defined controls is typical. Far more usually means duplication.

Can we buy a ready-made common control framework?

Many compliance platforms include one, already mapped to major frameworks. Review and adapt the controls so they describe how your company actually works.

Does a common control framework work for privacy laws too?

Yes. Privacy requirements such as data subject rights, retention and DPAs can be added as controls and mapped to GDPR, CCPA and other laws alongside security frameworks.

Who should own the common control framework?

The compliance or security lead owns the framework and mappings, while each control has its own operational owner in engineering, IT, HR or legal.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory, or professional advice. Requirements vary by framework, industry, and jurisdiction. Consult qualified advisors for your specific obligations.