Penetration Testing Checklist: How UK Companies Prepare in 2026

A penetration test is only as good as the preparation around it. Hand testers an unclear scope, the wrong credentials, or a blocking change-freeze window and you will pay for an engagement that finds nothing useful. This checklist walks through what a UK company needs to have in place, scope, access, legal, communication, and remediation, before the first packet is sent. Use it whenever you commission a CREST, CHECK, PCI DSS, or insurance-driven test.

Why preparation determines the value of the test

Penetration tests are time-boxed engagements. Testers usually have between 3 and 15 days to enumerate, exploit, validate, and write up. Every hour spent unblocking a missing VPN credential, chasing the right scope owner, or waiting on a change-window approval is an hour not spent finding the next critical finding. UK firms that prepare well consistently see two to three times more high-severity findings in the same engagement window, and far smaller invoices for retest scope creep.

1. Define the scope precisely

Asset inventory

• List every in-scope domain, subdomain, public IP, application, API, mobile app build, and cloud account.
• Mark anything explicitly out-of-scope (third-party SaaS you do not own, production payment rails under change freeze, etc.).
• Identify the data classifications each asset handles (PII, PCI, PHI, market-sensitive).
• Confirm hosting locations and who owns each environment.

Test type

• Choose between black-box (no information), grey-box (standard user credentials), or white-box (full architecture).
• Grey-box is the most common and the most cost-effective for application testing.
• White-box is appropriate where source-code-assisted secure code review is included.

2. Set business goals for the engagement

• State the driver: compliance (PCI DSS 11.4.3, ISO 27001 A.12.6.1, SOC 2 CC7.1), insurance renewal, FCA Operational Resilience evidence, M&A due diligence, or a specific threat-model concern.
• Define what a successful outcome looks like, passing audit, validated remediation, board-level assurance, or all three.
• Agree what the executive summary needs to communicate to non-technical stakeholders.

3. Stakeholder alignment before kick-off

• Nominate a single technical owner, usually a security engineer or platform lead, who can unblock testers within hours, not days.
• Brief application owners and DevOps that a test is happening, even if it is meant to be unannounced for SOC detection-validation purposes (in which case brief the SOC manager only).
• Inform third-party cloud providers (AWS, Azure, GCP) where penetration testing notification is still required by policy.
• Brief incident response so SOC alerts triggered by the testers are correctly attributed.

4. Technical access and test data

• Issue dedicated, named test accounts at each privilege tier (standard user, power user, admin), never share live user credentials.
• Provision VPN or jump-host access, with credentials tested end-to-end the day before the engagement starts.
• Allow-list the tester source IPs in any WAF, anti-DDoS, or rate-limiting layer that would otherwise mask real findings.
• Populate test data: realistic but synthetic records, sample transactions, sample files where uploads are in scope.
• Confirm test environments mirror production (same versions, configurations, integrations), testing a stale dev environment is a waste.

5. Legal, contractual, and rules of engagement

• Mutual NDA signed before scoping discussions, not after.
• Rules of engagement document signed by both sides covering: in-scope assets, prohibited techniques (DoS, social engineering, physical), data-handling, evidence retention.
• Written authorisation from the asset owner, required by the Computer Misuse Act 1990 in the UK.
• Notify your cyber-insurance provider; many policies require advance notice of penetration testing activity.
• Agree change-window timing if testing could affect production stability.

6. Communication during the test

• Agree a daily check-in slot (15 minutes is usually enough) for status, blockers, and critical-finding triage.
• Establish a secure channel for sharing findings live, a dedicated Slack/Teams channel, encrypted email, or a client portal.
• Define a pause-the-test trigger: what severity of finding warrants stopping work to remediate before proceeding?
• Agree out-of-hours contact details on both sides for production-impacting issues.

7. Reporting requirements

• Confirm the report format expected by your auditor (CREST, CHECK, PCI QSA, internal audit).
• Request findings mapped to control IDs (ISO 27001 Annex A, SOC 2 TSC, NIST CSF, PCI DSS requirement) for audit evidence.
• Ask for an executive summary written for the board and a technical appendix written for engineers.
• Confirm whether a letter of attestation is required for clients, regulators, or insurers.

8. Remediation and retest planning

• Assign an internal remediation owner before the test even starts, do not wait for the report.
• Reserve engineering capacity for the two weeks following report delivery.
• Confirm the retest window (typically 30 days post-engagement) and whether retests are included or charged separately.
• Decide how findings will be tracked: Jira ticket per finding is the standard.

Pre-engagement checklist (printable)

• ☐ Asset list signed off by every owner
• ☐ Out-of-scope items written down explicitly
• ☐ Business driver documented (compliance / insurance / threat-model)
• ☐ Single technical owner nominated and available
• ☐ Test accounts issued at every privilege tier
• ☐ VPN / jump-host access tested 24 hours before start
• ☐ WAF / rate-limit allow-list updated for tester IPs
• ☐ Cloud-provider notification submitted (where still required)
• ☐ Mutual NDA executed
• ☐ Rules of engagement signed
• ☐ Written authorisation from asset owner on file (Computer Misuse Act 1990)
• ☐ Cyber-insurance provider notified
• ☐ SOC briefed (or deliberately not, for detection-validation tests)
• ☐ Daily check-in slot booked
• ☐ Live-finding channel agreed
• ☐ Remediation owner assigned and capacity reserved
• ☐ Retest window confirmed in contract

Common preparation mistakes UK firms make

• Forgetting the WAF. A WAF in the way will mask SQL injection, XSS, and SSRF findings. Allow-list the tester IPs or run a parallel engagement with the WAF disabled.
• Stale test environments. Testing a six-month-old staging tier returns findings that have already been fixed in production, and misses new ones.
• One credential for all testers. Concurrent testers sharing one account cause lockouts, audit-log confusion, and missed authorisation findings.
• Late legal sign-off. Engagements regularly slip by a week because legal review of the rules-of-engagement document was not started in parallel with scoping.
• No remediation capacity. Findings sit untriaged for months. By the time the retest happens, the team has rebuilt the affected component and the findings no longer apply.

Ready to scope a CREST-accredited penetration test?

EJN Labs is an active CREST member firm. We run scoping calls in 30 minutes, issue fixed-price quotes within 24 hours, and include a free retest within 30 days as standard. Whether you need web application, API, external infrastructure, or cloud testing, we will help you arrive at the engagement fully prepared. Request a fixed quote.