The owner of a trucking company in Mississauga receives a 64-page PDF. Two critical vulnerabilities, five high, fourteen medium, about twenty low, and appendices full of black-and-white terminal screenshots. The IT provider replies: "We'll take a look." Three months later, nothing has changed.
This happens more often than you'd think. The penetration test cost several thousand dollars, yet the report sits in an inbox because nobody knows where to start.
A penetration test report isn't reserved for technicians. With a few reference points, a small-business owner can read one in an hour, ask the right questions and drive the fixes. Here's how.
TL;DR
- Read the executive summary and the scope first: they tell you what was tested, and above all what wasn't.
- CVSS severity is a starting point, not gospel; your business context matters.
- Attack chains are the most important part: breaking a single link can defeat the whole scenario.
- A report only pays off once it becomes an action plan with an owner and a deadline for every finding.
The sections of a good report
Most reports follow a similar structure, reflecting the reporting phase of recognized methodologies such as NIST SP 800-115. Here's what each part tells you.
| Section | What it's for | What to look for |
|---|---|---|
| Executive summary | Sum up the risk in business language | One clear sentence on what an attacker could do |
| Scope and methodology | Define what was tested, when and how | Exclusions and limitations |
| Attack chains | Tell the story of the tester's path | The entry point and the goal reached |
| Detailed findings | Describe each vulnerability | Severity, affected systems, evidence, fix |
| Recommendations | Prioritize remediation | Specific actions, not generic advice |
| Appendices | Provide technical detail | Mostly useful to your IT team |
The scope section deserves special attention. If the internal test excluded the payroll server, or the web app was tested without a logged-in account, the report says nothing about those risks. A "clean report" on a narrow scope is not a guarantee.
You don't need to read every page yourself. Split the work instead. As the owner or general manager, read the executive summary, the scope, the attack chains and the recommendations: that is where the business decisions are. Your IT lead or managed service provider takes the detailed findings and appendices, and comes back with an estimate of effort for each fix. Then sit down together for the prioritization, so nobody quietly decides on their own that a critical finding can wait until next quarter.
Understanding severity: CVSS, but with context
Most providers rate each vulnerability using CVSS (Common Vulnerability Scoring System), a standard maintained by the organization FIRST. Version 4.0 was published in November 2023. Its qualitative scale is:
- None: 0.0
- Low: 0.1 to 3.9
- Medium: 4.0 to 6.9
- High: 7.0 to 8.9
- Critical: 9.0 to 10.0
The base score measures a vulnerability's technical severity without knowing anything about your business. Version 4.0 makes this visible in the score's label: "CVSS-B" means base metrics only, while "CVSS-BT," "CVSS-BE" or "CVSS-BTE" indicate that real-world threat (T), your environment (E), or both were factored in. If your report shows only base scores, ask why.
A good tester adjusts or comments on severity based on your reality. A "critical" flaw on an isolated test server with no real data can wait. Conversely, a "medium" flaw on the portal every customer uses to log in may deserve an immediate fix.
Another useful signal: is the vulnerability listed in the Known Exploited Vulnerabilities (KEV) catalog maintained by the U.S. agency CISA? If so, attackers are already using it elsewhere. It goes to the top of the pile.
Attack chains: the most important page
Individual findings give you a list. An attack chain tells a story. For example:
- The tester captures a credential on the network through a poorly configured legacy protocol.
- That account has a weak password, cracked in minutes.
- The account can read a file share containing a password spreadsheet.
- One of those passwords belongs to a domain administrator.
Each step on its own might be rated "medium." Together, they lead to full control of the network in an afternoon. The good news: breaking just one link is often enough to defeat the whole scenario. Ask the tester which link is quickest and easiest to fix.
If your test covered an application, the chains look more like those described in our article on web application penetration testing and the OWASP Top 10.
From report to action plan
The report tells you what to fix. You decide who, when and how. Turn every finding into a row in a tracking sheet with an owner, a deadline and a status.
Here's an example internal policy, to adapt to your situation:
| Adjusted severity | Target timeframe (example) | Who decides |
|---|---|---|
| Critical | A few days | Leadership and IT, urgently |
| High | A few weeks | IT lead |
| Medium | Next maintenance cycle | IT lead |
| Low | Scheduled or accepted | IT lead, in writing |
These timeframes should line up with your patch management policy, if you have one. If you decide not to fix a finding (too costly, system being replaced in six months), document it as a risk acceptance signed by leadership. That's a legitimate business decision, as long as it's a conscious one.
Also separate quick wins from projects. Disabling a legacy protocol takes an evening; segmenting a plant network takes months. Both belong in the plan, just not on the same timeline.
Signs of a quality report
Not all reports are equal. A good one ticks these boxes:
- An executive summary you can understand without technical knowledge.
- A clear scope with dates, targets and exclusions.
- Manually validated findings, not a copy-paste from a scanning tool.
- Evidence for every significant finding (screenshot, request, excerpt).
- Reproduction steps so your IT team can verify the fix.
- Specific recommendations tailored to your systems.
- At least one end-to-end attack chain, when the test uncovered one.
- What worked well: an attempt blocked by your endpoint protection, an alert your MSP picked up. Those positives tell you which investments to protect.
If your report looks mostly like a list exported from a scanner, you may have paid for a vulnerability scan rather than a true penetration test.
The retest: closing the loop
Once fixes are in, ask for a retest. The tester checks that each finding is genuinely resolved and updates its status: fixed, partially fixed or still present. Without this step, you don't know whether the fix worked.
Retesting is often billed separately, so check when you compare quotes. To understand what drives the price, see our article on penetration testing cost in Québec. And if you're already planning the next test, our comparison of external vs internal penetration tests will help you choose the right scope.
Need help getting from report to fixes? Our team can take on the remediation and hardening of your systems.
Frequently asked questions
Can we share our penetration test report with a client or insurer?+
Avoid sending the full report: it describes exactly how to break in. Ask your provider for an attestation letter or a third-party summary that states the scope, dates, methodology and remediation status without exploitable details. If a client insists on more, put a non-disclosure agreement in place first.
How should we protect the penetration test report itself?+
Treat it as a confidential document: encrypted storage, access limited to the people who need to act, and no attachments sent to long distribution lists. Keep previous reports just as securely, since they let you measure progress from one year to the next.
Should we ask for a debrief meeting on top of the written report?+
Yes, and ask for it when you request the quote. An hour or two with leadership and IT lets you ask questions, confirm priorities and clear up ambiguous recommendations. That conversation is often where you truly understand what the tester was able to do.