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.
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. Those two sentences answer the question most people arrive with, and the rest of this page is the reasoning, plus the part nobody plans for: what happens to the findings after the report lands.
What the standard actually asks for, which Annex A controls are in play, and how to scope a test that fits your management system are covered in depth on ISO 27001 penetration testing, which is the page to read before you write a requirement. This page is the project view: money, calendar, and the evidence loop.
When to schedule it
The test is not a certification gate. It is evidence that a control in your Statement of Applicability operates, which means it has to sit inside the period the auditor is sampling and it has to be closed out. Working backwards from stage 2 gives a schedule that holds.
| When | What happens | Why there |
|---|---|---|
| Early implementation | Optional first test, unreported to the auditor | Finds architectural problems while they are still cheap to fix. Treat it as engineering spend, not compliance spend. |
| 16 to 20 weeks before stage 2 | Scope and book the test | Good Canadian firms are booked four to eight weeks out, and longer in the autumn. |
| 12 to 14 weeks before | Testing window | Late enough that the environment resembles what the auditor will see. |
| 10 to 12 weeks before | Report delivered, findings logged | Findings go into your corrective action process, not into an email thread. |
| 6 to 10 weeks before | Remediation and retest | The retest letter is the evidence that closes the loop. This is the step people omit. |
| Stage 2 | Auditor reviews report, actions and retest | They read the tracking, not the report. |
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, because a high severity finding with no closure evidence turns into a nonconformity at exactly the moment you have no time.
What happens to the findings
This is the part that gets a company a finding at stage 2 despite having bought a good test. Auditors are not assessing your security posture from the report. They are assessing whether your management system responded to it 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 precisely that trigger, and a register that did not move after the test is visible.
- Accepted findings need a named acceptor. Some findings are not going to be fixed, and that is a legitimate decision. It is a legitimate documented decision, 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.
Do not send the auditor the raw report alone
Hand over the report, the tracked corrective actions with dates and owners, the risk register entries that changed as a result, and the retest confirmation, as one package. Companies that hand over the report on its own invite an hour of questions about what they did with it, and the answer has to be assembled live from memory in front of an auditor.
What to budget across the cycle
All figures are Canadian dollars. Certification is a three-year cycle and testing is an annual cost inside it, not a one-off project line, which is where budgets usually go wrong.
| Scope | Year 1 | Years 2 and 3, each |
|---|---|---|
| Single web application and external network | $8,000 to $15,000 | $7,000 to $14,000 |
| Web application, API and cloud configuration review | $14,000 to $25,000 | $12,000 to $22,000 |
| Multiple products or an on-premise estate | $25,000 upward | $20,000 upward |
| Retest | Often included, confirm it | Often included, confirm it |
Two budget notes. 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. And 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.
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 genuinely Canadian consideration: if personal information is inside the test scope, the testing firm becomes a supplier handling that information, 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 properly.
Get testing quoted alongside the certification
Tell us your scope and your target stage 2 date and we will match you with Canadian firms that can test to that schedule.
Get matchedCommon questions
When should we do the penetration test for ISO 27001?
Finish the test and any retesting six to ten weeks before stage 2. That leaves time to close findings and produce closure evidence, and keeps the report recent enough to describe the environment the auditor examines. A report older than about twelve months at the time of the audit invites questions you would rather not answer.
How much should we budget for penetration testing in an ISO 27001 project?
$8,000 to $25,000 CAD a year for a typical Canadian SaaS scope, in each of the three years of the certification cycle rather than once. Budgeting it only in year one is a common error, and it surfaces at the first surveillance audit when the auditor asks what testing has happened since stage 2.
Does ISO 27001 require an annual penetration test?
The standard does not name penetration testing or set a frequency. What creates the expectation is your own Statement of Applicability: once you declare the relevant technical controls applicable and describe testing as how you operate them, the auditor holds you to your own description. The detail is on what the standard actually asks for.
Do we need to retest after fixing findings?
You need evidence that the fixes worked, and a retest letter from the testing firm is the cleanest form of it. Internal verification can be acceptable if it is documented and specific. What does not work is a closed ticket with no evidence attached, since that shows an intention rather than an outcome.