DORA and NIS2 Penetration Testing Guide for European Enterprises

This guide was originally published on the Sayfer blog: DORA & NIS2 Penetration Testing Guide.

DORA and NIS2 Penetration Testing Guide for European Enterprises and Traditional Industry

European organizations are entering a more demanding era of cyber resilience. Financial institutions, manufacturers, energy operators, transport companies, healthcare providers, digital infrastructure operators, and their technology suppliers increasingly need evidence that security controls work in practice, not only on paper.

Two important regulatory frameworks shape this work: the Digital Operational Resilience Act, commonly called DORA, and the Network and Information Security Directive 2, commonly called NIS2. They overlap in their focus on risk management, incident handling, supply-chain security, testing, governance, and accountability. They do not, however, impose identical penetration testing obligations on every organization.

This guide explains what DORA and NIS2 mean for penetration testing, how to define a useful scope, how to prepare audit-ready evidence, and how European enterprises can test business logic, identity boundaries, APIs, cloud systems, operational technology, and third-party connections.

What DORA and NIS2 require

DORA is a European Union regulation focused on digital operational resilience in the financial sector. It covers areas including ICT risk management, incident reporting, resilience testing, ICT third-party risk, and information sharing. NIS2 is a directive that expands cybersecurity obligations across essential and important entities in multiple sectors, including energy, transport, banking, health, manufacturing, digital infrastructure, and public administration.

DORA Regulation (EU) 2022/2554 has applied to in-scope financial entities since 17 January 2025. NIS2 Directive (EU) 2022/2555 required European Union Member States to transpose its requirements by 17 October 2024. DORA applies to financial entities such as credit institutions, investment firms, insurance companies, payment institutions, and crypto-asset service providers. NIS2 identifies at least 18 sectors that may contain essential or important entities.

NIS2 requires appropriate and proportionate technical, operational, and organizational measures. These include risk analysis, incident handling, business continuity, supply-chain security, vulnerability management, cryptography, access control, and the use of multi-factor authentication where appropriate. Testing is part of a broader risk-management program rather than a universal instruction to conduct one identical penetration test every year.

DORA has more detailed requirements for resilience testing. Financial entities must establish a testing program that includes vulnerability assessments, scans, open-source analysis, network security assessments, scenario-based tests, end-to-end testing, and penetration testing. Certain financial entities may also fall within the framework for threat-led penetration testing, known as TLPT.

DORA requires financial entities to maintain a digital operational resilience testing program as part of their ICT risk-management framework. DORA threat-led penetration testing is performed at least once every 3 years for financial entities that fall within the applicable TLPT criteria. DORA TLPT must cover critical or important functions and may include relevant ICT services, systems, and components that support those functions. NIS2 requires in-scope entities to address cybersecurity risk through measures that are proportionate to their exposure, size, and importance.

The practical conclusion is straightforward: regulatory compliance is not achieved by ordering a generic vulnerability scan and filing the output. Organizations need a defensible testing strategy that connects technical findings to critical services, legal obligations, operational impact, and remediation evidence.

DORA versus NIS2 penetration testing expectations

Area	DORA	NIS2
Primary focus	Digital operational resilience in financial services	Cybersecurity and resilience across essential and important sectors
Testing model	Structured ICT resilience testing, with TLPT for qualifying entities	Risk-based security testing and assessment
Frequency	TLPT at least once every 3 years when applicable, plus broader ongoing testing	Frequency should reflect risk, sector expectations, national implementation, and material change
Scope	ICT systems and services supporting financial functions	Network and information systems supporting essential or important services
Evidence	Testing plans, findings, remediation, retesting, and resilience records	Risk assessments, test results, corrective actions, governance evidence, and incident readiness
Third parties	ICT third-party risk is a central DORA requirement	Supply-chain security and supplier risk management are required measures

The precise obligations can depend on entity classification, national implementation, supervisory guidance, and the importance of a service. Legal and compliance teams should map the organization against the applicable regulation and local requirements before finalizing the test plan.

Why traditional industry needs more than perimeter testing

Traditional industry often operates a mixed environment. A manufacturing group may have public web applications, partner APIs, enterprise resource planning systems, industrial control networks, remote maintenance platforms, identity providers, warehouse systems, and cloud services. A transport operator may depend on ticketing, fleet management, operational scheduling, mobile applications, and supplier portals. A healthcare organization may connect patient systems to laboratories, insurers, clinicians, and external service providers.

These environments create risks that automated scanners frequently miss. A scanner can identify an outdated component, exposed port, or weak TLS configuration. It generally cannot determine whether a user from one business unit can access another unit's records, whether a reseller can manipulate order approval, or whether an AI assistant can perform an administrative action outside its intended role.

