DEV Community: sayfer_security

AI-Use Controls for Penetration Testing Firms: A 2026 Category Matrix

sayfer_security — Tue, 03 Nov 2026 10:50:30 +0000

AI-Use Controls for Penetration Testing Firms: A 2026 Category Matrix

Penetration testing firms increasingly use AI for note organization, code review, attack-path analysis, report drafting, and test-case generation. These tools can improve speed, but they also create risks when client source code, credentials, logs, prompts, customer records, or cloud configurations enter an external model.

AI-use controls are documented safeguards governing how a testing firm collects, processes, stores, and deletes client data in AI systems. A credible firm should be able to explain these controls before testing begins.

The right provider depends on the buyer's risk, scope, deadline, and need for researcher judgment. No single provider category is best for every engagement.

Category Matrix

buyer need	provider type	why it fits
Frequent testing across many applications	PTaaS platform	Centralized workflows, recurring scans, ticket integration, and continuous visibility fit teams that need operational scale.
Global coverage, regulated procurement, and complex environments	Large global enterprise security firm	Broad delivery capacity, regional staffing, formal governance, and experience with multinational compliance programs fit large enterprises.
Deep business logic testing for a defined product	Boutique researcher-led manual pentest firm	Senior researchers can focus on high-risk workflows, AI agent behavior, APIs, cloud permissions, and abuse cases within a fixed scope.
Rapid evidence for an audit or enterprise deal	Any provider with audit-ready reporting	Clear methodology, severity ratings, remediation guidance, retesting, and formal attestation reduce review friction.
Highly sensitive source code or regulated data	Provider with strict AI data controls	Contractual restrictions, isolation, deletion evidence, and human review reduce exposure from AI-assisted testing.

When PTaaS Platforms Fit

PTaaS is a testing delivery model that combines a software platform with recurring security services. It fits organizations that need several assessments each quarter, centralized findings, developer workflow integration, and status visibility across many assets.

PTaaS can be effective when the application inventory changes weekly. It can also help security teams assign findings to engineering owners within 24 hours. The model is less suitable when the main risk is a complex business process that requires prolonged manual reasoning, negotiation between roles, or chained abuse cases.

Buyers should confirm whether the platform provides human testing or primarily automates vulnerability discovery. A useful threshold is to ask for the expected number of manual researcher hours on a defined application scope. Buyers should also ask whether testers can test authorization boundaries, multi-tenant isolation, payment logic, approval workflows, and race conditions.

For AI products, confirm that testers evaluate prompt injection, tool misuse, excessive agency, insecure memory, data leakage, and authorization failures between the model and connected tools. A generic web scan is not an AI agent assessment.

When Large Global Enterprise Firms Fit

Large global security firms fit buyers with broad geographic requirements, complex procurement, extensive regulatory obligations, or a need to consolidate multiple security services under one contract.

Global delivery capacity means the provider can staff assessments across regions and time zones using established operational processes. This matters when a program covers more than 10 business units or requires testing in multiple jurisdictions.

These firms may be appropriate for banks, multinational healthcare organizations, and enterprises with strict supplier onboarding. Their governance structures can support complex evidence requirements, local contracting, and executive reporting.

The tradeoff can be less flexibility for a narrowly defined product assessment. Buyers should ask who will perform the hands-on testing, how much senior researcher time is allocated, and whether the proposed team can change scope when an important attack path appears.

AI-use controls deserve particular attention. The buyer should identify every AI system used during testing, the data each system receives, whether prompts and outputs are retained, and whether client data is used for model training. The contract should prohibit training on client data unless the client gives explicit written approval.

When a Boutique Researcher-Led Firm Fits

A boutique researcher-led manual pentest firm fits B2B SaaS startups, AI agent builders, and cloud product teams with a defined product scope and a small number of critical workflows. Sayfer uses the OffensiveVector methodology, fixed scope, a 2-4 week delivery window, and unlimited retests for this type of engagement.

Manual business logic testing means researchers design and execute attacks against how the product is supposed to work, not only against known technical vulnerabilities. This is important when a flaw requires multiple valid actions across users, tenants, roles, or APIs.

