Multi-Framework Support
Collect evidence once and map it across every framework
Each framework brings its own requirements, so its controls differ. What does not differ is the evidence underneath. A test and the proof behind it attach to a control, and that control can satisfy clauses in several frameworks at once, so adding a standard becomes a mapping exercise rather than a second programme.
Why multi-framework matters
Your second framework is mostly your first one, written differently.
The same control, described four ways
Access control is A.5.15 to ISO, CC6.1 to SOC 2, an implementation specification to HIPAA, and requirement 7 to PCI DSS. It is one thing you do, and four vocabularies for describing it to different readers.
Run separately, they cost separately
A programme per framework means collecting the same evidence more than once, answering the same question in two formats, and discovering in the second audit that the first one already proved it.
The buyer decides the framework, not you
One customer needs SOC 2, the next wants ISO 27001, a European deal raises GDPR and a healthcare one raises HIPAA. Whether you can say yes quickly depends on how much of the work carries over.
One programme, several frameworks
Evidence collected once underneath, with separate requirements, scope, and progress for each framework on top.
Every Framework on One Page
ISO 27001, SOC 2, GDPR, HIPAA, PCI DSS, CMMC, ISO 9001, CCPA, and a unified US data privacy programme covering CCPA, CPRA, VCDPA and similar state laws, all in one list. Each card explains what the standard is for, so choosing your next one does not start with a research project.
Progress Tracked Per Framework
Each framework carries its own completion percentage against the controls in its scope, so two standards in flight are two separate numbers rather than one blended figure that hides which audit is actually at risk. Open the framework and you get its overview alongside every control mapped to it, so the number and the work behind it sit on the same screen.
One Control, Every Framework It Satisfies
Each control lists the frameworks it is mapped to, with the clause it meets under each: ISO 27001:2022 A.5.15 here, SOC 2 CC 6.1 there, and a count when it satisfies more than one. Every framework a control carries is a requirement you are already meeting, and the tests behind that control count for all of them at once.
Tests and Policies Serve All of Them
Evidence is collected once and overlaps across every control it supports, in every framework those controls are mapped to. A test proving encryption at rest satisfies each standard that asks for it, and an approved policy counts wherever it is mapped, which is the practical reason a second framework costs a fraction of the first.
Frameworks Sit Beside the Work
Frameworks live in the same place as your controls, reports, audits, and data room, so moving from a requirement to the control that satisfies it to the evidence behind it takes no context switch. The framework is a view onto the programme rather than a separate system.
See What a Framework Involves First
Every framework is visible whether or not it is switched on for your plan, with its purpose and scope explained. Look at what HIPAA, PCI DSS, or CCPA would actually mean for you before committing, and talk to us when you are ready to enable it.
Resources
Read up before adding the next one.
Practical guides to compliance frameworks and control mapping, including how the common standards compare and overlap.
FAQs
Multi-framework questions answered.
That you run one compliance programme rather than one per standard. Each framework has its own requirements, so its controls differ, but a control can be mapped to more than one framework, and the tests and evidence behind it then count for every framework it is mapped to.
Most of it. The two overlap heavily on access control, change management, encryption, monitoring, and vendor management, and differ mainly in structure and what the auditor produces at the end. In practice the second framework is largely a mapping and gap exercise rather than a fresh implementation.
ISO 27001, ISO 42001, ISO 9001, SOC 2, HIPAA, GDPR, PCI DSS, HITRUST, CMMC, FedRAMP, NIST CSF, NIS 2, DORA, the EU AI Act, Cyber Essentials, CCPA, and a unified US data privacy programme covering CCPA, CPRA, VCDPA, and similar state laws. Anything not on that list can be built as a custom framework.
Build it as a custom framework. Define its requirements, map them onto the controls you already run, and it behaves like any other framework in the platform, with its own progress, evidence, and audit. Internal standards and customer-specific security requirements are the usual reasons teams need one.
Yes. Each framework tracks its own completion against the controls in its scope. That matters when two audits are in flight, because a single blended percentage hides the one that is behind, and the one that is behind is the one with a date attached.
The controls list has a mapped frameworks column, so each control shows every standard it satisfies and the clause it meets under each. A control carrying both an ISO 27001 clause and a SOC 2 criterion is overlap you are getting for free, and the evidence behind it counts for both at once.
No. Automated tests keep running against the same systems, and the results are mapped to whichever frameworks require them. Policies already approved count wherever they are mapped. What is genuinely new in a second framework is usually a short list of requirements the first one did not cover.
Yes. Each audit is created against its own framework with its own window, auditor, and evidence tracker, while drawing on the same underlying controls. Teams commonly run ISO 27001 certification and a SOC 2 observation window in parallel for exactly that reason.
Usually your buyers decide. SOC 2 tends to come from North American enterprise deals, ISO 27001 from European and international ones, HIPAA from healthcare data, and PCI DSS from card payments. Because the control work carries over, the cost of the second one is far lower than the first.
No. Every framework is visible with its description and scope so you can see what it would involve, and the ones included depend on your plan. The frameworks page shows which are active for you and which need a conversation with us to enable.
Add your next framework the cheap way
See how much of your next standard your current controls already cover, and what is genuinely left to do.