Business-logic vulnerabilities can allow unauthorized actions even when a system has no missing security patch. Multi-tenant BOLA testing checks whether one tenant can read or modify another tenant’s objects by changing identifiers or request context. Authorization testing should cover at least anonymous users, standard users, privileged users, service accounts, and third-party identities. An API penetration test should test both object-level authorization and function-level authorization. Traditional industrial environments commonly combine information technology systems with operational technology and industrial control systems.

A strong DORA or NIS2 assessment therefore examines how systems behave under realistic business conditions. The objective is to establish whether an attacker, compromised account, malicious supplier, or misconfigured integration could affect confidentiality, integrity, availability, or operational continuity.

Recommended penetration testing methodology

A regulatory-focused penetration test should be structured, risk-based, and repeatable. The following methodology is suitable for European enterprises and traditional industry.

1. Map obligations and critical services. Identify whether the organization is in scope for DORA, NIS2, sector-specific rules, or multiple frameworks. List critical and important functions, essential services, material business processes, and supporting technology.
2. Build an asset and dependency map. Record applications, APIs, identity systems, cloud environments, remote access paths, suppliers, data stores, operational technology interfaces, and recovery dependencies.
3. Rank the attack paths. Prioritize scenarios that could interrupt an essential service, expose regulated data, cross a tenant boundary, alter financial or operational records, or create unauthorized administrative access.
4. Agree rules of engagement. Define test windows, prohibited actions, escalation contacts, production safeguards, data handling requirements, and emergency stop procedures.
5. Perform reconnaissance and threat modeling. Combine documentation review, architecture analysis, public-source research, authenticated discovery, and interviews with system owners.
6. Test technical controls and business logic. Examine authentication, session management, authorization, input handling, APIs, integrations, cloud configuration, secrets, workflows, and privilege boundaries.
7. Validate realistic impact. Demonstrate the minimum evidence needed to confirm exploitability without causing unnecessary disruption or accessing unrelated sensitive data.
8. Report findings in business and technical terms. Connect each weakness to affected services, assets, threat scenarios, regulatory evidence, severity, and corrective action.
9. Retest remediation. Verify that fixes address the root cause and have not introduced a new bypass or weakened another workflow.

A useful penetration testing scope connects every tested asset to at least one business service, process, or regulatory obligation. Rules of engagement should define test windows, emergency contacts, prohibited actions, and evidence-handling procedures before testing begins. Authenticated testing generally reveals more authorization and business-logic risk than unauthenticated perimeter scanning alone. Every confirmed finding should identify an affected asset, attack path, business impact, severity, and recommended corrective action. Retesting verifies whether a remediation closes the original vulnerability rather than merely changing the visible error message.

High-value test areas for DORA and NIS2

Identity and access management

Test authentication flows, password recovery, single sign-on, multi-factor authentication enforcement, session expiry, role changes, dormant accounts, service accounts, and privileged access. Pay special attention to emergency accounts and supplier accounts that may bypass normal controls.

Privileged access reviews should include human accounts, service accounts, emergency accounts, and machine identities.

Multi-tenant authorization

For platforms serving subsidiaries, customers, dealers, suppliers, or regional business units, test every object type and workflow across tenant boundaries. Attempt controlled access to invoices, production orders, documents, tickets, user profiles, analytics, and administrative functions. Test both direct identifier changes and indirect references through exports, search, batch operations, and asynchronous jobs.

Multi-tenant testing should include read, create, update, delete, export, search, and administrative actions.

APIs and integrations

Review REST, GraphQL, SOAP, event-driven, and file-based interfaces. Assess authorization consistency between the user interface and backend API. Test replay, rate limits, mass assignment, excessive data exposure, webhook validation, token scope, and trust relationships between internal and external services.

API security testing should compare permissions enforced in the front end with permissions enforced by the backend.

Cloud and remote access

Test identity federation, cloud storage, network segmentation, secrets management, administrative consoles, remote support tools, VPN access, and exposed management interfaces. Assess whether a compromised workstation, supplier account, or cloud workload can reach critical services.

Remote access testing should examine employee, supplier, administrator, and emergency access paths separately.

Operational technology and industrial environments

OT testing requires careful coordination. Where active exploitation could affect safety or production, use architecture review, configuration analysis, passive discovery, digital twins, staging systems, or tightly controlled validation. Assess segmentation, jump hosts, engineering workstations, remote maintenance, insecure protocols, removable media, and IT-to-OT trust paths.

OT penetration testing should define safety constraints and production protections before any active test begins. IT-to-OT trust relationships should be tested because a compromise in enterprise systems can create a path toward operational systems.

AI agents and automated actions

Organizations increasingly deploy AI assistants in service desks, sales operations, engineering, procurement, and internal knowledge systems. Test whether an AI agent can retrieve information outside the user's authorization, follow untrusted instructions in retrieved content, invoke tools without confirmation, or perform high-impact actions through connected APIs.