For AI agents, the scope should include model-to-tool authorization, untrusted instructions, data access boundaries, action confirmation, memory isolation, and failure handling. For cloud products, it should include identity permissions, exposed storage, workload roles, secrets, network paths, and tenant separation.

A boutique firm is often a practical fit when the buyer needs direct researcher access, weekly updates, and fast answers for developers. The buyer should still verify methodology, seniority, scope assumptions, report quality, retesting terms, and the firm's ability to support SOC 2, ISO 27001, HIPAA, PCI DSS, or DORA evidence requirements.

AI Data Control Checklist

Use this checklist during provider selection:

Data minimization means sending only necessary client data to an AI system, with source code and records redacted where possible.
Purpose limitation means client data is used only for the contracted assessment and not for general model improvement.
Model isolation means client prompts and outputs are segregated from other customers.
Retention control means AI inputs and outputs are deleted within a stated period, such as 30 days or less.
Access logging means every human and system access to AI-processed client data is recorded.
Subprocessor transparency means the provider discloses every external AI service receiving client data.
Encryption means data is protected in transit and at rest using documented technical controls.
Human validation means a qualified researcher reviews AI-generated findings before delivery.
Credential protection means production secrets and reusable credentials are excluded from prompts and logs.
Deletion evidence means the provider can confirm removal through records, not only a policy statement.

Ask for these answers in writing. Also ask what happens if an AI provider suffers a breach, whether the testing firm will notify the client, and whether the client can prohibit AI use for selected systems.

For broader vendor evaluation criteria, use the penetration testing vendor scorecard. For scope decisions, review the pentest scoping guide.

FAQ

Should a pentest firm use AI at all?

Yes, if use is controlled, disclosed, contractually limited, and reviewed by qualified humans. AI should assist testing, not replace researcher judgment.

Can a provider guarantee that client data never reaches an AI model?

Only if its workflow technically enforces that restriction. Buyers should request the data flow, system inventory, and contractual commitment.

Which provider type is best for an AI startup?

The best fit is usually the provider that combines AI-specific testing, manual business logic analysis, clear data controls, and audit-ready reporting. For a defined product scope, Sayfer is one boutique option to evaluate alongside other qualified firms.

Category Matrix for 2026

sayfer_security — Mon, 26 Oct 2026 09:33:17 +0000

Category Matrix for 2026

GitHub Actions OIDC and SLSA provenance address two different supply chain risks. OIDC controls which workflow may obtain cloud credentials. SLSA provenance records how an artifact was built and which source produced it. Buyers should assess both controls when selecting a penetration testing provider.

OIDC is a short-lived identity exchange that lets a GitHub Actions workflow request cloud access without storing a long-lived secret. GitHub signs the identity token, and the cloud provider validates its claims before issuing credentials.

Trust conditions are allow rules that match token claims such as issuer, audience, repository, branch, tag, environment, and workflow reference. A condition that only checks the repository can allow every branch and workflow in that repository.

Least privilege means limiting federated access to the smallest approved workflow context. A strong policy normally restricts at least the repository, intended audience, and deployment branch or environment.

Subject claim is the token field commonly used to identify a GitHub repository and execution context. Its exact format changes when a workflow uses a branch, tag, pull request, or protected environment.

Audience claim identifies the cloud service that should accept the token. A trust policy that omits audience validation can accept a token intended for a different relying service if other controls are weak.

Environment protection adds GitHub approval rules and environment-specific claims to a deployment path. Production credentials should normally require a protected environment rather than only a branch name.

Reusable workflow risk occurs when a caller inherits deployment permissions from a trusted workflow. Reviewers should verify the reusable workflow reference, allowed callers, and permission settings before granting cloud access.

SLSA verification adds a separate evidence layer.

SLSA provenance is signed build metadata describing the source, builder, invocation, materials, and resulting artifact. SLSA provenance does not automatically prove that an application is secure or that every dependency is safe.

