Your ISO 27001 auditor wants evidence for A.8.9 configuration management. Your SOC 2 assessor wants the same control mapped to CC6.1. Your Cyber Essentials assessor wants to see secure configuration under CE5. Three frameworks, three evidence requests, one underlying control — and your security team is exporting the same AWS Config screenshots three separate times.
This is the audit fatigue tax UK firms pay when they treat frameworks as silos. A mid-sized SaaS business pursuing ISO 27001 certification, SOC 2 Type II for US customers, and Cyber Essentials Plus for UK public sector tenders can easily run 600+ control evidence requests across a single audit cycle. Most of those controls overlap. The work doesn't have to.
Cloud security framework mapping — done properly — collapses that overlap into a single control library with multiple compliance outputs. Here's how our consultants approach it, and where most internal teams get it wrong.
What framework mapping actually means
Framework mapping is the discipline of building one authoritative control set, then expressing it against multiple compliance schemes. You define the technical control once — say, "MFA enforced for all privileged IAM users in AWS, evidenced by IAM Credential Report" — and tag it to every framework requirement it satisfies.
For a typical UK cloud-native business, that single MFA control answers ISO 27001:2022 Annex A.5.17 (authentication information), A.8.5 (secure authentication), SOC 2 CC6.1 (logical access), Cyber Essentials CE2 (user access control), and NIST CSF 2.0 PR.AA-01. One piece of evidence. Five framework citations.
The mapping itself is not the hard part. NIST publishes the Cybersecurity Framework 2.0 Informative References, and ISO 27001:2022 Annex A is well-cross-walked against CIS Controls v8 and the AICPA Trust Services Criteria. The hard part is operationalising the mapping so audit evidence flows automatically rather than being manually rebuilt each cycle.
Why this matters now for UK firms
Three pressures are converging in 2026.
First, the Cyber Security and Resilience Bill, currently progressing through Parliament, will widen the scope of regulated entities under the UK's NIS Regulations 2018 — bringing managed service providers and a broader set of digital services into scope. Firms that previously sat outside formal cyber regulation will need defensible control evidence.
Second, UK firms with EU customers or EU subsidiaries face NIS2 Directive obligations through those entities (for EU-based entities, transposed into national law across member states since October 2024). The control demands are similar to UK NIS but the evidence formats differ. Mapping prevents duplicate work.
Third, UK financial services firms operate under the FCA's PS21/3 Operational Resilience rules, with the transition period having ended 31 March 2025. Important business services must demonstrate impact tolerances are tested — and the underlying ICT controls overlap heavily with ISO 27001 Annex A.5.30 (ICT readiness for business continuity) and A.8.14 (redundancy of information processing facilities).
The firms that built mapped control libraries before these pressures hit are the ones running clean audits today. The firms still running parallel compliance projects are burning consultancy budget and team capacity.
Practical implementation: how to build a mapped control library
1. Anchor on one framework as your control taxonomy
Pick ISO 27001:2022 Annex A or NIST CSF 2.0 as your primary structure. Annex A's 93 controls are the right granularity for most cloud-native UK firms. NIST CSF 2.0 works better if your stakeholders include US partners. Pick one. Don't try to merge taxonomies.
2. Map every other framework into your primary
Build a control register where each row is a control, and columns include: ISO 27001:2022 reference, SOC 2 TSC, Cyber Essentials question, CIS Controls v8 safeguard, and NIST CSF 2.0 subcategory. The CIS Controls Navigator is a free starting point.
3. Tie every control to a cloud-native evidence source
This is where most internal teams stop short. A control without an automated evidence source becomes a manual screenshot exercise every audit cycle. For AWS, point controls at AWS Config rules, Security Hub findings, and IAM Access Analyser reports. For Azure, use Microsoft Defender for Cloud regulatory compliance dashboards. For GCP, Security Command Centre.
4. Define evidence freshness rules
SOC 2 Type II requires evidence across the entire audit period (typically six to twelve months). ISO 27001 surveillance audits sample point-in-time and operating effectiveness. Cyber Essentials Plus is point-in-time. Tag each evidence artefact with its freshness requirement so you know what needs continuous capture versus annual snapshot.
Common mistakes our consultants see
Mapping at the wrong altitude. Teams map "access control" as a single concept across frameworks. That's too coarse. Map at the specific safeguard level — privileged access review frequency, session timeout values, MFA enforcement scope. Coarse mapping fails audits because the auditor asks specific questions.
Treating Cyber Essentials as a stepping stone, then rebuilding from scratch for ISO 27001. Cyber Essentials' five technical controls map cleanly into ISO 27001 Annex A. If you scoped Cyber Essentials properly, 30-40% of your ISO 27001 control evidence already exists. Don't restart.
Ignoring shared responsibility boundaries. Your AWS, Azure, or GCP provider holds SOC 2 and ISO 27001 certifications covering the underlying infrastructure. Reference their compliance reports for in-scope controls rather than evidencing physical security yourself. The AWS Artifact, Azure Service Trust Portal, and Google Cloud Compliance Reports Manager exist for exactly this.
Letting the mapping go stale. ISO 27001:2022 replaced the 2013 version's 114 controls with 93 restructured ones. Firms that mapped against the old standard and didn't refresh their library walked into transition audits unprep