ISO 27001 penetration testing
The standard contains no clause requiring a penetration test, yet almost every certified company buys one. The gap between those two facts is where most of the wasted money and most of the audit findings live.
ISO 27001 does not require a penetration test, and it certainly does not require one every twelve months. No clause and no Annex A control uses the words. What the standard requires is that you identify technical vulnerabilities, evaluate your exposure to them, act on that evaluation, and be able to show a certification auditor that the cycle runs. A penetration test is one of the strongest ways to produce that evidence, which is why it has become the default answer. It is a choice you make and then have to justify, not an instruction you follow.
That distinction changes what you buy. A company that believes the standard mandates an annual test buys the same test every year, whether or not anything changed, and books it four weeks before the surveillance audit. A company that understands the control it is satisfying scopes testing against its own risk assessment, tests when the system changes materially, and arrives at the audit with a rationale rather than an invoice.
What the standard actually asks for
The requirement lives in two places at once, and both matter to an auditor.
The management system clauses come first. Clause 6.1 makes you run an information security risk assessment and produce a risk treatment plan. Clause 8 makes you operate what that plan says. Clause 9.1 makes you determine what needs to be monitored and measured, by what method, and how the results get evaluated. Clause 9.3 pulls the results into management review, and Clause 10 makes you handle nonconformities. Nothing there names a test. All of it applies to whatever testing you do choose, which is why an untracked report sitting in a shared drive fails the standard more clearly than a modest test that feeds a treatment plan.
Annex A comes second. In the 2022 revision the controls sit in four themes: organizational, people, physical and technological. The technical testing expectation is spread across a handful of them rather than concentrated in one.
| Control | What it asks | What a test contributes |
|---|---|---|
| A.8.8 Management of technical vulnerabilities | Obtain information about vulnerabilities in systems in use, evaluate exposure, take appropriate measures | The closest thing to a testing requirement in the standard. A test is one input among scanning, vendor advisories and patch management |
| A.8.29 Security testing in development and acceptance | Define and carry out security testing during the development lifecycle | Application testing before a release goes live, and the criteria that decide whether it ships |
| A.8.25 Secure development lifecycle | Establish rules for secure development of software and systems | Where the testing gate sits inside the lifecycle, rather than the test itself |
| A.8.9 Configuration management | Establish and monitor configurations of hardware, software and networks | Findings about drift, default credentials and exposed management interfaces |
| A.5.35 Independent review of information security | Review the approach to managing information security at planned intervals | Independence: a report from a party that neither built nor operates the system |
| A.8.34 Protection of information systems during audit testing | Plan and agree testing on operational systems to minimize disruption | Rules of engagement, testing windows and the escalation contact |
Read that table as a set of connected obligations rather than a checklist. A.8.8 is about a process that runs continuously. A.8.29 is about a gate in your release path. A.5.35 is about independence. One annual external network test touches A.8.8 lightly and the other two not at all, which is how a certified company ends up with a test and a finding in the same year. The full control set and its structure is covered on ISO 27001 Annex A controls.
The Statement of Applicability decides your answer
The Statement of Applicability is the document where you record which Annex A controls apply, how each is implemented, and why any excluded control is excluded. It is the first thing a certification auditor reads and the thing your testing has to agree with.
If your Statement of Applicability says A.8.29 is implemented through security testing before each major release, an auditor will ask for evidence of testing before major releases. Producing one annual report dated in November will not satisfy that sentence, and the finding is against your own written description rather than against the standard. The reverse is also common and easier to fix: companies describe an ambitious testing program they do not run, when a plainer description of what they actually do would have been accepted. Write the Statement of Applicability to match reality, then improve reality on a schedule you control.
What a certification auditor looks for
A certification body auditor is assessing your management system, not reading your findings list for technical merit. They are rarely penetration testers and are not trying to second-guess the work. What they check is whether the control you claimed is defined, operated and evidenced.
- Scope agreement. The systems tested fall inside the ISMS scope statement, and anything inside the ISMS scope that was excluded from testing has a written reason.
- A link to the risk assessment. The decision to test, and the frequency you chose, traces back to identified risks rather than to habit.
- Independence and competence. Who performed the test, their qualifications, and that they are not the team that built or runs the system.
- Findings tracked to closure. Each finding carried into your risk treatment plan or corrective action register with an owner, a target date and a status, not left inside the report.
- Evidence of retest or accepted risk. Either the fix was verified, or the residual risk was formally accepted by someone with the authority to accept it.
- Management review input. Results reaching the review under Clause 9.3, because that is where the standard closes the loop.
The finding that keeps recurring
The most common testing-related nonconformity is not a missing test. It is a report with open high-severity findings and no record of what was decided about them. An unremediated finding with an owner and a date is a functioning management system. The same finding with nothing attached is evidence that you detect problems and then do nothing, which is a worse position than never having tested.
How often, and against what
Because no interval is prescribed, you set one and defend it. Annual testing is the common answer, and it is a reasonable default for a stable system, mostly because it aligns with the certification cycle: an initial audit, surveillance audits in the two years that follow, and recertification in the third year. An auditor who sees a current report at every visit has an easy job.
Frequency alone is a weak control though. The more defensible position ties testing to change as well as to the calendar: a full test annually, plus application testing before any release that alters authentication, authorization or tenant separation. That pairing satisfies A.8.8 and A.8.29 with one budget and matches how systems actually break. Which test type fits which asset is set out on test types compared, and the ranges for each are on penetration testing cost in Canada.
How this differs from the SOC 2 expectation
Both frameworks stop short of naming a penetration test, then diverge in what their auditors do with that silence.
| Question | ISO 27001 | SOC 2 |
|---|---|---|
| Is a test named in the requirements | No. Inferred from A.8.8, A.8.29 and A.5.35 | No. Inferred from the monitoring and risk mitigation criteria |
| What is being assessed | Whether your management system defines, operates and improves the control | Whether the controls you described operated effectively across the review period |
| Who sets the frequency | You do, justified by your risk assessment | You do, but practice has converged on one test inside each Type 2 period |
| Room to argue a different approach | Real, if the rationale is documented and consistent with the Statement of Applicability | Limited. A missing test tends to become an exception in the report |
| Where the result is recorded | Risk treatment plan, corrective actions and management review minutes | Described in the auditor's testing of the relevant criteria |
The practical consequence for a company doing both is that one test can serve both, provided the scope covers the system boundary each framework cares about and the remediation record is kept in a form each auditor accepts. Scoping for the SOC 2 side is covered on SOC 2 penetration testing requirements, and the requirement set behind it on SOC 2 requirements. Do not buy two tests for two certificates before checking whether one scope covers both.
Scoping a test that fits the ISMS
Start from the ISMS scope statement rather than from a price list. If the statement covers the product, the supporting cloud infrastructure and the corporate systems that administer them, then a web application test alone leaves two thirds of the scope untested and an auditor will notice. If the statement is narrower, say so plainly and test what is in it.
Agree the rules of engagement in writing before anything starts, since A.8.34 asks for exactly that: the testing window, the systems in and out of bounds, an escalation contact, and how any personal information the tester encounters is handled. Under PIPEDA that last point stays your accountability even when the work is done by someone else, so it belongs in the contract rather than in an email thread.
Ask for an attestation letter alongside the technical report. Certification auditors normally accept a letter confirming the date, scope, methodology and remediation status, and it is far safer to circulate than a document listing your unfixed vulnerabilities. What a full engagement should deliver is set out on what a penetration testing engagement includes.
Scope a test your certification auditor will accept
Tell us what your ISMS covers and where you are in the certification cycle, and we will put the same scope in front of Canadian testing firms.
Get matchedCommon questions
Does ISO 27001 require an annual penetration test?
No. The standard names no test and sets no interval. It requires you to manage technical vulnerabilities, test security during development, and review your approach independently at planned intervals. You decide what testing satisfies that and how often, and you document why. Annual is a common and defensible answer for a stable system, but it is your decision rather than a rule.
Can our internal team do the test instead of an external firm?
For A.8.8 and A.8.29, yes, provided the testers are competent and are not assessing their own work. A.5.35 asks for independent review, and internal independence is possible if the reviewers sit outside the team that built and runs the system. In practice most certified companies use an external firm at least once a cycle, because it is simpler to evidence and because customers ask for an external report anyway.
Will the certification auditor read our penetration test report?
They will look at it, mostly to confirm the date, the scope and the severity of findings. They are auditing the management system rather than the testing craft, so the questions that follow are about what you did with the findings: who owned each one, what the target dates were, whether fixes were verified, and whether anything still open was formally accepted.
We failed a control because of an open critical finding. What now?
Treat it as a nonconformity under Clause 10. Record it, do a root cause analysis rather than only fixing the instance, set a corrective action with an owner and a date, and retest to verify. Certification bodies expect nonconformities to be raised and closed. A finding you documented and worked is normal, and the position that actually costs you the certificate is evidence that the process for handling findings does not run.
One test for both ISO 27001 and SOC 2, or two?
One, in most cases. The technical work is the same and the difference is in how the result is recorded. Check that the scope covers the system boundary in both your ISMS scope statement and your SOC 2 system description, and that the report is dated inside the SOC 2 review period. Where the two boundaries genuinely differ, extend the scope of the single test rather than buying a second one.