What to Expect From Your First Penetration Test

If you've never had a penetration test, the process can seem opaque. Here's a straightforward walkthrough of what happens before, during, and after—so you know what you're getting into.

Before Testing Begins

Scoping and Agreement

First, you'll define what's being tested. This typically includes:

• Target systems: IP ranges, domains, applications
• Test type: External, internal, web application, wireless
• Boundaries: What's off-limits (production databases, specific systems)
• Timeline: Start date, end date, testing hours

You'll sign paperwork including:

• Statement of Work (SOW): Scope, timeline, deliverables, price
• Authorization to Test: Legal document confirming you own or have authority over the systems being tested
• NDA: Protecting confidentiality of findings (some testers include this in their standard agreement)

This paperwork protects both parties. Never hire a tester who skips the authorization—and never test systems you don't have explicit permission to test.

Preparation on Your End

Before testing starts, you may need to:

• Whitelist the tester's IP addresses so they don't get blocked by your security tools (for some tests—others intentionally don't whitelist to test detection)
• Provide credentials if doing authenticated testing
• Notify your team so they don't panic when security alerts fire
• Identify an emergency contact who can be reached if something goes wrong
• Document any fragile systems that need special handling

For internal tests, you'll also coordinate network access—either VPN credentials or on-site arrangements.

During Testing

What the Tester Does

The tester follows a methodology—typically something like:

1. Reconnaissance: Gathering information about your systems and organization
2. Scanning: Identifying live hosts, open ports, running services
3. Vulnerability identification: Finding potential weaknesses
4. Exploitation: Attempting to exploit vulnerabilities to gain access
5. Post-exploitation: Seeing how far they can go once inside
6. Documentation: Recording everything for the report

This might take anywhere from a few days to several weeks, depending on scope.

What You'll Experience

You probably won't notice much. Professional testers work carefully to avoid disruption. Testing happens during agreed-upon hours, and testers avoid actions that could crash systems or corrupt data.

Your security tools should fire alerts. If they don't, that's a finding. You might see IDS/IPS alerts, failed login attempts in logs, unusual network traffic, and endpoint detection alerts.

Don't remediate during testing. If you see the tester's activity and start blocking them or patching vulnerabilities mid-test, you're undermining the assessment. Wait until testing is complete.

Communication varies. Some testers provide daily updates. Others only reach out if there's a critical finding or problem. Clarify expectations upfront.

If Something Goes Wrong

Rarely, testing can cause unintended issues—a service crash, unexpected behavior, or a triggered alert that causes business disruption.

Good testers: test carefully to minimize risk, have your emergency contact ready, stop immediately if something breaks, and document what happened.

Critical Findings Protocol

If the tester discovers something severe—like an easily exploitable vulnerability giving access to sensitive data, or evidence that you've already been compromised—they should notify you immediately, not wait for the final report.

Clarify this expectation upfront: "If you find something critical, call me right away."

After Testing

The Report

You'll receive a report that typically includes:

Executive Summary: High-level overview for non-technical stakeholders. Overall risk posture, key findings, and recommendations.

Methodology: How testing was conducted, tools used, and approach taken.

Findings: Each vulnerability documented with description, severity rating (Critical/High/Medium/Low/Informational), evidence or proof of concept, business impact, and remediation steps.

Positive findings: What you're doing well (good testers note this).

The Debrief Call

Most engagements include a call to walk through findings. This is your chance to ask questions about specific vulnerabilities, understand the attack paths, clarify remediation steps, and discuss prioritization.

Bring your technical team to this call. The report is useful, but the conversation often provides crucial context.

Remediation

Now the real work begins. You have a prioritized list of vulnerabilities—start fixing them.

Typical prioritization:

1. Critical: Fix immediately (this week)
2. High: Fix soon (this month)
3. Medium: Fix in normal maintenance cycles
4. Low/Informational: Address when convenient

Don't try to fix everything at once. Focus on critical and high findings first.

Retesting

After you've remediated findings, you may want a retest to verify the fixes worked. Some testers include one retest in the original engagement; others charge separately.

At minimum, retest critical and high findings. There's no point in a penetration test if you don't verify that remediation actually worked.

What to Do With the Report

Treat it as confidential. A penetration test report is essentially a roadmap for attacking your organization. Limit distribution to people who need it.

Don't just file it away. The report is useless if findings don't get fixed. Track remediation, assign owners, and follow through.

Use it for compliance. If you need evidence of security testing for auditors, insurers, or customers, the report (or a letter of attestation) serves that purpose.

Plan for next year. Penetration testing isn't one-and-done. Annual testing is standard; more frequent if you make significant changes.

Questions to Ask Your Tester

Before the engagement:

• What's included in the report?
• How will you handle critical findings?
• Is retesting included?
• Who should I contact if there's a problem during testing?

After receiving the report:

• Which findings pose the most immediate risk?
• Are any of these being actively exploited in the wild?
• What quick wins can we implement immediately?
• What would you prioritize if budget is limited?

---