Do You Actually Need Penetration Testing?

Most companies do not need penetration testing yet, and many that buy it are paying for a checkbox exercise instead of real risk reduction. You need penetration testing when a customer contract, a compliance framework, or your own production risk demands proof that a human tried to break in and documented what happened. If none of those apply to you today, a vulnerability scan and a hardened SDLC will do more for less money.

What Penetration Testing Actually Is (and Isn't)

A penetration test is a time-boxed, human-led attempt to exploit weaknesses in a defined system, application, or network, with a report at the end showing what was found, how it was exploited, and how to fix it. It is not the same as a vulnerability scan, which is an automated tool flagging known CVEs against a target with no attempt to chain them together or prove exploitability. Scanners are cheap and fast. Real testing is slower, costs more, and finds things scanners cannot, like business logic flaws, chained low-severity issues that add up to account takeover, or authentication bypasses that only show up when a human thinks like an attacker.

This distinction matters because a lot of "penetration testing" sold in the market is a scan with a consultant's name on the cover page. If the deliverable reads like a CVE list with no narrative of how an attacker would actually move through your environment, you did not get a penetration test.

Who Genuinely Needs Penetration Testing

There are a handful of situations where testing is not optional, it is table stakes:

• You are pursuing SOC 2 Type II and a customer's security questionnaire explicitly asks for an annual penetration test. This is increasingly common for Canadian SaaS companies selling into the US, where enterprise procurement teams treat a pen test report as a hard gate.
• You handle regulated or sensitive data such as payment card data, health records, or financial account information, where a breach carries regulatory exposure under PIPEDA or, for Quebec-based operations, Law 25.
• You are shipping a new product, a major architecture change, or a new external-facing API and want to know what an attacker sees before your customers' security teams find out for you.
• You have already had a scan come back clean and want to validate that "no known CVEs" actually means "not exploitable," which are two different claims.
• You are a fintech, healthtech, or infrastructure company where a single successful intrusion has outsized downstream cost, well beyond what a typical SaaS breach would cost.

If you fall into one of these buckets, the question is not whether to test, it is how to scope it so the money buys signal instead of a stack of low-severity findings you already knew about.

Who Is Over-Buying Penetration Testing

We say this as the people who sell testing: a lot of early-stage companies buy a penetration test before they need one. Signs you are over-buying:

• You have never run a vulnerability scan and have no patch management process. Fix the basics first, testing a system with no baseline hygiene just documents things you already know are broken.
• You are buying it purely because a competitor mentions it on their website, not because a customer or auditor asked.
• Your application has no external attack surface yet, it is pre-launch or internal-only with no real users or data.
• You are treating a single point-in-time test as a substitute for ongoing security work, rather than one input into it.

In these cases, the better spend is usually a broader security assessment or advisory engagement that builds the fundamentals, so that when a test does happen, it finds something more interesting than default credentials and unpatched dependencies. Our security services are built around that sequencing rather than selling testing as a default first move.

How Penetration Testing Doubles as Compliance Evidence

If you are on the SOC 2 or ISO 27001 path, a properly scoped penetration test does double duty. Auditors want evidence of independent testing, and a report that documents methodology, findings, severity, and remediation timelines satisfies that requirement while also giving your engineering team a real punch list. The trick is timing it so the report lands with enough runway before your audit window to actually remediate findings, not just disclose them. Rushing a test two weeks before an auditor's evidence deadline turns it into a liability instead of an asset.

This is also where a human-led approach earns its cost over an automated-only vendor. A tester who has published CVEs, including work on critical infrastructure vulnerabilities, brings pattern recognition that a scanner cannot replicate, and produces a report that reads as credible to a skeptical enterprise security reviewer, not just a compliance checkbox.

Scoping It Right: Network, Application, or Both

Cost and value depend heavily on scope. A web application test targeting your core product is usually higher priority than an external network test for a company that is entirely cloud-hosted with no legacy infrastructure. Conversely, a company with on-premises systems, VPN infrastructure, or a hybrid environment needs network testing that a SaaS-only shop does not. Be specific with any vendor about:

• What is in scope (production, staging, specific APIs, mobile apps)
• Whether authenticated testing is included (logged-in user paths, not just the public-facing surface)
• Whether social engineering or physical testing is part of the engagement, which most companies do not need
• Retest timing, so fixed issues get verified rather than just marked "reported"

Where Canadian Companies Fit Into This

Penetration testing demand in Canada is concentrated where you would expect: Toronto and Waterloo fintech and SaaS companies selling into the US enterprise market, Ottawa firms with government or defence-adjacent contracts, and Vancouver and Calgary tech companies scaling past their first few enterprise customers. Montreal companies increasingly ask about testing alongside Law 25 compliance work, since the province's privacy law has sharper enforcement teeth than PIPEDA alone. Wherever you are, the underlying question is the same: does a customer, regulator, or your own risk profile require proof, or are you buying reassurance you do not yet need. A partner who works across both the compliance and offensive security sides, sometimes alongside specialist partners like Lorikeet when an engagement calls for deeper red-team depth, can tell you honestly which one you're in before you sign anything.

Get a Straight Answer on Whether You Need One

If you are not sure which category you fall into, that is a fifteen-minute conversation, not a sales pitch. We will tell you if a scan and process fixes solve your actual problem, or if a real penetration test is what a customer or auditor is going to require. Explore our broader compliance services if the driver is SOC 2 or another framework, or get in touch to talk through your specific situation.

How to read a testing proposal before you sign it

Proposals in this market look similar on the surface and differ enormously underneath. The first thing to look for is effort expressed in tester days rather than a lump sum, because that number is what actually determines depth. A moderately complex SaaS application with authenticated roles, an API, and a multi-tenant data model needs somewhere in the range of five to ten tester days for a first test. If a proposal quotes a week of calendar time but does not say how many days a human is on the keyboard, ask, and treat evasion as an answer.

Second, look for a named methodology and a named tester. Serious proposals reference something concrete such as the OWASP Application Security Verification Standard or the Penetration Testing Execution Standard, and they will tell you who is doing the work and what they have found before. Testing at traztech starts from $1,000 for a narrowly scoped engagement, and the reason we can quote that honestly at the low end is that scope is defined precisely rather than left open. Cheap and vague is the combination to avoid, because the vagueness is where the depth quietly disappears.

Third, check what happens after the findings arrive. A test without a retest is half a product. You want the retest included, with a defined window, so that when your team fixes an issue there is an independent confirmation that it is actually closed rather than a status change in a spreadsheet. And check whether a letter of attestation is included, since that is the artifact your customer's procurement team will file, and a report you cannot share externally without redacting half of it is awkward to explain later.

Grey box beats black box for almost everyone

Buyers often assume a black box test, where the tester starts with nothing but a URL, is the most rigorous option because it mimics a real attacker. In a fixed time box it is usually the least informative. Days spent on reconnaissance and account creation are days not spent testing authorization logic, and the result is a report heavy on surface findings and light on the flaws that actually cost you customer data.

Grey box testing, where the tester gets credentials for each user role, a description of the architecture, and sometimes read access to the code, produces far more per day. It also lets the tester attack the things that matter for a SaaS platform: whether a low-privilege user can reach an administrative endpoint, whether one tenant can read another's records by changing an identifier, whether an API enforces the same authorization rules as the web interface, and whether a workflow can be driven out of order to skip a payment or an approval step. Full white box testing with source access is worth the extra cost when the application handles money or health data, or when a previous test came back suspiciously clean.

Provide at least two accounts per role. Testers need to check whether user A can act on user B's data, and a single account per role makes that awkward and slow. It sounds trivial and it routinely costs a day of an engagement.

What delays a test, and what it costs you

Engagements slip for a small number of repeatable reasons. Credentials arrive late or do not work, which is the most common one by a distance. The environment is unstable and the tester spends a day chasing errors that turn out to be a broken deploy rather than a finding. Rate limiting or a web application firewall blocks the tester's traffic, so time goes into working around your own defenses instead of testing the application behind them. Nobody allow-listed the tester's source addresses. The test target turns out to be a staging environment that differs from production in exactly the areas being tested.

Each of these costs real money because tester days are consumed whether or not they produce findings. The preparation that avoids them takes about two hours: working credentials for every role issued and verified a week ahead, a named engineering contact reachable during the test window, agreed handling for anything critical found mid-test, source addresses allow-listed, and a written decision about whether testing happens against production or a genuine production mirror. If you test staging, know which controls exist only in production, because those are then untested and your report should say so plainly.

There is also a legal preparation step people skip. If you run on a cloud provider, check the current policy on testing your own hosted resources, and get written authorization from whoever owns the systems in scope. If the application integrates with a third party, testing their side without permission is their problem becoming yours. A one-page authorization letter signed by an officer of the company is standard practice and takes an afternoon.

When the report comes back and you disagree with it

Two situations arise often enough to plan for. The first is a finding you believe is wrong or overstated. That is a legitimate conversation, and a good tester will walk through the reproduction steps with your engineer and either demonstrate the impact or adjust the rating. What you should not do is quietly drop a finding you dislike, because the report is a record and a later auditor or customer may ask why an item disappeared between versions. Where you disagree, record a written management response with your reasoning and any compensating control. Reviewers respect that far more than a shortened list.

The second is a critical finding landing two weeks before a customer review or an audit deadline. Fix it, retest it, and disclose it with the remediation date attached. A report showing a critical issue found, fixed within eleven days, and independently verified reads as a functioning security program. The same issue omitted or fudged reads as a problem when the customer's own reviewer stumbles across it. On the timing point more generally, book testing so that findings land with at least six weeks of runway before anyone external needs the report, because remediation of an architectural finding is rarely a same-week job.

Severity ratings deserve one caution. A scanner-derived score describes the vulnerability in the abstract, not in your environment. An unauthenticated flaw on an internet-facing endpoint that serves customer data outranks a theoretically higher-scored issue on an internal service reachable only from a bastion host. Ask your tester to rate by business impact and to say so in the report, because that is what makes the document useful to your engineers rather than just defensible to your auditor.

Cost drivers worth understanding

Price tracks scope, and scope tracks a handful of variables. Number of distinct applications and APIs is the obvious one. Number of user roles multiplies the authorization matrix a tester has to work through, so a platform with four roles takes materially longer than one with two. Multi-tenancy adds work because isolation has to be probed at every layer. A mobile client adds a separate body of work covering the client itself and the endpoints it calls, some of which are usually undocumented. On-premises or hybrid infrastructure adds network testing that a pure cloud shop does not need.

Things that do not drive cost as much as people expect: total lines of code, number of customers, and company headcount. Things that drive it more than people expect: a request to test in production with change controls around it, a compressed timeline that requires rearranging a tester's calendar, and a scope that grows mid-engagement because a system nobody mentioned turns out to be in the blast radius.

Cheaper answers that are sometimes the right ones

If your driver is genuine curiosity about your own security rather than an external requirement, several options cost less and often teach you more at your current stage. Turning on dependency and secret scanning in your repositories, fixing what they find, and keeping them green is free and closes a category of real risk. Running your cloud provider's own posture tooling against a published benchmark surfaces the misconfigurations that lead to most cloud incidents. A focused threat modeling session on your two or three most sensitive workflows, done internally with a whiteboard, frequently identifies the same authorization gaps a tester would find, at the price of an afternoon.

A public bug bounty is not a substitute for a scoped test and should not be started first. It produces continuous coverage but unpredictable timing, no report suitable for procurement, and a triage workload that a small team will underestimate. Run it after you have had at least one real test and closed the obvious issues, or you will pay for other people to find your default configurations.

Equally, do not buy a red team exercise as your first engagement. Red teaming tests whether your detection and response function works, and if you do not yet have a detection and response function the answer is already known. Spend that money on logging and alerting instead, and revisit red teaming when a failed exercise would actually tell you something you cannot predict.

Finally, be honest about cadence. An annual test suits a product that changes slowly. A team shipping several times a week gets more value from a smaller test tied to significant releases plus ongoing vulnerability management, which is the shape most of our retained engagements take, and our published scopes exist so you can compare the two honestly before committing to either.