DORA & NIS2 Penetration Testing Guide

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.

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.

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.

A Practical Testing Cadence & Final Checklist

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.

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.