Penetration testing services: what's included

The short answer: penetration testing services are authorised, simulated attacks carried out by specialists on your networks, applications or cloud environments. A good engagement covers scoping and rules of engagement, testing against a public methodology, a report with evidence and prioritised fixes, and a retest to confirm the fixes work. You are buying proof of what an attacker could reach, not a list of scanner alerts.

That distinction matters when you compare offers. Two proposals can both say "pen test" and describe very different work: one is an automated scan with a branded cover page, the other is days of manual testing by people who chain weaknesses together the way a real intruder would. This guide sets out what a penetration testing service should include, the main test types, the phases and deliverables, how to choose a provider, what drives the cost, and where EU rules such as NIS2 and DORA expect security testing.

What a penetration testing service is

NIST describes penetration testing as security testing in which assessors mimic real-world attacks to find ways of getting around the security features of an application, system or network (NIST SP 800-115, section 5.2). The same guide notes that most tests look for combinations of vulnerabilities that give more access than any single flaw would.

That is the core of the service. A vulnerability assessment lists known weaknesses in breadth, mostly with automated tools. A penetration test goes in depth: testers try to exploit what they find, move from one foothold to the next and show the business impact, for example access to customer data or to the systems that run payroll. The two are complementary, and many organisations run scans continuously and commission a manual test at set intervals or before major changes.

What separates a test from an attack is authorisation. The work happens under a written mandate from the owner of the systems, within an agreed scope and time window, and every step is documented.

Types of penetration test

Most providers organise their services by target. The four you will see in almost every proposal:

• External network test. Everything reachable from the internet: firewalls, VPN gateways, mail servers, exposed remote access, forgotten test systems. The question it answers is what an outsider with no credentials can get to.
• Internal network test. The view of someone already inside, such as a compromised laptop or a malicious insider. It looks at Active Directory, lateral movement, privilege escalation and segmentation between office, production and management networks.
• Web application test. Customer portals, e-commerce, APIs and internal web tools. Authentication, session handling, access control between users and tenants, input handling and business logic. The OWASP Web Security Testing Guide is the usual reference here.
• Cloud test. Configuration and identity in your cloud accounts: permissions, exposed storage, management interfaces, keys and secrets, and the paths between cloud and on-premises systems.

Other common scopes are mobile applications, wireless networks and social engineering such as phishing simulations. Each test can also be run with different levels of knowledge: black box (no information), grey box (for example a standard user account) or white box (documentation, configurations, sometimes source code). Grey box is often the best balance between realism and coverage in a limited number of days.

A note on cloud tests

Cloud providers publish their own rules for testing customer resources. AWS lists services that customers may test without prior approval and requires approval for some activities, and Microsoft publishes rules of engagement for its cloud. Both exclude denial-of-service testing. A competent provider checks these policies during scoping, not after the first alert.

The phases of an engagement

Public methodologies group the work in slightly different ways. NIST SP 800-115 uses four phases (planning, discovery, attack, reporting) and says explicitly that this is one acceptable grouping among many. The Penetration Testing Execution Standard (PTES) defines seven sections: pre-engagement interactions, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post exploitation and reporting. In practice a well-run service follows this sequence:

1. Scoping and rules of engagement. Targets, exclusions, test windows, contacts for emergencies, what to do with sensitive data found during testing, and written authorisation. Most of the quality of a test is decided here.
2. Reconnaissance and discovery. Public information, exposed services, versions, user enumeration where in scope.
3. Vulnerability analysis. Tools plus manual checks to find candidate weaknesses, including misconfigurations and logic flaws that scanners miss.
4. Exploitation. Testers try to use the weaknesses, within the agreed limits, to confirm which ones are real.
5. Post-exploitation. From the first foothold: how far can an attacker go? Privilege escalation, lateral movement, access to the data or functions that matter to the business.
6. Reporting and debrief. Findings, evidence and remediation, presented to both technical teams and management.
7. Retest. After you fix the findings, the provider verifies the fixes and updates the report.

Deliverables: what the report should contain

The report is what you keep, show to auditors and use to plan work. Ask to see a sanitised sample before you sign. A useful report includes:

