A real penetration test does not start with hacking. The first hands-on-keyboard moment of a serious engagement is rarely a security tool — it is usually a Word document. Hours of authorization calls, a signed scope document, and a list of systems explicitly off-limits all have to land before any traffic touches the target network. The “hacking” most people picture — Nmap firing, Metasploit warming up, exploits running — sits four or five steps deep into a process that has already determined whether the engagement will be useful or wasted.
This piece walks through what those first steps actually look like, drawing on the Penetration Testing Execution Standard (PTES) and NIST SP 800-115 — the two methodology references most reputable engagements operate from — with MITRE ATT&CK reconnaissance (TA0043) as the technical mapping for the OSINT phase. The opening of a pentest matters more than the exploitation phase. It is where engagements are quietly decided to succeed or fail.
What Pentest Day One Actually Looks Like
The first phase in PTES is called Pre-engagement Interactions. NIST SP 800-115 calls the equivalent stage Planning. The terminology shifts by methodology, but the substance is identical: a multi-hour conversation between the testing team and the client, followed by a signed agreement that defines exactly what is permitted and what is not.
The work is unglamorous. A typical kickoff covers the engagement’s goals (compliance validation, real-world risk assessment, threat-led red-team simulation), the IP ranges and domains in scope, the systems explicitly excluded, the testing window, rules of engagement around social engineering and denial-of-service, the emergency stop-test signal, and escalation contacts for both sides. PTES dedicates a full documented section to the pre-engagement questionnaire used to drive this exact conversation, including time-estimation metrics and scope-creep prevention language.
What comes out of this phase — the statement of work (SOW) with rules of engagement attached — is the most important technical artifact of the engagement. It is the document that converts what would otherwise be illegal activity into authorized testing. Without a signed SOW, a pentester is committing federal computer crimes; with one, the same actions are billable. Most engagements measure this phase in days, not hours, because every clause matters.
What’s In a Real Statement of Work
A serious SOW reads less like a contract and more like an operations document. It enumerates assets, exclusions, hours, and the precise communication path for when something breaks — and something does break, on most engagements where active testing touches production systems.
The example below shows the structure of a typical excerpt. Real engagements add many more clauses (data handling, evidence retention, third-party notification requirements, coordination with the client’s blue team) but the skeleton is consistent across PTES, NIST SP 800-115, and OSSTMM-aligned engagements alike.
The stop-test signal deserves attention. PTES recommends a pre-agreed code phrase delivered through a known communication channel — not email, because email might not be checked in time. A competent engagement also defines who can issue the stop signal and how quickly the test team must acknowledge it; typical thresholds are five to fifteen minutes.
Why Most Pentests Fail at Scoping, Not Exploitation
Scope is where engagements quietly fail. NIST SP 800-115 emphasizes that scope definition based on risk, business criticality, and assessment objectives must happen before testing begins, but the phrasing hides how much room there is to get it wrong in either direction.
A scope that is too narrow produces a clean report on a small portion of the attack surface, leaving the systems an actual attacker would target untested. A scope that is too broad spreads a fixed budget thinly across low-value systems, leaving the crown jewels with eleven minutes of attention. Both failure modes result in next year’s breach happening in something the pentest didn’t seriously test — but the failure mode looks different in the post-incident review.
The fix is uncomfortable for clients: spend more time on the pre-engagement phase than feels reasonable. PTES’s pre-engagement section recommends scoping conversations with the security team, application owners, infrastructure leads, and at least one executive sponsor, because the answers about what matters most rarely agree across roles. A pentester who books one 30-minute call and asks for an IP list is not running a real engagement.
How Reconnaissance Actually Begins
Once the SOW is signed, the second phase begins. PTES calls it Intelligence Gathering. NIST SP 800-115 calls it Discovery. MITRE ATT&CK maps the same activity to Reconnaissance (TA0043) with seven major techniques: T1595 (Active Scanning), T1592 (Gather Victim Host Information), T1590 (Gather Victim Network Information), T1589 (Gather Victim Identity Information), T1593 (Search Open Websites/Domains), T1596 (Search Open Technical Databases), and T1598 (Phishing for Information).
The work splits cleanly into two modes. Passive reconnaissance queries third-party data sources only — certificate transparency logs, the Wayback Machine, GitHub, breach corpora — and never touches the target’s infrastructure. Active reconnaissance sends packets at the target: port scans, banner grabs, subdomain bruteforcing, DNS enumeration. The distinction is more than academic. Active recon may show in the target’s logs and trigger detection; passive recon almost never does. Most engagements spend days in passive mode before sending a single packet.
What passive recon turns up before exploitation is often the entire engagement. Cloud credentials committed to public GitHub repositories, environment files indexed by Google, production API tokens hardcoded into JavaScript bundles, dangling DNS records pointing at deprovisioned cloud accounts, internal documentation cached in archive.org — none of these require an exploit. They require curl, git grep, and time.
The OSINT Tools Pentesters Reach For First
The reconnaissance phase has a standard toolkit that has been stable for several years. New tools appear, but the foundational set hasn’t changed much, and a senior pentester usually reaches for the same five or six sources before anything else.
Two automation layers sit on top of this foundation. theHarvester aggregates email and subdomain data from search engines and public APIs. OWASP Amass does end-to-end attack-surface mapping across DNS records, certificate logs, ASN data, and scrape sources in a single pipeline. Maltego is the commercial heavyweight for relationship visualization across the same data, used heavily on engagements where the deliverable includes attack-graph artifacts. The framework alignment matters because clients increasingly expect findings mapped to ATT&CK technique IDs in the final report.
Threat Modeling: Where Time and Budget Get Allocated
PTES inserts an explicit Threat Modeling phase between intelligence gathering and vulnerability analysis, and this is where the data from OSINT converts into a prioritized attack plan. The phase usually doesn’t generate billable artifacts on its own, which is why junior testers skip it — but it determines how the next two weeks of testing get spent.
The exercise asks four questions in order. What did recon expose that has high business value (customer data, payment systems, admin panels)? What has high external exposure (internet-facing apps, exposed APIs, publicly indexed dev environments)? What looks low-maturity (legacy stacks, forgotten subdomains, unmonitored systems)? What’s a likely supply-chain or human entry point (third-party integrations, phishable accounts, helpdesk procedures)? The matrix that comes out drives every test that follows.
A pentester who skips this step ends up running tools instead of running a test. The difference matters: tool output without prioritization produces a 200-page report nobody reads, while a prioritized engagement produces a 12-page report with five findings the CISO can actually act on.
Where Engagements Quietly Go Wrong
The first phase is where most failures originate, not the exploitation phase. The recurring patterns:
Vague scope language. “The production environment” is not a scope. Real scope enumerates specific IPs, hostnames, application versions, and mobile-app build identifiers. Anything not named is out of scope by definition.
Missing data-handling clauses. What happens to PII or credentials the tester encounters in the wild? Most SOWs handle this poorly, leaving testers with sensitive data in their notes and no agreement on how to dispose of it. The client’s legal team usually flags this on review — late.
Active recon before authorization. A surprising number of testers run port scans during scoping calls, before the SOW is countersigned. This is not authorized; it is unauthorized scanning that happens to be done by someone who will eventually have authorization. Some companies have prosecuted for less.
No defined stop-test signal. When something breaks during active testing — and on engagements that touch production, something usually breaks — the lack of a pre-agreed code phrase, channel, and acknowledgment SLA turns a routine pause into an incident.
Treating OSINT as automated. Running OWASP Amass and submitting the output as “reconnaissance” misses the judgment work that justifies a senior tester’s day rate. The tools generate signal; a human decides what’s worth pursuing.
Frequently Asked Questions
How long does the pre-engagement phase usually take? Anywhere from a few days to several weeks, depending on engagement size, regulatory framework, and client procurement speed. PTES recommends not compressing this phase even when clients push for speed; rushed scoping is the leading cause of useless engagements.
Is OSINT against a target legal without a signed SOW? Generally yes for purely passive sources (public DNS, public GitHub, archived public pages), with significant gray areas around terms-of-service violations on platforms like LinkedIn. Active reconnaissance — even just port scans — is unauthorized access in many jurisdictions and should never happen pre-contract.
Do black-box engagements skip the scoping phase? No. Black-box refers to how much information the tester is given about the target, not whether scoping happens. The SOW exists either way. What changes is what’s listed inside it: in a black-box engagement, the client withholds internal architecture details that a white-box engagement would include.
Can a pentester find serious findings without ever exploiting anything? Routinely. Cloud credential leaks, exposed admin panels, dangling subdomains, and publicly indexed configuration files often constitute the most damaging findings on an engagement, and none requires an exploit.
Verdict: What “Starting” Really Means
The phases that come before exploitation make up the majority of the work on any serious engagement. PTES allocates two of its seven phases — pre-engagement and intelligence gathering — to what happens before any vulnerability analysis begins. NIST SP 800-115 echoes the same proportion in its Planning and Discovery phases. Practitioners who track time honestly often report 60% to 70% of engagement hours go to scoping, OSINT, and threat modeling combined.
The implication for clients is uncomfortable but specific. When evaluating pentest providers, ask about pre-engagement methodology, OSINT toolchain, and how findings get mapped to ATT&CK techniques — not which exploitation frameworks the team prefers. The exploit is the receipt. The pentest is everything that came before it.
