Original analysis · Needs validation · 3/5
What every framework agrees on.
Ask a security team which controls matter most and the honest answer is: whichever ones the last auditor came in asking about. PCI ranks them one way, the NIST baseline another, the ISO annex declines to rank them at all. The map that reconciles all of them already exists. This is what you see when you weight it by how much each standard actually counts, and read off where they converge.
The framework you were handed
The controls question has too many right answers.
Sit through enough audits and the pattern is hard to miss, because a control's importance is rarely a property of the control so much as a property of the regime you are being measured against this quarter. The bank running PCI DSS treats stored-data protection as the thing that ends careers. The federal contractor under NIST 800-53 sorts the same universe of controls into Low, Moderate, and High baselines. The shop chasing a SOC 2 report cares about the Common Criteria and treats the rest as optional. Each of them is right, inside its own frame, and none of them can tell you what the other frameworks would have prioritized without going and reading the other frameworks.
There are two hundred seventy of these frameworks once you count the regional privacy laws, the sector regulations, the federal baselines, and the international standards, and the translation problem between them is already solved, because the Secure Controls Framework, Tom Cornelius's free metaframework, maps roughly sixteen hundred unified controls to all two hundred seventy, using NIST IR 8477 Set Theory Relationship Mapping to record each crosswalk with a relationship type. If you implement an SCF control, you can read off which paragraph of GDPR, which 800-53 identifier, and which PCI requirement it satisfies, so the dictionary is built and it works well.
What the dictionary does not give you is the picture. The SCF ships as a spreadsheet: fifteen hundred ninety- one rows, four hundred thirty-one columns, every cell a list of control identifiers, and almost nobody reads that as a whole because it is not built to be read as a whole. The crosswalk exists, but the view across it does not, so the obvious question, the one a data person asks on contact with a table this shape, goes unanswered: forget any single framework, which controls do the standards agree on?
Consensus, weighted
Count the agreement, then fix the two ways a count lies.
The naive version is a popularity contest, where for each SCF control you count how many standards map to it and the controls that nearly every standard touches rise to the top. It is the right instinct, but it is wrong in two specific ways, and correcting those two is most of what the analysis does.
The first lie is that every standard gets one vote. A niche state privacy statute and NIST 800-53 do not carry the same weight in a real control program, and a count pretends they do. So each of a curated set of two dozen major standards carries an importance weight, normalized so the average is one and the spread runs from about 0.57 to 1.41. The big four (800-53, ISO 27001, NIST CSF, PCI DSS) sit at the top; the newer and single-sector regimes sit lower. These weights are mine and they are an opinion, seeded from mandate scope and adoption rather than from a published number, which is a limit I come back to at the end.
The second lie is subtler and more interesting. Standards rank their own controls, and they hide the ranking in plain sight. NIST 800-53 sorts controls into Low, Moderate, and High baselines. CIS splits its catalog into Implementation Groups one through three, where IG1 is the essential hygiene every organization owes. HIPAA flags each implementation specification Required or Addressable. PCI publishes a Prioritized Approach that buckets every requirement into six risk milestones. CMMC has levels; IEC 62443 has security levels. Ten of the two dozen standards expose a priority like this, and a flat count throws all of it away. So a control mapped at 800-53 Low, or CIS IG1, or HIPAA Required, counts for more than the same standard's specialized, high-baseline, addressable tail, because the foundational rung is the one each standard leans on hardest. I pulled those rankings out of the SCF's own columns where they live, and out of the source regulation for the two (HIPAA and PCI) that keep their priority in a separate document.
Put together, a single standard's contribution to a control is its importance times the priority it assigns that control. Sum those across every standard that maps the control and you have its weighted consensus. The diagram at the top of the page is that number made into a flow: the major standards on the left, the SCF controls they converge on in the middle, and any one target standard you choose on the right. The flow conserves, which matters more than it sounds. A control's consensus splits across the target controls it maps to rather than copying itself onto each, so a node's height is its share of the agreement, not an artifact of how many places it points.
Reading it
Height is agreement. Color is domain. The target is yours.
The left column is the source standards, grouped by what they govern: security control frameworks, operational technology, privacy, and AI governance. The middle column is the SCF controls those standards converge on, colored by the SCF domain they belong to so that governance, asset management, access control, and the rest cluster together rather than scattering. The right column is whichever single standard you point at. The default points at NIST CSF 2.0 and shows the whole field, which is deliberately dense so that the default conveys the scale of the agreement, and to read it you narrow it. Pick one SCF domain, or switch the target to PCI DSS or ISO 27001 or any of the two hundred seventy, and the diagram redraws around your choice.
A tall middle node is a control that many important standards agree on, each at a serious internal priority. A tall node on the right is a control in your chosen standard that catches a lot of that converged weight. Hover any flow and it tells you the arithmetic: which control of the source standard maps here, the importance times priority that produces the weight, and the tier each standard assigns. The control names on the right resolve to their real titles where the framework's catalog is public, which for now means NIST's; the rest stay as identifiers, because the SCF stores the crosswalk as identifiers and not as the copyrighted control text behind them.
There is a toggle worth knowing about, because weighted is the default and carries the argument, so if you turn the weighting off you get the raw count, every standard one vote, every control flat inside its standard. Switching between them is the fastest way to see how much the weighting changes the story, and it changes it a lot: controls that lead on a raw count slide down once you account for the fact that the standards backing them are minor or rank them as afterthoughts.
The AI view
Where the AI frameworks agree, counted on their own terms
The default view buries the SCF's AI controls, and it does so for a structural reason more than a weighting one, because none of the 160 controls in the SCF's Artificial Intelligence & Autonomous Technologies domain maps to NIST 800-53, ISO 27001, ISO 27002 or CSF 2.0. So under the main consensus the best of them collects five agreeing standards against a top-fifty cutoff of fourteen by raw count, and by weighted consensus the best of them sits in a five-way tie at 547th of 1,591. Turning the weighting off doesn't rescue them, which is how I know the importance seeds aren't what keeps them down.
So the tool has a second view, which you reach from the View menu at the top of the diagram or by opening the tool's AI view directly, and it is drawn below. It swaps the left column for the SCF's own five AI framework columns (ISO/IEC 42001:2023, NIST AI 100-1, which is the AI RMF, NIST AI 600-1, the EU AI Act and Texas TRAIGA), gives each one a plain vote because none of the five ranks its controls internally, and opens on the AI domain against the AI RMF as the target, with the 45 AI-domain controls that no AI framework maps shown in gray rather than dropped. It is built from the same SCF crosswalk columns as the rest of this page and carries the same attribution, so it adds no other publisher's content.
The number I'd take from it is that 200 of the 315 SCF controls those five frameworks map to, about 63 percent, sit outside the AI domain, led by governance, HR, risk, compliance, asset management and technology development. The share moves a good deal by framework, from 71 percent of the 149 controls ISO/IEC 42001 maps down to 41 percent of the 140 that NIST AI 600-1 maps, which fits a management-system standard on one end and a generative-AI risk profile on the other, and it suggests a good share of what the AI frameworks ask for is ordinary control work a program may already be doing. The view shows where the frameworks agree, though, and says nothing about whether those controls hold up against attacks aimed at AI systems, which is the question the ATLAS Wall takes up by ranking MITRE ATLAS mitigations against a 48-incident record, with a weighting built from ATLAS data alone. I'd read the two side by side and never multiply them, since the SCF tells you what the frameworks converge on and the ATLAS Wall tells you which mitigations touch real attack paths.
Two other AI control catalogs come up whenever I show this, and I looked at both as a possible overlay before building it. AIUC-1, from the Artificial Intelligence Underwriting Company, updates quarterly, with its Q4 2026 release dated 15 October 2026, but its site terms (last updated 15 July 2025) forbid copying, distributing or creating derivative works from its content, and its GitHub mirror carries no licence. The CSA AI Controls Matrix, at v1.1 from 22 June 2026 with 247 controls and a v1.1.1 machine-readable bundle released 4 August 2026, has the better data, OSCAL included, but CSA's licensing FAQ of 13 March 2026 says the free version is for internal reference only and can't be altered or turned into derivatives without a licence. That is my reading of their published terms rather than legal advice, and it is the main reason neither is the basis for an overlay here, since a reshaped crosswalk of either would be the derivative those terms rule out. The SCF also maps neither of them, so there is nothing on this page's licensing basis to join, and neither carries a current ATLAS join either, because the AICM bundle has no ATLAS mapping and the AIUC-1 ATLAS crosswalk page, last updated 22 July 2025, attaches requirements to 17 of the 44 mitigations in ATLAS v2026.10. Both are worth reading on their publishers' sites, and if the SCF adds a column for either, I'd offer it as a target here the same day.
What it surfaces
The foundational core, and the controls that only look popular.
The same handful of controls sits at the top no matter how you turn it, namely governance and program oversight, risk management, asset inventory, secure configuration baselines, and access control. These are the controls nearly every standard maps, and the standards that rank their controls almost all rank these foundational, at 800-53 Low, CIS IG1, or HIPAA Required. That is not a surprising list, and it is the lack of surprise that carries the finding, because when twenty serious standards map a control and most of them call it the floor rather than the ceiling, that is about as close to settled as security controls get, and the consensus says a program whose first dollar is not going here is spending it in the wrong place.
The more useful read is in the asymmetry the flow exposes. Frameworks describe the same idea at different grain. One standard captures a concept in a single control; another spreads it across fifteen. Because the flow conserves, the coarse framework's single control catches the full weight of the concept while the granular framework's fifteen each catch a fifteenth. So when you target a specific standard, the diagram is telling you which of that standard's controls are doing the heavy lifting for the rest of the world's agreement, and which are fine-grained leaves that the broader consensus barely touches. That is a procurement and engineering signal a single framework's own priority labels cannot give you, because a framework only knows its own ranking.
And the weighting earns its keep on the controls that look popular and are not. A control can map to a long list of standards and still sit low, because the standards mapping it are minor regional regimes or because the ones that do rank their controls file it under their specialized tail. Turn the weighting off and those controls jump up the raw count, but turn it back on and they settle where the evidence puts them, so the popularity contest and the weighted consensus disagree most exactly on the controls that are common without being central, which is where the disagreement matters.
Where this stops short
A reading of the SCF's data, not a settled method
The crosswalk is the SCF's; the weighting is mine, and the weighting is where the judgment calls live. The importance scores that decide a standard's vote are seeded from mandate scope and adoption, which is Tier B and C evidence because real adoption is rarely published as a number. They are an editable table, and changing it moves the picture. That is deliberate: the toggle and the table are both exposed precisely so the result can be argued with rather than taken on faith.
Two more boundaries are worth naming plainly. Only ten of the two dozen standards expose an internal priority; the other fourteen contribute at a neutral weight, not because I ignored their ranking but because they genuinely do not rank their controls, since ISO 27001 selects controls by risk assessment rather than declaring a baseline and GDPR is binding in full, so their flatness in the diagram is honest rather than a gap. And the flow splits a control's consensus equally across the targets it maps to, when the better divisor would be the STRM relationship strength the SCF records elsewhere. That strength is not in the cell data I parse, so equal split is the defensible default until it is. Where a target framework references a control only at the section level, as PCI's prioritized milestones sometimes do, the priority falls to neutral, and the same happens to the Appendix A3 supplemental requirements that the milestone map I transcribed does not cover; together those two cases cover about eight percent of PCI's mapped controls.
So this is a way of seeing the SCF's own data, not a published methodology, and it inherits the standard I hold this kind of work to: it should be wrong in ways you can name and check, not in ways that hide. The weights are visible and editable, the priority for each standard is pulled from that standard's own rules, the flow conserves so the heights mean what they claim, and the gaps are the gaps in the source rather than in the extraction. The next step is the one it has not had: review against the people who build the SCF, and a test against a real control program to see whether its consensus core matches where that program's auditors and incidents actually concentrate.
