How to Prepare for a Penetration Test: A Practical Buyer's Guide

A penetration test is one of the few security purchases where the buyer shapes the result as much as the supplier. Give a capable team a vague scope and a broken test account, and you get a thin report. Give the same team a clear objective, working access and a contact who answers the phone, and the same budget produces findings your engineers can act on.

The UK National Cyber Security Centre (NCSC) describes penetration testing as a way of gaining assurance in your security, not a primary method for finding vulnerabilities, and points out that a test only shows whether your systems are vulnerable to known issues on the day it runs. The value comes from asking the right question, testing the right things and acting on the answer.

This guide is for security leaders and CTOs at growing companies who commission tests rather than run them.

Start With the Question You Need Answered

Every useful test starts with one sentence describing what you want to learn. "Can someone on the internet reach customer data?" leads to a very different engagement from "How far could an attacker get from a compromised laptop?"

Do the basics first. If you are not already scanning for vulnerabilities and tracking what you expose to the internet, testers will spend expensive days reporting missing patches and forgotten hosts. Continuous attack surface discovery and routine scanning should catch those, leaving testers free to look for what tools miss: broken access control, chained weaknesses and abuse of business logic.

Choose the Right Type of Test

Tests are usually described by their target. Most growing companies need several over time, but rarely all at once.

An internal test rehearses the lateral movement phase of an attack, starting from an assumed foothold. For web applications, the OWASP Web Security Testing Guide is a widely used reference; version 4.2 is the current stable release, with version 5.0 in development. For mobile apps, the OWASP Mobile Application Security project pairs a verification standard (MASVS) with a testing guide (MASTG) for Android and iOS.

Black, Grey or White Box

The second choice is how much the testers know at the start.

• Black box: testers start with little more than a target list. The NCSC notes that this lack of information can leave vulnerabilities undiscovered in the time available.
• Grey box: testers receive accounts for each user role and some documentation, so time goes on testing rather than reconnaissance. For applications this is often the best use of a fixed budget.
• White box: testers receive full information, which can include source code. The NCSC says this kind of open test confirms how well your internal vulnerability assessment and management controls work.

NIST SP 800-115 also distinguishes overt testing, done with the knowledge and consent of IT staff, from covert testing, done without their knowledge but with the full knowledge and permission of upper management. Covert testing also exercises detection and response, but NIST notes that overt testing is less expensive, carries less risk and is used more often.

Scope the Engagement Properly

Scoping is where most of a test's value is won or lost. The NCSC recommends involving risk owners, technical staff who know the target system and a representative of the testing team, and producing a document that sets out the technical boundaries, types of test, timeframe and amount of effort.

Before the scoping call, prepare the following.

• Targets: IP ranges, hostnames, URLs, API documentation, app builds and cloud account identifiers
• Exclusions: systems you do not own and fragile legacy services
• Environment: production is most realistic; staging is safer but only useful if it closely mirrors production
• Access: working credentials for every role in scope, a plan for multi-factor authentication and synthetic test data
• Known issues: the NCSC advises sharing a current vulnerability assessment with the testers
• Timing: avoid release weeks and peak trading periods

Cloud and Third-Party Services

You can only authorise testing of systems you own or control, and the major cloud providers publish their own rules for customer testing.

• AWS lets customers test without prior approval for a published list of services, prohibits denial-of-service testing and requires prior approval for any testing that includes command and control (C2).
• Microsoft Azure has not required pre-approval since 15 June 2017, but testers must comply with the Microsoft Cloud Unified Penetration Testing Rules of Engagement, which prohibit denial-of-service testing.
• Google Cloud says customers do not need to contact Google before testing, but must abide by its Acceptable Use Policy and Terms of Service and make sure tests only affect their own projects.

Rules of Engagement and Authorisation

Written authorisation is what separates a penetration test from an attack, so treat it as a legal document. In NIST SP 800-115, the planning phase is where rules are identified, management approval is finalised and documented, and testing goals are set, before any testing happens.

Based on the rules of engagement template in NIST SP 800-115, yours should cover at least these points.

• Purpose, scope, assumptions, limitations and the risks of intrusive testing
• Named points of contact on both sides, including your incident response team
• The test schedule and the hours when testing may take place
• Where testing will originate and how tester activity can be told apart from a real attacker
• How the teams will communicate during the test
• Criteria for halting the test, and what happens if a live service is affected or a real attack occurs mid-test

