Enterprise Penetration Testing: Complete Guide to Scope, Methodology, Testing Areas, and Cost

In December 2024, the U.S. Department of Health and Human Services proposed making annual penetration testing an explicit HIPAA requirement. Twenty months later, that proposal is still not law, and the federal Unified Agenda now projects final action in July 2027. Meanwhile, hundreds of vendor pages tell healthcare buyers that HIPAA already mandates an annual pentest.

That gap between what regulations actually say and what the market repeats is expensive. It leads to tests scoped against the wrong requirement, budgets defended on the wrong grounds, and audit evidence that does not answer the question an assessor asked.

This guide covers what enterprise penetration testing is at a decision-making level, how scope gets defined, what methodology should look like, which infrastructure areas belong in scope, what five major global frameworks actually require, and how cost is built. Every regulatory claim below is traceable to a named instrument, and where a requirement is proposed rather than binding, this guide says so.

What Is Enterprise Penetration Testing?

Enterprise penetration testing is an authorised, scoped simulation of adversary behaviour against production or production-equivalent systems, designed to establish whether weaknesses can be chained into an attack path that has real business impact. It goes beyond identifying flaws. It proves exploitability, measures blast radius, and validates whether existing controls detect and stop the activity.

This section defines the activity precisely, then explains what separates it from smaller-scale testing. 

The definition that matters at enterprise scale

Three properties distinguish enterprise work from a standard application pentest.

• Attack-path orientation. The deliverable is not a list of vulnerabilities. It is a demonstrated route from an external foothold through to a business-critical objective, with each hop evidenced.
• Control validation, not just flaw discovery. The test establishes whether EDR was alerted, whether segmentation was held, and whether the SOC noticed. A finding that says “nobody detected sixteen days of lateral movement” carries more weight with a board than twenty medium-severity issues.
• Business impact framing. Impact is expressed in terms of what an attacker could reach: customer records, payment flows, intellectual property, and operational continuity.

Authorisation and rules of engagement

Testing without written authorisation is unlawful in most jurisdictions. Enterprise engagements require a signed authorisation letter naming the assets, the testing window, the permitted techniques and the escalation path.

Rules of engagement should clearly define which techniques are excluded, which systems are fragile, what happens if a critical finding appears during testing, and who has the authority to stop the engagement. In addition, third-party infrastructure may require authorisation from the provider before testing begins. Similarly, cloud providers publish their own testing policies, and most major providers allow customers to test their own resources without prior notification. However, specific services and testing activities may still be excluded.

Vulnerability versus attack path

This distinction is the one enterprise buyers most often miss, so it is worth showing rather than asserting.

Consider a hypothetical global manufacturer. An automated scan produces three findings across different systems, each rated medium:

1. A marketing subdomain running an outdated CMS plugin
2. An internal file share with overly permissive read access
3. A service account whose password has not been rotated in four years

Reviewed individually, none justifies emergency remediation. A queue sorted by CVSS would place all three below several high-rated issues elsewhere.

A tester chains them. The CMS flaw yields code execution on a low-value host in the DMZ. From there, the file share is readable and contains a legacy deployment script with the service account credential in plaintext. That account turns out to hold local administrator rights across a server group, because it was provisioned in 2019 for a migration that finished years ago.

An initial foothold on a marketing box becomes administrative access to production infrastructure. No single finding was critical. The path was.

Mapping the path to a named framework matters for the report. Each hop corresponds to techniques catalogued in MITRE ATT&CK: initial access through a public-facing application, credential access from unsecured credentials, and lateral movement using valid accounts. Framework mapping lets a defender check whether they have detection coverage for each step rather than for the finding alone.

What the organisation should receive

A defensible engagement produces evidence, not assertions. Reproduction steps, request and response captures, screenshots of achieved access, a timeline of activity that the SOC can correlate against its logs, and a remediation plan ordered by exploitability.

Retesting closes the loop. A finding marked ‘resolved’ without independent verification is a finding that someone has decided to believe.

The practical implication for a security lead is that scope and methodology determine value far more than vendor brand. A well-scoped test against a mediocre provider beats a badly scoped one against an excellent provider.

How Is Enterprise Penetration Testing Different From Vulnerability Assessment?

A vulnerability assessment identifies and catalogues known weaknesses, usually through automated scanning. Penetration testing attempts to exploit them and chain them into attack paths. Red teaming goes further, testing detection and response against a defined objective without the defenders’ knowledge. The three are complementary layers, not substitutes for one another.

Buyers routinely purchase one while believing they bought another. This section separates them precisely.

The comparison:-

Why the distinction has practical consequences

Scanners cannot reason about authorisation. An endpoint returning HTTP 200 to an authenticated request looks healthy to software. Whether that record belonged to a different customer is a question requiring knowledge of the application’s intent.

That gap maps to a documented risk category. OWASP ranks Broken Access Control first in the Top 10, and the OWASP API Security Top 10 lists Broken Object Level Authorization as API1. Both are logic categories, and both resist automation for the same reason.

Chaining requires context a tool does not hold. In the manufacturer example above, no scanner links a CMS flaw to a file share to a service account, because nothing in the data suggests they are related.

Red teaming assumes maturity that many enterprises lack. Running an adversary simulation against an organisation with no detection capability produces a predictable result at considerable cost. The sensible sequence is assessment, then penetration testing, and finally red teaming, once detection is in place to test.

A worked example of the difference

A scanner flags an SSRF-susceptible parameter on an internal reporting service. Severity: medium. The report says the application fetches user-supplied URLs.

The tester asks a different question: what can that service reach? On a cloud-hosted workload, an SSRF that reaches the instance metadata service may yield temporary credentials for the attached role. When that role has broad storage permissions, a medium-rated parameter can become a data exposure path.

