ISO 27001 penetration testing for Annex A 8.8 evidence
ISO/IEC 27001 does not make penetration testing mandatory, but its Annex A control 8.8 covers the management of technical vulnerabilities, and a test is a common way to evidence it; your risk treatment decides whether you run one, and your certification body's auditor judges the evidence. BERRY9 tests your applications, APIs, networks and cloud accounts by hand from Hyderabad and hands over an executive report, an engineering report giving each finding a proof of concept and a CVSS 3.1 score, and a remediation matrix that records every fix.
- Tests start from
- INR 27,000 + 18% GST
- Control in focus
- Annex A 8.8
- Your certificate
- Issued by your certification body
- Delivery
- Remote from Hyderabad
Last reviewed
Find: a manual test of the applications, APIs, networks and cloud accounts inside your ISMS scope.
Evaluate: a CVSS 3.1 severity for every finding, set against your own environment and data.
Act: a proof of concept and a fix per finding, collected in a remediation matrix your team works through.
Confirm: fixed findings checked again on the retest terms in your proposal.
01 / What ISO 27001 expects
Is penetration testing required for ISO 27001?
ISO/IEC 27001 does not list penetration testing as a mandatory activity. It does contain a control for technical vulnerabilities, and whether a test is the right way to meet it is settled by your own risk treatment and judged by your certification body's auditor.
A standard for your ISMS
ISO/IEC 27001 sets out the requirements for an information security management system (ISMS): how an organization assesses its information security risks, chooses controls to treat them, and keeps the system working and improving. The current edition is ISO/IEC 27001:2022.
Certificates come from certification bodies
ISO and IEC publish the standard but do not certify anyone. Certification comes from a certification body that audits your ISMS, first in two stages and then through surveillance audits across a three-year cycle. A testing firm, BERRY9 included, takes no part in that audit.
Annex A 8.8 in plain words
Control 8.8, management of technical vulnerabilities, asks you to obtain information about weaknesses in the information systems you use, evaluate how exposed you are to them and take appropriate measures. A penetration test is one common way to gather that information for the systems in scope.
Controls arrive through risk treatment
Annex A is a reference list of controls. Clause 6.1.3 has you compare the controls your risk treatment needs with that list and record the result, with reasons for each inclusion or exclusion, in a Statement of Applicability.
If your documents still use the 2013 numbering, control A.12.6.1 covered the same topic; in the 2022 edition it is 8.8.
Ask your certification body, or the consultant preparing you, what evidence they expect for 8.8 before we scope the test.
02 / Evidence map
What a penetration test gives your ISO 27001 evidence
A test report is evidence for several Annex A controls at once, and for the risk process behind them. The table pairs each control with what a BERRY9 report contributes. It is a planning aid only: whether the evidence is adequate is your certification body's call, and a test on its own does not earn a certificate.
| Control or clause | What it covers | What the BERRY9 report contributes |
|---|---|---|
| 8.8 Management of technical vulnerabilities | Obtaining information about technical vulnerabilities, evaluating exposure to them and taking appropriate measures | Confirmed weaknesses in the systems tested, each with a proof of concept, a CVSS 3.1 severity and the fix |
| 8.29 Security testing in development and acceptance | Security testing processes defined and carried out within the development life cycle | A manual test of a new or changed application around its release, with results your developers can act on |
| 8.3 Information access restriction and 8.5 Secure authentication | Access to information restricted under the access control policy, and secure authentication technologies and procedures | Findings on sign-in, sessions, roles and records a user should not reach, from the web and API tests in scope |
| 8.20 Networks security and 8.22 Segregation of networks | Networks and network devices secured, managed and controlled, and groups of services, users and systems kept apart | Findings on exposed services and on whether one network zone can reach another, from a network test |
| 8.9 Configuration management | Configurations, including security configurations, of hardware, software, services and networks set and kept under control | Misconfigured hosts, services and cloud settings found during the test, each paired with the change that closes it |
| Clauses 6.1.2 and 6.1.3 Risk assessment and risk treatment | Information security risks identified, analyzed and evaluated, and a plan to treat them | An executive report on what each finding means for the business, and a remediation matrix to carry into the treatment plan |
Control numbers and titles follow ISO/IEC 27001:2022 Annex A, and the middle column paraphrases each one. Check which of these controls your Statement of Applicability includes.
What auditors commonly look for in a test report:
- Scope that matches your assets. Auditors commonly compare the systems tested with the assets in your inventory and ask about anything left out.
- Independence. The people who test a system should not be the people who built it; an outside tester is one clear way to show it.
- A documented method. Auditors do not usually ask for one particular method, but they expect the one used to be written down; every BERRY9 report sets out the phases it followed.
- Findings tracked to closure. Each finding logged with an owner and a due date, and evidence that it was fixed or that its risk was formally accepted.
03 / Scoping
Scope the test with your certification body and risk register
Your ISMS scope, asset inventory and risk register already record what matters to your organization. A test scoped from them, and checked with your certification body or consultant, is less likely to leave a gap an auditor raises later.
Show details for Scope the test with your certification body and risk register
- Your ISMS scope statement. The boundaries set under clause 4.3: which sites, teams, products and systems your certificate is meant to cover.
- The asset inventory. The applications, APIs, hosts and cloud accounts recorded under control 5.9, so the test list and the inventory agree.
- Risks in the register. Entries that name technical weaknesses or unauthorized access, so testing goes where your own assessment puts the exposure.
- Audit dates. When the stage 2, surveillance or recertification audit falls, so the report and the fixes are ready before it.
- Open audit findings. Any nonconformity or observation raised last time about vulnerability management, so this test answers it.
- Roles, environments and limits. The user roles to test as, production or staging, and what testing must not touch, approved in writing in the rules of engagement.
Where testing sits in the certification calendar:
Before the audit
Readiness test
Finds what to fix while there is still time to fix it, and to record the fixes, before an auditor reads the file.
OutputFindings and a remediation matrix
After the fixes
Retest
Fixed findings are checked again on the retest terms in your proposal, so the record shows each issue closed.
OutputRetest results for your evidence file
After a major change
Repeat test
Clause 8.2 has you reassess risk when significant changes are proposed or occur, and a new product, platform or network is a natural point to test again.
OutputFresh evidence for 8.8
04 / Which tests
Which tests fit an ISO 27001 scope
ISO/IEC 27001 does not say which systems to test; your ISMS scope and risk assessment do. For most organizations that means the applications, APIs, networks and cloud accounts that hold or carry customer data.
Show details for Which tests fit an ISO 27001 scope
Web applications
Customer portals and internal applications inside your ISMS scope, tested under each role to show whether access rules hold.
APIs
The endpoints behind your apps and integrations, with each one tried as every role you provide.
Networks
External addresses and internal ranges, including whether zones that should be separate really are (controls 8.20 and 8.22).
Cloud accounts
Identity and access settings, security groups and network paths in the AWS, Azure or GCP accounts your ISMS covers.
SOC 2 as well
Running a SOC 2 examination too? One test can support both programs, if the systems overlap and both auditors agree the scope and the timing.
Every service we offer
The full list of tests BERRY9 runs, grouped by what they cover, for systems this list leaves out.
Every test runs through the five phases on our VAPT methodology page, and the sample VAPT report shows the layout your ISMS team will file.
05 / Deliverables
What you get from an ISO 27001 penetration test
Every BERRY9 test includes the five items below.
Show details for What you get from an ISO 27001 penetration test
- An executive report setting out the scope, what was found and what it means for the business, written for management review and your risk owners.
- An engineering report giving every finding its steps to reproduce, a proof of concept and the recommended fix.
- CVSS 3.1 severity for each finding, scored against your own environment so the priorities you record are your own.
- A remediation matrix with each finding beside its fix: the list your team works through and updates as items close.
- Retest terms, as stated in the price section of this page.
BERRY9 itself holds ISO/IEC 27001:2022 certificate 26MEQVU27; that certificate is ours and does not certify your organization. Its scope is vulnerability assessment and penetration testing (VAPT) services and corporate training. BERRY9 tests your systems; it does not audit your ISMS or issue certificates.
06 / Who it fits
Who ISO 27001 testing from BERRY9 suits
ISO 27001 testing from BERRY9 works well when the push for it comes from your own ISMS, a certification audit or a customer asking for your certificate. If a regulator or a tender names its own kind of auditor, you may need a different firm, and we say so early.
Show details for Who ISO 27001 testing from BERRY9 suits
Working toward a first certificate
Organizations building an ISMS who want a test before the stage 2 audit, while there is still time to fix findings and update the risk register.
Certified and heading into an audit
Teams that hold a certificate and want current vulnerability evidence in the file before the next surveillance or recertification visit.
Suppliers asked for proof
IT services, SaaS and product firms whose customers ask for both an ISO 27001 certificate and a recent independent test report during vendor reviews.
Not a fit: when a CERT-In empanelled auditor is required. ISO/IEC 27001 says nothing about CERT-In. Some regulators, tenders and contracts require a CERT-In empanelled auditor, and BERRY9 is not that firm. We are not CERT-In empanelled, and we tell you so before you pay.
ISO 27001 testing is delivered remotely from our one office in Hyderabad to organizations anywhere in India, and on-site work can be arranged. Local details are on the VAPT services in Hyderabad page.
07 / Price
What an ISO 27001 penetration test costs
An ISO 27001 penetration test with BERRY9 starts from INR 27,000 + 18% GST. That is where pricing begins, not a fixed fee: the systems, roles and environments inside your ISMS scope set the final figure, which you receive in a written proposal after scoping.
ISO 27001 penetration test
Starts fromINR 27,000 + 18% GST
Starting price for a manual test of systems inside your ISMS scope: applications, APIs, networks or cloud accounts. The final figure depends on how many of them are in scope.
- Executive and engineering reports
- Proof of concept and CVSS 3.1 severity per finding
- Remediation matrix
What moves the price
Priced byScope
Three things set the figure for an ISO 27001 test:
- Systems inside your ISMS scope
- User roles and tenants to test as
- Environments, such as production and staging
The starting price for small scopes includes one free retest. For larger scopes, the retest terms are written into the proposal before work starts.
The VAPT cost guide for India explains each factor that moves a VAPT price.
08 / Inquiry
Send us your ISMS scope and audit dates
Tell us what your ISMS covers, which systems sit inside it, when your next certification or surveillance audit falls and what your auditor or consultant has asked for. We reply with a written proposal naming the systems to test.
Prefer to talk first? Call +91 86868 92922 or write to contact@berry9.com.
09 / FAQ
Frequently asked questions
Short answers about scope, price and how testing works. For anything else, call +91 86868 92922.
Is penetration testing required for ISO 27001?
ISO/IEC 27001 does not list penetration testing as a mandatory activity. Annex A control 8.8 asks you to obtain information about technical vulnerabilities, evaluate your exposure and act on it, and a penetration test is one common way to do that for the systems in scope. Whether you need one is a decision for your risk treatment, and your certification body's auditor judges whether your evidence is enough. See the section on Is penetration testing required for ISO 27001? above.
What does Annex A 8.8 cover?
Control 8.8 of ISO/IEC 27001:2022, management of technical vulnerabilities, covers obtaining information about technical vulnerabilities in the information systems you use, evaluating how exposed the organization is to them and taking appropriate measures. In the 2013 edition the same topic was control A.12.6.1. See the section on What a penetration test gives your ISO 27001 evidence above.
What should an ISO 27001 VAPT report include?
Auditors commonly look for the scope and dates of the test, the method followed, each finding with its severity and fix, and a record that findings were closed or their risk accepted. A BERRY9 test delivers an executive report for management, an engineering report with a proof of concept and a CVSS 3.1 score per finding, and a remediation matrix to track closure. See the section on What you get from an ISO 27001 penetration test above.
How often should we run a penetration test for ISO 27001?
The standard sets no fixed interval for testing. Clause 8.2 asks for risk assessments at planned intervals and when significant changes are proposed or occur, so the frequency follows from your risk assessment; agree it with your certification body, and test again after major changes such as a new product, platform or network. See the section on Scope the test with your certification body and risk register above.
Will our certification body accept your report?
Your certification body decides, and no testing firm can promise its view. It helps to send us their expectations, or your consultant's, before scoping, so the test covers the systems in your ISMS scope and the report sets out scope, method, findings and fixes plainly.
Can BERRY9 certify us for ISO 27001?
No. BERRY9 tests systems; it does not audit management systems or issue certificates. ISO/IEC 27001 certificates come from certification bodies after they audit your ISMS, and our report is one piece of the evidence you show them.
Does BERRY9's own ISO 27001 certificate help our certification?
No. Our certificate concerns BERRY9's own management system and tells an auditor nothing about yours. Certification does not pass from a supplier to its customers: your organization is certified only through its own audit.
Do I need a CERT-In empanelled firm for ISO 27001?
Not for ISO/IEC 27001 itself, which says nothing about CERT-In. A CERT-In empanelled auditor becomes necessary when a regulator, a tender or a contract requires one. BERRY9 is not CERT-In empanelled, and if your requirement names one, we tell you before you pay. See the section on Who ISO 27001 testing from BERRY9 suits above.
How much does an ISO 27001 penetration test cost?
With BERRY9, an ISO 27001 penetration test starts from INR 27,000 + 18% GST. The systems, roles and environments inside your ISMS scope set the final figure, which comes in a written proposal after scoping. See the section on What an ISO 27001 penetration test costs above.
Can one test cover both ISO 27001 and SOC 2?
It can, when the systems in your ISMS scope and your SOC 2 system boundary overlap and the test date suits both audits. Ask both auditors before the scope is fixed.