Penetration testing as a service (PTaaS): a guide

Penetration testing as a service (PTaaS) is a way of buying and delivering penetration tests, not a new kind of test. Qualified testers still carry out authorised, largely manual attacks on your systems, but the work runs as an ongoing service: findings appear on a platform as soon as they are confirmed, test cycles follow your releases, and retesting of fixes is part of the agreement rather than a separate order.

The method stays the same; the commercial and operational model changes. Most teams looking at PTaaS are not after a different test. They want to leave behind the annual cycle in which the report describes an application that has already changed twice. This guide covers what the model includes, how it compares with a project-based pen test, when it fits and when it does not, how it relates to NIS2, DORA and ISO 27001, and what to ask a provider. For test types, phases and report contents in general, see our guide to penetration testing services.

What penetration testing as a service means

PTaaS is a market term. It does not appear in NIST SP 800-115, in the NIS2 Directive or in DORA, so the contract defines what you actually get: two offers with the same label can contain very different work. Across the market, three elements recur, and they describe the model better than the acronym:

• An ongoing engagement, priced by period or by consumption (credits, tester days, number of assets), instead of a single purchase order for a single test.
• A delivery platform where each finding appears once the tester has confirmed it, with severity, evidence, status and remediation history, instead of a document handed over at the end of the project.
• Retesting included: the provider verifies your fixes within the scope of the agreement, and a finding closes only when the fix holds.

Many providers add automated scanning between manual cycles. That is useful, as long as the contract states what the scanner covers (known weaknesses, in breadth) and what the testers cover (chained attacks, business logic, access control between users and tenants, and anything else a scanner cannot reason about).

PTaaS vs a traditional penetration test

Cadence

The starting point is a limitation documented long ago. NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment published in September 2008, puts it plainly in section 6.2: "Since an assessment provides a snapshot of security at a given point in time, organizations may choose to require more frequent assessments." This is not a flaw of penetration testing. It is what a point-in-time measurement of a changing surface is.

A traditional engagement concentrates effort in one window, often with more depth on a single target. PTaaS spreads the effort across the year: shorter cycles, incremental tests on new releases, and a scope that is revised as the environment changes.

Delivery of findings

In the project model, a finding exists for you when the report arrives. In PTaaS it appears when the tester confirms it. A critical issue found on day three can enter the development backlog on day three, not weeks later, and an integration with your ticketing system turns it into tracked work rather than a line in an attachment.

The other side of this: a continuous stream of findings with no readable summary is worth less than a well-written report. Ask for a periodic executive summary and a report format you can share with customers and auditors.

Retesting

This is the most practical difference. In the project model, verifying fixes is a separate activity with its own order and schedule, and for that reason it sometimes does not happen. In PTaaS it is part of the cycle: you fix, request a retest, and the finding closes only when the verification passes.

What does not change

The method. The phases are still those described in NIST SP 800-115 (planning, discovery, attack and reporting, with reporting running alongside the other three), and for web applications the usual reference remains the OWASP Web Security Testing Guide, whose current stable version is 4.2. The preconditions stay too: written authorisation from the system owner, a declared scope, agreed test windows and rules for handling any data accessed during testing. An ongoing service does not remove scoping; it makes scoping a recurring task.

What PTaaS is not

Three common confusions, all of them expensive if you notice them late.

• Not a vulnerability scan with a new name. If the offer delivers only scanner output in a dashboard, you are buying recurring scanning. That has value, but it is different work: a scan lists known weaknesses in breadth, a penetration test exploits them in depth to show what an attacker could reach.
• Not a bug bounty. A bug bounty opens a scope to a community of researchers and pays per valid result. In PTaaS the testers are identified and under contract, and coverage is systematic and documented. The two can complement each other; they are not interchangeable.
• Not a red team exercise. A threat-led exercise built on realistic scenarios and run without warning the security team has different goals and rules. A subscription to recurring tests does not stand in for it.

How a PTaaS engagement runs

1. Initial scoping. Assets in scope, user roles, environments (production or staging), test windows, an immediate alert channel for critical findings, and who authorises what.
2. Baseline test. The first full cycle sets the starting picture. Every later cycle measures a difference against it.
3. Findings as they are confirmed. Each verified issue goes on the platform with severity, reproducible evidence and remediation guidance.
4. Remediation and retest. The tester verifies the fix, and the finding closes only if the verification passes.
5. Further cycles and scope review. This is the step most often skipped. If the asset list is not updated, the service keeps testing what it already covers and misses what has appeared since: new subdomains, new APIs, new cloud accounts, systems that came with an acquisition.

When PTaaS makes sense

The model works best when your attack surface changes faster than a yearly test can follow.