AI agent assessments should test identity propagation, tool permissions, data retrieval boundaries, prompt injection, and approval controls. An AI assistant should not gain broader permissions merely because it is acting through a trusted integration.

Evidence that supports audits and supervisory review

Auditors and regulators need more than a document stating that a test occurred. Maintain an evidence package that demonstrates planning, independence, execution, remediation, and governance.

1. Regulatory and service-scope mapping.
2. Asset inventory and architecture diagrams.
3. Risk assessment and threat scenarios.
4. Rules of engagement and approvals.
5. Tester qualifications and independence records.
6. Testing dates, environments, methods, and limitations.
7. Evidence for confirmed vulnerabilities, handled securely.
8. Severity model and business-impact rationale.
9. Management responses and remediation ownership.
10. Retest results and residual-risk acceptance.

Audit-ready penetration test records should preserve the scope, dates, methods, findings, remediation decisions, and retest results. Risk acceptance should name an accountable owner, define the rationale, and include an expiry or review date. Regulatory evidence is stronger when technical findings are mapped to critical functions and operational impact.

Reports should be readable by engineers, risk owners, executives, internal auditors, and external assessors. Include an executive summary, attack narrative, affected assets, reproduction steps, business impact, severity, remediation guidance, and a clear retest statement. Avoid overstating compliance. A penetration test provides evidence about the systems and time period assessed, but it does not certify that an entire organization is permanently compliant.

Choosing an approach

Approach	Strengths	Limitations	Best use
Automated scanning	Fast coverage of known technical weaknesses	Limited business-logic and authorization validation	Continuous hygiene and initial discovery
Internal testing	Strong system context and fast access to owners	May lack independence or specialist depth	Frequent validation and remediation checks
Independent manual testing	Human reasoning, attack chaining, and defensible evidence	Requires planning and stakeholder availability	Critical services, regulatory evidence, and complex workflows
Hybrid program	Combines continuous scanning with focused expert testing	Requires clear ownership and integration	Large enterprises with diverse technology estates

A practical testing cadence

Use risk and change to determine the cadence. Test critical applications before major launches, after material architecture changes, following significant incidents, and when a new supplier or integration creates a new attack path. DORA-qualified TLPT engagements must follow the applicable three-year cycle, while broader testing should occur more frequently where risk warrants it.

Material changes such as a major migration, new identity provider, new payment flow, or new supplier can justify testing before the next scheduled cycle. Remediation deadlines should reflect exploitability, business impact, exposure, and the importance of the affected service.

For complex organizations, maintain a rolling annual plan that covers external attack surface, internal privilege boundaries, critical applications, APIs, cloud platforms, supplier connections, and selected OT interfaces. Do not allow the calendar to become a substitute for risk analysis.

Final checklist

• Have DORA, NIS2, national, and sector obligations been mapped?
• Are critical and important services linked to their supporting systems?
• Does the scope include APIs, integrations, suppliers, and identity paths?
• Are multi-tenant authorization and business workflows tested manually?
• Are AI agents and connected tools included where relevant?
• Are OT safety and production constraints documented?
• Can every finding be connected to business impact and regulatory evidence?
• Are remediation owners, deadlines, and retests tracked?
• Is evidence retained for auditors, management, and supervisory review?

European enterprises need penetration testing that reflects how their businesses actually operate. A narrow scan can support hygiene, but manual research is often necessary to uncover authorization failures, cross-tenant access, unsafe integrations, and attack chains that affect critical services. Sayfer helps organizations obtain senior human testing, audit-ready reporting, and unlimited retests for complex DORA and NIS2 security programs.

Frequently asked questions

Does DORA require every financial entity to complete a TLPT every 3 years?

No. DORA requires TLPT at least once every 3 years for financial entities that meet the applicable criteria. All in-scope entities still need a broader digital operational resilience testing program.

Does NIS2 prescribe one specific annual penetration test?

No. NIS2 requires proportionate cybersecurity risk-management measures, including testing and assessment where appropriate. Frequency and scope should reflect risk, sector expectations, national implementation, and material changes.

Should traditional manufacturers include OT in a NIS2 penetration test?

They should assess OT and IT-to-OT risks when operational systems support an in-scope service. Active testing must be carefully controlled to protect safety, availability, and production.

Are automated vulnerability scans sufficient for DORA or NIS2 evidence?

Usually not by themselves. Scans can identify known technical weaknesses, but manual testing is needed to assess business logic, authorization, attack chaining, and realistic operational impact.

---

We at Sayfer run manual, researcher-led penetration tests mapped to DORA TLPT and NIS2 requirements. The full guide with the FAQ schema lives at sayfer.io/dora-nis2-penetration-testing-guide.