How Much Does a Penetration Test Cost in 2026?

Direct answer: in Canada, a focused penetration test of a single web application typically starts around $1,000 to $3,000 CAD for a narrow, well-defined scope, and a broader engagement covering web applications, internal and external networks, APIs, and cloud environments can run well into five figures. The number is not arbitrary. It is driven by scope, depth, test type, and how much access the testers are given up front. At traztech, penetration testing starts from $1,000 CAD, scoped to your actual risk rather than a generic package, and priced against the plans on our pricing page.

That range is wide on purpose, because a pen test is not a single product. It is skilled human time spent trying to break into a specific set of systems, and the price should move with the size and sensitivity of that target, not with a vendor's rate card. Once you understand the handful of things that actually move the number, you can scope a test that fits your budget without over-buying a report you do not need or under-buying protection you do.

What actually drives the cost

Scope. This is the single biggest lever. Testing one web application with a handful of user roles is a small, contained job. Testing a web app plus its APIs, an internal and external network, and a multi-cloud environment across AWS and GCP is several jobs stitched together. The more systems, subdomains, and entry points in scope, the more tester hours it takes, and hours are what you are actually paying for.

Depth. A light test looks for common, known issues using established methodology and calls it done when it has covered the OWASP-style checklist. A deep test goes further: it chains smaller findings into a real attack path, probes business logic that no scanner understands, and behaves like an attacker who is genuinely trying to get all the way in and pivot from there. Depth costs more because it cannot be automated away. It is judgment, not a tool run.

Test type changes the price too

Web application, network, cloud configuration, and social engineering (phishing simulations, for example) are different disciplines that draw on different skill sets and tooling. A test that spans several of them costs more than a single-discipline engagement, but it also gives you a far more complete picture of where you are exposed. If you are choosing where to start, most Canadian SaaS companies get the most value from a web application test first, since that is usually the customer-facing surface an enterprise buyer or auditor will ask about.

Black box versus white box (and why white box is often better value)

If testers start with zero knowledge of your system and have to discover architecture, endpoints, and roles from scratch, that reconnaissance eats a large share of the engagement. A white box test, where you hand over architecture diagrams, API documentation, and test credentials up front, lets testers skip the mapping phase and spend nearly all of their time actually finding and exploiting weaknesses. For most companies on a budget, white box testing produces a more useful report per dollar spent, because less of the clock goes to discovery and more goes to depth.

What you should actually get for the money

A real penetration test is a human-led attack against your systems, not an automated vulnerability scan with a cover page and a logo. When the engagement wraps up, the deliverable should include findings ranked by severity and by what an attacker could realistically do with them, clear and specific remediation steps for each finding (not generic advice copied from a template), and a retest once fixes are in place to confirm the holes are actually closed. If what lands in your inbox is a 200-page raw export from a scanning tool, you paid for the wrong thing, no matter what it was called on the invoice.

Why cheap tests often cost more later

The lowest quotes in the market are almost always automated vulnerability scans relabelled as penetration tests. Scans have a real place in a security program, particularly for continuous monitoring between full tests, but they do not find business logic flaws, they do not chain issues together the way an attacker would, and they will not satisfy a serious enterprise security review or an auditor asking how the test was actually performed. Paying a little for a scan and believing you have had a proper penetration test is usually the most expensive mistake a growing company makes, because it fails exactly at the moment you need it to hold up, whether that is a customer's vendor security questionnaire or the aftermath of an actual incident.

The Canadian angle: compliance and privacy law context

For companies based in Toronto, Waterloo, Ottawa, Vancouver, Calgary, or Montreal selling into the US or scaling nationally, a penetration test is rarely just a technical exercise. It usually needs to feed into a broader compliance story. If you are pursuing SOC 2 to unblock a US enterprise deal, your test evidence and remediation timeline become part of the audit record, so the report needs to be defensible, not just technically accurate. If you handle personal information and operate in Quebec, Law 25 imposes its own security safeguard obligations on top of PIPEDA, and a documented, human-led penetration test is one of the clearer ways to demonstrate you took reasonable steps to protect that data. None of this changes the mechanics of scoping, but it does change what "good enough" looks like, since a report that would pass a casual internal review will not necessarily satisfy an auditor or a Quebec regulator asking pointed questions after an incident.