The scanner was correct about the flaw and silent about the consequence. Both outputs are useful. Only one supports a remediation decision.

Understanding these boundaries lets a security lead buy the right thing and lets a compliance officer explain to an assessor why a scan report does not satisfy a testing requirement.

Why Does Enterprise Penetration Testing Matter to the Business?

Penetration testing converts uncertain security posture into evidence. It validates whether controls work under attack, identifies which of thousands of findings are genuinely exploitable, provides audit evidence that regulators accept, and gives leadership a defensible basis for security investment decisions.

The business case rests on specific outcomes rather than breach fear, and this section sets them out.

Security control validation

Organisations buy controls but rarely verify them. Testing establishes whether segmentation actually prevents lateral movement, whether MFA covers every authentication path, and whether the EDR agent is deployed in accordance with the asset inventory.

The most commercially useful finding is often a negative one. Discovering that a control you already pay for does not work is often more commercially useful than assuming it is cheaper to find out during an incident.

Exploitable-risk identification and prioritisation

Enterprise vulnerability backlogs run to thousands of open items. Severity scoring alone does not order them usefully, because severity is calculated without knowledge of your architecture.

Two public data sources improve that ordering considerably. The CISA Known Exploited Vulnerabilities catalogue lists vulnerabilities with confirmed active exploitation. The Exploit Prediction Scoring System estimates the probability of exploitation within 30 days. A CVSS 9.8 with an EPSS probability below 1% and no KEV listing is a theoretical problem. A CVSS 6.5 with high EPSS and a KEV entry is next week’s incident.

Penetration testing adds the third input: whether the flaw is reachable and exploitable in your specific environment.

Compliance evidence

Several frameworks either require testing or accept it as evidence of control effectiveness. Section 8 covers the detail. The practical point is that a single well-scoped engagement can produce evidence usable across multiple obligations, provided the framework mapping is specified during scoping rather than retrofitted afterwards.

Incident preparedness

An engagement generates a documented attacker timeline. Comparing that timeline against what the SOC detected produces a measurable detection-coverage figure, mapped to MITRE ATT&CK techniques. That measurement is difficult to obtain any other way.

Investment validation and stakeholder trust

Security budgets are defended on assertion. Testing replaces assertion with demonstration: this control held, that one did not, and here is the remediation cost.

Externally, enterprise procurement now routinely requests a recent testing summary or attestation letter. For B2B vendors, a credible report shortens security review cycles measurably, which is a revenue argument rather than a risk one.

For most enterprises, the strongest internal case combines two of these: a stalled deal in security review and a specific control that testing showed did not work. Both are concrete, and neither depends on estimating breach probability.

Need a Pen Test?

Talk directly with senior security experts. Book a quick call or grab a quote today.

Get a Quote →

When Should an Enterprise Conduct a Penetration Test?

Testing cadence should be risk-based, not calendar-based, with regulatory minimums as a floor. PCI DSS requires testing at least annually and after significant change. DORA requires threat-led testing every three years for identified entities. HIPAA currently has no explicit cadence. Event triggers matter more than the annual date for teams shipping frequently.

Distinguishing genuine requirements from vendor convention is the point of this section.

What is actually mandated?

Two observations follow from that table. Only PCI DSS and DORA name a frequency in the text of the instrument. And “annual penetration testing” as a universal requirement is a market convention, not a legal one.

Event triggers that matter more than the calendar

For organisations that release frequently, a report from eleven months ago describes a system that no longer exists. These triggers should sit in a written list, owned by a named person, reviewed at release planning:

• Significant change to authentication or authorisation logic
• New externally exposed application, API or endpoint
• Cloud migration, new region, or major architectural change
• Merger or acquisition bringing unfamiliar infrastructure into scope
• New payment flow, or a new category of regulated data entering the environment
• Material change to the third-party integration surface
• Following any confirmed security incident
• A CISA KEV addition or vendor advisory affecting technology you run
• A new contractual or regulatory obligation changing control scope

We underuse the penultimate trigger. We publish KEV additions continuously, and an entry naming a product in your edge infrastructure should prompt you to assess exposure rather than file a notification.

Building the cadence

A defensible programme has three layers. Continuous automated scanning for hygiene. Annual or semi-annual penetration testing for depth, aligned to whichever regulatory floor applies. Event-triggered testing on the list above.

Mature organisations add a fourth: red teaming or purple teaming once detection capability exists to measure.

The practical planning note most teams learn the hard way is that cadence describes when the report must exist, not when the engagement starts. A half-yearly obligation with a four-week engagement and a two-week remediation window means work begins roughly two months before the date of each cycle.

What Are the Main Types and Scope of Enterprise Penetration Testing?

Enterprise testing divides into network, application, cloud, identity, wireless, physical and social engineering domains, each with distinct methodology and tooling. Scope is defined by asset boundaries, knowledge level (black, grey or white box), environment, testing windows and explicit exclusions. Poorly defined scope is the most common cause of engagements that deliver less than expected.

This section covers the testing types, then the scoping framework that determines whether the engagement finds anything useful.

The testing types

1. External network testing:

Targets internet-facing infrastructure from an unauthenticated position. Common weakness categories include exposed management interfaces, unpatched edge appliances, weak VPN configuration and forgotten hosts. Edge devices deserve particular attention because they appear in the CISA KEV catalogue with regularity.

2. Internal network testing:

Assumes a foothold and asks what an attacker reaches next. This is where segmentation gets validated and where most enterprises discover their flat-network problem.

3. Web application testing:

Follows the OWASP Web Security Testing Guide, covering authentication, session management, authorisation, input validation, business logic and configuration. Depth here depends almost entirely on whether testing is authenticated and multi-role.

4. API testing:

Targets the OWASP API Security Top 10 categories: object-level and function-level authorisation, excessive data exposure, resource consumption, and unsafe consumption of third-party APIs. APIs need testing independently of the interface that fronts them, because the interface hides nothing from a direct caller.

5. Mobile application testing:

Follows the OWASP Mobile Application Security Testing Guide, covering client-side storage, transport security, binary protections, and the backend the app talks to. Mobile binaries also leak internal endpoints more reliably than any other source.

6. Cloud penetration testing:

Examines IAM policy, storage exposure, network security groups, key management, logging coverage and the metadata service. Cloud testing is largely a configuration and identity exercise rather than an exploitation one.

7. Active Directory and identity testing:

Deserves its own line because enterprise compromises usually escalate here. Recurring categories include delegation misconfiguration, service account privilege, credential exposure in scripts and Group Policy, and certificate services misconfiguration.

8. Wireless testing:

Covers rogue access points, weak authentication, guest network segregation and whether the corporate SSID leads anywhere sensitive.

9. Segmentation testing: 

Validates that network zones are genuinely separated. PCI DSS requires it explicitly, and it is useful well beyond card environments.

10. Container and Kubernetes testing:

Examines cluster RBAC, pod security policy, secrets handling, image provenance and the control plane. Relevant where workloads are orchestrated.

11. IoT and OT testing:

Applies where the organisation runs connected devices or industrial control systems. It requires different tooling and far more caution around availability.

12. Social engineering:

Covers phishing, vishing and pretexting, within a legal and HR-approved framework. It tests people and processes rather than technology.

13. Physical security testing:

Covers facility access, tailgating and device security, and requires explicit written authorisation naming the facilities and the individuals permitted to test.

14. Red teaming and adversary simulation:

Combines several of the above against a defined objective, without defender foreknowledge.

Knowledge levels

Grey box is the right default for most enterprise work. Pure Black Box spends a meaningful share of a fixed budget rediscovering facts you could have supplied in an email.

The scoping framework

Scope is where engagements succeed or fail. Work through these nine dimensions before requesting a quote.

1. Assets – 

Named applications, IP ranges, domains and subdomains, API endpoints, cloud accounts and subscriptions, and mobile applications by platform. Reconcile four sources: gateway configuration, source repositories, passive traffic observation, and external reconnaissance, including certificate transparency logs.

2. Environment – 

Production, staging, or both. Production carries operational risk and is what regulators increasingly expect. DORA Article 26 requires TLPT on live production systems explicitly, with no test-environment substitution permitted.

3. Knowledge level and credentials – 

Which roles and how many accounts are there per role? Provision at least two accounts per role. Horizontal privilege escalation cannot be tested with one, and this single omission is the most common cause of a missed critical finding.

4. Identity and account scope – 

Which directory, which trust relationships, and whether cloud identity is in scope alongside on-premises.

5. Geographic and jurisdictional boundaries – 

Where the assets sit, where the testers sit, and whether any data protection or export restriction applies to either. This matters more than teams expect for multinational scopes.

6. Third-party dependencies – 

Which SaaS platforms, which hosting providers, which integrations? Each may require its own authorisation, and some may contractually prohibit testing.

7. Testing windows – 

Business hours, out-of-hours, and blackout periods around financial close or peak trading.

8. Exclusions – 

Systems too fragile to test, techniques not permitted, data not to be accessed. Get exclusions in writing. Undocumented exclusions become your problem when something is later found to have been out of scope.

9. Authorisation and rules of engagement – 

The signed authorisation letter includes named escalation contacts on both sides with out-of-hours cover, an agreed protocol for critical findings discovered mid-engagement, and agreed halt conditions.

A scope document covering those nine dimensions, attached to your RFP, will produce comparable quotes. Without it, you will receive quotes that differ by a factor of five and cannot be compared rationally.

What Are the Five Phases of Enterprise Penetration Testing Methodology?

The five phases are planning and scoping, reconnaissance and discovery, vulnerability identification and exploitation, post-exploitation and impact analysis, and reporting with remediation validation. Recognised methodologies including PTES, NIST SP 800-115 and the OWASP testing guides structure the process differently in detail, but the sequence and intent are consistent.

No single methodology is mandatory. What matters is that the provider follows a documented methodology and can show you which one.

Phase 1: Planning and scoping

Scope confirmed against the nine dimensions above. Authorisation signed. Rules of engagement agreed. Test accounts provisioned and verified as working before day one.

Threat modelling belongs here. The tester should be asking what an attacker would want from this specific business. With a lending platform, how does money leave without repayment? On a healthtech platform, how does an attacker reach records without a clinical relationship? Across multi-tenant SaaS, how does one customer reach another’s data?

Evidence produced: scope document, authorisation letter, rules of engagement, threat model.

Phase 2: Reconnaissance and discovery

Passive and active information gathering. Subdomain enumeration, certificate transparency review, service and version fingerprinting, technology stack identification, and content discovery for undocumented routes.

In this phase, use Nmap to enumerate hosts and services, Amass or Subfinder to discover subdomains, ffuf or dirsearch to discover content, and Wireshark to analyze protocols at the protocol level when needed.

A representative service enumeration command, run only against authorised targets:

The rate limit matters. Enterprise edge devices and older appliances fail under aggressive scanning, and an availability incident caused by testing damages the programme more than the findings help.

This phase routinely surfaces assets the client did not know were live. This phase routinely discovers staging environments indexed by search engines, deprecated API versions still responding, and integration endpoints from pilots that ended years ago.