• an executive summary in plain language: overall exposure, the few issues that matter most, and what they would allow an attacker to do;
• the scope and method: targets tested, dates, test type, methodology followed and any limitations;
• for each finding, a severity rating on a stated scale, such as CVSS, the affected assets, evidence such as screenshots or request and response pairs, and steps to reproduce;
• attack paths that show how individual weaknesses were chained;
• remediation guidance specific to your environment, in priority order;
• after the retest, the status of each finding (fixed, partially fixed, open), which is often the version customers and auditors ask for.

Check whether the retest is included in the price or quoted separately. A test without a retest tells you what was wrong; it does not confirm that it has been put right.

Where NIS2 and DORA expect security testing

NIS2

Article 21(2) of Directive (EU) 2022/2555 lists the minimum cybersecurity risk-management measures for essential and important entities. Two of them relate directly to testing: point (e), security in 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 name penetration testing as a mandatory measure; it sets the outcome and leaves the method to the entity and its national transposing law.

For digital providers such as cloud computing, data centre, managed service and managed security service providers, Commission Implementing Regulation (EU) 2024/2690 goes further. 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, a documented test methodology, and documented results with mitigating actions for each finding. Recital 15 lists penetration tests among the tests that may be used. If you are in scope, 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. Article 24 requires a digital operational resilience testing programme, tests carried out by independent parties (internal or external), procedures to prioritise and remedy the issues found, and, at least yearly, appropriate tests on all ICT systems and applications supporting critical or important functions. These obligations apply to financial entities other than microenterprises; microenterprises carry out their tests under Article 25(3), combining a risk-based approach with strategic planning of ICT testing. Article 25 lists the tests the programme may include, and penetration testing is one of them.

Article 26 adds threat-led penetration testing (TLPT) for the financial entities that competent authorities identify, at least every three years, on live production systems. Article 27 sets requirements for TLPT testers, including demonstrated expertise in threat intelligence, penetration testing and red team testing, certification by an accreditation body in a Member State or adherence to formal codes of conduct or ethical frameworks, and professional indemnity insurance. The detailed method sits in Commission Delegated Regulation (EU) 2025/1190, which sets the active red team testing phase at a minimum of 12 weeks. A TLPT is a different engagement from a standard pen test, and our DORA service page covers the wider framework.

How to choose a penetration testing provider

Price comparisons only make sense once the offers describe the same work. These questions separate them:

• How many tester days, and how much of it is manual? Ask for the split between automated scanning and manual testing, and who does each part.
• Which methodology? A credible answer names a public reference (PTES, OWASP WSTG, NIST SP 800-115) and explains how the provider adapts it to your scope.
• Who are the testers? Ask for profiles and certifications of the people on your engagement, not of the company in general.
• What does the sample report look like? Look for evidence, attack paths and specific remediation, not generic advice copied from a scanner.
• Is the retest included, and within what window?
• How is risk to production managed? Test windows, emergency stop procedures, handling of any data accessed, and insurance.
• What happens after the report? A debrief with your team, help prioritising fixes, and a link to continuous vulnerability management so the next test does not find the same issues.

If you are subject to DORA TLPT, Article 27 already gives you a checklist for the tester. For other tests it is a reasonable benchmark too.

What drives the cost

Pricing models vary, but the cost of a penetration testing service mostly follows effort in tester days. The factors that move it:

• Scope size: number of external IP addresses, internal network segments, applications, API endpoints, user roles or cloud accounts;
• Complexity: custom business logic, multi-tenant applications and hybrid environments take longer than a brochure site;
• Test type and knowledge level: white box with code review costs more effort than a black box external scan, and gives more depth;
• Constraints: out-of-hours windows, on-site work for internal tests, production-only environments;
• Reporting needs: extra reports for customers or regulators, attestation letters;
• Retest and repeat cadence: one-off tests versus a programme with several tests a year.

An honest quote comes after a scoping call, because the same headline ("web application test") can mean three days or three weeks.

How AmagisTech works on penetration testing

We see a penetration test as one step in a cycle: test, fix in priority order, verify, then keep watching the same surface between tests. Our cybersecurity services cover offensive testing alongside vulnerability management, and for workloads in public cloud our cloud security work starts from the configuration and identity findings that cloud tests usually bring to light.

In short: a penetration testing service should give you an agreed scope, manual testing against a public methodology, a report with evidence and prioritised fixes, and a retest. NIS2 asks you to assess whether your security measures work, DORA names penetration testing in its testing programme and requires TLPT for identified financial entities, and a clear scope is what makes offers comparable. If you want to scope a test for your environment, talk to our team.