The second framework is where most compliance programs start to hurt. SOC 2 went fine; then a healthcare customer asks about HIPAA, a European prospect wants ISO 27001, and payments brings PCI DSS. Each framework arrives with its own spreadsheet, its own wording and its own evidence requests — and the team ends up proving the same MFA setting four times.
The way out is to stop working per framework. This post explains the unified control set behind InsightAssure, shows the real mappings for four representative controls, and covers scoping and the ISO Statement of Applicability.
Requirements are not controls
A framework requirement says what must be true. A control is what you do to make it true. The two have a many-to-many relationship:
- One control satisfies many requirements. Enforcing MFA satisfies SOC 2 CC6.1, ISO 27001 A.8.5, HIPAA §164.312(d) and PCI DSS 8.4.
- One requirement needs several controls. SOC 2 CC6.1 (logical access security) is addressed by unique accounts, MFA, password requirements, privileged access, encryption at rest, network segmentation and more.
If you organize the program by requirement, you duplicate work. If you organize it by control — and map each control to every requirement it satisfies — you test once and report everywhere.
The library
InsightAssure ships eight frameworks — SOC 2, SOC 1, ISO/IEC 27001:2022, HIPAA Security Rule (with breach notification), PCI DSS v4.0.1, NIST CSF 2.0, GDPR and ISO/IEC 42001:2023 — totalling 559 requirements, and a set of 114 unified controls in 19 domains (governance, HR, risk, vendors, assets, access control, endpoints, network, cryptography, logging, vulnerabilities, change management, continuity, incident response, physical, privacy, processing integrity, confidentiality and AI governance).
Every requirement in the library lists the controls that satisfy it. Each control carries an auditor-facing statement, a frequency, whether it is automated, manual or hybrid, a test procedure (what an auditor does to test it), evidence guidance, and the policy templates that govern it.
Four controls, mapped
These are the actual mappings in the library, not illustrations.
| Control | SOC 2 | SOC 1 | ISO 27001:2022 | HIPAA | PCI DSS 4.0.1 | NIST CSF 2.0 | GDPR |
|---|---|---|---|---|---|---|---|
| IAM-02 Multi-factor authentication | CC6.1, CC6.6 | CO-01 | A.8.5 | 164.312(d) | 8.4, 8.5 | PR.AA-03 | Art. 32 |
| CHG-02 Peer review of changes | CC5.2, CC6.8, CC8.1 | CO-02 | A.8.30, A.8.32 | 164.312(c)(1) | 6.2, 6.5 | PR.PS-06 | — |
| BCP-01 Backups | CC7.5, CC9.1, A1.2, PI1.5 | CO-05 | A.8.13 | 164.308(a)(7)(ii)(A), 164.310(d)(2)(iv) | — | PR.DS-11 | Art. 32 |
| VND-03 Annual review of critical vendors | CC4.1, CC9.2, P6.4 | CO-09 | A.5.22 | — | 12.8 | GV.RM-05, GV.SC-07, GV.SC-09, DE.CM-06 | — |
CHG-02 also maps to ISO 42001 A.6.2.5, and VND-03 to ISO 42001 A.10.3. A dash means the framework does not address that control directly (HIPAA's vendor requirements, for instance, sit with business associate agreements, which map to VND-04 rather than VND-03).
What this buys you in practice:
- IAM-02 is backed by three monitors:
idp.mfa_enforced,accounts.mfa_all_systemsandaccounts.admin_mfa. Fix MFA once and seven frameworks' requirements move. - CHG-02 is backed by branch-protection monitors and
changes.peer_reviewed, which reads every merged change from GitHub, GitLab, Bitbucket or Azure DevOps and checks for an approval from someone other than the author. The same changes become the auditor's population for every framework that asks about change management. - BCP-01 is backed by
db.backups(backups on, ≥ 7 days retention),db.deletion_protectionandstorage.versioning. BCP-02 (the annual restore test) is a separate, manual control because a backup you have never restored is not a control. - VND-03 is backed by
vendors.reviewed; the review itself records the vendor's SOC report and maps the CUECs it places on you to your controls.
What fixing one control does
Take the Northwind demo workspace, where two people have MFA disabled in the identity provider. idp.mfa_enforced is failing, so IAM-02 is failing, so every requirement IAM-02 maps to is in progress rather than met — in SOC 2, SOC 1, ISO 27001, HIPAA, PCI DSS, NIST CSF and GDPR at once. The issue opened by the monitor names the two accounts.
When the identity admin enrolls those two people, the next sync (or a manual "run now") turns the monitor green, resolves the issue with a note, sets IAM-02 to passing if its other monitors and evidence allow, and re-evaluates every one of those requirements. One fix, seven frameworks, no spreadsheet. The reverse is just as automatic: if someone later disables MFA for a contractor, all seven move back.
How adoption works
Adopting a framework copies its requirements into the organization, creates any controls it needs that do not exist yet, and links them. Controls already present from another framework are reused, not duplicated — adopt ISO 27001 after SOC 2 and most Annex A controls land on controls you already operate, so the work that remains is mostly the ISO-specific management-system clauses rather than re-proving MFA or backups.
Adopting again later adds whatever the library gained since; it never overwrites what the organization changed. That matters because the copies are yours: you can reword a control statement, change an owner or frequency, remap a requirement, or add a custom framework (a customer's security schedule, an internal standard) and map it onto the same controls.
Scoping
Not every requirement applies to every organization, and every framework expects you to say so — with a reason.
- SOC 2: the Security category (CC1–CC9) is always in scope. Availability, Confidentiality, Processing Integrity and Privacy are chosen per report; criteria in categories you leave out are marked out of scope with the note "Category not in the scope of this report".
- Individual requirements: a requirement can be taken out of scope only with a justification. The API refuses an out-of-scope change without one, because it is the first thing an auditor asks to see.
- Controls: a control can be marked not applicable, again with a reason — for example PHY-01 office access for a fully remote company, with physical security of data centers covered by the cloud provider (PHY-02).
- Resources: a single bucket, account or laptop can be excluded from scope with a note, so a sandbox account does not fail production tests.
The ISO 27001 Statement of Applicability
ISO 27001 makes scoping formal: clause 6.1.3 requires a Statement of Applicability (SoA) listing every Annex A control, whether it applies, the justification for including or excluding it, and its implementation status.
In InsightAssure the SoA is a view of data you already maintain. The ISO framework carries the 93 Annex A controls (37 organizational, 8 people, 14 physical, 34 technological) plus the management-system clauses 4–10. Each Annex A requirement's in-scope flag and scope note is the applicability decision and justification; its status — met, in progress, gap — comes from the health of the mapped controls.
Where unified controls stop
Cross-mapping is powerful, but it has limits worth stating plainly:
- Wording still differs. A HIPAA auditor reads "addressable implementation specifications"; a PCI QSA tests to the letter of a defined requirement. The control is shared; the narrative in each report is not.
- Some requirements are framework-specific. PCI DSS cardholder-data environment segmentation, HIPAA business associate agreements, GDPR data-subject rights and ISO 42001 AI impact assessments each need controls that other frameworks never ask for. The library includes them (PRV-02, PRV-05, AI-01 …) and only the frameworks that need them pull them in.
- Evidence windows differ by auditor. The library's windows (quarterly controls 120 days, annual 395) are sensible defaults; your auditor's period and sampling decide what actually gets tested.
- Certification bodies and CPA firms decide. A mapping is your assertion. Expect the auditor to review it, and expect to adjust a few.
A practical order of adoption
For a cloud SaaS company the usual sequence is SOC 2 first (broadest coverage of the shared controls), then ISO 27001 (adds the management-system clauses: risk methodology, internal audit, management review, the SoA), then the industry framework your customers demand — HIPAA for healthcare, PCI DSS if you touch card data, SOC 1 if you process customers' financial data. ISO 42001 is increasingly asked of companies building AI features. Each one after the first costs a fraction of the first, because most of its requirements land on controls that are already passing.