Evidence produced: asset inventory as discovered, service enumeration output, and discrepancy list against the client’s own inventory.

Phase 3: Vulnerability identification and exploitation

Automated scanning establishes the baseline quickly. Nessus, Nuclei and OWASP ZAP cover known CVEs, misconfigurations and missing headers. This work should be fast and should not dominate the engagement.

Manual testing follows, and this phase is where the engagement earns its cost. Burp Suite Professional is the standard workbench for application and API work, with Repeater and Intruder used for authorisation testing across roles, and session handling configured for multi-account work. BloodHound maps Active Directory attack paths. Metasploit is used for validated exploitation where the rules of engagement permit.

Exploitation is bounded. The objective is proof, not damage. Testers should demonstrate access without exfiltrating production data and should stop at the point where impact is established.

Evidence produced: validated findings with reproduction steps, request and response captures, and proof-of-access screenshots.

Phase 4: Post-exploitation and impact analysis

The phase that produces enterprise-relevant findings. Privilege escalation, lateral movement, persistence assessment where authorised, and determination of what a compromise actually reaches.

Each step is mapped to MITRE ATT&CK techniques so defenders can check detection coverage per technique rather than per finding.

Safety controls apply throughout. No destructive actions. No production data exfiltration. Persistence mechanisms documented and removed. A running activity log timestamped for SOC correlation.

Evidence produced: attack path narrative, ATT&CK technique mapping, detection timeline for comparison against SOC records, and business impact assessment.

Phase 5: Reporting, remediation and validation

Findings documented with severity, evidence, business impact and remediation guidance. We need to conduct a walkthrough session with the engineering team, because if a developer misunderstands the issue, they may close it incorrectly, which is worse than leaving it open.

Remediation follows, then an independent retest. The retest verifies both that the original issue is closed and that the fix introduced nothing new.

Evidence produced: full report, remediation roadmap, retest results with dates, and attestation letter where required.

Want a Sample Penetration Testing Report?

See how our experts document vulnerabilities, risk severity, and clear remediation steps.

Download Sample Report→

Methodology references worth naming in your RFP

Asking a prospective provider which methodology they follow and requesting the mapping in the report filters vendors quickly. A provider whose entire methodology is a tool list has answered the question.

Which Infrastructure Areas Should an Enterprise Pentest Cover?

Enterprise scope spans external and internal networks, Active Directory and identity, endpoints and servers, segmentation, cloud infrastructure, SaaS and third-party integrations, web and mobile applications, APIs, databases, containers, VPN, wireless, email, DNS, CI/CD and, where present, IoT and OT. Each area has distinct weakness categories and distinct remediation.

The matrix below replaces the generic “we test your network” statement with something you can hold a provider to.

A defensive validation example worth running yourself

Active Directory delegation misconfiguration is a recurring enterprise finding, and it is checkable without any offensive tooling. Unconstrained delegation permits a host to impersonate any authenticating user, which makes it a high-value target.

Domain controllers will appear legitimately. Anything else warrants investigation.

The remediation is to move the account to constrained delegation, scoped to named services, and to mark sensitive accounts as not delegatable:

Why the fix works. Unconstrained delegation stores a forwardable ticket-granting ticket on the host, so compromising that host yields the credentials of everyone who authenticated to it. Constrained delegation limits impersonation to named services. Marking privileged accounts as not delegatable prevents their tickets from being cached on a delegating host at all.

Limitations worth stating. This addresses one delegation class. Resource-based constrained delegation carries its own risks and is configured on the target rather than the source, so a separate audit is needed. The third command is also disruptive if any privileged account legitimately relies on delegation, so validate before applying in production.

If you work through this matrix with a prospective provider, asking which areas are in scope and whether coverage is automated or manual, you will learn more about the engagement than any proposal document will tell you.

What Do Global Compliance Frameworks Actually Require: DPDP, HIPAA, SOC 2, DORA and CPS 234?

These five frameworks differ fundamentally in what they require. DORA names a testing frequency. PCI DSS names one. HIPAA, SOC 2, CPS 234 and India’s DPDP framework do not. Treating any of them as a universal annual pentest mandate misstates the law and produces testing scoped against the wrong obligation.

Each framework is covered below with its jurisdiction, applicability, security expectation, relationship to penetration testing, and limitations. Every claim is traceable to the named instrument.

India: the Digital Personal Data Protection framework

Jurisdiction and applicability. The Digital Personal Data Protection Act, 2023, applies to processing of digital personal data within India and to processing outside India where it relates to offering goods or services to data principals in India. The DPDP Rules were notified on 13 November 2025, with Data Protection Board provisions effective immediately, consent-manager provisions from 13 November 2026, and the substantive compliance obligations from 13 May 2027.

Security expectation. Section 8(5) obliges every Data Fiduciary to implement reasonable security safeguards to prevent personal data breaches. Section 8(6) requires breach notification to the Board and affected data principals.

Relationship to penetration testing. The Act does not name penetration testing, prescribe a frequency, or mandate a methodology. What it creates is liability for the absence of safeguards, and testing is one of the most direct ways to evidence that safeguards existed and were verified. Significant Data Fiduciaries carry additional obligations under Section 10, including regular assessments of data protection impacts and independent audits, where testing evidence is more directly relevant.

Penalties. The schedule sets ceilings: up to ₹250 crore for failure to implement reasonable security safeguards and up to ₹200 crore for breach notification failure. These are maxima, and Section 33 factors apply before an amount is fixed.

Limitation to state clearly. No one can currently say with authority what “reasonable” means under DPDP, because enforcement practice does not yet exist. Anyone claiming a definitive DPDP testing requirement is extrapolating.

