Reading regulation like a threat model

When you ask a compliance manager and a security researcher to read the same regulation, they produce different documents. The compliance manager returns with a gap list mapped to articles and annexes. The researcher returns with questions about what the regulation takes for granted.

The threat modelling habit

Threat modelling is often described as a process for identifying attacks. That description undersells what it actually does. Its real function is to make implicit assumptions visible. Before any attack can be mapped, the model must first represent what the system does, what it trusts, and where those trust relationships are assumed rather than enforced.

The classic questions in threat modelling are less a methodology and more an insistence: the person responsible for a system's security must understand the system as it actually operates, not as it was intended to operate. This habit produces a particular kind of output: not a list of vulnerabilities, but a map of where the system's design assumptions can be broken, and what consequences follow when they are.

How regulation gets read instead

The conventional approach to a new regulatory obligation is decomposition. The regulation is broken into numbered requirements. Each requirement is mapped against existing policies, procedures, and controls. Where no mapping exists, a gap is recorded. Remediation is scoped. Work is allocated.

This approach is auditable, repeatable, and produces documentation that looks like thoroughness. It is also systematically incomplete in one specific way: it tests whether a control exists to address a requirement, not whether the control is adequate to the risk the requirement was designed to address.

A control can satisfy a clause whilst doing almost nothing to reduce the underlying exposure. Consider a requirement for the regular review of access rights to ICT systems. The organisation conducts an annual review in a spreadsheet, signed off by a manager who lacks the context to challenge any entry. The gap analysis column is green. The exposure is unchanged.

The conventional approach takes the regulation's goals as given and asks whether they are covered. The researcher's approach asks whether those goals are achievable given the organisation's actual state.

Applying the researcher's lens

Reading a regulation the way a researcher reads a system means starting with a different question: not what does this require, but what does this assume?

Every material regulatory requirement rests on assumptions about what the regulated organisation can do. GDPR Article 32, which requires appropriate technical and organisational measures to ensure a level of security appropriate to the risk, assumes you have an accurate enough picture of your personal data processing to know what assets are at risk and what threats they face. Without a maintained processing inventory, every Article 32 control is built on a false premise: you are securing things you cannot fully describe. NIS 2 Article 21 assumes that entities have correctly classified themselves as essential or important, accurately scoped which of their network and information systems are in scope, and can proportionate their measures accordingly. A classification error at that threshold means every measure downstream of it is calibrated to the wrong question. DORA's ICT third-party risk management requirements assume a complete inventory of ICT third-party providers, the ability to classify them by criticality, and contractual relationships that provide sufficient visibility to monitor and manage those dependencies. The regulations differ in sector and scope; the pattern is the same. If the foundational assumption fails, the controls that flow from it will not deliver the protection the regulation intends.

The assumption question produces a different class of finding. Instead of "we lack a policy for X," the finding becomes "the policy for X assumes a capability we do not have, which means the policy will never work as intended." These are structurally different problems: the first can be addressed by writing a document; the second cannot.

Faster gap analysis

The practical benefit of this approach is speed. Under analysis, a regulation resolves into a relatively small number of foundational assumptions. If those foundations are sound, the detailed requirements built on them are likely to be deliverable. If they are not, no amount of control design will make them so.

Incident reporting obligations make this especially visible. NIS 2's requirement for a 24-hour early warning and 72-hour significant incident notification, DORA's four-tier classification and reporting chain, and the UK Cyber Security and Resilience Bill's tightened timeframes for critical infrastructure and managed IT services all rest on the same three load-bearing assumptions: that the entity can detect the incident within the prescribed window; that it can classify it against defined thresholds; and that it can produce structured notification content under time pressure. Test those three foundations once, and you have answered the core gap question for all of them simultaneously. The obligations differ in sector, scope, and timeframe. The underlying assumptions do not.