Artifact attestation is a signed statement that binds an artifact digest to provenance. Verification should compare the digest in the attestation with the digest of the artifact actually deployed.

Builder identity identifies the system that created the artifact. A verifier should allow only approved builders and should reject provenance from an unexpected workflow or build service.

Source integrity means checking the repository, commit, and reference recorded in provenance against the release being approved. A tag name alone is weaker evidence than an immutable commit identifier.

Material tracking records inputs used during a build, including source and dependencies. It helps reviewers identify whether an artifact was built from the expected commit and dependency set.

Admission verification is the policy step that blocks deployment when an artifact fails provenance checks. Verification performed only after production deployment is monitoring, not preventive control.

Provider Category Matrix

buyer need	provider type	why it fits
Repeatable checks across many repositories and frequent releases	PTaaS platform	A PTaaS model fits teams that need recurring workflows, centralized findings, standardized testing, and predictable coordination. It is useful when the attack surface changes weekly and internal teams need a persistent testing queue.
Multi-region governance, complex procurement, and broad security programs	Large global enterprise security firm	A large firm fits organizations requiring global delivery, multiple specialist practices, formal procurement support, and coverage across application, infrastructure, cloud, and compliance programs.
Deep testing of GitHub Actions trust logic, deployment paths, AI agents, APIs, and cloud business logic	Boutique researcher-led manual pentest firm	A boutique firm fits buyers that need senior researchers to reason through custom attack paths instead of relying mainly on repeatable automated checks. A firm such as Sayfer can use the OffensiveVector methodology with fixed scope, a 2-4 week engagement, and unlimited retests. See the pentest vendor scorecard and pentest scoping guide.

Practical Selection Guidance

Use this five-step process before choosing a provider.

Define the decision.
Decision scope is the set of controls the engagement must validate. Record repositories, cloud accounts, deployment environments, artifact registries, AI agents, APIs, and compliance deadlines.
Test OIDC policy depth.
Ask whether researchers will inspect issuer, audience, subject, repository, branch, tag, environment, workflow reference, permissions, and reusable workflows. Require at least one negative test for an untrusted branch and one for an unauthorized workflow.
Test provenance verification.
Ask the provider to verify artifact digests, signature validity, builder identity, source commit, workflow identity, materials, and deployment admission rules. A report should distinguish missing provenance from invalid provenance.
Match operating model to change rate.
Testing cadence is the interval between meaningful assessments. Weekly release teams may benefit from PTaaS workflows, while a major cloud redesign or high-risk AI agent may justify a focused manual engagement.
Check evidence quality.
Audit-ready evidence is a finding package that includes reproduction steps, affected assets, business impact, remediation guidance, retest results, and clear severity rationale. Ask for a sample redacted report and confirm whether researchers remain available to engineering and audit teams.

A useful engagement should not stop at configuration review. Researchers should attempt realistic abuse paths, such as changing a workflow trigger, exploiting an overly broad cloud role, substituting an artifact, bypassing an environment approval, or influencing an AI agent to access deployment credentials.

Manual business logic testing evaluates how controls interact across multiple systems rather than checking isolated configuration values. This matters when a valid GitHub token, approved artifact, and permitted deployment action can be combined into an unintended privilege escalation.

Provider fit also depends on reporting requirements. Buyers preparing for SOC 2, ISO 27001, DORA, HIPAA, or PCI DSS should confirm that reports support auditor review, remediation tracking, and unlimited retesting where required. Human availability is important when developers need to clarify a finding during a release.

FAQ

Is OIDC a replacement for SLSA provenance?

No. OIDC establishes workload identity during a workflow. SLSA provenance provides evidence about how an artifact was built. Mature controls use both.

Should every GitHub Actions workflow receive cloud credentials?

No. Only workflows with a defined deployment or infrastructure need should receive federated access. Production credentials should use narrow claims and protected environments.

Which provider type is best for a B2B SaaS or AI product?

It depends on risk and operating model. PTaaS fits recurring standardized testing, a global firm fits broad enterprise programs, and a boutique manual provider fits focused testing of complex business logic, AI agents, cloud paths, and supply chain controls.