Interaction worth planning for. DPDP breach notification and CERT-In’s six-hour incident reporting under Direction 20(3)/2022 run in parallel, to different bodies, on different clocks. Incident response plans operating in India need both paths documented.

United States: HIPAA Security Rule

Jurisdiction and applicability. Covered entities and business associates handling electronic protected health information in the United States.

Security expectation. The current Security Rule requires risk analysis under 45 CFR 164.308(a)(1)(ii)(A), risk management, and periodic technical and non-technical evaluation under 164.308(a)(8). Methods and frequency are risk-based.

Relationship to penetration testing. The current Security Rule does not require penetration testing and does not name an annual cadence. It requires that you identify risks and evaluate whether safeguards remain effective. A well-scoped test provides strong evidence for both, but the rule does not prescribe it.

The proposed change. On 27 December 2024, the HHS Office for Civil Rights issued a Notice of Proposed Rulemaking that would require automated vulnerability scanning at least every six months and penetration testing by qualified persons at least every twelve months, or more frequently where the entity’s risk analysis requires it. The proposal also addresses mandatory encryption, MFA, asset inventories, network maps and segmentation.

Status as at September 2026: the NPRM has not yet been finalised. The proposed provisions are not binding. The federal Unified Agenda has listed the rule under RIN 0945-AA22 with projected final action dates that have moved more than once, most recently to 2027.

Limitation to state clearly. Vendor content asserting that HIPAA mandates annual penetration testing is describing a proposal as though it were law. Buy testing because your risk analysis justifies it, not because of a rule that has not yet been finalised.

United States: SOC 2

Jurisdiction and applicability. Not a regulation. SOC 2 is an attestation report produced by a licensed CPA firm against the AICPA Trust Services Criteria. Applicability is contractual, driven by customer requirements.

Security expectation. The Trust Services Criteria address logical access (CC6 series), system operations and vulnerability management (CC7 series), and monitoring of controls (CC4 series).

Relationship to penetration testing. The Trust Services Criteria do not explicitly require penetration testing. In practice most auditors expect it as evidence under CC4.1 monitoring of controls and CC7.1 vulnerability detection, and many enterprise customers require it contractually regardless of the auditor’s position.

Limitation to state clearly. A SOC 2 report’s value depends entirely on its stated scope, the criteria selected, and whether it is Type I or Type II. “We are SOC 2 compliant” is not a meaningful statement without those details.

European Union: DORA

Jurisdiction and applicability. Regulation (EU) 2022/2554 applies across the EU to a broad set of financial entities, including credit institutions, payment institutions, investment firms, insurers, trading venues and crypto-asset service providers, plus designated critical ICT third-party providers. It has applied since 17 January 2025.

Security expectation. Article 25 requires a digital operational resilience testing programme, including vulnerability assessments and scans, and testing of ICT systems supporting critical functions at least annually.

Relationship to penetration testing. DORA is the most prescriptive of the five. Article 26 requires threat-led penetration testing at least every three years for financial entities identified by the competent authority, excluding microenterprises and certain entity types. The specifics matter:

• Testing must cover several or all critical functions
• Testing must be performed on live production systems, with no test-environment substitution
• Organizations must include systems supporting critical functions that they outsource to ICT third-party providers within the scope
• Article 27 sets requirements for testers, including competency and independence
• The regulatory technical standards, published on 17 July 2024, specify phases, methodology and remediation, and make purple teaming mandatory in the closure phase
• Internal testers are permitted for up to two of every three TLPT cycles; the third must use external testers, and threat intelligence must always come from an external provider
• TLPT follows the TIBER-EU framework, with the ECB publishing a TIBER-EU SSM Implementation Guide in November 2025

Limitation to state clearly. Article 26 does not apply to every financial entity. It applies to those identified by their competent authority on the basis of systemic importance and ICT risk profile. A small payment institution is subject to Article 25 testing obligations but very likely not to TLPT. A recurring supervisory criticism concerns mis-scoped perimeters rather than absent testing, particularly incomplete mapping of outsourced systems supporting critical functions.

Australia: APRA CPS 234

Jurisdiction and applicability. Prudential Standard CPS 234 applies to APRA-regulated entities in Australia: authorised deposit-taking institutions, general insurers, life companies, private health insurers and registrable superannuation entity licensees. It extends to third parties managing information assets on their behalf.

Security expectation. Paragraph 27 requires entities to test the effectiveness of information security controls through a systematic testing programme, with nature and frequency commensurate with five named factors: the rate at which vulnerabilities and threats change, the criticality and sensitivity of the information asset, the consequences of an incident, the risks of exposure to environments where the entity cannot enforce its policies, and the materiality and frequency of change to information assets.

Relationship to penetration testing. CPS 234 does not name penetration testing or prescribe a frequency. It requires systematic testing proportionate to those five factors, conducted by appropriately skilled and functionally independent specialists. Paragraph 28 requires entities relying on a third party’s control testing to assess whether that testing is commensurate with the same factors.

Limitation to state clearly. CPS 234 is principles-based. Any vendor claiming it mandates annual penetration testing is supplying an interpretation, not quoting the standard. What the standard does require is that your chosen frequency be justifiable against paragraphs 27(a) to 27(e), which means you must document the reasoning.

Comparison

What this means when scoping an engagement

First, specify the required frameworks during the scoping stage rather than adding them later. This way, a single engagement can produce evidence that supports several compliance obligations. Moreover, building the framework mapping into the process from the start makes reporting easier. Otherwise, retrofitting control mappings onto a completed report can be difficult and, in some cases, impossible.

And verify every regulatory claim against the current instrument before you rely on it. The HIPAA example above shows how quickly market convention drifts from legal text.