Then add prohibited techniques (such as denial of service, or social engineering unless explicitly agreed), how sensitive data found during testing is handled and deleted, and how critical findings are escalated. Make sure the signatory has authority over every system in scope.

Unless the test is covert, give your security operations team the test windows and source addresses, and make sure your incident response plan names who can confirm whether suspicious activity belongs to the test. Otherwise a genuine alert may be dismissed as "probably the pen testers".

What Happens During the Test

NIST SP 800-115 describes four phases: planning, discovery, attack and reporting. Discovery covers information gathering, scanning and vulnerability analysis; the attack phase verifies potential vulnerabilities by attempting to exploit them, often feeding further discovery. The Penetration Testing Execution Standard (PTES) splits the same work into seven sections, from pre-engagement interactions through exploitation and post-exploitation to reporting.

Your role is to stay reachable: keep contacts available to fix broken accounts quickly, decide in advance who approves an emergency fix if something critical is escalated, and record any changes you make during testing.

What a Good Penetration Test Report Contains

The report is the product you are buying, so agree its structure in advance. According to the NCSC, it should include the security issues uncovered, a method of resolving each one, an opinion on the accuracy of your organisation's vulnerability assessment and advice on improving your internal vulnerability assessment process.

In practice, a report that serves both executives and engineers contains the following.

• A plain-language executive summary of overall risk, the most serious findings and their business impact
• Scope, methodology, test dates and limitations, including anything that could not be tested
• For each finding, the affected assets, evidence, steps to reproduce, a severity rating and specific remediation advice
• Attack narratives showing how lower-severity issues were chained into a serious compromise

Severity Scoring

Most reports rate findings with the Common Vulnerability Scoring System (CVSS). The current version, CVSS v4.0, was released by FIRST on 1 November 2023. The CVSS v4.0 specification states that the Base Score reflects a vulnerability's severity according to its intrinsic characteristics, and encourages organisations to enrich it with threat and environmental information as an input to their own risk assessment.

A CVSS score is a starting point for prioritisation, not a measure of business risk: a medium-severity flaw on the system holding customer data may matter more than a high-severity flaw on an isolated test server.

Remediation and Retesting

The NCSC is clear that risk assessment and decisions on fixes are your organisation's responsibility, and that vulnerability risk assessment and mitigation should not be wholly outsourced to the test team.

A workable remediation process looks like this.

1. Triage each finding with your own context: data sensitivity, exposure and compensating controls
2. Assign an owner and a target date, with tighter deadlines for higher severity
3. Fix root causes rather than single instances, and record any risk you accept and who accepted it
4. Retest to confirm each fix works and has not introduced a new problem

The NCSC recommends giving special attention to findings you did not already know about and working out how to catch similar issues yourself in future. Application findings should also feed back into your secure software development lifecycle as new test cases, so the same class of flaw does not return.

PCI DSS, for example, requires exploitable vulnerabilities found during penetration testing to be corrected and the testing repeated to verify the corrections. Agree the retest window and its cost in the original contract.

How Often Should You Test?

There is no single correct interval. The NCSC guidance does not set one, and observes that it is not uncommon for a year or more to pass between tests.

Where standards do set a frequency, it is usually annual plus change-driven. PCI DSS v4.0.1, which replaced v4.0 when that version was retired on 31 December 2024, sets these minimums.

SOC 2 contains no explicit penetration testing requirement, but the Cloud Security Alliance notes that a test can support several of the Trust Services Criteria and calls one highly advisable. Our guides to SOC 2 compliance automation and ISO 27001 and NIS2 readiness cover how testing fits into a wider evidence programme.

Outside formal requirements, a sensible baseline is to test each critical internet-facing system and application at least once a year, and again after significant change such as a major release, a new payment flow, a cloud migration or an acquisition, with continuous scanning in between.

Conclusion

A penetration test is only as useful as the preparation behind it. Decide the question you need answered, choose the test that fits it, scope precisely, put authorisation in writing and insist on a report with evidence and specific fixes. Then close the loop with remediation, retesting and a schedule that follows your rate of change.

If you want an outside view, Enigma Labs' cybersecurity audit and penetration testing services combine a structured audit across network, endpoints, identity, cloud and compliance with targeted penetration testing where it adds value. Critical findings are escalated as soon as they are confirmed, and the report comes with a prioritised remediation roadmap and a remediation workshop that walks your team through every finding.