Which regulations require recurring pentests, and how to deliver them without manual work

Five frameworks tell Norwegian SMBs to test their security regularly. Only one of them, for a small group of designated financial entities, requires a human red team. The other four can be answered with continuous AI testing, and at SMB scale they should be.

TL;DR: DORA, NIS2, ISO 27001, PCI DSS, and GDPR all expect security testing on a recurring basis. Only DORA’s threat-led penetration test, mandated for designated large financial entities, is required to be a human red team. For everything else, an autonomous AI pentest run continuously closes the requirement and produces better evidence than a once-a-year manual report.

Across the compliance scoping calls I have run this quarter, the same misread keeps surfacing: a board is told the company “needs an annual pentest” for ISO 27001, NIS2, or PCI DSS, and a budget line gets cut for one human engagement a year. The frameworks do not say that. They say test, and they say repeat. They almost never say how, and they almost never say who.

That misread costs money and produces worse security. Here is what the rules require, and the operational answer FM CyberSecurity runs for the recurring layer.

DORA testing, two layers in one regulation

The Digital Operational Resilience Act sets two different testing obligations for the financial sector, and they should not be confused.

The first layer is the general digital operational resilience testing programme (DORA Articles 24 and 25). Every financial entity in scope must run a documented testing programme that covers vulnerability assessments, scans, network security tests, source code review where relevant, scenario-based tests, and end-to-end testing. Systems supporting critical or important functions get tested at least once a year. The regulation does not name penetration testing as the only acceptable method. It expects evidence that the controls work. The Norwegian DORA law and regulation came into force on 1 July 2025.

The second layer is threat-led penetration testing, TLPT (DORA Articles 26 and 27). This is a manual red-team engagement, intelligence-led, against live production, repeated at least every three years. It is mandatory only for financial entities that Finanstilsynet designates based on a risk assessment of size, market share, ICT risk profile, and criticality of services to the wider financial system. Globally systemically important institutions are in scope automatically. The Norwegian implementation runs through TIBER-NO, the local version of the EU’s TIBER framework, jointly established by Norges Bank and Finanstilsynet.

To be direct about scope: FM CyberSecurity does not deliver TLPT or TIBER-NO engagements. Those tests require certified red-team providers with five years of senior pentest experience, threat intelligence supplied by an external provider, and indemnity coverage written into the rules (Joint RTS on TLPT, EBA). It is a separate market, and the entities running it are not SMBs.

FM CyberSecurity serves the layer below. For the general testing programme under Articles 24 and 25, we run Aikido AI Pentest continuously against the in-scope applications. The findings feed the ICT risk register, with article references in the documentation pack. That is the layer where most Norwegian financial firms sit.

For the article-by-article picture and what to send Finanstilsynet, the DORA checklist for Norwegian financial firms walks through the ten steps.

NIS2 testing, named without naming

NIS2 does not use the word “pentest” anywhere in Article 21. The directive lists ten risk-management measures and expects entities to assess the effectiveness of those measures. The European Commission’s implementing regulation 2024/2690 and the ENISA technical guidance treat security testing, including penetration testing, as a primary method.

Translated to operations: NIS2 wants testing on a regular basis, after significant change, and with results that feed back into the risk assessment. It does not say once a year. It does not require a human team. It does require evidence.

In Norway the first NIS directive is incorporated through digitalsikkerhetsloven, in force from 1 October 2025, supervised by NSM through sector authorities. The Norwegian incorporation of NIS2 is being prepared by the Ministry of Justice and Public Security; expect testing language consistent with the EU implementing regulation.

For SMBs in NIS2 scope, the recurring testing requirement is exactly what continuous AI pentest is built for: every release, every significant change, automatically, with a date-stamped audit trail.

ISO 27001 testing, the Annex A 8.29 control

ISO/IEC 27001:2022 has one Annex A control dedicated to security testing: Annex A 8.29, “Security testing in development and acceptance”. It consolidates two controls from the 2013 version into a single requirement that testing happens during development and before acceptance into production.

The control does not specify “annual penetration test” anywhere. It expects a structured testing process appropriate to the risk: static analysis, dynamic testing, vulnerability scanning, penetration testing where relevant. Auditors look for the process, the testing plan, and the evidence that findings get fixed. They look for whether you tested what you built.

In one composite ISO 27001 readiness review this spring, the gap that took the longest to close was not on the technical side. The client had paid for a one-day manual pentest a year before the audit, kept the report, and called it done. The auditor wanted to see testing tied to the release cycle, evidence that the new endpoint shipped two months earlier had also been tested, and a way to demonstrate the same for the next release. A point-in-time report a year old does not answer Clause 8 of the standard, which is about doing the work and keeping the proof.