How Much Does Enterprise Penetration Testing Cost?

There is no defensible universal price. Cost is driven by scope volume, testing depth, the manual-to-automated ratio, tester seniority, geography, regulatory mapping requirements and retest inclusion. Published ranges vary widely by region and rarely state their scope assumptions, which makes most quoted figures unusable for budgeting.

This section explains the drivers and gives a framework for evaluating quotes, rather than inventing a figure.

Why published pricing is unreliable

Three problems affect almost every pricing figure you will find.

• Scope assumptions are usually unstated. A quoted range for ‘a web application pentest’ means nothing unless you know the role count, endpoint count, whether testing is authenticated, and how many tester-days the client allocates.
• Geography moves the number substantially. Day rates differ by a factor of several between markets. A figure sourced from one region is not transferable to another.
• Vendor-published ranges reflect that vendor’s model. A firm selling automated testing with light review and a firm selling three weeks of senior manual work will both publish “penetration testing pricing”, and the numbers are not comparable.

For those reasons, this guide does not present a global price table. What follows is more useful: the drivers and how to evaluate a quotation.

The cost drivers

The PTaaS question

Penetration Testing as a Service subscriptions bundle periodic testing with a platform for findings management, often with continuous scanning between engagements.

The model suits organisations with frequent releases and an appetite for continuous visibility. You should ask how much genuine manual testing the subscription includes per cycle, because some PTaaS offerings rely largely on automation with periodic manual review. That is a legitimate product, but it is not equivalent to a scoped manual engagement, and you should not price it as such.

A framework for evaluating quotations

Ask every bidder for the same seven data points, and the quotes become comparable:

1. Total tester-days, split manual and automated
2. Named assigned testers with certifications
3. Roles and accounts required
4. Methodology followed, named
5. Frameworks’ findings will be mapped to
6. Number of retest rounds included
7. What is explicitly excluded

The diagnostic question. Ask what proportion of findings on a typical engagement came from manual work rather than tooling. A serious firm gives you a number with a caveat about variance by application type. A scanner-led firm gives you a paragraph about their comprehensive hybrid methodology.

A cost red flag worth mentioning. If the quoted price cannot support the tester-days claimed at any plausible day rate for that market, something is being substituted. Work the arithmetic backwards before comparing on price.

Treat cost as a function of scope and depth rather than a market rate, and the comparison becomes tractable.

What Should an Enterprise Penetration Testing Checklist Cover?

A working checklist spans five stages: before testing, during testing, after testing, remediation, and retesting. First, the pre-testing stage determines most of the engagement’s value because proper preparation ensures that testers spend their time finding security issues rather than figuring out how your environment is assembled. As a result, clear scope, access, documentation, and test requirements can help testers focus on identifying and validating vulnerabilities.

This stage is built to be usable directly by a security manager.

1st Stage: Before testing

Objectives and scope

• The testing objective was stated in one sentence, and it was agreed with the sponsor.
• Driver identified: regulatory, contractual, risk-based, or post-incident
• Asset inventory complete, reconciled across gateway configuration, repositories, passive traffic and external reconnaissance
• Scope document covering all nine dimensions from section 5
• Exclusions documented with written justification
• Environment decided: production, staging, or both, with rationale
• Framework mapping specified up front

Authorisation and legal

• Signed authorisation letter naming assets, window and permitted techniques
• Rules of engagement agreed, including halt conditions
• Third-party and cloud provider authorisation obtained where required
• NDA executed
• Legal and HR sign-off where social engineering or physical testing is in scope

Logistics

• The testing window was agreed upon, with blackout periods identified.
• Source IP allowlisting completed
• At least two test accounts per role, provisioned and verified, working before day one
• Role definitions documented, stating intended permissions per role
• VPN or bastion access is arranged where internal testing is in scope
• Named escalation contacts on both sides, with out-of-hours cover
• Out-of-band path agreed for critical findings discovered mid-engagement

Vendor qualification

• A redacted sample report was requested and actually read.
• Assigned testers named, certifications verified, written into the contract
• Methodology named and documented
• Insurance and liability position confirmed
• Retest rounds confirmed in writing

Self-preparation

• Free scanner run internally first; obvious issues already fixed.
• Default and test credentials removed from production
• Repository history checked for committed secrets
• Error pages confirmed not to return stack traces
• Engineering team briefed that testing is coming and why

2nd Stage: During testing

• Kickoff call completed, scope confirmed verbally
• Daily or milestone progress updates agreed and arriving
• Critical findings escalated out of band within hours, not held for the report
• Testing activity logged with timestamps for later SOC correlation
• Production impact monitored, with the halt protocol available
• Scope changes documented and approved in writing, never verbally
• SOC informed or deliberately not informed, per the engagement design

3rd Stage: After testing

• Draft report received and reviewed for factual accuracy
• Walkthrough session held between testers and the engineering team
• Severity ratings reviewed against your business context, not accepted raw
• False positives challenged and resolved
• Attack paths understood by the people who will fix them
• Detection timeline compared against SOC records, gaps recorded
• Findings mapped to the applicable frameworks
• Executive summary reviewed for board readability

4th Stage: Remediation

• Every finding assigned a named owner and a target date
• Prioritisation by exploitability and business impact, not severity score alone
• KEV and EPSS checked for any CVE-based findings
• Definition of done stated per finding, testable rather than aspirational
• Fixes reviewed for regression risk before deployment
• Risk acceptance decisions documented with named approver, date and expiry
• Remediation log maintained live, not reconstructed later

5th Stage: Retesting and closure