How to scope a test without overpaying or underbuying

Start by naming the actual trigger: is this for an enterprise security review, a SOC 2 or PCI requirement, a Law 25 or PIPEDA safeguard obligation, or simply wanting to know where you stand before something goes wrong? That trigger determines how much depth and coverage you need. From there, list every system that touches customer data or sits on the internet, decide whether black box or white box makes more sense for your timeline and budget, and get quotes against that specific scope rather than a generic "pen test" line item. Anyone willing to give you a firm number before understanding your scope is either guessing or quietly selling you a scan.

How we scope it at traztech

We scope every test to your actual risk and what you need it for, whether that is closing an enterprise deal, satisfying SOC 2 or PCI, meeting a Law 25 or PIPEDA obligation, or simply finding out where you are exposed before a customer or a regulator does. Testing is delivered in partnership with Lorikeet Security and led by Jacob Masse, a published security researcher with five CVEs to his name, including CVE-2024-45163, a CVSS 9.1 kill-switch vulnerability in Mirai-derived botnet malware, so you get genuine offensive depth rather than a rebadged scan. If you are also weighing what SOC 2 will take beyond the pen test itself, our overview of security and penetration testing services lays out how the pieces fit together.

If you want to talk through your scope and get a real number instead of a guess, tell us what you are running and we will size the engagement to your actual risk.

How quotes are actually built, line by line

Every credible quote you receive is a day-rate multiplied by an estimate of tester days, with a few fixed items added on top. Once you know that, you can read a proposal properly instead of comparing bottom-line numbers that were assembled on different assumptions. Ask any firm to break the number into testing days, reporting days, retest days, and project management. If they cannot or will not split it, the number is a guess.

Testing days are the hours a human spends against your systems. For a single web application with three or four user roles, a straightforward authentication model, and no unusual technology, that is commonly four to seven days. Add a mobile client and you are adding two to three days because the tester has to handle certificate pinning, local storage, and the API surface the app exposes. Add an internal network segment and you are adding time for host discovery, credential attacks, and lateral movement attempts, which are slower than web testing because much of it involves waiting on scans that only a person can interpret.

Reporting days are usually one to two, and firms that quote suspiciously low are often the ones squeezing this. A finding written in twenty minutes reads like a scanner entry. A finding written properly includes the request that triggered it, the response that proves it, the account context, the business consequence, and a remediation instruction specific to your framework rather than a link to an OWASP page. That takes real time and it is the part of the deliverable your auditor and your buyer will actually read.

Retest days are typically half a day to two days depending on how many findings you fixed. Some firms include one retest within a fixed window, commonly thirty to ninety days after the report. Others charge for it separately, and a few quietly do not offer it at all, which becomes a problem when a customer asks for evidence that the critical finding was closed.

The scoping questions that move the number most

When we size an engagement, a handful of answers change the price far more than anything else. Knowing them before you request quotes will save you a round trip with every vendor you approach.

How many distinct user roles exist, and can they see each other's data? Multi-tenant SaaS is the case where this matters most. Testing tenant isolation properly means the tester needs at least two accounts in two separate tenants, ideally with different permission levels, and then systematically attempts to reach one tenant's objects from the other. This is where the genuinely severe findings live in SaaS products, and it is also the work that gets skipped when a scope is written as "test the app" without specifying accounts.

How many endpoints does the API expose, and is there documentation? An OpenAPI specification handed over on day one can remove a day of discovery. Without it, testers are reverse-engineering routes from the front end and will miss anything the web client never calls, which is frequently where the weak authorisation checks are.

Is there a non-production environment that mirrors production? Testing against production constrains what a tester can do. Destructive checks get pulled, rate limits interfere, and the team has to coordinate around business hours. A representative staging environment with production-like data volumes usually makes the test both cheaper and deeper. A staging environment with three seeded records and none of the integrations enabled is worse than useless because findings there will not be believed.

