On this page
- Does ISO 27001 require VAPT?
- The Annex A controls behind an ISO 27001 VAPT
- What ISO 27001 certification auditors expect to see
- VA vs PT: why ISO 27001 programmes need both
- What should be in scope for an ISO 27001 VAPT?
- How often should you do VAPT for ISO 27001?
- Preparing for an ISO 27001 VAPT audit, step by step
- What a good ISO 27001 VAPT report contains
- ISO 27001 VAPT for organisations in India
- Common mistakes in ISO 27001 VAPT programmes
- Where VAPT fits in the ISO 27001 certification cycle
- Example wording for your vulnerability management procedure
- ISO 27001 and SOC 2: one VAPT, two audits
- ISO 27001 VAPT for cloud-native and SaaS companies
- How Summit supports ISO 27001 VAPT
- Frequently asked questions
Does ISO 27001 require VAPT?
ISO/IEC 27001:2022 is a management system standard. It tells you to identify information security risks and treat them with appropriate controls, and Annex A lists 93 controls you consider in that process. It is deliberately technology-neutral, so it never names a specific test.
The control that matters most is A.8.8 Management of technical vulnerabilities. It requires that information about technical vulnerabilities is obtained, your exposure is evaluated, and appropriate measures are taken. You cannot evaluate your exposure without looking for vulnerabilities, and you cannot show an auditor that you looked without evidence. Vulnerability scanning and penetration testing are the standard ways to produce that evidence.
So the practical answer is: VAPT is not mandatory by name, but an ISO 27001 programme without it is very hard to defend in an audit, and harder still with enterprise customers who ask for your latest penetration test report alongside your certificate. Our ISO 27001 framework guide covers the wider certification journey.
The Annex A controls behind an ISO 27001 VAPT
- A.8.8 Management of technical vulnerabilities
- Find, evaluate and treat technical vulnerabilities in a timely way. Scanning and penetration testing are the core evidence.
- A.8.29 Security testing in development and acceptance
- Define and perform security testing in the development life cycle. Covers code review, application testing and pre-release penetration testing.
- A.5.35 Independent review of information security
- Review your approach independently at planned intervals and after significant change. An external penetration test is one form of independent review.
- A.8.9 Configuration management
- Secure configurations are defined and monitored. Configuration weaknesses found in testing are evidence here.
- A.8.20 to A.8.22 Network security
- Networks and network services are secured and segregated. Network VAPT tests these controls.
- Clauses 6.1 and 8.2 to 8.3
- Risk assessment and treatment. Findings must flow into your risk register and treatment plan.
The 2022 revision reorganised Annex A from 114 controls in 14 domains into 93 controls in four themes (organisational, people, physical and technological). If your documents still reference the 2013 numbering, such as A.12.6.1 for technical vulnerability management, update them; A.8.8 is the 2022 equivalent.
What ISO 27001 certification auditors expect to see
Certification auditors sample evidence to decide whether your controls are implemented and effective. For vulnerability management, they typically look for:
- A documented vulnerability management policy or procedure: what is tested, how often, who owns it, and how fast each severity must be fixed
- Evidence of regular vulnerability scanning of in-scope systems, with results
- An independent penetration test report covering internet-facing and critical systems, usually within the last 12 months
- Tickets or records showing findings were assigned, prioritised and fixed within your stated timelines
- Retest evidence for critical and high findings
- A link from findings to your risk register and risk treatment plan
- Testing after significant changes, such as a new application, a cloud migration or a major release
The gap auditors find most often
The policy and the evidence do not agree. The policy says “critical vulnerabilities fixed within 7 days”, the penetration test found two criticals, and the tickets show one was fixed after 40 days and the other is still open with no risk acceptance. That is a nonconformity even though you did the test. Set timelines you can meet, and document risk acceptance when you cannot.
VA vs PT: why ISO 27001 programmes need both
The two halves of VAPT answer different questions, and an ISO 27001 auditor expects to see both working together.
Vulnerability assessment (VA)
Broad and frequent. Automated scanning plus review across all in-scope hosts and applications, run monthly, quarterly or continuously. Shows you know your exposure.
Penetration testing (PT)
Deep and periodic. A skilled tester exploits and chains weaknesses, tests access control and business logic, and proves real impact. Shows your controls withstand a real attacker.
Scanning alone misses the issues that matter most in modern applications, such as broken authorisation between tenants, insecure business logic and chained misconfigurations. Penetration testing alone, once a year, leaves eleven months without visibility. Our explainer on what a VAPT assessment is goes deeper into the difference.
What should be in scope for an ISO 27001 VAPT?
Start from your ISMS scope statement and your asset inventory. Anything inside the ISMS scope that is exposed to the internet, holds sensitive information or supports a critical process is a candidate.
Internet-facing applications
Customer portals, web applications and APIs, tested authenticated with realistic roles.
External network perimeter
Public IP ranges, VPN gateways, remote access, email and DNS infrastructure.
Internal network
Active Directory, servers and segmentation between user, server and management networks.
Cloud environments
IAM, storage, network exposure, logging and key management in AWS, Azure or GCP.
Mobile and thick clients
Apps that handle in-scope information, and their back-end APIs.
Key suppliers and integrations
Where contracts allow, integrations that carry sensitive data across your boundary.
Prioritise by risk. Your auditor will not expect every asset to be penetration tested every year, but they will expect your choices to match your risk assessment. A rarely used internal wiki and your payment API do not need the same depth.
How often should you do VAPT for ISO 27001?
ISO 27001 sets no frequency. What it requires is that your approach is risk-based, documented and followed. A cadence that most auditors accept as reasonable for a typical SaaS or technology company is:
- Vulnerability scanning
- Monthly or continuous for internet-facing assets; at least quarterly internally
- Penetration testing
- At least annually for internet-facing and critical systems
- Change-driven testing
- After major releases, new applications, architecture changes or cloud migrations
- Retesting
- After fixes for critical and high findings, before closing them
- Development testing
- Security testing in the release pipeline for new and changed code (A.8.29)
Higher-risk environments, such as fintech, health data or platforms with frequent releases, often test more often or move to continuous testing of critical applications.
Preparing for an ISO 27001 VAPT audit, step by step
- Confirm the ISMS scope and asset inventory. The VAPT scope should be traceable to them.
- Write or update the vulnerability management procedure. Include scanning frequency, penetration testing frequency, severity definitions and remediation timelines.
- Run vulnerability scanning and fix what it finds, so the penetration test can focus on deeper issues.
- Commission an independent penetration test of your internet-facing and critical systems, scoped against your risk assessment.
- Log every finding in your ticketing system with severity, owner and due date, and add significant risks to the risk register.
- Fix and retest. Keep the retest report or letter as evidence of closure.
- Accept residual risk formally where a finding cannot be fixed in time, with a named risk owner and a review date.
- Present it at management review (clause 9.3), so leadership sees the results and decisions are recorded.
What a good ISO 27001 VAPT report contains
The report itself becomes audit evidence, so its quality matters. Look for:
- Clear scope with asset list, dates, test type and environment
- Methodology referencing recognised standards such as OWASP, NIST SP 800-115 or PTES
- Findings with severity, affected assets, evidence, impact and specific remediation
- An executive summary for management review
- A retest section showing what was fixed and verified
- Optional but helpful: a mapping of findings to Annex A controls
Our article on what a SOC 2 VAPT report looks like walks through each section in detail; the same structure works for ISO 27001. You can also see our sample VAPT report.
ISO 27001 VAPT for organisations in India
Many Indian companies pursue ISO 27001 because enterprise and international customers ask for it, and because it gives structure to other obligations. Three points are worth knowing:
- DPDP Act alignment. India’s Digital Personal Data Protection Act requires reasonable security safeguards for personal data. An ISO 27001 programme with regular VAPT is strong evidence of those safeguards. See our guide to what the DPDP Act is.
- Sector regulators. Entities regulated by RBI, SEBI or IRDAI often have their own audit requirements, and some require an auditor on CERT-In’s empanelled list. ISO 27001 evidence complements, but does not replace, those audits.
- Customer due diligence. Global customers usually ask for the ISO 27001 certificate, the Statement of Applicability and the latest penetration test summary together.
Common mistakes in ISO 27001 VAPT programmes
Testing the wrong things
The marketing website is tested every year; the customer API and admin console never are. Scope by risk, not by convenience.
Scan reports presented as pentests
Auditors and customers increasingly recognise raw scanner output. Make sure the annual test includes manual testing.
No link to the risk register
Findings sit in a PDF and never reach risk treatment, so clause 6.1 evidence is missing.
Unrealistic remediation timelines
Aggressive SLAs that are routinely missed create nonconformities. Set achievable timelines and track them.
No retest
Without retest evidence, there is no proof findings were closed.
Stale Annex A references
Documents still citing 2013 control numbers after transition to ISO 27001:2022 confuse auditors and suggest outdated documentation.
Where VAPT fits in the ISO 27001 certification cycle
ISO 27001 certification runs on a three-year cycle, and testing evidence is reviewed at each stage:
Stage 1 audit
The auditor reviews your documentation, including the vulnerability management procedure and your Statement of Applicability. A planned or completed penetration test shows A.8.8 is more than a policy.
Stage 2 audit
The auditor tests whether controls operate. Expect to show recent scan results, the penetration test report, tickets for findings and retest evidence.
Surveillance audits (years 2 and 3)
The auditor samples controls again. A fresh annual test, and evidence that last year's findings were closed, are commonly reviewed.
Recertification (year 3)
A full reassessment. A consistent testing history across the cycle is strong evidence of a working ISMS.
Plan your annual penetration test so the report and retest are complete a few weeks before each audit. Testing a week before Stage 2 leaves no time to fix findings, and an auditor will notice open criticals.
Example wording for your vulnerability management procedure
Auditors read your procedure first, then check the evidence against it. Clear, realistic wording avoids nonconformities. A typical structure:
- Scope
- All systems within the ISMS scope, prioritised by the risk assessment
- Scanning
- Internet-facing systems scanned at least monthly; internal systems at least quarterly
- Penetration testing
- Independent penetration test of internet-facing and critical systems at least annually and after significant change
- Severity
- Findings rated Critical, High, Medium, Low using CVSS adjusted for business context
- Remediation targets
- For example Critical 14 days, High 30 days, Medium 90 days, Low at next planned release
- Exceptions
- Findings not fixed in time require documented risk acceptance by the risk owner, with a review date
- Reporting
- Results and trends reviewed at management review
Choose remediation targets your team can meet consistently. The numbers above are an example, not a requirement.
ISO 27001 and SOC 2: one VAPT, two audits
Many companies hold both ISO 27001 certification and a SOC 2 report. The testing evidence overlaps almost completely: an independent penetration test with a clear scope, verified findings, remediation tracking and retest results satisfies both, as long as the scope covers the ISMS and the SOC 2 system description. Align the timing with both audit periods and ask for a report that maps findings to Annex A and the Trust Services Criteria, so one engagement serves both.
ISO 27001 VAPT for cloud-native and SaaS companies
Many ISO 27001 programmes today cover systems that run entirely on AWS, Azure or GCP. Two points often confuse teams:
- Shared responsibility. Your cloud provider’s own ISO 27001 certificate covers its infrastructure, not your configuration, applications or identities. Your VAPT scope must still cover what you build and configure on top.
- Cloud provider testing policies. Major cloud providers allow customers to test their own resources without prior approval for most services, within published policies. Your testing firm should follow them.
- Configuration is part of the attack surface. IAM roles, storage permissions, security groups and logging settings deserve a configuration review alongside application testing, because misconfiguration is a leading cause of cloud data exposure.
- Infrastructure as code. If you deploy with Terraform or CloudFormation, reviewing the templates finds problems before they reach production and is good evidence for A.8.9 and A.8.29.
How Summit supports ISO 27001 VAPT
Summit provides independent, manual penetration testing scoped to your ISMS and risk assessment: web application VAPT, network VAPT and cloud security assessment. Reports include severity rationale, evidence, stack-specific fixes, an Annex A mapping and a retest of fixed findings, so they slot straight into your audit evidence.
Preparing for ISO 27001 certification or surveillance?
Share your ISMS scope and audit date and we will propose a VAPT scope that fits. Read the ISO 27001 guide or get a quote.
Frequently asked questions
Is VAPT mandatory for ISO 27001 certification?
ISO 27001 does not use the words penetration test. It requires you to manage technical vulnerabilities according to your risks. In practice most certification auditors expect regular vulnerability scanning and an independent penetration test of internet-facing and critical systems as evidence that Annex A 8.8 is working.
Which ISO 27001 controls does a VAPT support?
Mainly A.8.8 Management of technical vulnerabilities, A.8.29 Security testing in development and acceptance, and A.5.35 Independent review of information security. Findings also feed your risk assessment and risk treatment plan under clauses 6.1 and 8.
How often should we do VAPT for ISO 27001?
The standard sets no frequency. A common, defensible baseline is continuous or quarterly vulnerability scanning, an annual penetration test of internet-facing and critical systems, and additional testing after significant changes. Write the cadence into your policy and follow it.
Does the certification auditor test our systems?
No. The certification body audits your management system and samples evidence. It does not perform technical testing. That is why your own VAPT reports, tickets and retest results are the evidence it relies on.
Can an internal team do the penetration test?
It can support A.8.8, but A.5.35 asks for independent review, and many auditors and customers expect an external tester for the annual penetration test. Internal testing works well alongside it, for example in the development cycle under A.8.29.