• Retest scheduled with the same provider
• Original findings verified closed with evidence
• Patches checked for newly introduced issues
• Revised report and attestation letter issued
• Evidence filed against the relevant framework control identifiers
• Lessons applied to the secure development lifecycle
• Next cycle diarised, with triggers listed
• Board or committee briefed on posture movement, not finding counts

Working this list end to end takes discipline rather than budget, and it is the highest-leverage thing a security manager can do to improve engagement outcomes.

What Common Challenges Do Enterprise Penetration Testers Face, and How Do They Solve Them?

The recurring failures are not technical. They are incomplete asset inventories, have unclear scope, have weak remediation ownership, and have an inability to translate findings into business risk. Each challenge has a practical mitigation, and most require cost discipline rather than budget.

Each challenge below is paired with a mitigation you can take action on this quarter.

Structuring remediation around the attack chain

Individually low-severity findings rarely move a remediation budget. Chained, they do. Structuring the narrative around the path makes the argument for you.

Returning to the manufacturer example from section 1:

Initial foothold. An outdated CMS plugin on a marketing subdomain yields code execution on a DMZ host. Control fix: patch and remove the plugin, move the subdomain behind the standard WAF and patch baseline, and add the host to the managed asset inventory. Retest: confirm code execution is no longer achievable.

Pivot. The DMZ host reads an internal file share containing a deployment script with a plaintext service credential. Control fix: segment the DMZ so internal shares are unreachable, remove the credential from the script, move it to a secrets manager, and audit all shares for embedded credentials. Retest: confirm the share is unreachable from the DMZ and the credential is rotated.

Objective. The service account holds local administrator rights across a server group, provisioned for a 2019 migration. Control fix: reduce the account to least privilege, rotate the credential, implement a tiered administration model, and review every service account provisioned for a completed project. Retest: confirm the account no longer holds administrative rights and the path is broken at three points.

Presenting remediation this way changes the conversation. Instead of thirty medium findings ordered by score, leadership sees one path with three breakpoints and can fund the cheapest one that severs it.

The consistent theme across all of these challenges is that engagement quality depends as much on the buyer’s preparation as on the provider’s skill.

What Should a Comprehensive Enterprise Penetration Testing Report Include?

A report serves three readers with different needs: executives need risk posture and decisions, engineers need reproduction steps and fixes, auditors need scope, methodology and traceability. A report written for one audience requires your team to translate it for the other two.

This section sets out the structure that serves all three, and what each reader actually needs.

The structure

Sections 7, 11, 12 and 13 are the ones most often missing, and they are the ones that determine whether the document is usable outside engineering.

What each finding should carry

Finding ID:

EPT-2026-014 Title: Service account with excessive privilege enables lateral movement to production server group Severity: Critical. CVSS v3.1 base 8.8, adjusted for exposure and data sensitivity CWE: CWE-266, Incorrect Privilege Assignment ATT&CK techniques: T1078 Valid Accounts, T1021 Remote Services, T1552.001 Credentials In Files Status: Closed, retested and verified 4 September 2026

Affected assets:

svc_deploy_legacy service account; 14 hosts in the PROD-APP server group

Description:

A service account provisioned in 2019 for a completed migration retains local administrator rights across the production application server group. An attacker recovered the account credential in plaintext from a deployment script on an internal file share that a compromised DMZ host could read earlier in the assessment.

Attack path:

Initial foothold via an outdated CMS plugin on the marketing subdomain, followed by reading an internal file share, recovering credentials, and gaining administrative access across 14 production hosts. The full chain is documented in Appendix B, items 4.1 to 4.9.

Evidence:

Authenticated session screenshots, host enumeration output, and timestamped activity log for SOC correlation. Appendix B.

Business impact:

Administrative access to the production application tier. An attacker at this position could modify application behaviour, access the customer database tier, or establish persistence. No production data was accessed during testing.

Detection result:

No alert was generated at any stage of the chain. Sixteen hours of activity across three hosts produced no SOC notification.

Framework mapping:

ISO/IEC 27001:2022 A.8.2 privileged access rights, A.8.3 information access restriction · NIST CSF 2.0 PR.AA-05 · CIS Control 5

Remediation:

Reduce the account to the least privilege required for its current function, or decommission if unused. Rotate the credential. Remove the credential from the deployment script and move it to a secrets manager. Audit all internal files shares for embedded credentials. Implement a tiered administration model. Review every service account provisioned for a completed project.

Retest result:

Verified closed. Account decommissioned 28 August 2026. Deployment script credential removed and rotated. Share audit completed, two further embedded credentials were identified and remediated separately as EPT-2026-021 and EPT-2026-022.

The detection result line is worth highlighting. It is the single most useful data point in most enterprise reports and the one most providers omit entirely.

Executives versus engineers

Executives need:

We rate your overall posture, identify the three issues that matter in business terms, show the trend against your last assessment, report the remediation status, and ask what decision you need to make. One page. No CVSS vectors, no endpoint paths.

Engineers need:

reproduction steps they can follow unaided, the exact affected asset, the vulnerable and corrected configuration, and a definition of done that is testable.

A report that mixes these serves neither. Separating them is a formatting decision that costs the provider nothing and saves your team days.

Prepare for Penetration Tests with Qualysec

Choose a partner that helps you identify and fix real security risks before real hackers do.

Talk to an Expert→

Conclusion

Enterprise penetration testing earns its cost when it answers questions nothing else can. Does segmentation actually hold? Would anyone notice? Which of four thousand open findings can be reached and chained? Is the control we bought three years ago doing the job we assumed?

The two failures that waste the most money are both avoidable. Scoping against a requirement that does not exist, which the HIPAA example in section 8 illustrates, and buying a scan while believing you bought a test. Both are prevented by reading the instrument and asking about tester-days.

