Hacker AcademyHacker Academy

Penetration testing guide

When you need penetration testing, what it covers, and what to expect.

Penetration testing helps you find and validate exploitable weaknesses before attackers do. This guide explains how to plan a useful engagement, including the concrete testing expectations that apply under PCI DSS.

What is penetration testing?

A penetration test is an authorised, controlled attempt to identify and validate weaknesses in systems, applications, cloud environments, or networks. The work goes beyond a vulnerability scan: testers investigate whether a weakness can be exploited, what an attacker could reach, and how the issue should be fixed.

The aim is not simply a list of technical findings. A useful test gives leadership and technical teams evidence of material risk, context for prioritisation, and a practical route to remediation.

When should you test?

Testing is most valuable when it is linked to a decision, a change, or an assurance need. Common triggers include launching a customer-facing application, making a significant infrastructure or cloud change, onboarding a major client, responding to a customer security questionnaire, or validating the effectiveness of security controls.

The right frequency depends on risk, change, exposure, and contractual commitments. For some organisations, an annual cycle supports assurance. For others, testing should also follow meaningful changes to the environment.

What does a test cover?

Scope should match the asset, threat model, and assurance objective. It can include public-facing infrastructure, internal networks, web and API applications, cloud environments, identity systems, wireless networks, or segmentation controls.

Clear rules of engagement and agreed testing windows
Manual validation of weaknesses and attack paths
Evidence of impact, without unnecessary disruption
Prioritised findings with remediation guidance

Compliance and assurance

PCI DSS and other requirements

For organisations and systems within PCI DSS scope, penetration testing is a specific requirement. PCI DSS expects internal and external penetration testing at least annually and after significant changes, using a defined methodology. The engagement must reflect the cardholder data environment and, where relevant, validate segmentation controls.

PCI DSS is a clear example of a standard that sets concrete testing expectations. Customer contracts, insurers, regulators, and sector frameworks can also require evidence of testing. ISO 27001 does not impose one universal annual pentest for every organisation; its risk-based approach means the right assurance activity should follow the organisation's scope, risk treatment, and applicable obligations.

The practical question is therefore: which obligations apply to this system, and what evidence will demonstrate that the controls are working? A properly scoped penetration test can be part of that evidence.

Reference: PCI SSC Penetration Testing Guidance.

How to prepare and use the results

Start by agreeing the systems in scope, key contacts, testing windows, rules of engagement, and the risk or compliance question the test needs to answer. This prevents a broad technical exercise from producing a report that does not help the business make a decision.

After testing, review findings by exploitability and business impact. Assign owners and dates for remediation, fix the highest-risk issues first, and retest material fixes where assurance is needed. A report has value when it drives that work through to completion.

Planning a penetration test?

We can help you define a proportionate scope, test the systems that matter, and turn the findings into an actionable remediation plan.