Turning NIS2 accountability into assurance with offensive testing | Softcat
Skip to main content

Turning NIS2 accountability into assurance with offensive testing

How offensive testing gives leaders confidence in NIS2 readiness
Softcat PPT Background Corner Lit Radial Teal Gradient RGB Softcat PPT Background Corner Lit Radial Teal Gradient RGB

David Pearson

Cyber Security Assessor

Executives now own cyber risk in law, not only in principle. The EU’s NIS2 Directive, which came into force in 2023, is a cyber security law that expands requirements on organisations, and makes boards personally accountable for risk management. It’s about proving your cyber defences don’t just exist on paper, but actually stand up to real-world attacks. NIS2 requires management bodies to approve and oversee risk management measures and provides for liability if those measures are not met. The UK’s Cyber Governance Code of Practice reinforces this by setting clear board actions to govern cyber risk.

The next logical step after setting policy and governance is proving they work. That evidence comes from offensive testing, which shows that controls work in practice.

What technical assurance means under NIS2

Technical assurance is the ability to demonstrate, with clear evidence, that your prevention, detection and response controls work against real attack techniques.

 For boards, this turns Article 20 obligations into verifiable, measurable outcomes.

 For security teams, it creates a repeatable loop: test, fix, verify, report.

A risk-led offensive testing stack

It’s a good idea to design tests around your most important business risks and the techniques adversaries are most likely to use. Think of this as a structured way to test whether your business could withstand the same tactics real attackers would use.

External hygiene and coverage

continuous external attack surface monitoring and weekly authenticated vulnerability scanning with risk-based SLAs.

Secure configuration checks on cloud, identity and critical platforms.

Control effectiveness checks

Breach and Attack Simulation (BAS) to validate specific controls against common techniques.

Attack path validation across Active Directory and cloud identity to uncover and expose lateral movement and privilege escalation routes.

Human-in-the-loop scenario

Purple teaming to co-develop and tune detections with the SOC, reducing mean time to detect and respond.

Red teaming on a small number of high-impact scenarios tied to crown-jewel assets and key business services.

Process and social vectors

Phishing and vishing assessments with coaching to improve behaviour and processes.

Tabletop exercises to validate decision flow, legal, privacy and communications.

Change-driven tests

Trigger testing after major releases, mergers, supplier changes or policy exceptions, so assurance keeps pace with change.

Responsibilities and ownership

Clear ownership is critical. Without it, gaps appear and accountability falls through the cracks. NIS2 and the UK Code focus on leadership governance and training. Translate this into clear operational responsibilities so no one is left guessing.

Board and Executive Risk Committee: set risk appetite, approve the annual test strategy, receive quarterly assurance reports, and accept or reject residual risk. EUR-Lex GOV.UK

CISO: own the technical assurance framework, sign off scope and rules of engagement, ensure independence of testing, and report outcomes in business terms.

Security Engineering and Architecture: remediate findings, harden configurations, prioritise fixes based on business impact, and prevent regression.

Detection and Response: map tests to detections, tune rules, measure mean time to detect and respond, and lead purple team cycles.

Red Team or External Partner: plan and execute tests safely, align with relevant threat profiles, provide auditable evidence, and support re-tests.

IT Operations and Product Teams: implement remediations, manage change windows, verify that fixes persist across releases.

Legal, Data Protection, HR: approve scope where personal data or employee testing is involved, handle notifications and ethics.

How to measure technical assurance

Move beyond counting issues and shift the focus to tracking outcomes that demonstrate risk reduction and control performance. This ensures it’s not just a box-ticking compliance exercise but proves that security investments actually reduce risk.

Outcome KPIs

  • Reduction in exploitable attack paths to crown-jewel assets.
  • Percentage of critical vulnerabilities remediated within SLA and independently re-tested.
  • Mean Time to Detect and Mean Time to Respond for tested techniques.
  • Dwell time during red team exercises from initial access to detection.
  • Control efficacy rate: blocked or alerted techniques over total executed.
  • Detection coverage mapped to MITRE ATT&CK for in-scope systems.

Governance KPIs

  • Percentage of tests tied to board-approved risk scenarios and control objectives.
  • Percentage of findings with an owner, deadline and verification step.
  • Percentage of remediations verified by re-test within time/ date range.
  • Percentage of tests triggered by change events.

Package these in a quarterly Technical Assurance Scorecard so the management body can fulfil Article 20 oversight.

Cadence that fits board governance

  • Quarterly: publish the Technical Assurance Scorecard to the board, including executive decisions required.
  • Monthly: run BAS and attack path validation on a rotating scope, feed results into SOC tuning.
  • Twice yearly: run focused red team scenarios aligned to the top business risks.
  • Ad-hoc: trigger tests after material change, supplier onboarding, or notable threat intelligence updates.

Using ATT&CK to keep everyone aligned

To keep everyone on the same page, it helps to use a common framework. It’s critical to map every test and every detection to MITRE ATT&CK techniques and sub-techniques, and report coverage and results by families, grouping things like credential access, lateral movement and exfiltration. This gives engineering teams clear targets for hardening systems and gives leaders a consistent language across vendors and platforms.

Ethics, scope and safety

Testing should be tough, but it also must be safe and ethical. This means agreeing on rules of engagement, stop conditions, data handling and timing in advance. Where possible, avoid exfiltrating live personal data where synthetic data proves the same point. Store artefacts securely so they’re available for audit, and don’t forget governance. Ensure leaders complete the training required by Article 20 and, in the UK, follow the Code’s guidance on board literacy and assurance.

NIS2 raises the bar for cyber governance, putting accountability firmly on the shoulders of executives and boards. However, policies and frameworks can only go so far, assurance comes from testing that proves your controls work in practice. If you’d like to explore how offensive testing and technical assurance can support your NIS2 or UK Code compliance journey, get in touch with the team.