Wednesday, 9:30am. The CISO gets two requests in the same morning. The first is from a senior developer, asking which framework to follow to secure a new API before it goes live. The second is from the legal team, asking whether the company can demonstrate compliance with the NIS Regulations before the regulator's next review.

Two questions that both contain the word "framework", yet call for completely different answers. The first is about a technical method for building something secure. The second is about a regulatory obligation that has to be evidenced. Confusing the two families of framework — or worse, trying to answer one with the tool meant for the other — is one of the most common sources of confusion in running a cyber security programme.

A cyber security framework is a structured reference that either guides how to secure a system in practice (a technical framework) or sets out and evidences regulatory compliance (a compliance framework). Telling these two families apart is the precondition for running a cyber security programme properly.

• Cyber security frameworks fall into two distinct families: technical and methodological frameworks (OWASP, MITRE ATT&CK, CIS Controls, NIST CSF, PTES), and regulatory compliance frameworks (the NIS Regulations, the FCA/PRA operational resilience regime, UK GDPR, ISO 27001).

• The first family answers the question "how do we actually secure this"; the second answers "how do we prove we're secure".

• A technical framework guides an action (fix a flaw, harden a configuration). A compliance framework demands evidence (documentation, traceability, audit).

• Automation is powerful for evidence collection and continuous gap tracking, but limited on contextual interpretation and governance decisions.

• Combining the two families in a single approach, rather than treating them separately, is what turns compliance into a by-product of good operational control.

Technical frameworks answer an engineer's question: how, precisely, do you make a system, an application or an organisation withstand a given attack. These are frameworks that describe mechanisms, controls or methodologies, independent of any legal obligation.

OWASP structures application security around identified, documented risks, as we covered in our article on the OWASP Top 10:2025. OWASP is used when designing, building or auditing an application: a developer coding an authentication feature consults the OWASP recommendations on that specific risk directly.

MITRE ATT&CK maps the tactics, techniques and procedures actually observed in attackers, organised into a matrix. MITRE ATT&CK is used to structure detection or threat-intelligence work: a SOC analyst investigating suspicious behaviour can map it to a precise ATT&CK technique to understand where the attacker sits in their progression.

CIS Controls offers a prioritised list of concrete security measures, from the most basic (asset inventory) to the most advanced (regular penetration testing), with progressive maturity levels. CIS Controls is used to build or audit a security programme as a whole, particularly for an organisation starting out that needs to prioritise.

NIST Cybersecurity Framework structures security work around functions (identify, protect, detect, respond, recover) rather than isolated controls. The NIST CSF is used to give a coherent overall view of a security programme, particularly to communicate it to a non-technical board.

PTES and OSSTMM specifically frame penetration-testing methodology: what to cover, in what order, to what level of rigour. Both methodologies are used when scoping or assessing the quality of a pentest, whether internal or carried out by a supplier.

What all these technical frameworks share: none has any legal force in itself. No one penalises you for not following the OWASP Top 10. Their value is operational, not legal. In the UK, the NCSC's Cyber Assessment Framework (CAF) sits alongside them as an outcomes-based framework — increasingly the backbone of NIS compliance, but used by many organisations simply as a structured way to assess their security maturity.

Compliance frameworks answer a different question: how do you demonstrate, to a regulator, an auditor or an insurer, that the organisation meets a set of requirements set outside itself.

The NIS Regulations 2018 are the UK's core cyber security legislation for operators of essential services and relevant digital service providers, covering risk management, security measures and incident reporting (a 24-hour early warning followed by a 72-hour report to the relevant sector regulator and the NCSC). The regime is being substantially reformed: the Cyber Security and Resilience Bill, introduced to Parliament in November 2025 and expected to receive Royal Assent in late 2026 (with phased implementation potentially running to 2028), widens scope to managed service providers and data centres, tightens reporting, and introduces a two-tier penalty regime (up to £17m or 4% of global turnover for the most serious breaches). The NCSC's Cyber Assessment Framework (CAF) is being placed on a firmer footing as the assessment backbone. Note that if your organisation has EU operations, the EU's NIS2 Directive may apply there in parallel.

The FCA/PRA operational resilience regime governs the UK financial sector. Firms were required to remain within their impact tolerances for important business services by 31 March 2025, and the Critical Third Parties (CTP) Oversight Regime — created under the Financial Services and Markets Act 2023 and in force since 1 January 2025 — lets the FCA, PRA and Bank of England directly oversee the most systemically important suppliers to the sector. It is the UK's closest analogue to the EU's DORA, which applies to your EU financial operations.

