How a penetration test is run: the phases from kickoff to handover

Three phases that every penetration test follows

A penetration test has a beginning, a middle, and an end. Each stage produces something the next depends on. Planning produces an agreed scope and rules of engagement. Active testing produces findings. Reporting turns those findings into a document the client can act on.

NIST SP 800-115, the technical guide to information security testing, divides a test into planning, discovery, attack, and reporting. The commercial convention compresses discovery and attack into a single active-testing window, but the logic is the same: agree what will be tested before touching it, test it, then document what was found. A penetration test that skips any of these stages is incomplete.

The phases are not equal in calendar time. Active testing typically occupies the largest share of a scoped engagement, with planning and reporting splitting the rest. The ratio shifts with scope: a large internal infrastructure engagement needs more preparation; a small web application test needs more reporting.

Planning: scope, rules of engagement, and what to have ready

Active testing cannot begin until two documents are signed: a scope definition and an authorisation letter. The scope definition names every system in and out of bounds. The authorisation letter, signed by someone with authority over those systems, is what distinguishes a penetration test from an unauthorised intrusion attempt. Without it, the tester has no legal ground to stand on.

The kickoff call works through five items that cannot be left to email: the scope boundary confirmed in full, the rules of engagement (testing hours, rate limits, what counts as an emergency stop), test accounts covering each access tier, the name and phone number of the person reachable during testing, and the method for raising an urgent finding. How to scope a penetration test, and what to leave out covers the scope conversation in full. What to have ready before a penetration test starts covers the documentation side.

A kickoff call that takes longer than expected is usually a planning problem rather than a testing problem. Ambiguity about scope, missing test accounts, and an authorisation letter that names systems too broadly are the causes. Resolve them before the testing window opens.

Reconnaissance: mapping the attack surface before the first probe

Reconnaissance is the first active phase of a test. It divides into passive and active work. Passive reconnaissance gathers information without sending a packet to the target: certificate transparency logs, DNS records, public code repositories, job postings that name internal technology, and registration data. It is legal, invisible to the target, and often produces the most useful findings.

Active reconnaissance begins when the tester sends traffic to the target systems: port scans, service fingerprinting, directory enumeration, login-page discovery. The OWASP Web Security Testing Guide organises this phase into information-gathering tests, each with specific tools and expected outputs. A tester who skips reconnaissance and jumps directly to exploitation is working from an incomplete map.

Reconnaissance is not read-only from the client's perspective. If the scope includes social engineering or phishing simulation, reconnaissance also covers employee enumeration and email address harvesting. The rules of engagement should state explicitly whether this channel is in scope, because the boundary between passive reconnaissance and an unauthorised data-collection exercise is narrower than it appears.

Active testing: from the first probe to the confirmed finding

Active testing is the phase most people picture when they hear the word penetration test. The tester probes for weaknesses identified in reconnaissance, confirms each vulnerability with evidence, and attempts to chain them into a path toward the objective. NIST SP 800-115 describes this as the attack phase: attempting to gain access, escalate privilege, and move laterally within the defined boundary.

A finding is not confirmed until the tester can produce a reproducible case: a request, a response, and a description of what the response proves. A port that accepts a connection is not a finding; a service running an end-of-life version with a known exploit chain is. The MITRE ATT&CK framework maps the techniques a tester may use in this phase to adversary behaviour, which is useful when the report needs to map findings to detection logic.

Some tests include an objective beyond finding vulnerabilities: reaching an internal system from an external foothold, reading a named file, or accessing a production database. These objectives shape which paths the tester pursues. From public application to internal network: the external foothold chain walks one such chain in full. When the tester reaches the objective during the testing window, it is documented as a finding with the full path, not as a yes-or-no result.

The client's security team should be reachable during active testing. A tester who discovers a critical vulnerability mid-test may need to pause and report it immediately. Rate limits, alerting thresholds and production traffic can all be affected by an unmanaged test. The emergency stop procedure agreed at kickoff is for exactly this situation.

Reporting: from tester's notes to the delivered document

The report phase turns notes and screenshots into a document that two audiences can use: the security team, who needs reproducible steps and evidence; and the leadership team, who needs a risk summary and a remediation plan. What a penetration test report has to contain describes both sections in detail.

Each finding carries a severity rating, a description of the vulnerability, the steps to reproduce it, the evidence (request, response, screenshot), the business impact, and the remediation recommendation. Severity ratings use a standard scale, commonly CVSS, so findings can be prioritised against one another. A finding without evidence is not a finding: the tester's notes are not the deliverable.

The report is delivered as a draft first, with a window for the client to raise factual questions. A finding that names the wrong system, cites the wrong version, or reproduces incorrectly should be corrected before the final version is signed off. The final report is what the penetration testing engagement produces, and it may be presented to auditors, regulators, or procurement teams.

Retest and sign-off: verifying fixes and closing the engagement

A retest is a second round of testing scoped to the findings from the original. The tester repeats the exact test cases used to discover each vulnerability and records whether the fix is effective. A finding is closed when the tester cannot reproduce it. A finding is not closed when the original payload is blocked but an equivalent one succeeds: the fix has to address the class of vulnerability, not the specific instance in the report.

Not every finding reaches a retest. Critical and high severity findings should be fixed and verified before the engagement closes. Medium severity findings are usually bundled into a planned remediation sprint. Low severity findings and informational notes may be accepted as risk, documented and left open. How to compare penetration testing proposals describes how to ask a provider what their retest policy covers before you sign.

Sign-off is the client's confirmation that the engagement is complete and the findings are accepted. It does not mean every vulnerability is fixed; it means the deliverables are correct, the findings are understood, and the client holds a record of the test. That record is what a regulator or auditor will ask to see when they ask whether penetration testing has been conducted.

Penetration testing phases and UAE regulatory evidence

In a regulated environment, the evidence a regulator asks for goes beyond the report. It includes the scope document, the rules of engagement, the test accounts, and the retest record. The four UAE regulatory regimes that name security testing each have a view on what a complete engagement looks like.

CBUAE's cybersecurity regulation for financial institutions requires regular penetration testing and expects the results to be presented to governance functions. Banks and payment service providers operating in Dubai and Abu Dhabi are subject to this requirement. The planning phase documentation, specifically a signed scope and authorisation letter, is part of the evidence trail a CBUAE reviewer will ask to see.

DESC, the Dubai Electronic Security Centre, requires penetration testing for Dubai government entities and their technology suppliers. NESA's UAE Information Assurance Standard applies at the federal level and names penetration testing as a required control for critical information infrastructure. ADHICS, the Abu Dhabi Healthcare Information and Cyber Security standard, applies the same requirement to healthcare entities operating under the Abu Dhabi Department of Health.

A client in Dubai or Abu Dhabi presenting penetration test evidence to an auditor should be ready to show the full engagement record: scope document, rules of engagement, the final report with finding severity ratings, and the retest record. A report without a retest record is an incomplete engagement under most UAE regulatory frameworks, and an engagement without a signed authorisation letter may not be accepted as evidence at all.

Frequently asked questions