The UK Cyber Security and Resilience Bill is particularly instructive here, because it extends near-miss reporting and brings managed service providers and wider ICT supply chain participants into scope for the first time. The near-miss requirement assumes a detection capability sensitive enough to identify events that did not fully materialise, a classification scheme that can distinguish them from ordinary operational noise, and a reporting pipeline that can produce compliant notifications even when no incident actually occurred. For many MSPs newly brought into scope, none of those assumptions currently hold. A clause-by-clause gap analysis would record each sub-requirement as a separate gap. An assumption-based analysis identifies the detection and classification capability as the single foundational problem, and everything else as downstream of it.

Sharper scoping

Threat modelling scopes effort by asking which assets an adversary would target and which attack paths are credible. Regulatory scoping by assumption works similarly: which parts of the organisation's estate are actually subject to the regulation's requirements, and which are in the path of a plausible failure?

GDPR's jurisdictional reach produced a generation of scoping exercises that mapped data subjects, processors, and international transfers without asking which processing activities presented the highest risk of harm to the people whose data they handled. That is the question Articles 25 and 35 are actually asking. Reading those articles through their assumptions rather than their requirements surfaces a different scope: not every system that touches personal data, but the processing activities where a failure would cause real harm. The difference matters enormously for where DPIA resource gets spent.

The UK Cyber Security and Resilience Bill creates a similar challenge for managed service providers. The scoping question is not simply "are we in scope?" but "which of our services are relied upon by in-scope entities in ways that create a pass-through obligation?" That question is buried inside the scope provisions, not stated as an explicit requirement. An MSP reading the Bill as a list of clauses might not surface it. An MSP reading the Bill as a system would start by mapping which client relationships could create that dependency, and work outward from there.

Controls that map to real exposure

The output of reading regulation as a threat model is a different kind of control design. Rather than controls that address articles, you have controls that address the assumptions articles rest on, calibrated to your specific environment.

"Access to ICT systems shall be controlled" is an article. The assumption it rests on is that the entity knows what ICT systems it has, who should have access to them, and what access currently exists. A control that addresses the article is an access control policy. A control that addresses the assumption is an asset inventory process, a joiners-movers-leavers process tied to that inventory, and an access review scoped by what the inventory reveals.

Breach notification obligations follow the same pattern. GDPR's 72-hour notification requirement, and the tighter windows now being introduced under the UK Cyber Security and Resilience Bill for certain sectors, are articles. The assumptions they rest on are that the organisation can detect a breach, assess its nature and likely consequences, and produce a regulatorily adequate notification, all within the prescribed window. A policy stating that breaches will be notified within 72 hours addresses the article. A detection process, a severity assessment procedure, a legal escalation path, and a pre-approved notification template address the assumptions. Without the second group, the first is a statement of intent, not a control.

The gap between those two things is where most compliance programmes live: in the space between satisfying a clause and delivering the protection the clause was designed to provide.

Putting it together

A practical workflow for reading a new regulation this way involves three passes. The first is a quick read for intent: what risk is the regulation trying to address, and what would failure look like from the regulator's perspective? This is not about articles; it is about understanding the threat model the regulator was responding to when they wrote the requirement.

The second pass identifies the load-bearing assumptions. For each major section, ask what must be true about the organisation for this requirement to be fulfillable. These assumptions are the critical path. If any of them fail, the section is not achievable regardless of how many controls are documented.

The third pass is the gap analysis, beginning with the assumptions rather than the clauses. Which assumptions hold in this organisation? Where do they fail? What work is required to establish the foundations, and what control design becomes possible once those foundations exist?

The output is not structurally different from a conventional gap analysis: it is still a list of things to do. But the items on the list are grounded in the organisation's actual capability constraints and in the real-world exposures the regulation was designed to address, rather than in a mapping exercise between text and documentation.

A documentation audit can be satisfied by evidence that a process ran. Regulatory supervision under the current wave of cyber and data protection legislation is increasingly testing something different: not whether the process existed, but what it found, what changed as a result, and how quickly the organisation could demonstrate its position under pressure. Whether that scrutiny comes in the form of a DORA supervisory review, an ICO enforcement investigation following a breach notification, or a competent authority inspection under the UK Cyber Security and Resilience Bill, the question is the same. Reading the regulation with that question in mind from the start produces controls that are ready for it.