Nobody knows how to scope a control framework¶
Open the Secure Controls Framework and scroll right, past the 252 mapping columns. Three columns sit there empty in every single release: Minimum Security Requirements, MCR, DSR.
They are empty on purpose. They are also the whole ballgame.
The empty columns¶
The SCF maps 1,534 controls to 252 laws, regulations and frameworks across 44 countries, as at the release I built against — the Council moves those counts every release. It is the best cross-mapping work in the field, and it is free. But it deliberately stops short of one thing: telling you which of those 252 apply to you.
That is not an omission. It is a legal determination, and the SCF Council is right to leave it to the organisation. Those three columns are where you record the answer — MCR for what binds you, DSR for what you chose.
Here is the problem. In practice almost nobody fills them in properly. The scoping conversation happens once, in a meeting, verbally, and the output is a shared understanding that evaporates the moment someone asks "why is this control in our programme?" The alternative failure is worse: adopt all 1,534 and call it thorough. Both roads end at an auditor asking a question nobody can answer.
Scoping is the most consequential decision in the whole exercise and it is the least documented one.
MCR and DSR is the distinction that matters¶
Two categories, and the difference is not academic.
MCR — Minimum Compliance Requirements. Statutory, regulatory or contractual. Imposed on you. You do not get to opt out.
DSR — Discretionary Security Requirements. ISO 27001, NIST CSF, CIS. Adopted because they are good practice. You own the decision and you can revisit it.
The split decides who signs an exception. A gap against a DSR is a prioritisation call a security lead can make on a Tuesday. A gap against an MCR is a finding, and it goes to someone with a different job title. Any control framework that flattens these into one undifferentiated list has thrown away the only piece of information that tells you what to do first.
So I built the scoping layer¶
Tell it where you operate and what business you are in. It returns the control set that actually applies — and, for every control, which specific instruments put it there.
A UK financial services firm inside EU scope: 45 instruments, 1,043 controls, of which 378 are legally binding and 201 are both binding and material enough that the SCF says a compensating control is not permitted. That last number is the one to take to a board.
Switch the country to Germany and everything recalculates. Australia and defence returns three instruments, not thirty — because the SCF carries no Australia-specific defence law, so only the cross-sector and privacy instruments qualify. That is the rule working, not a bug, and being able to see that is the point.
The rule itself is boring, which is how it should be. Binding instruments from your jurisdiction come in, gated by sector, except cross-sector and data protection law which always come in — GDPR does not care what business you are in. Non-jurisdictional obligations like PCI DSS and SWIFT are gated strictly on sector, because you acquire those by doing a kind of business rather than by being located somewhere. Voluntary frameworks come in only if you said you adopt them. Then you override by hand, and your overrides win.
What I got wrong, and what that taught me¶
I finished the thing, wrote the README, and typed "the SCF is free to use". Then I actually read the licence.
The SCF is CC BY-ND 4.0. Attribution-NoDerivatives. Section 2(a)(1) grants the right to "produce and reproduce, but not Share, Adapted Material", and Section 3(b) leaves no wriggle room: "You do not have permission under this Public License to Share Adapted Material." Section 4(b) closes the database-rights door too, which matters in the EU specifically.
A workbook built out of SCF content is Adapted Material. Which meant the thing I had just built was mine to use and not mine to publish.
The fix turned out to be better than the original plan. The tool ships as a builder, not a workbook. You download the SCF yourself, free, unmodified, from the Council. You run one command. The transformation happens on your machine. Nothing derived from the SCF passes through my site at all — I am shipping a transformation, you supply the input.
There is a lesson in there that has nothing to do with the SCF. "Free" is not a licence. Free to use and free to redistribute modified are different permissions, and the gap between them is where well-meaning GRC people publish things they should not. If you have ever put a control framework into a client deliverable, it is worth ten minutes with the licence text you agreed to.
Controls do not exist in a vacuum¶
This tool answers "which controls apply to me". That is genuinely useful and it is also only the end of the chain.
Controls exist because you have assets. Assets exist because they support processes. Processes exist because they deliver a business function. And in the EU, some of those functions are critical or important — which is the word that changes your obligations under DORA, and has cousins in NIS2 and in national critical-infrastructure regimes, each drawing the threshold in a slightly different place.
Run it the right way round and it looks like this:
Critical or important function → supporting processes → primary and secondary assets → protection needs → controls.
That chain is what I am building next. Identify the critical or important function under whichever regime binds you, and let the regime set the threshold. Decompose it into supporting processes. Inventory the assets underneath — primary and secondary, in the ISO 27005 sense. Run a protection needs analysis. Run a business impact analysis and get real RTO, RPO and maximum tolerable outage figures out of it. And only then arrive at controls, which by that point you can justify all the way back to a business function rather than to a framework row number.
Most organisations do this backwards: pick a framework, adopt its controls, then reverse-engineer a story about why. The chain above is the same work in the order that makes it defensible.
The scoping tool is the last link. The rest is coming.
The Secure Controls Framework is the work of the Secure Controls Framework Council, LLC, used under CC BY-ND 4.0. Not affiliated with or endorsed by the Council. Scoping is a legal determination as much as a technical one — this is a derivation aid, not legal advice.