Before the Test Starts
The pentest does not begin with someone attacking your network. It begins with a phone call. The scoping call is where you and the testing firm agree on what gets tested, how it gets tested and when.
This call typically runs 30 to 60 minutes. The tester will ask about your environment: how many external IPs, how many web applications, do you have an internal network in scope, are there cloud assets. Your answers determine the level of effort and the price. Be specific. Vague scope leads to vague results.
The NDA
Before any technical details change hands you will sign a mutual non-disclosure agreement. This protects both sides. You are about to share network diagrams and IP ranges. The tester is about to document every weakness they find. Neither party wants that information leaking.
Rules of Engagement
The rules of engagement document is the contract between your team and the testers. It defines:
- Target list
- Every IP address, domain, application and network segment that is in scope. Anything not on this list does not get touched.
- Testing window
- The specific dates and hours when testing is authorized. Most firms test during business hours unless you request after-hours work.
- Testing boundaries
- What is explicitly off-limits. Production databases with live customer data, specific legacy systems that cannot handle scanning, third-party hosted services you do not own.
- Emergency contacts
- Direct phone numbers for your IT team and the lead tester. If something unexpected happens at 2 AM, both sides know exactly who to call.
- Communication protocol
- How the tester reports critical findings during the engagement. A good firm will not wait until the final report to tell you about a critical vulnerability. You will hear about it the same day.
Get this document right. Read every line. If your legal team needs to review it, give them time. Rushing the rules of engagement is how misunderstandings happen.
What You Need to Provide
Depending on the test type, the firm may ask for credentials (for authenticated testing), VPN access (for internal testing) or a list of user roles to test against. For a black-box external test, you may provide nothing beyond the target list. For a grey-box web application test, you will typically hand over two or three user accounts with different privilege levels.
During the Test
Once the testing window opens, the testers go to work. Here is what actually happens day by day on a typical two-week external and web application engagement.
Days 1 through 3: Reconnaissance and Scanning
The testers map your external attack surface. They run port scans, identify services, fingerprint software versions and look for known vulnerabilities. This phase is mostly automated tooling guided by experienced hands. Your IDS or SIEM will likely fire alerts. That is normal. Some clients inform their SOC team in advance so they do not waste time investigating the authorized testing activity.
Days 4 through 8: Manual Testing and Exploitation
This is where the real work happens. Automated scanners find the obvious stuff. Manual testing finds the business logic flaws, the chained vulnerabilities and the misconfigurations that scanners miss entirely. The tester is attempting to gain unauthorized access, escalate privileges and move laterally through your environment.
They will not break production. Professional testers know the difference between proving a vulnerability exists and causing damage. They use the minimum level of exploitation needed to demonstrate risk. If a SQL injection vulnerability exists, they prove it returns data. They do not dump your entire database.
Days 9 and 10: Cleanup and Verification
The testers remove any accounts they created, reverse any configuration changes and verify they have left your environment exactly as they found it. They also re-verify their findings to eliminate false positives before writing the report.
Communication During Testing
Expect a brief daily or every-other-day status update via email. If the tester finds a critical vulnerability (something actively exploitable that poses immediate risk) they will call your emergency contact directly. This is standard practice. You should never be surprised by a critical finding in the final report because you should have already heard about it during the test.
The Report
The report is what you are actually paying for. The testing is just the means to produce it. A good pentest report serves two audiences with very different needs.
Executive Summary
This section is written for your CISO, your board and anyone who needs to understand risk without reading packet captures. It covers the overall security posture, the highest-risk findings summarized in plain language and a risk rating. Typically one to three pages. If your executive summary is longer than that, your tester is padding.
Technical Findings
Each finding includes:
| Component | Purpose |
|---|---|
| Severity rating | Critical, High, Medium, Low or Informational. Based on CVSS or a similar framework. |
| Description | What the vulnerability is and why it matters. |
| Evidence | Screenshots, HTTP requests/responses and tool output proving the vulnerability exists. |
| Impact | What an attacker could do with this vulnerability in the real world. |
| Remediation | Specific steps your IT team needs to take to fix it. Not vague advice. Actual configuration changes, patches or code fixes. |
| References | Links to CVEs, OWASP entries or vendor advisories for further reading. |
Every finding should have evidence. If a finding has no screenshot and no proof, push back. Unsubstantiated findings are useless for remediation because your IT team cannot fix what they cannot reproduce.
Report Red Flags
Watch out for reports that are mostly scanner output pasted into a template. A twenty-page report with fifteen pages of Nessus output and five pages of boilerplate is not a pentest report. It is a vulnerability scan someone charged pentest prices for. The manual findings, the business logic flaws, the chained attack paths: that is what separates a real pentest from a checkbox exercise.
After the Report
Getting the report is not the finish line. It is the halfway point.
The Remediation Period
Most engagements include a remediation window, typically 30 to 90 days. During this period your IT team works through the findings from highest severity to lowest. Start with the criticals and highs. Mediums can wait. Lows and informationals go on the backlog.
A good testing firm will make themselves available for questions during remediation. If your team is unsure how to fix a finding, they should be able to pick up the phone and ask the tester who found it. If your vendor disappears after delivering the report, that is a problem.
The Retest
After remediation, the tester comes back to verify the fixes. This is usually a shorter engagement (one to three days) focused specifically on re-testing the findings from the original report. Did the critical SQL injection get patched? Is the exposed admin panel now behind authentication? The retest confirms your team actually fixed the issues rather than just closing tickets.
What "Passing" Means
There is no pass or fail in penetration testing. Every organization has findings. The question is whether the remaining findings represent acceptable risk. If you remediated all criticals and highs and the remaining items are mediums and lows with compensating controls in place, that is a strong result. If your compliance framework requires a clean retest (PCI DSS for example) then your QSA will define what "passing" looks like.
For organizations that need this for cyber insurance or SOC 2, the retest report showing remediation of critical and high findings is typically what the auditor or underwriter wants to see.
Common Fears Debunked
"Will it break our systems?"
No. The rules of engagement exist specifically to prevent this. Denial-of-service testing is almost always excluded unless you explicitly request it. Testers avoid destructive actions. In twenty years of conducting penetration tests, the number of times a properly scoped engagement caused a production outage is near zero. The scoping call and rules of engagement exist to keep it that way.
"Will you see our data?"
Minimal exposure. Testers may see data incidentally when proving a vulnerability exists. For example, demonstrating a SQL injection may return a few rows from a database table. Professional testers do not exfiltrate bulk data. The NDA covers any data they do encounter. After the engagement, they securely delete all testing artifacts.
"What if you find something terrible?"
That is the point. Finding critical vulnerabilities is not a failure of the pentest. It is the pentest doing exactly what it is supposed to do. Better to find it in a controlled test than discover it during an incident response at 3 AM. The worst pentest result is not a report full of criticals. The worst result is a clean report from a tester who did not try hard enough.
"Do we need to tell our staff?"
That depends on the test type. For a standard network and application pentest, you typically inform IT leadership and the SOC. For a social engineering engagement that includes phishing, you may choose to keep it quiet so the results reflect real employee behavior. Discuss this during the scoping call.
FAQ
Will a pentest break our systems?
No. Professional penetration testers follow strict rules of engagement that define exactly what is tested and how. Denial-of-service testing is excluded by default. Testers use non-destructive techniques to prove vulnerabilities exist without causing damage. The scoping process and emergency contact protocols ensure any unexpected behavior is caught and addressed immediately.
How long does a pentest take?
Active testing typically runs one to two weeks for an external network and web application engagement. Internal network tests run three to five days. The full timeline from initial scoping call to final report delivery is usually three to six weeks. Add another one to three days for the retest after your team completes remediation.
What does a pentest report look like?
A quality report has two sections. The executive summary gives leadership a plain-language overview of risk in one to three pages. The technical findings section documents each vulnerability with a severity rating, description, evidence screenshots, real-world impact assessment and specific remediation steps. Every finding should include proof. If there is no evidence, it is not a finding.