UK GDPR and the Data Protection Act 2018 govern personal-data protection, with technical and organisational security obligations (Article 32) directly tied to cyber security, enforced by the Information Commissioner's Office (ICO). The October 2025 ICO fine against Capita illustrates the stakes: £14m, following a 2023 ransomware breach that exposed the data of around 6.6 million people, with the ICO citing inadequate privileged-access controls, a 58-hour delay in isolating a compromised device against a one-hour target, an under-resourced SOC and insufficient penetration testing.

ISO 27001 and Cyber Essentials are certifications rather than laws. ISO 27001 certifies a structured, audited information-security management system; Cyber Essentials (and Cyber Essentials Plus), the NCSC-backed UK scheme, certifies a baseline of five technical controls and is frequently required to bid for UK government and public-sector contracts. Neither is a legal obligation in itself, but both are increasingly demanded contractually.

Compliance frameworks can also be sector-specific rather than cross-cutting — for example the NHS Data Security and Protection Toolkit (DSPT) in health, which is aligning with the NCSC's CAF.

What these compliance frameworks share: they demand documented, traceable and often timestamped evidence, not merely a good practice applied silently. An organisation can be genuinely well secured and yet non-compliant, simply because it hasn't documented what it does.

The choice is never made in the abstract. It depends on the concrete question you have to answer.

You're building or auditing an application. Technical frameworks: OWASP for application risks, PTES or OSSTMM if a pentest is planned to validate the result.

You're building a security programme from scratch. CIS Controls to prioritise measures by maturity, NIST CSF (or the NCSC's CAF) to give the board a communication structure.

You're investigating an incident or structuring your detection. MITRE ATT&CK, to characterise precisely what happened and where the attacker sat in their progression.

You need to demonstrate regulatory compliance. The NIS Regulations (or the incoming Cyber Security and Resilience regime) or the FCA/PRA framework depending on your sector, UK GDPR if personal data is involved, ISO 27001 or Cyber Essentials if a client or a tender requires it.

You're managing a chain of suppliers. The two families connect: the NIS Regulations (and the forthcoming CS&R regime) and the FCA/PRA framework now explicitly require oversight of supply-chain security, which ties directly to the issues we develop in our article on cloud supplier risk and TPRM.

In practice, these two families never exclude each other: the NIS regime requires regular security audits, which themselves rely on technical frameworks like OWASP or methodologies like PTES to be done properly. The regulatory framework sets the obligation; the technical framework supplies the method to meet it.

The honest answer comes in two parts, and they aren't symmetrical.

What automates well: evidence collection and continuous gap tracking. A governance, risk and compliance (GRC) platform can centralise regulatory obligations, automatically detect a configuration drift against a given CIS control, or raise an alert the moment an asset falls out of expected compliance. External attack surface mapping can continuously check that a framework like OWASP is still respected across a perimeter that changes every week, rather than settling for a frozen annual audit. The remediation workflows themselves automate largely: automatic conversion of a detected vulnerability into an actionable ticket in an ITSM tool, with pre-filled fields and generated recommendations, rather than manual re-entry at every incident.

What resists automation: contextual interpretation and governance decisions. A framework like the NIS Regulations isn't a checklist to tick mechanically: it asks you to assess whether the measures in place are proportionate to the organisation's real risk, which presupposes a human judgement the regulation itself never removes. Likewise, qualifying the real criticality of an automatically detected gap — deciding whether a non-compliant configuration is a serious operational risk or a justified exception — remains a task that calls for an analyst's expertise rather than an automatic rule.

The most important nuance to keep in mind: effective automation doesn't replace the framework, it operationalises it. A tool doesn't decide that an organisation is compliant with the NIS Regulations; it continuously collects the evidence that lets a human, internal or auditor, assert it with a solid file rather than a last-minute reconstruction before a review.

"On the ground, what we automate really well is the freshness of the evidence. It used to be that a compliance audit started from an inventory rebuilt by hand, often out of date. With continuous attack-surface monitoring, the evidence already exists by the time the auditor asks for it."
— Florent Montel, co-founder of Patrowl

This logic of continuous rather than reconstructed evidence ties directly to what we develop in our article on CISO priorities for 2026: auditors now expect timestamped, continuously verifiable evidence, not declarative compliance signed off once a year.

