Penetration testing

A penetration test covers the specific systems and attack surface agreed in scope, tested manually by a professional rather than only scanned automatically. The scope is agreed before testing starts, and it determines what is examined, how deeply, and what the engagement can and cannot tell you.

For an adversarial, objective-based exercise involving people, process and multiple attack paths rather than exhaustive testing of one defined target, see red teaming. For broader, largely automated identification of known weaknesses across many systems, see vulnerability assessment.

A penetration test is usually commissioned when an organisation needs hands-on assurance about a specific system, and the reason varies with the organisation, the system and the requirement involved.

Common situations include:

• before launching or materially changing an internet-facing product or service
• when a customer or contract requests independent security testing
• as part of a wider assurance or compliance programme
• after significant changes to an application, API or infrastructure
• when an organisation wants a deeper manual assessment than vulnerability scanning alone provides

There is no universal rule that every company needs a penetration test, or that tests should happen at the same interval everywhere. Need and frequency depend on factors such as system risk, how often the environment changes, customer and contractual requirements, regulatory or compliance context, previous findings, and the nature of the environment itself. Where the underlying question is broader than technical testing of a defined target, a security audit or audit-readiness exercise may be a better fit.

The type of test should reflect the system or attack surface you actually need assessed, rather than a generic package. Most requests fall into one of the areas below, and a provider can advise on what fits the scope you describe.

Hands-on testing of a web application and the functionality it exposes, including authentication, session handling, business logic and other application behaviour reachable within the agreed scope.

Testing of the interfaces an application exposes, including authentication, authorisation, input handling and the functionality available through the API to different roles or callers.

Assessment of internal or external network and infrastructure attack surfaces in scope, such as exposed services, hosts and configuration reachable by an attacker.

Some questions are better answered by an adjacent service. If the question concerns how securely software is designed, built and reviewed rather than a single test, see application security. If it concerns how a cloud environment is configured and architected, see cloud security. A broader adversarial exercise spanning people, process and multiple attack paths is red teaming, which is a different kind of engagement rather than a larger penetration test. And if you mainly need broad, largely automated coverage of known weaknesses, a vulnerability assessment is a related but different activity: scanning identifies known issues at breadth, while a penetration test involves a professional working hands-on within a defined scope.

A provider generally needs enough information to understand the proposed scope before they can suggest an approach or a price. Requirements vary between providers, but the following is often useful:

• what application, API, infrastructure or environment needs testing
• what is explicitly in scope and out of scope
• whether the target is production, staging or another environment
• whether authenticated access or test accounts can be provided
• the relevant user roles or permission levels
• the reason for the test, such as internal assurance, a customer request or a contractual requirement
• any deadline, and what is driving it
• whether a formal report is required for a customer or third party
• any important operational or testing constraints

Clearer scope generally makes it easier for providers to propose appropriate work and pricing, though the approach and cost still depend on the provider and what you agree together.

Once you know roughly what needs testing, the choice of provider is mostly about fit with that scope. Points worth considering:

• experience with the relevant type of system or technology
• their proposed testing approach and how they define scope
• how findings are communicated during and after the engagement
• report format, and who the report is intended to be read by
• whether remediation guidance or retesting forms part of the agreed scope
• relevant credentials or accreditations, where these matter to the requirement you are meeting
• ability to work within your operational constraints and timelines

Heelr's identity and provider verification requirements are a starting point for your own due diligence, not an assessment of technical expertise or suitability for a particular engagement.

Most engagements conclude with the findings documented in a report, though the exact deliverables depend on what you agreed in scope.

A report may include:

• the vulnerabilities or findings identified
• severity ratings or prioritisation
• the affected systems or components
• evidence supporting each finding
• remediation guidance
• an executive or customer-facing summary, where agreed

Responsibility for remediation stays with your organisation unless remediation work is separately included in the scope. Some engagements also include retesting after fixes are made, if that is agreed with the provider.

It is worth being clear about what the result represents. A penetration test reflects the system and the scope that were tested, at the point in time they were tested. It does not certify that a product, company or environment is secure, and a report with few findings is not a guarantee about future security or about how any customer will respond.

Customer requests are one of the most common triggers, and they are worth unpacking before commissioning anything. Clarify exactly what the customer requires, confirm which system or product they expect to be tested, and establish whether they need a report or some other form of evidence. Understand any deadline attached to the commercial process, and check whether testing or evidence you already hold may be relevant to what they are asking for. Where new testing is genuinely required, commission it against a scope that matches the request.

Not every request means a new test is automatically necessary. For wider context on security requirements in an enterprise deal, see our guide for startups selling to larger customers.