Trust is considered the core of any business relationship. And when it comes to handling your client’s sensitive data, you have to prove that you’re worthy of that trust.
As a globally recognized security framework, ISO 27001 does exactly that. Companies that handle customer data, mostly SaaS providers, analytics platforms, and data processors, are expected to have the certification to attest for a strong information security posture.
In 2024, ISO 27001 certifications nearly doubled from 48,671 to 96,709 globally. That’s a meaningful statistic because it tells you how many organizations worldwide have committed to building a formal information security management system.
However, what it doesn’t tell you is how many of those certified organizations still got breached.
In early 2026, Canvas, a learning management system by Instructure, suffered multiple breaches exposing data of 275 million users across 9,000 schools globally. Instructure held active ISO 27001 certification at the time, and yet the attackers entered Instructure’s system twice.
So, what does that tell you? It says that ISO 27001 gives you a structured approach to managing information security risk. It does not tell you where an attacker will find a way into your systems.
That gap is exactly what manual penetration testing closes.
If you are preparing for ISO 27001 certification or maintaining an existing program, this is the distinction you have to remember. The standard is a governance framework, not a security guarantee.
That is why, in this blog, we will first understand where ISO 27001 compliance ends and operational security begins, and how manual penetration testing bridges that gap.
What Are the Requirements for ISO 27001 Compliance?
ISO 27001:2022 is the current version of the international standard for Information Security Management Systems. If you are still certified under the 2013 version, you must consider restarting the certification process under the new revision.
The 2022 update restructured Annex A from 114 controls across 14 domains into 93 controls organized across four themes: Organizational, People, Physical, and Technological.
It also added 11 new controls, topics the 2013 edition did not address. They cove areas like threat intelligence, cloud security configuration, and data masking.
Now, the standard works in two layers. The main body (Clauses 4 through 10) defines the requirements for your ISMS, and Annex A provides the control objectives and controls themselves. The place where auditors look at is your governance posture, defined by ISO 27001’s many body.
For ISO 27001 penetration testing, the two most directly relevant controls sit in the Technological theme of Annex A:
- A.8.8 or Management of Technical Vulnerabilities: This control requires organizations to obtain timely information about technical vulnerabilities in the systems in use, evaluate what exposures lie in those vulnerabilities, and take appropriate measures.
ISO 27002:2022 explicitly states that penetration tests can be planned and performed by authorized persons to support vulnerability identification.
- A.8.29 or Security Testing in Development and Acceptance: This control requires security testing to be defined and performed across the development lifecycle.
It includes code review, vulnerability scanning, and penetration testing to identify weak coding and design before systems go into production.
These two controls are where ISO 27001 penetration testing requirements live in practice. But the picture is not complete without two other clauses.
- Clause 6.1.2 or the Information Security Risk Assessment: It mandates that organizations systematically identify, analyze, and evaluate information security risks.
- Clause 9.1or Monitoring & Analysis: This requires monitoring and evaluation of your system to demonstrate that your ISMS is actually working.
Taken together, these clauses and controls create an obligation to prove your security posture through evidence, not just through documentation of intent. That evidence obligation is precisely what makes manual pentesting for compliance non-negotiable for any organization seriously contemplating an ISO 27001 compliance.
How Can a Manual Pentesting Also Bolster Your ISMS?
Sometimes, SMBs generate automated scan reports in the name of pentesting. The fact is those will never pass an auditor’s review.
Auditors expect a signed pentest report dated within twelve months, a remediation log showing closure of high-risk findings, a documented testing plan, and findings mapped to specific Annex A controls.
This is why the distinction between automated scanning and manual penetration testing is not a minor technical detail.
Findings from a manual pentest can even be fed directly into four of the most scrutinized documents in your ISMS, thus bolstering them further. Take a look into what they are:
Replaces hypothetical risks with concrete, evidence-based findings from your actual environment.
A firewall rule classified as a control looks different once a tester demonstrates it can be bypassed by a misconfigured service.
Replaces hypothetical risks with concrete, evidence-based findings from your actual environment.
A firewall rule classified as a control looks different once a tester demonstrates it can be bypassed by a misconfigured service.
Unfiled or unverified findings create audit liability.
A pentest report with no remediation log is evidence of a problem, not evidence of control.
Statement of Applicability (SoA)
Annex A.8.8, A.8.29, A.5.15, A.8.2
Pentesting will map each finding to the specific Annex A control it affects. A.8.8 for vulnerability management, A.8.29 for application security, and access control failures to A.5.15 and A.8.2.
It tells the auditor your testing is structured, not ad hoc.
SoA lists controls as applicable with no technical evidence to support them.
Stage 2 auditors increasingly treat this as a non-conformance.
Monitoring & Measurement Record
Clause 9.1: Performance Evaluation
Annual penetration testing for ISO 27001 compliance provides recurring technical evidence that controls are operating effectively and not just that documented for certification.
Without pentest, controls are documented but not periodically validated.
Clause 9.1 requires demonstrated effectiveness, not assumed effectiveness.
What Should an ISO 27001-Aligned Manual Penetration Test Cover?
A penetration test report that satisfies ISO 27001 auditors is not simply a list of findings. It is a formal document that is structured to answer the questions auditors and enterprise buyers will actually ask.
Now just because pentesting aids in an ISO 27001 certification doesn’t mean it has to be done arbitrarily. Its scope is determined by everything in your ISMS boundary, from the systems and applications to the infrastructure and your risk profile.
At minimum, this is what a mature ISO 27001 penetration testing program should address:
- External Network and Perimeter Testing:
External testing evaluates what an attacker can reach and exploit from outside your environment without prior access. This includes internet-facing infrastructure, exposed services, and network perimeter controls.
The objective is to determine what attack surface is visible to an external threat actor and whether firewall rules, access controls, and exposed services are configured as your ISMS documentation claims.
- Web Application and API Testing:
Applications handling sensitive data are not only the primary targets but also the primary sources of exploitable vulnerabilities that automated scanners consistently miss. Manual application testing covers a lot of bases including business logic flaws, authentication weaknesses, and authorization bypass among others.
For healthcare and manufacturing organizations, this often includes the applications that handle patient data, manufacturing execution system interfaces, or ERP integrations.
- Internal Network and Lateral Movement Testing:
Internal testing simulates what an attacker can do once they have gained an initial foothold. Red teams will use phishing attacks or compromised credentials.
This is where the most consequential findings emerge. Perhaps an Active Directory misconfiguration that enables privilege escalation, a network segmentation failure that allows lateral movement between environments, or service accounts with excessive permissions that have not been reviewed since deployment will catch your eye during a pentest.
For manufacturing environments with IT/OT boundaries, internal testing should specifically evaluate whether those boundaries hold under adversarial conditions, not just whether they are documented.
- Cloud Configuration Review and Testing:
ISO 27001:2022 added explicit cloud security controls that were absent from the 2013 edition. Annex A includes controls for cloud service use (A.5.23), information security for use of cloud services, and related configuration requirements.
A penetration test scoped to your ISO 27001 program should include validation of cloud configuration against those controls.
Keeping all these in mind, this is what a compliant, audit-ready penetration test report will look like at the end of the day:
- Defined scope aligned to your ISMS boundary, with documented rules of engagement.
- Methodology statement explaining the testing approach and techniques used.
- Tester qualifications or credentials, establishing the independence and competence of the testing team.
- Findings with severity ratings using a recognized standard (CVSS is the most common) with proof of exploitation (screenshots, command output, exploit chains) not just theoretical descriptions
- Control mapping each finding to the specific Annex A control it affects, so the auditor can trace the finding to your SoA and risk treatment plan.
- Remediation guidance with actionable steps for each finding.
- A remediation log and retest evidence showing that high-severity findings were closed and verified.
Most vendors will deliver a PDF with findings and CVSS scores in the name of penetration testing. ISO 27001 compliance requires explicit linkage between findings and the controls those findings affect, and that is also what buyers and auditors need.
Mapping is what transforms a pentest report from a security document into a compliance document.
How Can KLEAP Help?
KLEAP’s penetration testing engagements are built around what your ISO 27001 compliance program actually needs, and not just a long list of findings.
Every engagement starts with a scoping conversation anchored to your ISMS boundary, your certification status, and where you are in your audit cycle. That context shapes the testing scope, the evidence we prioritize, and how we structure the final report.
This is KLEAP’s concierge model applied to security testing. We provide no template or generic checklist. One expert with knowledge of the industry and the framework stays with you until you have a report ready for the auditor.
Our methodology is taking a hands-on approach. That matters when it comes to ISO 27001 penetration testing evidence.
Everything from business logic flaws to finding attack paths requires a human tester thinking like a threat actor. Every report maps findings to Annex A controls. Remediation guidance is specific enough to act on. And we support the retest cycle, so remediated findings are verified closed, not just marked resolved.
For organizations approaching certification for the first time, we coordinate the penetration test with the gap analysis and remediation program, so that testing evidence is ready for Stage 2 audit.
For those in surveillance cycles, we scope annual engagements to changes in the environment since the last test, with evidence structured for the auditor reviewing your risk treatment plan at the next visit.
If you are preparing for ISO 27001 certification or maintaining an existing program, the right place to start is a conversation.