Are there third parties in scope? If part of your platform runs on a vendor's infrastructure, you may need their written authorisation before testing. Major cloud providers permit customer-initiated testing of your own resources under published rules, but a SaaS component you resell is a different matter, and chasing that permission has delayed more engagements than any technical issue.

Hidden costs that show up after the quote

The invoice from the testing firm is rarely the full cost. Budget for the internal side as well, because teams that do not are the ones who end up with a report nobody acts on.

Remediation engineering is the largest of these. A test that produces fourteen findings will consume real sprint capacity, and for anything touching authorisation logic the fix is often architectural rather than a patch. Plan for at least one engineer having partial availability for two to four weeks after the report lands.

Coordination is smaller but real. Somebody on your side needs to provision accounts, whitelist tester IP addresses if you run a WAF, answer questions during the test window, and attend the readout. Half a day a week for the duration is a fair estimate.

Then there is the cost of doing it twice. If you commission a test before your product has settled, and then ship a major release two months later, the report is describing a system that no longer exists. Enterprise buyers frequently ask for a test no older than twelve months, so timing the engagement to sit ahead of your sales cycle rather than behind it is worth some thought.

What a buyer or auditor does with the report

Very few enterprise security reviewers will read your full report. Most ask for one of three things: an attestation letter confirming a test was performed by a named third party within a stated period, a summary page listing finding counts by severity with remediation status, or the full report under NDA if the deal is large enough. Ask your testing firm at scoping time whether they produce a shareable letter separate from the technical report. If they do not, you will be sending a document containing exploitation detail about your own product to a prospect's procurement team, which is a decision worth making deliberately rather than under deadline.

Auditors care about different things. For SOC 2, the questions are whether testing happens on a defined cadence, whether findings were tracked to closure, and whether the remediation timelines matched your own stated policy. A report showing four criticals is not an audit problem. A report showing four criticals alongside a policy promising thirty-day remediation and a ticket that sat open for seven months is an audit problem. The document that gets you through is the remediation tracker, not the pen test itself. On one engagement the audit firm reduced its own quote by $11,000 once the readiness position was documented, which we wrote up in our auditor vetting case study.

When you should not buy a penetration test from us

There are situations where spending $1,000 or more on a human-led test is the wrong call, and we would rather tell you now than take the engagement.

You have never run a vulnerability scan. If nobody has looked at your dependency tree, your cloud configuration, or your patch levels, a penetration tester will spend expensive days documenting things a free or low-cost scanner would have caught in an afternoon. Run the basics, fix the obvious, then bring in a tester to find what tooling cannot. You will get a far better report for the same money.

Your product is pre-launch and changing weekly. Testing an application that will be substantially rewritten before it has customers produces findings with a short shelf life. A design and architecture review is usually the better spend at that stage, because fixing an authorisation model on paper costs a conversation and fixing it after launch costs a migration.

A buyer asked for evidence and will accept something lighter. Read the actual request. Some questionnaires ask whether you perform regular security testing, and an honest description of automated scanning plus a scheduled test date satisfies them. Buying a full engagement to answer a question that did not require one is a common and avoidable expense.

The obligation is really compliance, not security. If what you need is a SOC 2 report and the test is one line item inside it, start with a gap analysis so you understand the whole scope before committing budget to one piece of it. Our compliance work starts there for exactly this reason, and pricing is published so you can see how the pieces sit together.

Questions to ask before you sign

Ask who specifically will do the testing and what their background is, because firms routinely sell senior names and staff the work with juniors. Ask what methodology they follow and what they do beyond it, since methodology coverage is the floor rather than the ceiling. Ask how findings are validated, because a report containing false positives will cost your engineers days of wasted investigation and will damage your credibility if you forward it to a customer. Ask what happens if they find a critical issue mid-test, and confirm they will call you rather than wait for the report. Ask whether the retest is included and how long you have to use it.

Finally, ask for a redacted sample report. Any firm doing this work properly has one ready. Reading two pages of somebody else's findings tells you more about what you are buying than an hour of sales conversation, and it is the fastest way to separate genuine testing from a scan with a cover page. If you want to talk through scope against a real environment, get in touch and we will size it honestly, including telling you when the answer is to spend less.