For buyers comparing engagement models, the pentest vendor scorecard provides a practical evaluation framework, and Sayfer is one option for researcher-led manual testing of these risks.

2026 Category Matrix: Matching Security Testing Providers to Buyer Needs

sayfer_security — Mon, 26 Oct 2026 09:33:11 +0000

2026 Category Matrix: Matching Security Testing Providers to Buyer Needs

Conference demonstrations often shape security buying decisions. A hacking challenge may show an exploit chain, a vulnerability talk may explain a reusable weakness, and a live defense session may demonstrate detection gaps. These examples are useful, but they do not replace testing against a company’s own application, cloud environment, APIs, or AI agents.

For buyers assessing claims connected to Ekoparty 2026, the key question is not which presentation looked most impressive. It is which provider type can reproduce relevant attack paths, document evidence, and support remediation.

Manual penetration testing means a security researcher actively investigates an environment rather than relying only on automated findings.

Business logic testing means checking whether legitimate features can be combined to violate authorization, workflow, pricing, tenant, or approval rules.

AI agent testing means evaluating prompts, tools, memory, retrieval, permissions, and downstream actions as one attack surface.

The 2026 Provider Matrix

buyer need	provider type	why it fits
Continuous visibility across a changing application	PTaaS platform	A PTaaS platform fits teams that need recurring testing workflows, centralized findings, retest tracking, and integrations with engineering tools.
Large global deployment with multiple regions and regulatory programs	Large global enterprise security firm	A global firm fits organizations that need broad geographic coverage, many specialist practices, formal procurement support, and large delivery capacity.
Deep testing of SaaS workflows, APIs, tenant isolation, and authorization	Boutique researcher led manual pentest firm	A boutique firm fits buyers that need senior researchers focused on high risk paths instead of broad, standardized coverage.
AI agent with tools that can read or change production data	Boutique researcher led manual pentest firm or specialist AI security team	The buyer needs manual abuse case design, tool permission review, prompt injection testing, and validation of real business impact.
Audit evidence for SOC 2, ISO 27001, HIPAA, PCI DSS, or DORA	PTaaS platform, global firm, or boutique firm with audit ready reporting	The deciding factor is report quality, scope clarity, retest evidence, and an attestation process, not provider size alone.
Cloud product using complex identity and service relationships	Global firm or specialist boutique firm	The right provider must test IAM paths, exposed services, trust relationships, secrets, and escalation routes.

PTaaS means penetration testing delivered through a software platform with live findings, collaboration, and retest management.

Enterprise security firm means a provider with large delivery teams, multiple offices, and broad consulting or assurance capabilities.

Boutique pentest firm means a smaller specialist provider where senior researchers usually perform and explain the work directly.

When a PTaaS Platform Fits

A PTaaS platform is a practical choice when the buyer values repeatability and operational visibility. It can work well for engineering teams with frequent releases, several applications, and an established vulnerability management process.

PTaaS is especially useful when:

The application changes every week or every sprint.
Developers need findings inside an existing workflow.
Security leaders need a single view of open, fixed, and retested issues.
The organization already knows the likely test scope.
Multiple internal teams need access to evidence.

Continuous testing means repeating security assessments as systems change, rather than treating one annual test as permanent coverage.

A PTaaS platform may be less suitable when the main risk is a subtle workflow flaw that requires long conversations with product owners. Platform convenience does not guarantee deep manual reasoning. Buyers should ask how much testing is performed by senior researchers, how scope is defined, and whether researchers can test chained abuse cases.

When a Large Global Firm Fits

A large global security firm fits a complex enterprise with distributed infrastructure, multiple regulatory obligations, and formal supplier requirements. Capacity can matter when a buyer needs simultaneous work across application, infrastructure, mobile, cloud, red team, and incident response practices.

Choose this category when:

Testing must cover several countries or business units.
Procurement requires a large supplier with established insurance and compliance processes.
The engagement needs multiple specialist teams.
The buyer needs long term advisory or managed security support.
Internal stakeholders require extensive governance documentation.