Get the preparation right, and everything downstream improves. A reconciled asset inventory, two accounts per role, a written trigger list named ‘remediation owners’, and retesting contracted as a deliverable rather than sold later. None of that requires a budget.

Qualysec is a specialised penetration testing company working across web applications, APIs, cloud environments, mobile applications and infrastructure. Automation clears the mechanical layer early, certified consultants spend the bulk of the engagement on authorisation logic and business flow abuse, and findings arrive with reproduction steps written for the engineer shipping the patch. Reports map to the frameworks you are filing against, and retesting is included rather than invoiced separately.

If you are scoping an engagement and want a second view on whether the scope covers what your obligation actually requires, that is a conversation worth having before the RFP goes out rather than after.

Frequently Asked Questions

1. How long does an enterprise penetration test take?

Two to four weeks for a single well-scoped application or a modest network range, including reporting and one retest. Four to ten weeks for a multi-asset enterprise scope spanning web, mobile, API and cloud. DORA threat-led testing typically runs three to four months because of the threat intelligence and scoping phases. Anything advertised as a complete enterprise assessment in a few days is a scan.

2. Should we test production or a staging environment?

Production, where operationally feasible, because staging differs in configuration, integrations and access controls, and those differences are usually where the risk sits. DORA Article 26 requires production testing for TLPT with no substitution permitted. Where production carries genuine availability risk, agree to a controlled window and non-destructive rules of engagement rather than silently substituting staging.

3. Do we need to give testers credentials?

Yes, for almost any useful enterprise engagement. Most real risk sits behind authentication, and unauthenticated-only testing misses the entire authorisation class. Provide at least two accounts per role so horizontal privilege escalation can be tested. Grey box testing, with credentials and limited documentation, is the right default for enterprise scope.

4. How often should cloud environments be tested?

Configuration review should be continuous through automated posture tooling. Manual testing should follow the same event triggers as everything else: new region, major architectural change, new identity federation, or a significant change to IAM policy. Annual manual testing of cloud identity and storage configuration is a reasonable floor for most enterprises. Check your provider’s testing policy before starting.

5. Why do APIs need separate testing from the web application?

This is because the interface does not hide anything from a direct caller. An application may mask a field, hide an administrative control, or enforce a check in JavaScript, while the API behind it does none of those things. API testing targets object-level and function-level authorisation directly, which is where the OWASP API Security Top 10 concentrates its highest-ranked risks.

6. Is Active Directory testing really necessary if we are moving to cloud identity?

Usually yes, because hybrid is the common reality rather than an interim state. Most enterprises retain on-premise directory services alongside cloud identity, and the trust relationship between them is itself an attack surface. Delegation misconfiguration, service account privilege issues, and certificate services issues remain exploitable regardless of the progress of cloud migration.

7. Does a penetration test make us compliant?

No. Testing produces evidence that supports compliance obligations. It does not confer compliance. HIPAA requires risk analysis and management, SOC 2 requires an auditor’s attestation against selected criteria, DORA requires a testing programme plus much else, and DPDP requires reasonable safeguards across the whole processing lifecycle. A test is one input.

8. How do we choose between penetration testing and red teaming?

Choose penetration testing if you want to know what is exploitable. Choose red teaming if you already have detection capability and want to know whether it works. Running a red team exercise against an organisation with no SOC produces predictable and expensive results. The sensible sequence is assessment, then penetration testing, and finally red teaming, once there is something to measure.

9. What should we do if the test finds critical issues?

Nothing dramatic. Almost every first engagement surfaces critical findings, and that is the process working. Contain if the issue is actively exploitable, remediate by priority, then retest. Your rules of engagement should define an out-of-band escalation path so critical findings reach you within hours rather than in the final report.

10. Is retesting always necessary?

For anything you intend to report as closed, the answer is yes. A finding marked ‘resolved’ without independent verification is a decision to believe rather than a confirmation. Retesting also catches regressions introduced by the fix, which happens more often than teams expect. Contract it as a deliverable rather than accepting it as an extra paid.

11. How do we verify a provider’s competence?

Request a redacted sample report and read it properly. Inquire what proportion of findings on a typical engagement came from manual work. Demand the names and certifications of the assigned testers and get them written into the contract. Confirm the methodology by name. Those four questions filter most of the field.

12. Can internal teams perform enterprise penetration testing?

Partly. Internal teams are well placed for continuous scanning, secure development practice and pre-engagement cleanup, which reduces what you pay for external testing. But independence matters both for objectivity and for most compliance frameworks. APRA CPS 234 requires functionally independent specialists, and the HIPAA NPRM proposes qualified individuals. DORA permits internal testers for TLPT only for two of every three cycles.

13. How should findings be prioritised for remediation?

Findings should be prioritised by exploitability and business impact rather than severity score alone. Four questions, in order: is this being actively exploited, checked against the CISA KEV catalogue and EPSS; what does the affected asset expose; how reachable is it from outside; and what does the gap block commercially? A backlog sorted by CVSS buries the handful of items that matter.

14. What is the difference between a penetration test and a security audit?

A penetration test attempts to exploit weaknesses and prove impact. An audit assesses whether controls and processes exist and operate as documented, usually against a named framework. Audits are broader and more documentary; tests are narrower and more technical. Several regulatory regimes expect both, and some jurisdictions require a specifically accredited organisation to perform the audit.

15. Should social engineering be included in scope?

It depends on what you want to learn. Technical testing tells you whether systems resist attack. Social engineering tells you whether people and processes do. It requires legal and HR approval, careful framing to avoid punitive use of results, and clear rules about what testers may and may not do. Many enterprises run it as a separate exercise rather than bundling it.