Penetration testing services: what you get
A penetration testing engagement is four things: a scope you agreed, a period of testing by a person, a report you can act on, and a retest that proves you did.
Penetration testing services are engagements where a qualified tester attempts to break into a system you own, under written authorization, and documents how they did it so you can close the route. The deliverable is not a list of vulnerabilities. It is a set of findings with proof, ranked by what an attacker could actually do with them in your environment, and a retest showing which ones are now closed. Anything that stops short of that is a different product wearing the same name.
The stages of a real engagement
Firms use different words for these, but any engagement worth buying has all five. If a proposal skips one, that is the question to ask before you sign.
| Stage | What happens | Typical duration |
|---|---|---|
| Scoping | Asset inventory, role definitions, exclusions, and the day count that follows from them | One to two weeks before testing |
| Rules of engagement | Written authorization, testing windows, escalation contacts, prohibited techniques | Signed before any traffic is sent |
| Testing | Reconnaissance, mapping, manual testing against the methodology, exploitation and proof | Three days to four weeks |
| Reporting and readout | Written findings with reproduction steps, plus a live walkthrough with the engineers | Three to ten business days after testing |
| Retest | Re-verification of the findings you fixed, with an updated report or letter | Within thirty to ninety days |
Scoping is where the engagement is won or lost
Bad scoping produces a report about the wrong thing, and you do not find out until the readout. The scoping conversation should be uncomfortable and specific. A good tester will push back on your description of the system, because the description you give is the architecture you believe you have.
The questions that matter: what are the distinct user roles and can any of them see another customer's data. Where is the authorization decision made, in the front end or in the service. What is the tenant boundary. Which endpoints are undocumented. What did you build yourselves rather than buying. What are you most afraid of, and what would end the company.
That last question is worth answering honestly. Scope written to satisfy an auditor and scope written to find the thing that would hurt you are usually different, and if you only have budget for one, you should know which one you are buying.
Exclusions belong in writing
Denial of service, testing against third-party SaaS you do not own, and physical access are commonly excluded, and cloud providers have their own rules about what testing they permit against their infrastructure. Write exclusions into the scope with a reason attached. An auditor reading the report later will accept a documented exclusion. What they will not accept is discovering the exclusion by noticing that a system in scope was never mentioned.
Methodology, named rather than described
Ask which published methodology the firm follows and expect a name. The common ones are the OWASP Web Security Testing Guide for applications, the Penetration Testing Execution Standard for the overall engagement structure, and NIST SP 800-115 as the framing auditors recognize most readily. For internal network work, mapping findings to MITRE ATT&CK techniques makes the report far more useful to whoever runs your detection.
The reason to insist on this is coverage. A methodology forces the tester to walk categories they would otherwise skip when a system is stubborn, and it gives you a defensible answer when someone asks what was tested and what was not. Freestyle testing by a strong tester can produce better findings. It cannot produce coverage evidence.
What a good report looks like
The report is the product. Judge a firm on a redacted sample before you judge it on price, and ask for one from an engagement resembling yours rather than whatever is polished for sales.
A good finding contains: a plain description of the flaw, the exact request or steps to reproduce it, evidence that it worked, an impact statement written in terms of your business rather than a generic severity label, and a fix that names the component to change. If a finding says "implement input validation" and nothing more, the tester has handed the hard part back to you.
A good report also contains the things that are absent: an explicit list of what was tested and found sound. That section is what makes the report useful to an auditor, and it is the first thing cut when the engagement was too short.
Severity should be adjusted for your environment. A critical CVE on a service reachable only from inside a VPN is not a critical for you, and a medium-severity authorization flaw that exposes every customer's records is not a medium. Firms that publish raw CVSS scores without contextualizing them are transferring the analysis to you.
Deliverables to ask for by name
- The full technical report, with reproduction steps for every finding.
- An executive summary that a board or a customer can read without translation.
- An attestation or summary letter you can share externally, confirming that a test occurred, its scope and its dates, without listing your open vulnerabilities.
- Findings in a machine-readable form, so they can be loaded into your issue tracker rather than retyped.
- A retest report or an updated letter once fixes are verified.
The attestation letter deserves attention because of how it gets used. When a prospect's procurement team asks for your penetration test results, sending the full report hands a list of your unfixed weaknesses to a company that has not signed anything meaningful about protecting it. The letter exists to answer that request safely, and firms that do not produce one are leaving you to choose between oversharing and stalling the deal.
Retest is the part auditors care about
Finding a vulnerability proves very little on its own. What a SOC 2 auditor is looking for is that you identified issues, triaged them, fixed the serious ones, and can show that the fix worked. That last step is the retest, and it is the reason a report with no retest often fails to do the compliance job it was bought for.
Confirm the retest window in writing. Thirty days is common and it is short: if the report lands in December, your engineers are unlikely to have closed a high finding before the window shuts. Ninety days is more realistic for a company without a dedicated security engineer.
Choosing between firms
Ask who is doing the work, not who is selling it. In smaller Canadian firms the person on the sales call is frequently the tester, which is a good sign. In larger ones, ask for the named lead tester and their background, because the quality range within a single firm is wider than the range between firms.
Ask what percentage of the engagement is manual. Ask what the last interesting finding they reported was, in general terms. Ask how they handle a finding you dispute. And ask for the redacted sample report. A firm that treats these as reasonable questions is a firm that has good answers.
Independence matters if the test supports an audit. The organization that built or currently manages the system should not be the one attesting to its security. If your managed service provider offers to test the environment they run, that is a useful internal exercise and it is not independent evidence.
Get scoped before you get quoted
Describe your systems and the requirement driving the test, and we will put a consistent scope in front of Canadian firms.
Get matchedCommon questions
How long does a penetration test take end to end?
Plan on four to eight weeks from first conversation to final report. Testing itself is usually one to two weeks, but scoping takes a week or two, good firms are booked several weeks out, and reporting adds another week. If an audit date is driving the schedule, start the conversation two months before you need the report in hand.
What do we need to have ready before testing starts?
Working test accounts for every role in scope, a stable environment, API documentation if you have it, an architecture diagram, and a named contact who can answer questions the same day. Also a decision about who gets alerted if a monitoring system fires during testing, since an unannounced test that triggers a real incident response wastes a night of everyone's time.
Should we tell our own team the test is happening?
For a penetration test, yes. The goal is finding vulnerabilities, and hiding the test from your engineers adds noise without adding information. Keeping the exercise secret is a red team characteristic, where the point is testing whether detection and response work. Those are different products with different budgets.
Who owns the report?
Check the contract, because it varies. You should own the report and have an unrestricted right to share it with customers, auditors and insurers. Some firms restrict redistribution or require notification before you share, which becomes a problem the first time a prospect asks for it under a deadline.
Can one test cover SOC 2 and ISO 27001 at once?
Yes, and it usually should. Both are satisfied by independent technical testing of the systems in scope, with evidence of remediation afterward. The requirement is that the tested scope matches the audited scope, so write the scope statement with both in mind. Details are on SOC 2 penetration testing and in the ISO 27001 Annex A controls.