• Frequent releases. If an application changes every two weeks, a yearly test describes a version that no longer exists.
• Many assets to cover over the year. With ten applications and one testing budget, a distributed plan covers more ground than one concentrated project.
• Recurring customer requests. Mid-market companies that sell to larger organisations are often asked for the results of a recent penetration test in security questionnaires and audits, for example during a SOC 2 or ISO 27001 programme. A current, verified result avoids turning every renewal into an urgent project.
• A small team that has to prioritise. An ordered stream of findings with severity and status is easier to work through than a long report delivered once a year.

When a project-based test fits better

• A small, stable scope. Infrastructure that rarely changes does not need an ongoing engagement.
• A single check before go-live. Here you need depth in one window, not coverage spread over time.
• Obligations that call for a specific exercise. For financial entities required to perform threat-led penetration testing (TLPT) under DORA, that test has its own requirements and is not met by a recurring service.
• Tight operational constraints. Where test windows are rare and agreed months ahead, as in many industrial environments, continuity is hard to put into practice.

PTaaS, NIS2, DORA and ISO 27001: what the rules ask for

No EU rule names PTaaS. Several ask for something an ongoing model helps you show: that security testing is a process, not an event.

NIS2

Article 21(2) of Directive (EU) 2022/2555 lists the minimum cybersecurity risk-management measures for essential and important entities. Two are directly relevant: point (e), security in network and information systems acquisition, development and maintenance, "including vulnerability handling and disclosure", and point (f), "policies and procedures to assess the effectiveness of cybersecurity risk-management measures". The Directive does not prescribe a testing method, and national transposing laws can add detail.

For digital providers, including cloud computing, data centre, managed service and managed security service providers, Commission Implementing Regulation (EU) 2024/2690 is more specific. Point 6.5 of its Annex requires a security testing policy, with the need, scope, frequency and type of tests set from the risk assessment, and documented results "including assessment of criticality and mitigating actions for each finding". Recital 15 lists penetration tests among the tests that may be used, and mentions testing after infrastructure or application changes that the entity considers significant: the release-driven cadence that PTaaS is built around. Our NIS2 service page explains how the Article 21 measures are put in place.

DORA

Regulation (EU) 2022/2554 is more explicit for financial entities other than microenterprises. Article 24 requires them to "establish, maintain and review a sound and comprehensive digital operational resilience testing programme", to have tests carried out by independent parties, internal or external, and to ensure, at least yearly, that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions. Article 24(5) is the one that matches retesting: it requires procedures to prioritise, classify and remedy the issues found, and "internal validation methodologies to ascertain that all identified weaknesses, deficiencies or gaps are fully addressed". Article 25 lists penetration testing among the tests the programme may include.

Article 26 reserves TLPT for the financial entities that competent authorities identify, at least every three years. That is a separate engagement from any PTaaS contract. Our DORA service page covers the wider framework.

ISO/IEC 27001:2022

Annex A includes control 8.8 on the management of technical vulnerabilities and control 8.29 on security testing in development and acceptance. Both are recurring activities tied to the life cycle of your systems, and auditors look for evidence that they actually happen. Our ISO 27001 service page covers the certification path.

The practical reading across all three: what an auditor or regulator values is not the subscription, it is the documented sequence of findings, fixes and verifications.

Questions to ask before you sign

Offers with the same label vary widely. Six questions separate a testing service from a dashboard with a scanner inside.

• Who does the testing? In-house team or subcontractors, with which skills, and how many hours of manual work per cycle.
• Which methodology? NIST SP 800-115, OWASP WSTG, PTES, and how the report shows which checks were performed and which were not.
• What does the fee include? How many cycles, on which assets, at what depth, and what is billed separately.
• How are assets counted? By domain, application, IP address or API endpoint. This is the item that makes two apparently identical quotes diverge.
• How and when are critical findings reported? You need an immediate alert channel, not a wait until the end of the cycle.
• What leaves the platform, and how is data handled? Report format for customers and auditors, export options, where evidence is stored, who can access it and what remains available when the contract ends.

The same factors drive effort: the number and type of assets and how often they change, the number of user roles to test (each role multiplies the authorisation combinations), cycle frequency and the share of manual work, the environment (production calls for more care than a faithful staging copy), retesting and integrations with ticketing and development pipelines. A quote that does not name them is an estimate made blind.

From testing to monitoring

An ongoing testing service shortens the time a weakness stays exploitable. It does not tell you whether someone is exploiting one right now: that question is answered by logs collected and correlated in a monitoring service. Testing reduces the attack surface, monitoring reduces the time to detection.

AmagisTech works with mid-market organisations on both sides through our cybersecurity services. If you are weighing an ongoing testing model and want to work out which scope, cadence and depth make sense for your environment, talk to our team.