If you are a security architect, GRC manager, or compliance lead, you have almost certainly maintained a spreadsheet that maps controls from one framework to another. You have sat in meetings where someone asks which ISO 27001 clauses are satisfied by the NIST controls you have already implemented. You have spent days preparing evidence for an auditor who needs to see the same controls through the lens of a different framework.
Today we are publishing something that should make a significant part of that work unnecessary.
OSA now provides bidirectional compliance mappings between NIST SP 800-53 Rev 5 and 21 major frameworks, plus clause-level coverage analysis for 14 of them. That is 8,604 individual mappings, 660 framework clauses analysed, and every mapping available as structured JSON via our API. All free, all open source.
Explore the framework mappings
The Problem We Are Solving
Compliance mapping is one of the most time-consuming and least rewarding tasks in security architecture. It is also one of the most duplicated. Thousands of organisations independently build the same crosswalks between the same frameworks, producing slightly different results because the work is done manually, by different people, under different time pressures.
The result is a compliance industry built on spreadsheets. A GRC analyst at a bank spends two weeks mapping PCI DSS v4 requirements to their NIST control baseline. A security architect at an insurer does the same for APRA CPS 234. A consultant rebuilds the ISO 27001 to SP 800-53 mapping for every new client. The intellectual effort is real, but the output is rarely reusable, rarely machine-readable, and rarely maintained after the initial engagement.
This matters most for practitioners in lines two and three — the security architects, risk managers, GRC leads, and programme managers who sit between the board and the operations floor. These are the people who must translate regulatory obligations into implementable controls, demonstrate compliance across multiple frameworks simultaneously, and justify security investment to stakeholders who think in different compliance languages.
What We Have Published
Every framework now has three views, accessible from the framework page:
Framework to SP 800-53
Start from a framework clause and see which SP 800-53 controls address it. This is the view a compliance lead uses when preparing for an audit: "I need to demonstrate compliance with ISO 27001 clause 8.1 — which NIST controls do we have in place that satisfy this?"
For example, ISO 27001:2022 shows all 117 clauses ordered by clause ID, each linked to the SP 800-53 controls that address it. A compliance manager can walk through each clause systematically and trace it to implemented controls.
SP 800-53 to Framework
Start from a SP 800-53 control and see which framework clauses it maps to. This is the view a security architect uses when assessing what a control implementation buys them across multiple compliance obligations: "We have implemented AC-02 Account Management — which ISO 27001, PCI DSS, and DORA requirements does this help satisfy?"
This view is grouped by NIST control family, so you can see the compliance reach of your entire access control programme, your audit logging capability, or your incident response controls at a glance.
Coverage Analysis
For 14 frameworks, we provide a clause-by-clause coverage assessment: how well does the SP 800-53 control set address each framework requirement? Each clause receives a coverage percentage, a rationale explaining the mapping logic, and a gap statement identifying what SP 800-53 does not cover.
This is the view a risk manager uses to understand residual compliance risk: "We have a strong SP 800-53 baseline, but where does it fall short of NIS2? What additional controls do we need beyond NIST?"
The NIS2 coverage analysis, for example, shows that while SP 800-53 provides strong technical coverage for most NIS2 articles, it has gaps in areas like supply chain notification obligations and regulatory reporting timelines — requirements that are procedural and jurisdictional rather than technical.
The 21 Frameworks
The mapping library covers the frameworks that practitioners in regulated industries encounter most frequently:
International standards: ISO 27001:2022, ISO 27002:2022, ISO 42001:2023, COBIT 2019
NIST family: NIST CSF 2.0 (the strategic companion to SP 800-53's operational detail)
Industry-specific: PCI DSS v4.0.1, CIS Controls v8, SOC 2 TSC, FINOS CCC, IEC 62443, ASD Essential Eight
Regulatory: NIS2 Directive, EU DORA, EU GDPR, UK PRA/FCA, MAS TRM, APRA CPS 234, BSI IT-Grundschutz, ANSSI, FINMA Circular 2023/1, OSFI B-13
This selection reflects where our practitioners work. Our analytics show traffic from over 100 countries, with concentration in the US, UK, Singapore, Germany, Australia, Switzerland, and Canada. We have prioritised the frameworks that serve these jurisdictions, particularly financial services regulation where security architecture requirements are most prescriptive.
Why This Matters for Lines Two and Three
The CISO sets the strategy. The SOC handles the incidents. But the people in the middle — the ones who design the controls, run the compliance programmes, prepare the audit evidence, and justify the budget — are the ones who need this data most.
Consider three scenarios that play out daily in regulated organisations:
The multi-framework audit. Your organisation is subject to ISO 27001, PCI DSS, and DORA. Three frameworks, three audit cycles, three sets of evidence requests. But the underlying controls are substantially the same. A security architect who can show that AC-02 (Account Management) simultaneously satisfies ISO 27001 A.5.15, PCI DSS 7.2.1-7.2.6, and DORA Art.9(4)(b) reduces evidence preparation from weeks to days. That is what the SP 800-53 to framework view provides.
The gap analysis. Your CISO asks: "We have a mature NIST baseline. What additional work do we need for NIS2 compliance?" Without a mapping, this question requires a consultant engagement. With OSA's coverage analysis, you can see immediately that SP 800-53 covers 78% of NIS2 requirements on average, with specific gaps in supply chain notification (Art.23), coordinated vulnerability disclosure (Art.12), and management body accountability (Art.20). That is a concrete workplan, not a consulting proposal.
The control rationalisation. You are implementing a new control — say, privileged access management. Your GRC manager asks which compliance requirements it satisfies. Rather than searching through six different framework documents, you look up the relevant SP 800-53 controls (AC-06, AC-06(1) through AC-06(10)) and see every framework clause they map to across all 21 frameworks. That turns a half-day research task into a five-minute lookup.
These are not edge cases. They are the routine work of security governance in any regulated organisation. Making them faster and more reliable is not glamorous, but it compounds. A security team that spends 30% less time on compliance mapping has 30% more time for architecture, threat modelling, and the work that actually reduces risk.
Mapping Methodology
We take the mapping methodology seriously because practitioners need to trust the data. The full methodology is published on the framework mappings page, but the key principles are:
Control-objective alignment, not keyword matching. Each mapping is derived by comparing the security objective of a SP 800-53 control against the intent of a framework requirement. We do not map based on superficial keyword overlap.
Many-to-many relationships. A single NIST control may map to multiple framework requirements, and vice versa. We map every meaningful relationship rather than forcing one-to-one pairings.
Maximum granularity. We cite the most specific reference available: article sub-paragraphs for NIS2, margin numbers for FINMA, individual safeguards for CIS Controls. Broad section-level references are used only when the framework itself does not decompose further.
Coverage weightings are expert judgement. The coverage percentages in our analysis represent informed professional assessment of how well SP 800-53 addresses each requirement. They are not mechanical scores. A clause rated at 70% means that SP 800-53 covers the majority of the requirement's intent but has identifiable gaps — and we tell you what those gaps are.
API Access
All mapping data is available programmatically via the OSA API. The /api/v1/frameworks endpoint lists all 21 frameworks with control counts and mapping totals. The /api/v1/frameworks/{id}?fields=mappings endpoint returns paginated mapping data for any framework.
This means you can integrate OSA's mappings into your GRC tooling, build automated compliance dashboards, or generate framework-specific evidence matrices programmatically. The data is structured JSON, version-controlled in Git, and validated on every commit.
What Is Next
The mapping library will grow as frameworks evolve. When PCI DSS publishes a revision, we update the mappings. When a new framework gains regulatory traction, we add it. The SP 800-53 Rev 5 control catalogue is the stable anchor — it changes infrequently, so most updates are driven by framework revisions.
We are also working toward connecting these mappings to OSA's maturity assessments. The vision: complete an assessment against a security pattern, and see not just your maturity gaps, but which compliance obligations those gaps affect across every mapped framework. That turns a maturity score into a compliance risk statement — actionable data for the people who need to prioritise remediation.
If you work in security architecture, GRC, or compliance, we built this for you. Browse the framework mappings, trace a few clauses through to controls, and tell us where the mappings need refinement. Every mapping is stored as structured data in our open source repository — pull requests and issues are welcome.
Chris Lethaby — Co-founder, Open Security Architecture