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 findings with proof, ranked by what an attacker could do with them in your environment, and a retest showing which ones are now closed. Anything short of that is a different product wearing the same name.
The stages of a real engagement
Firms use different words for these. Any engagement worth buying has all five, and a proposal that skips one 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 find out at the readout. The scoping conversation should be uncomfortable and specific. A good tester pushes back on your description of the system. What you describe 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.
Answer that last one honestly. Scope written to satisfy an auditor and scope written to find the thing that would hurt you are different. If you have budget for one, 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 will accept a documented exclusion. They will not accept finding it by noticing that a system in scope was never mentioned.
What to have ready before the window opens
Testers lose real days to accounts that do not work and documentation that never arrives, and you pay day rate for them either way. Work through this before the kickoff call, not during it. The list is kept in your own browser, so you can come back to it.
0 of 0 done ยท
The last two get left until afterwards, and both are harder to settle then. Handling of personal information stays your accountability under PIPEDA even when someone else does the work, and the retest window is where the closure evidence either happens for free or does not.
Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.
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.
Insist on it for the coverage. A methodology forces the tester through categories they would skip when a system is stubborn, and it gives you an 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 each named standard actually covers, and the phases an engagement runs through, are set out on penetration testing methodology.
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 like 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 lists 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. A firm that publishes raw CVSS scores without contextualizing them has handed the analysis back 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.
Watch the attestation letter, 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 signed nothing meaningful about protecting it. The letter answers that request safely. A firm that does not produce one leaves you choosing between oversharing and stalling the deal. Which of the four documents to send, and to whom, is on report versus attestation letter.
Retest is the part auditors care about
Finding a vulnerability proves little on its own. A SOC 2 auditor wants to see that you identified issues, triaged them, fixed the serious ones and can show the fix worked. That last step is the retest, which is why a report without one often fails 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 will not close a high finding before the window shuts. Ninety days is more realistic for a company without a dedicated security engineer. What the retest costs when it is not included, and what auditors accept as closure evidence, is on retest and remediation verification. The retest planner turns your report date and window into the day the fixes have to ship.
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 often the tester, which is a good sign. In larger ones, ask for the named lead tester and their background. 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. Ask for the redacted sample report. A firm that treats these as reasonable questions has good answers.
Before any of that, write the scope down. The scoping questionnaire produces a document you can send to several firms unchanged, which is the only way their quotes describe the same engagement. If you want continuous coverage rather than one annual window, pentest as a service is the model to price against this one.
Independence matters if the test supports an audit. Whoever built or manages the system should not be the one attesting to its security. A managed service provider testing the environment they run is a useful internal exercise. It is not independent evidence.
If your industry sets the requirement
What triggers the purchase, and so what the engagement has to contain, differs by sector. Canadian fintech can have several regulators reaching it at once, on fintech penetration testing in Canada. Health tech is governed provincially rather than federally, on health tech penetration testing in Canada. A Canadian SaaS company selling into the United States is answering a customer contract rather than a statute, which is on SaaS penetration testing in Canada.
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.