What Patrowl automates in practice, in this logic: continuous discovery of exposed assets across the whole perimeter, detection of catalogued and non-catalogued vulnerabilities with expert qualification before they're surfaced, automatic generation of enriched remediation tickets in existing ITSM tools, and a centralised history of corrective actions directly usable for the documentation required by UK GDPR, the NIS Regulations and the FCA/PRA operational resilience framework — and, for organisations with European operations, NIS2 and DORA.

Beyond the general principle, here is how this distinction plays out in a platform like Patrowl.

On the methodological and technical side, Patrowl relies on three frameworks to structure its own testing and qualification. OWASP underpins the detection of application vulnerabilities, whether catalogued (CVE) or not: it's the framework that directly guides what the automated pentest engine looks for on an exposed application. PTES (Penetration Testing Execution Standard) and OSSTMM frame the penetration-testing methodology itself, whether run by the automated engine or by in-house pentesters during manual validation of critical findings. None of these three has any regulatory force: they ensure the testing method is rigorous and reproducible, not that a legal obligation is met.

On the regulatory and compliance side, Patrowl's role is to produce the continuous, timestamped evidence that compliance documentation rests on. That evidence feeds directly into UK GDPR record-keeping, the NIS Regulations (and the incoming Cyber Security and Resilience regime), and the FCA/PRA operational resilience framework — and, for organisations with European operations, into NIS2 and DORA. Patrowl doesn't decide that you're compliant; it ensures that, when a regulator, an ISO auditor or a cyber insurer asks, the proof already exists rather than being reconstructed at the last minute.

What concretely separates these two columns in day-to-day use: the methodological frameworks determine what Patrowl tests and how, behind the scenes, without ever appearing directly in a regulatory audit report. The compliance frameworks determine how the results of those tests are presented, documented and historised to serve as proof before a regulator, an ISO auditor or a cyber insurer.

A technical framework and a compliance framework aren't two variants of the same tool: they answer two different questions, and confusing them leads either to security that's technically solid but undemonstrable, or to documentary compliance that corresponds to no operational reality.

Automation changes things, but on one precise point: it turns evidence collection from a one-off, reconstructed exercise into a continuous, timestamped flow. It never replaces the judgement of interpreting a framework against a real context, nor the governance decision that follows. The best combination remains the one where both families of framework feed each other, and where automation serves the evidence rather than claiming to stand in for judgement.

What is the difference between a technical framework and a compliance framework? A technical framework (OWASP, MITRE ATT&CK, CIS Controls) guides a concrete securing action, with no legal force in itself. A compliance framework (the NIS Regulations, the FCA/PRA regime, UK GDPR, ISO 27001) imposes a regulatory or contractual obligation that must be demonstrated through documented, traceable evidence.

Do you have to choose between technical and compliance frameworks? No, they're complementary. Compliance frameworks often set the obligation to audit or secure a perimeter, without specifying the method. Technical frameworks supply that method.

Can compliance with the NIS Regulations or FCA operational resilience be fully automated? No. Evidence collection, continuous gap tracking and documentation generation can be largely automated. Interpreting whether measures are proportionate to the real risk, and the governance decision that follows, remain human tasks the regulation itself presupposes.

Which framework should I use to secure an application before it goes live? OWASP for the specific application risks, complemented if needed by a pentest structured to a methodology like PTES or OSSTMM to validate the result independently.

Why can an organisation be well secured but non-compliant? Because regulatory compliance demands documented, traceable evidence of what is done, not just a good practice applied silently. An effective but undocumented security measure is not proof of compliance.

Is the UK subject to NIS2? No. NIS2 is an EU directive and does not apply directly in the UK. The UK has its own NIS Regulations 2018, currently being reformed by the Cyber Security and Resilience Bill (Royal Assent expected in late 2026). NIS2 only applies to your operations within the EU, so UK organisations with European entities may face both regimes in parallel.

Sources: NCSC (Cyber Assessment Framework, Cyber Essentials) · UK Parliament and DSIT (Cyber Security and Resilience Bill, Cyber Action Plan) · ICO (Capita monetary penalty, October 2025) · FCA / PRA / Bank of England (operational resilience and Critical Third Parties regime, PS24/16) · NIS Regulations 2018 · UK GDPR and Data Protection Act 2018 · NHS England (Data Security and Protection Toolkit) · OWASP Top 10:2025 · Patrowl product pages.