Prepare Your Company for a Penetration Test

Organizations that prepare properly for a penetration test get significantly more value from the engagement — more findings uncovered, faster testing, fewer wasted days on access issues, and remediation guidance that maps directly to their actual infrastructure. Organizations that do not prepare create conditions where testers spend the first third of the engagement waiting for credentials, negotiating scope ambiguities, and navigating escalation paths that were never defined. That lost time comes directly out of the testing window.

Preparation is not bureaucratic overhead — it is what converts a penetration test from a compliance checkbox into a genuine security improvement. This guide walks through every step, in the right order.

Step 1: Define Scope and Objectives Before Contacting Your Provider

The most common preparation mistake is treating scope definition as something the provider will do for you during the kickoff call. By that point, you are already burning engagement hours. Scope definition is internal work that should be done before the scoping questionnaire arrives.

Answer these questions first:

What is being tested?

Specific web applications (list every URL and environment — production, staging, development)
API endpoints (public, partner, internal)
External network perimeter (list IP ranges and domains)
Internal network (specify network segments, VLAN ranges, domain infrastructure)
Cloud infrastructure (specify AWS accounts, Azure subscriptions, GCP projects)
Mobile applications (specify iOS and Android builds, and whether you can provide IPA/APK files)
Source code (if code-assisted testing is in scope)

What is the objective?

Compliance-driven (PCI DSS scope validation, SOC 2 evidence, ISO 27001 Annex A)
Pre-launch security validation
Post-incident assessment
Ongoing program (recurring assessment)

What is explicitly out of scope? Third-party systems you do not own, payment processors (Stripe, Adyen — these have their own compliance programs), shared infrastructure operated by hosting providers, and any system whose availability is business-critical and cannot tolerate any testing traffic, even controlled.

Having this documented before the kickoff call makes scoping a confirmation exercise rather than a discovery session. The checklist for choosing a pentest provider helps ensure the vendor you select has the platform and process to make use of the detailed scope you provide.

Step 2: Obtain Written Authorization — The Rules of Engagement

This is the non-negotiable legal foundation of any penetration test. Testing computer systems without explicit written authorization is a criminal offense under computer fraud laws in virtually every jurisdiction — regardless of whether you own the systems being tested or the tester is working on your behalf.

The Rules of Engagement (RoE) document should specify:

Authorized targets — exhaustive list of IP ranges, domains, and systems included in scope
Excluded targets — explicitly named systems that must not be touched
Authorized testing techniques — specify whether denial-of-service simulation, social engineering, physical access testing, or destructive testing are permitted
Testing window — permitted hours and days for active testing (some organizations restrict testing to off-hours to protect production availability)
Emergency contacts — technical and business contacts who can be reached immediately if an issue arises during testing
Data handling — how captured data (credentials, PII discovered during testing) will be stored, handled, and destroyed after the engagement
Authorization chain — signatures from the person who owns the systems and has authority to authorize testing (often the CISO or CTO, depending on governance structure)

If your systems run on cloud infrastructure, verify that your cloud provider's penetration testing policy permits the testing activities in scope. AWS requires notification for certain testing activities through their Vulnerability Research Program. Azure and GCP have their own policies (covered in detail in the cloud testing article in this series). Failure to comply with your cloud provider's policy can result in account suspension — independent of whether the testing itself is authorized by your organization.

A professional provider will send a rules of engagement template and a detailed scoping questionnaire covering the specific authorization requirements for AWS, Azure, GCP, and on-premises infrastructure — this should be part of the engagement setup process, not an afterthought.

Step 3: Notify the Right Stakeholders

Determine who needs to know the test is happening — and who should not know.

People who must be notified:

IT / infrastructure team leads — they need to know that anomalous traffic, failed login attempts, and unusual network activity during the testing window is expected and should not trigger incident response
Security operations / SOC — critical decision: do you notify your SOC? In a standard "gray box" pentest, yes — SOC notification prevents wasted incident response effort on expected test activity. In an engagement specifically designed to test detection capability, you may deliberately not notify the SOC (this becomes a partial red team element and requires explicit agreement)
Legal / compliance — depending on your industry and jurisdiction, legal needs to review the authorization paperwork
Executive sponsor — whoever owns the budget and will receive the final report should be informed before testing begins, not after

People who should not be notified (in detection-sensitive engagements): If one of the objectives is to evaluate whether your SOC detects and responds to suspicious activity, notifying them defeats the test. In that case, restrict knowledge to a "white cell" — typically the CISO and the executive sponsor — and coordinate with the provider on handling the scenario where the SOC begins a real incident response procedure during the test.