The ISO 27001 checklist for Norwegian SMBs walks through scope to certification step by step. The testing answer in step 7 is the same one we recommend for NIS2: run the test against every release, automatically, and store the evidence in your ISMS evidence pack.

PCI DSS, the one framework that names pentest

PCI DSS version 4.0.1 is the only one of the five frameworks that uses the word “penetration test” as a direct requirement. Requirement 11.4 mandates internal penetration testing (11.4.2) and external penetration testing (11.4.3) at least annually, and after any significant change to infrastructure, applications, or segmentation controls. All v4.0 future-dated requirements became mandatory on 31 March 2025, so any merchant or service provider handling cardholder data in 2026 is operating under the full requirement.

The standard does not say a human has to do it. The PCI Security Standards Council’s penetration testing guidance describes methodology, scope, and reporting expectations. It does not prescribe the tester. What matters is qualified testing, scope coverage, and rescoping after significant change. The “after significant change” trigger is where annual manual tests fall behind reality fastest: a new payment flow shipped in June does not get tested until the next yearly engagement.

For PCI DSS, continuous AI testing closes both clocks at once. The annual requirement is satisfied by the run that completes inside the assessment window. The significant-change requirement is satisfied because the test reruns automatically on the change.

GDPR, indirect but real

GDPR does not require pentesting. Article 32 requires technical and organisational measures appropriate to the risk, and it lists “a process for regularly testing, assessing and evaluating the effectiveness” of those measures as one of the examples. Datatilsynet, in its supervisory practice, treats testing failures as evidence of inadequate Article 32 implementation when a breach happens. The exposure shows up after the incident, not in the rule text.

If you already run continuous testing for one of the four frameworks above, the GDPR Article 32 obligation is closed in the same motion. That is the cheap part.

What FM CyberSecurity runs, and why we chose this delivery model

FM CyberSecurity delivers pentest exclusively through Aikido AI Pentest. No manual web, mobile, network, red-team, or social-engineering pentest. The decision is deliberate and documented: at SMB scale, continuous AI testing produces better evidence, costs less per finding, and aligns with how the regulations read on the page.

Three quantified observations from the last two quarters of assessments work:

In four ISO 27001 readiness reviews this year, the average gap-to-close on the security testing control (Annex A 8.29) ran from three weeks to six. The technical fixes took less time than the documentation. Continuous testing produces the documentation as a side effect of the run.

In one composite NIS2 scoping engagement with a manufacturing SMB this quarter, the testing programme they proposed to the supervisor was “one external pentest per year.” That answer would fail the implementing regulation’s “regular” wording the first time a significant change shipped between tests. Switching to continuous testing changed the documentation, not the scope.

In six application reviews this spring, the AI pentest surfaced authentication and authorisation flaws, IDORs and broken access control, that a typical one-day manual engagement would have flagged in the same depth. The difference was the rerun: when the developer pushed the fix, the test reran the same day, not next year.

For the regulatory framing side of the work, FM CyberSecurity’s compliance practice maps the requirement to the testing programme in plain English, with article references in the documentation pack. The technical testing runs in parallel. They are not the same engagement.

To be explicit on what we do not do: TLPT for designated DORA entities under Articles 26 and 27 is a manual red-team engagement and FM CyberSecurity does not deliver it. If your firm is designated by Finanstilsynet for TLPT, you need a TIBER-NO provider on the qualified list. We can help you run the rest of the testing programme around it.

What this costs you to ignore

Three things go wrong when the “annual manual pentest” frame stays in place at SMB scale.

The point-in-time problem: the test passes in May, the new feature ships in July, and the audit in November finds an untested production change. The auditor writes a finding. The certificate is at risk.

The cost problem: a meaningful manual external pentest at Norwegian rates lands in the high five figures to low six figures per engagement, and most SMBs cannot afford to run it more than once a year. Continuous AI testing fits a yearly budget that buys more coverage, not less.

The evidence problem: a PDF report from a year ago is a single data point. A continuous testing log is a date-stamped record of every test, every change, every fix, every rerun. Auditors prefer the second one.

The misread is fixable. Read what the framework says on the page, choose the testing model that delivers the evidence, and stop paying once a year for something the regulation never required.

If this resonates

• Read the DORA checklist for Norwegian financial firms or the ISO 27001 checklist for Norwegian SMBs for the framework-by-framework view.
• Forward this to your compliance lead or DPO before the next audit committee meeting.
• Talk to Christian in FM CyberSecurity’s assessments practice for a 30-minute view on how continuous testing maps to your specific framework obligations.