ISO 27001 penetration testing: when to buy

Most companies buy the test at the wrong point in the project, which means paying for it twice. The timing question turns out to matter more than the scoping question, because a report dated after your stage 2 is evidence of nothing.

Last reviewed 2026-08-31Written by Jacob Masse, TrazTech Inc.

Schedule your penetration test to finish, including retesting of anything serious, six to ten weeks before your stage 2 audit. Budget $8,000 to $25,000 CAD for a typical Canadian SaaS scope, plus a retest that is often included but should be confirmed in writing. The part nobody plans for is what happens to the findings after the report lands.

What the standard asks for, which Annex A controls are in play, and how to scope a test are on ISO 27001 penetration testing. This page is the project view: money, calendar and the evidence loop.

Which test did your Statement of Applicability promise?

Four things get sold under the same budget line and they are not interchangeable. Getting it wrong is how a company buys $20,000 CAD of the wrong assurance and still takes a finding. Read your own Statement of Applicability wording first. Whatever it describes is what the auditor holds you to.

Vulnerability scan

Automated, cheap, run on a schedule. It evidences the technical vulnerability management control and it is the right answer for most of what that control needs. $1,000 to $6,000 CAD a year, or included in tooling you already pay for. It is not a penetration test and describing it as one in your documents is the finding.

Penetration test

Manual, scoped, time-boxed, with a human trying to chain findings together. This is what most Statements of Applicability end up describing and it is what the schedule below is built around.

Secure code review

Reading the source rather than attacking the running system. Relevant to the secure development controls rather than to the technical vulnerability ones, and a reasonable substitute for nothing. Buy it when the risk assessment points at code quality, not because it sounds thorough.

Red team exercise

Objective-based, adversary-simulating, usually unannounced to the defending team. Excellent value for a mature organization and close to worthless as ISO 27001 evidence for a first certification, because it produces a narrative rather than a finding list your corrective action process can consume.

When to schedule it

The test is not a certification gate. It is evidence that a control in your Statement of Applicability operates, so it has to sit inside the period the auditor samples and it has to be closed out. Work backwards from stage 2.

Testing too early is the more common mistake. A report from ten months before stage 2, against an environment that has since changed twice, invites the question of whether it describes the system in scope. Testing too late is worse. A high severity finding with no closure evidence turns into a nonconformity at the moment you have no time.

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.

What happens to the findings

This is what gets a company a finding at stage 2 despite a good test. Auditors are not assessing your security posture from the report. They are assessing whether your management system responded the way your own documents say it will.

• Every finding gets logged in the same place your other nonconformities go. If your corrective action process lives in a ticket tracker, these go in the ticket tracker. A PDF in a shared drive is not a record of corrective action.
• Findings above your risk acceptance threshold have to reach the risk register. Clause 6.1.2 asked you to define when reassessment happens. A penetration test that reveals a risk you had not identified is that trigger, and a register that did not move after the test is visible.
• Accepted findings need a named acceptor. Some findings will not be fixed, and that is a legitimate decision. It has to be a documented one, made by the risk owner, not a silence.
• The retest letter is the closure evidence. Ask the testing firm for a short retest report or letter confirming which findings were verified as fixed. This one document does more work at stage 2 than the original report does.

0 of 0 done · Reset

• The report itself, with the scope statement and the dates the testing ran
• A note reconciling the test scope against your certification scope, naming anything in scope that was not reached Scope statement
• Corrective actions in the same system your other nonconformities live in, with owners and dates Nonconformity process
• The risk register rows that changed because of the test, showing the reassessment your own method requires
• A named acceptor and a written rationale for every finding you decided not to fix
• The retest letter confirming which findings were verified as fixed
• The testing firm in your supplier register, with the data handling terms attached

What to budget across the cycle

All figures are Canadian dollars. Testing is an annual cost inside a three-year cycle, not a one-off project line. That is where budgets go wrong.

Years two and three are not free: surveillance auditors ask what testing has happened since the last visit, and "none" against a Statement of Applicability that claims the control operates is a finding. If your scope grows, so does the test, which is one more reason a narrow first scope saves money for three years rather than one. The itemised certification cost puts this line next to the others, and the cost calculator includes it in the three-year total.

When you should not buy a penetration test

The standard never names penetration testing, so there are cases where buying one spends compliance budget on assurance you did not need. Say so in your Statement of Applicability before an auditor makes you.

• You have no internet-facing system in scope. An internal tool behind a corporate identity provider, with no public attack surface, is evidenced adequately by vulnerability scanning and configuration review. Writing that reasoning down is the work, not buying the test.
• Your scope is a single purchased platform you do not control. Testing somebody else's software usually breaches their terms and tells you about their product rather than your management system. The supplier control and their own certification are the evidence here.
• You tested eight weeks ago and nothing shipped since. A second test for the certificate is money for a duplicate document. Use the existing report, and if the auditor questions its age, the change record is what answers them.
• You are more than two quarters from stage 2. Test now and you will be testing again before the audit. The exception is the optional early test in the first row of the schedule above, which is engineering spend and should not be presented as compliance evidence.

What you cannot do is claim the technical controls are applicable, describe testing as how you operate them, and then not test. The control selector shows which exclusions your scope actually supports, and cost is never one of them.

Choosing the firm, briefly

Buy the test on scope and quality, not on the framework label. A test sold as "ISO 27001 penetration testing" is the same work as any other test of the same scope, and a premium attached to the framework name is a premium for nothing. What is worth paying for is manual testing rather than a tidied scanner report, a named methodology, and a report that distinguishes what was tested from what was in scope but not reached.

One Canadian consideration: if personal information is inside the test scope, the testing firm becomes a supplier handling it, which engages PIPEDA or the applicable provincial statute and your own supplier security control. Ask where testing data is stored and for how long, and add the firm to your supplier register before the engagement rather than after. Canadian testing firms and what testing costs in Canada cover selection.

Common questions