Step 4: Prepare the Testing Environment

Authentication credentials Provide the provider with test accounts at every privilege level that will be tested:

Unauthenticated (no credentials) for black-box web testing
Standard user account for authenticated web/API testing
Administrative account if admin functionality is in scope
Service account credentials if internal systems require them

Accounts should be dedicated test accounts, not shared with real users, and should be provisioned with realistic data if the application's behavior varies based on account state. Using a real production account for testing creates data integrity risks if the tester inadvertently modifies records during testing.

Data considerations If testing involves a database containing real personal data, discuss with legal whether testing should occur on a sanitized copy. PCI DSS Requirement 12.3.4 and GDPR both create obligations around how personal data is handled during security testing.

Monitoring and logging Ensure that logging is active on all in-scope systems during the testing window. Post-engagement, the tester's activity logs are valuable for validating findings, confirming test coverage, and correlating with your own security monitoring. If logging was not active, you cannot verify that the test covered what was agreed.

Step 5: Build an Asset Inventory

You cannot scope what you cannot enumerate. Before testing begins, produce a current inventory of:

All domains and subdomains associated with your organization (use a tool like subfinder, amass, or check your DNS provider's zone file)
All public IP addresses assigned to your organization
All cloud accounts and their associated services
All third-party services integrated with your application (and whether they are in scope)

NIST SP 800-115 (Technical Guide to Information Security Testing and Assessment) explicitly identifies asset inventory as a prerequisite for planning the technical testing effort. If you discover undocumented systems during the scoping process, that discovery itself is a security finding — shadow IT and unmanaged assets represent an uncontrolled attack surface.

Step 6: Designate a Technical Point of Contact

Every penetration test engagement needs a single technical point of contact (POC) on your side who is:

Available during testing hours to answer questions about system behavior and scope
Authorized to expand or restrict scope on short notice if the tester discovers adjacent systems
Able to provide additional credentials or access if a testing blocker arises
Empowered to make real-time decisions without requiring escalation

Without a dedicated POC, testers wait. Waiting on your engagement means findings that could have been surfaced in week one arrive in week three — or not at all.

Step 7: Define the Emergency Escalation Plan

What happens if the tester discovers a critical vulnerability — a working remote code execution, a database with plaintext credentials, an unauthenticated admin panel exposed to the internet — that needs immediate attention before the end of the engagement?

Define in advance:

Who is the emergency technical contact (with a mobile number, not just email)?
Who makes the decision to halt testing if a critical finding creates production risk?
What is the procedure if the tester accidentally causes a service disruption?

Critical vulnerabilities discovered during testing are not theoretical risk — they are live exposure that may already be known to threat actors. A good provider will surface critical findings on the same day they are discovered and flag them through an out-of-band communication channel, not batch them into the final report.

What NOT to Do

Do not start testing without authorization documentation signed. This is not a formality — it is legal protection for both your organization and the provider.

Do not give testers production database write access unless write operations are explicitly in scope and the implications for data integrity are understood and accepted.

Do not schedule testing during major release windows or business-critical periods — a pentest that triggers unexpected behavior during a product launch creates unnecessary business risk and creates pressure to restrict testing scope at exactly the wrong moment.

Do not treat the kickoff call as the scoping session — arrive with a completed draft scope, a named POC, and a signed or near-final authorization document. The kickoff call should be for questions and validation, not first-draft scoping.

Do not hide known vulnerabilities from the tester — some clients are reluctant to disclose known issues because they do not want them in the report. This is counterproductive: a good provider will find them anyway, and the remediation guidance from a tester who does not know the full context will be less precise than guidance from one who does.

What Happens When Preparation Is Skipped

The cost of poor preparation is not abstract. The following scenarios are representative of what actually happens in engagements that begin without adequate groundwork — each one is preventable with thirty minutes of preparation work per item.

Credentials not ready on day one. The tester arrives at the start of the testing window with no test accounts provisioned. The client's IT team needs to create the accounts, get them approved, and push them through the ticketing system. Half a day is lost before active testing begins. On a two-week, $15,000 engagement, half a day of testing time represents approximately $700 in wasted scope — paid for and not delivered.

Scope agreed verbally, not in writing. The tester exploits a production API that the engineering team believed was excluded from scope. The misunderstanding triggers an emergency call involving the CISO, the lead developer, and the provider's project manager. Three hours are consumed resolving the disagreement. The disputed API must be partially retested from scratch because the initial test run occurred under ambiguous authorization.

No staging environment available. Testing proceeds directly on production. A directory traversal proof-of-concept causes the web server process to throw an unhandled exception and generate an error response that triggers a PagerDuty alert. The on-call engineering team begins an incident response procedure before the security team can communicate that the activity was planned. Thirty minutes of incident response burn is attributed to the pentest.

No designated point of contact during testing. The tester discovers an unauthenticated endpoint returning serialized customer records — a finding that warrants immediate notification due to active data exposure risk. The finding is sent to a shared inbox. Six hours pass before anyone reads it. The exposure is live throughout that window.

Each of these outcomes is entirely preventable. None of them require significant time investment to prevent — they require only that the preparation steps in this guide are completed before the testing window opens, not during it.

Frequently Asked Questions

Should I notify my development team before a penetration test?

Yes, in almost every engagement. Your development and infrastructure teams need to know that anomalous traffic, failed authentication attempts, and unusual network patterns during the testing window are expected and authorized. Without that notification, a developer monitoring application error rates may trigger an internal escalation or manually intervene to block traffic, disrupting the test. The only exception is when one explicit objective of the engagement is to evaluate whether your team detects and responds to attack activity — in that case, notification is deliberately withheld from operational teams, and the scope of the non-notification should be agreed in writing in the rules of engagement.

What is a rules of engagement document and why does it matter?

A rules of engagement (RoE) document is the written authorization that defines the legal and operational boundaries of a penetration test. It specifies which systems may be tested, which are excluded, what testing techniques are authorized, the permitted testing schedule, emergency contact information, and who has authority to expand or halt the engagement. It is signed by the person in your organization who owns the systems and has authority to authorize testing — typically the CISO or CTO. Without a signed RoE, unauthorized computer access laws in most jurisdictions apply regardless of the parties' informal agreement. A RoE also protects both sides contractually: it defines what the provider is authorized to do and what your organization can expect. Professional providers send a RoE template as part of engagement kickoff — if a provider does not, request one before testing begins.

How do I set up test accounts without affecting production data?

Create dedicated test accounts that are not shared with real users and are clearly labeled (e.g., [email protected]) so they can be audited and deprovisioned after the engagement. Provision each account at the privilege level that needs to be tested: unauthenticated access, standard user, and administrative user if admin functionality is in scope. If the application's behavior differs based on account history or data state — for example, an account that has never placed an order versus one with transaction history — create accounts that reflect those states. Do not use a real production user's credentials under any circumstances: if the tester modifies a record or triggers an account lockout, the impact falls on a real person. After the engagement ends, disable and audit all test accounts before deprovisioning them.

How long before the test starts should I complete preparation?

Scope definition, asset inventory, and stakeholder notification should be complete at least one week before the testing window opens. Authorization documentation — the rules of engagement and any cloud provider notifications required — should be finalized and signed at least three to five business days before testing begins. Test accounts should be provisioned and verified at least 48 hours before the first day of testing so there is time to resolve provisioning issues without delaying the start. Scheduling a kickoff call with the provider two to three days before testing starts allows both sides to confirm that access, credentials, and scope documentation are in order before the clock starts.

What should I do if testing accidentally disrupts production?

Stop the specific activity that caused the disruption immediately and notify the provider's project lead through the out-of-band emergency contact defined in your rules of engagement — not through the primary communication channel, which may be delayed. Confirm whether the disruption is attributable to testing activity or coincidental. If testing is the cause, the provider should halt the relevant test cases pending your team's assessment of whether to continue, modify scope, or reschedule. Document the timeline of the event, the tester's activity at the time, and the system response. Review the rules of engagement to determine whether the test case that caused the disruption was within authorized scope — if it was not, this is a scoping failure that needs immediate resolution. Most professional providers carry professional liability coverage for testing incidents; confirm this before the engagement begins.

Preparation is the multiplier on testing quality. An hour spent on proper scope definition, authorization, and asset inventory before the engagement starts returns significantly more in finding quality and remediation precision than an hour of additional testing time. Understanding what a good penetration test report looks like before the engagement begins helps you hold the provider accountable to the right deliverable standards from day one.

Providers whose core business is offensive security testing are best positioned to run the kickoff process described above without treating it as an afterthought. WhiteJaguars is one such provider, according to the company's published service description.

How to Prepare Your Company for a Penetration Test