By requirement
ISO 27001 security testing your auditor can rely on
ISO/IEC 27001:2022 does not mandate a penetration test. Its Annex A controls cover managing technical vulnerabilities, security testing in development and acceptance, and independent review of information security. We run testing that shows the controls you have selected work.
What it asks for
What ISO/IEC 27001 actually asks of security testing
ISO/IEC 27001 is a management system standard. Clauses 4 to 10 are mandatory, while Annex A lists 93 reference controls in four themes: organisational, people, physical and technological. You determine the controls you need through risk treatment and record the decision in a Statement of Applicability, justifying inclusions and exclusions. Nothing in the standard says you must commission a penetration test, so claims that it does overstate it. What the standard does require is that the controls you select are implemented, and that information security performance and the effectiveness of the ISMS are monitored and evaluated.
That is where testing comes in. Controls such as 8.8 on technical vulnerabilities and 8.29 on security testing in development and acceptance are hard to evidence without technical testing, and external testing can also feed the independent review under 5.35. Certification audits are typically sample-based, and auditors commonly ask how you know a control works, so a scoped, documented test with tracked remediation is often the clearest answer. The frequency, depth and scope are yours to define in proportion to risk, and once written into your ISMS, you can expect to be audited against them.
Annex A 8.8 Management of technical vulnerabilities
You are expected to find out about technical vulnerabilities in the systems you use, judge how exposed you are and take proportionate action. Vulnerability scanning and penetration testing show how exposure is identified; remediation records and retests show what you did about it.
Annex A 8.29 Security testing in development and acceptance
Security testing processes are expected to be defined and carried out as part of the development life cycle. Testing applications before release, and testing new or changed systems before acceptance, gives direct evidence that security requirements were actually met.
Annex A 5.35 Independent review of information security
Your approach to managing information security, and how it is implemented across people, processes and technology, should be reviewed independently at planned intervals or when significant changes occur. That review usually rests on audit, but testing by a party independent of the team that runs the systems can feed into it.
Annex A 5.36 Compliance with policies, rules and standards
You should regularly check that your own security policies, rules and standards are being followed. Technical checks against your hardening, access and configuration standards show whether they hold in practice, not just on paper.
Annex A 8.34 Protection of information systems during audit testing
Audit tests and other assurance work that touches operational systems should be planned in advance and agreed between the testers and appropriate management. Agreed rules of engagement, test windows and data handling limit disruption and are evidence in themselves.
What to test
What a risk-led ISO 27001 test should cover
Internet-facing estate
Websites, APIs, remote access and cloud services inside your ISMS scope, prioritised by the risks in your register rather than by whatever a scanner happens to find.
In-scope applications
Applications you build or buy that process information within the ISMS scope, tested before release or acceptance and after significant change, supporting 8.29 and your secure development controls.
Internal network and identity
Directory services, privileged access, segregation between networks and cloud identity, tested from an assumed-breach position, where a single weakness can undermine many Annex A controls at once.
People and process
Where your risk assessment calls for it, social engineering or scenario-based testing that checks whether awareness, reporting and incident response controls work under realistic pressure.
What you receive
What you receive, and how it supports your audit evidence
Scope tied to your ISMS
A scoping record linking tested assets to your ISMS scope and risk register, so an auditor can see why these systems were tested and how the decision was made.
Report mapped to Annex A
Findings with severity, evidence and remediation advice, each referenced to the relevant Annex A controls, making it easier to feed results into risk treatment and management review.
Retest and closure record
Verification of which findings are fixed and which remain open, supporting 8.8 and showing that nonconformities and weaknesses are followed through rather than filed away.
Rules of engagement
Documented authorisation, test windows, contacts and data-handling terms agreed with your management before testing starts, which supports 8.34 and shows the assurance activity itself was properly controlled.
Common pitfalls
Where ISO 27001 testing goes wrong
Mistakes that cost time at audit, and how to avoid them.
Scope that misses the ISMS
A test of the marketing website while core systems sit untested gives weak evidence. Auditors typically look for alignment between test scope, ISMS scope and the risks you have recorded.
Policies you cannot meet
Writing quarterly testing into policy, then testing annually, invites a nonconformity of your own making. Set a cadence your risk justifies and your budget can sustain.
Reports without treatment
A pentest report with open critical findings and no treatment decisions suggests 8.8 is not operating. Record whether each finding is fixed, accepted or scheduled, with owners.
Scanning presented as independent review
Automated scans are useful vulnerability evidence, but 5.35 concerns your overall approach to information security, so scans alone do not amount to that review. Be clear with your auditor about what each activity demonstrates.
Who decides what counts
PXL Security is an independent offensive-security firm, not an auditor, assessor, certification body or regulator. We deliver the testing and the evidence; your auditor, assessor or competent authority decides what they accept. This page is general guidance, not legal advice. We summarise these requirements in our own words from publicly available guidance; always check the exact wording against the official standard before relying on it.
FAQ
Questions we're often asked
Does ISO 27001 require a penetration test?
No. ISO/IEC 27001:2022 does not mandate penetration testing. It requires you to treat information security risks and show that the controls you select are operating, and for controls such as 8.8 and 8.29 a penetration test is a common and practical way to provide that evidence.
What will a certification auditor want to see?
Practice varies between certification bodies, but auditors typically look for evidence that technical vulnerabilities are identified and dealt with: test or scan reports, remediation records, risk acceptance decisions and retests. They also commonly look for consistency between your policy, your Statement of Applicability and what you actually did.
How often should we test for ISO 27001?
The standard does not set a testing frequency. Base it on your risk assessment, the rate of change in your systems and any customer or contractual expectations, write it into your ISMS, and then keep to it, because auditors will generally check against what you defined.
Can a penetration test count as the independent review under 5.35?
It can contribute, but 5.35 concerns your overall approach to managing information security, not only technical controls. An external test is good evidence for the technical side and usually sits alongside internal audit and other independent reviews.
Are you our certification body or auditor?
No. PXL Security is not a certification body or ISO auditor, and we do not certify, or confirm, compliance with ISO/IEC 27001. We perform the security testing and document it so your auditor can evaluate it as part of their own assessment.
Is this page audit or legal advice?
No. It is general guidance based on our understanding of ISO/IEC 27001:2022 and its Annex A controls. How the standard applies to you is a matter for your own risk assessment and your certification body, so confirm expectations with them.
Services that deliver this
Scope your ISO/IEC 27001 test.
Send a short description of your environment and goals. A senior tester, not a salesperson, will reply with questions, a proposed approach and a quote.