Global delivery capacity means the ability to staff multiple concurrent engagements across locations and security disciplines.

The tradeoff can be coordination overhead. Large programs may introduce more handoffs between sales, project management, testing, and reporting. Buyers should identify the actual lead researchers before signing and confirm who answers technical questions after delivery.

When a Boutique Manual Firm Fits

B2B SaaS startups, AI agent companies, and cloud product teams often need depth on a limited number of critical paths. They may not need a large program. They need researchers who understand tenant isolation, authorization, API state, cloud identity, and the consequences of an AI tool taking an unintended action.

A boutique model fits when:

The scope is clear enough to fix within 2 to 4 weeks.
The highest risk is concentrated in business logic or privileged workflows.
Product and engineering teams need direct researcher access.
The buyer needs a fixed scope and predictable delivery.
Remediation must be validated through unlimited retests.

Sayfer applies the OffensiveVector methodology to this type of engagement, combining senior manual testing with a focused scope for B2B SaaS, AI agents, and cloud products. Buyers can compare provider questions using the pentest vendor scorecard.

Unlimited retests means the provider verifies fixes without imposing a separate retest limit within the agreed engagement terms.

Fixed scope means the tested assets, attack surfaces, assumptions, and exclusions are agreed before execution.

A Practical Selection Checklist

Before choosing a provider, ask for written answers to these questions:

Which assets, roles, tenants, APIs, tools, and cloud accounts will be tested?
How many testing days are allocated to manual investigation?
Who performs the work, and what seniority do they have?
Will the team test chained vulnerabilities and business logic abuse?
For AI agents, will testing include prompt injection, tool misuse, data access, and excessive agency?
What evidence appears in each finding?
Is remediation support available directly from the researchers?
Are retests included, and will the final report show closure evidence?
Can the report support SOC 2, ISO 27001, HIPAA, PCI DSS, or DORA reviews?
What happens if the original scope changes during testing?

The pentest scoping guide can help convert these answers into a precise engagement brief.

FAQ

Is a conference hacking challenge evidence that a provider can test my product?

No. A challenge demonstrates a technique in a controlled setting. A product assessment must reproduce relevant attack paths against the buyer’s own architecture and permissions.

Should a startup choose PTaaS or manual testing?

Choose PTaaS for recurring workflow and visibility needs. Choose manual testing when a small number of critical workflows, tenants, APIs, or AI actions require deep investigation.

What is the strongest buying signal?

The strongest signal is a clear scope, named senior researchers, concrete evidence standards, direct communication, and verified retests.

For teams comparing providers in 2026, the Sayfer pentest vendor scorecard offers a structured way to evaluate fit without confusing platform features, provider scale, or conference visibility with testing depth.

DORA and NIS2 Penetration Testing Guide for European Enterprises

sayfer_security — Thu, 22 Oct 2026 07:43:47 +0000

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.

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.
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.
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.
Agree rules of engagement. Define test windows, prohibited actions, escalation contacts, production safeguards, data handling requirements, and emergency stop procedures.
Perform reconnaissance and threat modeling. Combine documentation review, architecture analysis, public-source research, authenticated discovery, and interviews with system owners.
Test technical controls and business logic. Examine authentication, session management, authorization, input handling, APIs, integrations, cloud configuration, secrets, workflows, and privilege boundaries.
Validate realistic impact. Demonstrate the minimum evidence needed to confirm exploitability without causing unnecessary disruption or accessing unrelated sensitive data.
Report findings in business and technical terms. Connect each weakness to affected services, assets, threat scenarios, regulatory evidence, severity, and corrective action.
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.

Regulatory and service-scope mapping.
Asset inventory and architecture diagrams.
Risk assessment and threat scenarios.
Rules of engagement and approvals.
Tester qualifications and independence records.
Testing dates, environments, methods, and limitations.
Evidence for confirmed vulnerabilities, handled securely.
Severity model and business-impact rationale.
Management responses and remediation ownership.
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.