Why ISO 27001 buyers commission penetration testing for the ISMS
If you run an information security management system (ISMS) and your certification body, a customer or your own risk owners expect technical testing evidence, a penetration test is usually the most direct way to show that technical weaknesses were found, judged and treated. It supports Annex A controls A.8.8 and A.8.29 and the risk treatment plan, and it should be sized to the ISMS scope rather than to the whole company. ISO/IEC 27001:2022 does not name penetration testing as a required activity. Instead, it asks the organization to obtain information about technical vulnerabilities, evaluate its exposure to them and take appropriate measures under A.8.8, and to define and run security testing processes in development and acceptance under A.8.29. A penetration test is one way to meet those expectations, and it is often the clearest one, but the standard leaves the method to you.
The test addresses specific risks recorded in your ISMS: exposed services and interfaces inside the certification scope, weaknesses in authentication and access paths, misconfigurations that automated scanning does not reveal, and flaws introduced by new releases before they reach production. Each finding should link back to a risk in your risk register and to a treatment decision, whether that is remediation, acceptance with a recorded owner or a planned change. Testing that produces findings with no traceable treatment tends to raise questions at audit rather than close them.
Before you commission the work, confirm with your certification body how it expects to see A.8.8 and A.8.29 evidenced, whether it accepts a test of a defined subset of systems, and how it treats test reports produced by a provider it has not reviewed. Confirm also which assets sit inside the ISMS boundary and the statement of applicability, because the test scope should follow those, not the company's full estate. Ask your provider to show how it will record scope, methodology and retest results so that the report can be read by an auditor who was not involved in the engagement.
How to scope a penetration test to the ISMS boundary
The ISMS scope statement sets the boundary for the test, and the risk assessment and statement of applicability explain why each component sits inside or outside it. The cards below cover the decisions a buyer should document before a provider writes a single test case.
Systems and applications inside the boundary
Start from the ISMS scope statement and list every application, service and data store it names, then map each to the risk assessment entries that justify its inclusion. Internet-facing portals, administrative consoles and systems that process customer or regulated data are usually the first candidates. Ask the provider to test against that written list, and record any component the scope statement names but the test does not reach, with the reason.
Documented inclusions and exclusions
Every component left out of the test needs a written justification that ties back to the risk assessment or the statement of applicability. Common exclusions include systems owned by another organization, components with no connection to scoped data, and legacy systems being retired. An auditor will test whether the exclusion reasoning holds, so a vague note such as "not in scope" invites questions about gaps in the ISMS.
Cloud accounts, sites and networks
Confirm which cloud accounts, subscriptions, office networks, data center ranges and remote access paths belong to the ISMS. Shared accounts that host both in-scope and out-of-scope workloads need a clear boundary, because testing one may touch the other. Ask the provider to confirm the cloud provider's testing rules apply to each account and to list the IP ranges and domains in the rules of engagement.
Roles, people processes and test accounts
ISO/IEC 27001 scope also covers people and processes, such as help desk password resets, onboarding and access approvals. Where the test includes social engineering or account-based attacks, agree which roles are in scope and which accounts the tester may use. Create dedicated test accounts at each privilege level, disable them after the engagement, and record their creation and removal as evidence.
Third-party hosted components
Hosted SaaS tools, managed databases and third-party payment or identity services often sit inside your ISMS scope but belong to someone else. Check the provider's written testing policy before the engagement and get the vendor's permission where required. Components that the vendor forbids testing should be recorded as excluded, with evidence of the vendor's own assurance report used instead.
Rules of engagement and out-of-scope systems
The rules of engagement set testing windows, permitted techniques, escalation contacts and the stop conditions for production impact. They also name out-of-scope systems the tester must not touch, even if discovered during testing. Agree on how the tester reports discovered assets outside the boundary, since these may need their own risk assessment and ISMS review. Confirm this document is signed before testing begins.
How a penetration test runs from scoping to retest
The sequence turns an ISMS scope and a risk treatment decision into validated findings, a documented remediation path and retest evidence that shows the weaknesses were actually closed. Each stage produces an artifact an auditor can trace back to Annex A controls A.8.8 and A.8.29.
Define the ISMS scope and test objectives
The client and the tester agree which systems, applications, networks, locations and third-party services fall inside the information security management system scope, and which of them are in or near the risk treatment plan. The client's ISMS owner signs off on the boundary, because that boundary decides what the test must cover and what the auditor will sample. The output is a written scope statement listing in-scope assets, excluded assets with reasons, and the test objectives tied to specific risks.
Agree rules of engagement and test windows
Both parties document the permitted techniques, testing hours, source IP addresses, accounts and test data, escalation contacts, emergency stop criteria and handling of any sensitive data the tester may encounter. Cloud, hosting and SaaS providers may impose their own testing rules, so those are checked before work starts. The output is a signed rules of engagement document that defines what counts as an authorized action and who can halt the work.
Gather information about in-scope assets
The tester maps the in-scope environment using the information the client supplies, such as architecture diagrams, asset inventories and network ranges, and then confirms what is visible from outside the organization. This reconnaissance is passive or lightly active and stays within the agreed boundary. The output is a current asset map that the test plan uses to choose targets, and any discrepancy with the client's inventory is reported back to the ISMS owner as an asset management finding.
Test from external and internal positions
Testers assess the organization from the internet and from inside the network, using the access level a realistic attacker or an insider with a standard account might hold. Application, network and identity weaknesses are examined against the methodology agreed in scoping, and the work is logged so every action can be reconstructed. The output is a set of candidate weaknesses with the evidence needed to show their location, conditions and potential impact, all recorded in the test log.
Validate and rank findings
Each candidate weakness is confirmed by the tester so that false positives are removed and the actual exposure is understood, including whether compensating controls already limit the impact. Findings are rated on severity and on their relevance to the ISMS scope and to the risks named in the risk treatment plan. The output is a validated findings list with reproducible descriptions, affected assets, risk ratings and the defensive evidence that supports each rating.
Deliver the report and agree remediation
The tester issues a report that separates an executive summary from technical detail, states the methodology and scope, and lists each finding with its rating and recommended corrective action. The client's owner assigns each finding to a remediation owner and a target date under its vulnerability management process, which feeds the risk treatment plan. The output is an approved remediation plan that links each finding to a tracked action.
Retest corrected findings and record closure
After the client applies fixes, the tester verifies each corrected finding and records whether it is closed, partly mitigated or still open, with the evidence used to decide. Findings that remain open are returned to the remediation plan with an updated risk decision. The output is a retest report and an updated findings register that together show how each technical vulnerability was evaluated and treated, as ISO/IEC 27002:2022 guidance on technical vulnerability management describes.
Which weakness categories auditors and risk owners expect tests to find
This table lists the weakness categories that penetration tests for an ISMS commonly surface, what each looks like inside the ISMS boundary, and why it matters for the risk treatment plan. Use it to check that your test scope covers the places where risk is most likely to sit, then confirm each category against your own asset inventory and risk register.
| Weakness category | What it looks like in the ISMS | Why it matters for the risk treatment plan |
|---|---|---|
| Exposed external services | Internet-facing hosts, portals or remote access endpoints in ISMS scope that are not listed in the asset inventory | Unknown exposure undermines the vulnerability information that A.8.8 requires the organization to obtain and evaluate |
| Weak authentication and session handling | Administrative consoles, customer logins or single sign-on flows that lack strong factors, lockout or proper session expiry | Access controls are often a treatment option in the risk plan, so test results should confirm whether the chosen control works |
| Missing patching evidence | Systems in scope where patch status cannot be shown, or where tested versions differ from those recorded in change records | Auditors look for a link between identified vulnerabilities and remediation records, not only for the patch itself |
| Insecure configuration | Default settings, unnecessary services or verbose error handling on servers, containers or cloud resources inside the ISMS boundary | Configuration weaknesses frequently recur after changes, so they should appear in the treatment plan with an owner and review point |
| Broken access control | Users able to reach records, functions or administrative paths beyond their assigned roles | Access rights tie directly to ISMS controls on user access, so findings here usually require a control owner to respond |
| Segmentation gaps between ISMS and non-ISMS systems | Routes, shared directories or trust relationships that let systems outside the ISMS reach in-scope assets | A gap like this can place out-of-scope systems inside the risk picture, so the scope statement and risk assessment may need revision |
| Insecure development or acceptance practices | Releases that reach production without security testing, or acceptance criteria that omit security checks, relevant to A.8.29 | Findings here point to process controls in the treatment plan, not only to a single defect, so the fix is often a documented change to the lifecycle |
What ISO 27001 controls and related frameworks expect from testing
ISO/IEC 27001:2022 does not prescribe a penetration test by name. Its Annex A controls ask for the outcome. Control A.8.8, Management of technical vulnerabilities, asks the organization to obtain information about technical vulnerabilities, evaluate its exposure and take appropriate measures. Control A.8.29, Security testing in development and acceptance, asks for security testing processes during development and before acceptance. Penetration testing is a common way to evidence both, but the auditor will look at how the organization decided to test, not only whether a report exists.
- Scope against the ISMS: The auditor will compare the test scope with the ISMS scope statement and the assets in the risk assessment.
- Risk treatment plan: Testing frequency and depth should trace back to identified risks and the treatment decisions recorded for them.
- Test plans and reports: Expect review of the plan, the methodology, the tester's qualifications and the findings.
- Remediation records: Evidence should show findings were prioritized, fixed and retested, with any accepted risks approved.
- Organizational structure: The control owner, the review cadence and the link to the vulnerability management process should be documented.
Confirm with your certification body how it expects A.8.8 and A.8.29 to be evidenced, including sampling and the level of detail it wants in test plans.
Clients and other frameworks often ask for penetration testing in more specific terms than ISO 27001 does. Mapping helps you reuse one test for several obligations, but each framework still sets its own scope and frequency. The Center for Internet Security maps its Safeguard 18.2, which asks for external and internal penetration tests at least annually, to ISO/IEC 27001:2022 control A.8.8 and to PCI DSS requirement 11.4.3.
- CIS Safeguard 18.2: Maps to A.8.8, so one annual external and internal test can support both references if the scope matches.
- PCI DSS 11.4.2 and 11.4.3: Require internal and external tests at least every 12 months and after significant changes, by a qualified tester with organizational independence.
- NIST SP 800-53 CA-8: Penetration testing is selected in the high security baseline, with CA-8(1) for independent testers also in that baseline. Lower baselines do not select it.
- Scope differences: PCI DSS scope is set by the cardholder data environment, so a test built for ISO 27001 may need additional segmentation or CDE coverage.
- Evidence reuse: A single report can serve several reviews only if it names the systems, dates and methodology each reviewer needs.
Before reusing a report across frameworks, confirm with each reviewing party that the scope, frequency and tester independence they require are met.
DeployOpen plans, performs and documents security testing and prepares evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Certification to ISO/IEC 27001 is granted by an accredited certification body after its own audit, and the auditor decides whether the controls are effective for the scope you declare. The organization owns the ISMS, the risk decisions and the evidence that goes to the auditor.
- Certification body: Decides the audit scope, sampling and what counts as sufficient testing evidence.
- Your ISMS owner: Maintains the scope statement, the risk treatment plan and the decision on accepted risks.
- Testing provider: Scopes, performs and reports the test under a written agreement, and supports retesting.
- Shared expectations: Ask early whether the certification body expects an independent tester, a named methodology or a specific report structure.
- Timing: Agree when the test will fall relative to the audit window so findings and retests are complete when the auditor reviews them.
Confirm your certification body's expectations for penetration testing, tester independence and report content before the test is commissioned.
What the penetration test report gives your auditor and risk owners
A penetration test report is only useful to an ISO 27001 certification body if it shows how the test was scoped, how findings were rated, and how each finding was closed. The cards below cover each part of the report and what it contributes to A.8.8 evidence, the risk treatment plan and management review.
Executive summary for management review
The summary gives management a short view of the test: what was tested, the overall result, and the findings that need decisions. Management review records should be able to point to this summary when they show that technical vulnerabilities were considered. Check that it names the ISMS scope in the same terms as your statement of applicability, so an auditor can match the test to the systems you claim to protect. Ask the provider to state the test window and date of the report.
Scope and methodology statement
This section records which assets, networks, applications and accounts were in scope, which were excluded, and which testing approach was used. An auditor reads it to decide whether the test covers the ISMS scope boundary or only a convenient subset. Confirm that exclusions are written down with reasons, and that the methodology names the standard or guidance followed. Vague wording such as "security assessment" gives an auditor little to rely on.
Tester qualifications and independence
The report should identify the testers, describe their relevant experience, and state whether they were organizationally independent from the teams that build and run the systems. Independence matters most when the tester also remediates or configures the same environment, because the report then cannot verify that environment on its own. Ask the provider to confirm this statement in writing before the test begins, so the claim is not reconstructed after the fact.
Findings with severity and exploitability context
Each finding should describe the weakness category, the affected component, the evidence observed, and a severity rating with the reasoning behind it. Exploitability context helps risk owners decide whether a finding is an immediate treatment item or a scheduled one under the risk treatment plan. Check that ratings follow a documented scale and that the report explains any adjustment made for your compensating controls. The report describes weaknesses without publishing exploit steps.
Affected assets and remediation guidance
Affected assets link each finding to a named system, host or application that appears in your asset inventory. Remediation guidance tells engineering what to change and gives the risk owner a basis for accepting, mitigating or transferring the risk. This pairing is what connects A.8.8 evidence to the risk treatment plan. Confirm that asset identifiers match your inventory, because an auditor will sample findings and trace them back.
Retest results and closure records
The retest section shows which findings were verified as corrected, which remain open, and which were accepted as risks with approval. Auditors look for this closure trail because a finding without a verified fix or an approved risk decision is an open item. Ask that retest evidence be dated and tied to the original finding identifier. Keep the report, the remediation tickets and the retest together so the chain can be shown during a surveillance or recertification audit.
Summary letter for customers
A short summary letter gives customers and prospects confirmation that a test took place without releasing the full findings. It is usually the document shared in a security review, while the full report stays with the certification body and internal risk owners. Check that the letter states the scope, the test dates and the overall result, and that it does not imply a certification the organization does not hold. DeployOpen does not issue certifications, so the letter should describe the test only.
How retesting and remediation records close the loop for auditors
An ISO 27001 auditor will not accept a penetration test report on its own as evidence that technical vulnerabilities are managed. What closes the loop is a traceable chain: each finding is assigned to a named owner, the fix is made through a recorded change, and a retest confirms the fix worked. Under Annex A control A.8.8, the organization must evaluate its exposure and take appropriate measures, so the auditor will look for that chain for each finding that touched the ISMS scope. Before the test starts, agree the owners and the change process with the people who will fix the findings, including how exceptions and risk acceptances are recorded and who signs them. Ask the tester to deliver findings in a form that maps cleanly to your ticketing system, with the affected asset, the severity rating and the recommended fix for each item.
Keep the test plan, the schedule, the final report, the remediation tickets, the change records and the retest report together in one evidence folder or repository, indexed by finding ID. Auditors typically sample from the risk treatment plan and from the vulnerability management records, then ask to trace a sampled item from the report through to the closed change and the retest. If the pieces live in different tools with no shared identifier, that trace takes time and invites questions. Confirm with your certification body how long it expects records to be retained and in what format it will accept them, because those expectations are set by the certification body and your own policy, not by the standard text alone. Also confirm whether accepted risks need a documented review date.
Repeat testing after significant changes to the ISMS scope, not only on a calendar. A new hosting environment, a change in the services in scope, a major release of an in-scope application or a change in how the risk assessment rates an asset can each make the previous test stale. Tie the trigger to the risk assessment: when a change alters the likelihood or impact of a risk in the treatment plan, record the decision either to retest or to explain why the existing evidence still holds. Keeping that decision on file is often what satisfies an auditor who asks why the last test predates a major change. Agree these triggers in writing with the tester when you scope the work, so the retest is planned rather than discovered during the audit.
How ISMS penetration testing differs across environments
For A.8.8, this environment is tested to confirm that vulnerabilities in customer-facing and internal applications are found, rated and handled. The starting point is the application inventory, filtered to systems that handle information inside the ISMS scope, including the authentication, session and data-handling paths those systems use.
- In scope: staging or production-equivalent instances of ISMS applications, their APIs, authentication flows and role-based access paths.
- Out of scope: third-party SaaS applications you do not operate, unless the contract permits testing and the provider agrees in writing.
- Evidence to keep: the application inventory, the test accounts and roles used, and findings mapped to the affected functions and data.
- Method: an approach aligned with the OWASP Web Security Testing Guide and ASVS, with both unauthenticated and authenticated coverage.
Confirm that every in-scope application has a named owner, a test account and an entry in the statement of applicability that matches what was tested. The Web applications and APIs service page sets out the methodology in more detail.
Cloud testing for ISO 27001 covers the accounts, subscriptions, clusters and identity configurations that host in-scope information. The provider controls the underlying infrastructure, so the test boundary follows the shared responsibility model and the provider's published testing rules. Auditors will expect the cloud estate in the test to match the cloud estate in the asset inventory.
- In scope: ISMS cloud accounts and subscriptions, network exposure, identity and privilege paths, and Kubernetes workloads, namespaces and admission settings.
- Out of scope: provider-managed infrastructure, and any activity the provider's testing policy prohibits without prior approval.
- Confirm first: the provider's current testing rules, any notification steps, and whether intrusive or denial-of-service tests are excluded.
- Evidence to keep: configuration review outputs, the cluster hardening baseline applied, and retest results showing corrected misconfigurations.
Reconcile the account and cluster list against your asset inventory before the test starts, since accounts created outside the normal process are a frequent point of audit questioning. The Cloud service page covers provider-specific scope in more detail.
Infrastructure testing covers the network and identity layer that connects in-scope systems. For A.8.8, the goal is to find exploitable weaknesses in exposed services, internal segments and directory services, and to show that the findings were assessed and handled. Where the ISMS relies on network separation to limit the impact of a compromise, the test should check whether that separation holds.
- In scope: external address ranges in the ISMS scope, internal segments hosting in-scope systems, Active Directory, and remote access and wireless where they are part of the ISMS.
- Out of scope: networks belonging to business units, group companies or subsidiaries that the ISMS does not cover, and any production domain controllers the agreed scope excludes.
- Segmentation: where separation is a control, test whether it is enforced from both sides of the boundary.
- Evidence to keep: an asset list for each address range, a domain and trust map, and findings tied to the affected segment or domain.
Confirm the address ranges and domains against the ISMS scope document and obtain written sign-off for any test that could affect production availability. The Infrastructure and Active Directory service page describes the test types in more detail.
Self-hosted platforms such as identity providers, collaboration suites, source hosting and monitoring tools are often in the ISMS scope because they hold sensitive information or control access to other systems. The assessment covers the deployed version, its configuration, the hosting layer, the identity integration and the administrative interfaces. Findings are measured against the project's own hardening and security guidance.
- In scope: the installed version and configuration, the hosting and container layer, identity and single sign-on integration, backup targets and administrative interfaces.
- Out of scope: the upstream project source code unless separately agreed, and any hosted service run by the project maintainers.
- Version status: confirm the installed version is still receiving security updates, since an unsupported version is a finding in its own right.
- Evidence to keep: a version and configuration baseline, patch records supporting A.8.8, and findings linked to the upgrade or configuration change that closed them.
Confirm which installation and deployment mode are in scope, because a test of one instance does not establish the posture of a second instance with different settings. The Self-hosted open-source platforms service page explains the assessment approach.
Control A.8.29 asks for security testing in development and acceptance, so this environment covers the path from code to release. The test looks at the pipelines that build in-scope software, the secrets and credentials they use, and the pre-production environments where new or changed systems are accepted. Results should feed the acceptance decision for each change, not only the audit file.
- In scope: CI/CD pipelines that build or deploy ISMS software, build secrets handling, artifact integrity and signing, and deployment credentials.
- Out of scope: development work that does not feed ISMS systems or that the ISMS scope excludes.
- Approach: a penetration test of pre-production builds combined with a review of pipeline configuration, with reference to the OWASP CI/CD risks.
- Evidence to keep: pipeline security test records, acceptance test results recorded against each change, and documented remediation for critical findings.
Check that the acceptance criteria for new systems include a security testing gate and that results are recorded against the specific change. The Code and supply chain service page covers source, dependency and pipeline review in more detail.
What your team should prepare before the test starts
Most of the scoping time on an ISO 27001 test goes to finding out what is in the ISMS scope and where it lives, so the first thing to assemble is a written ISMS scope statement paired with a current asset inventory. The scope statement tells the tester which business processes, locations, products and services the certification covers, and the inventory maps those to hosts, applications, cloud accounts, network segments and third-party services. Without both, the provider has to infer boundaries, and the usual result is either a test that misses systems your auditor will ask about or one that reaches into assets outside the ISMS and creates unnecessary risk. Pair the inventory with current network diagrams that show trust zones, firewalls, remote access paths and any connections to shared or hosted infrastructure. Ask your provider which of these artifacts they need in what format before the scoping call, and confirm that your asset register is the one your certification body reviewed. Next, fix the people and access questions before the test window opens. Prepare test accounts at each privilege level the application or platform supports, and agree in advance who will issue them, how they will be disabled, and how credentials will be shared. Name a technical contact for each in-scope system who can answer architecture questions within the working day, and a decision-maker who can approve changes to scope or pause testing. Identify the change freeze windows that cover month-end, release trains and other business-critical periods, and confirm with system owners whether a backup or log retention job, a monitoring alert rule or a security information and event management (SIEM) integration should be coordinated with the test. Testers will generate alerts, and your security operations team should know which ones are expected so that genuine incidents are not dismissed, and the test is not mistaken for one. Finally, agree the rules of engagement in writing before any traffic is sent. The document should record permitted test windows, source IP addresses, prohibited techniques such as denial of service, data handling and destruction rules, escalation paths for critical findings, and the named signatories on both sides. Confirm whether the provider will need your cloud provider's permission, since published testing rules and shared responsibility terms differ by platform. Your ISO 27001 risk treatment plan should also be on hand, because it explains which risks the test is meant to inform, and that link is what makes the report useful as evidence of control A.8.8 rather than only a list of findings.
What to check in a penetration testing provider before you sign
A penetration test for ISO 27001 is only as useful as its scope, its tester and its evidence trail. The checks below cover what to confirm in writing before work starts and what to inspect when the report arrives. Ask every provider the same questions so the answers can be compared directly.
Written scope and methodology
Ask for a written scope statement that names the ISMS boundary, the in-scope systems, IP ranges, applications and user roles, and the explicit exclusions. Confirm the methodology the provider follows and whether it covers both network-layer and application-layer testing. A scope that does not match your statement of applicability or your asset register will leave gaps an auditor can find. Ask how changes to scope are handled during the engagement.
Tester qualifications and independence
Ask who will do the testing, what certifications and experience those individuals hold, and whether they report to a team that runs or operates the ISMS controls being tested. Auditors look for testers who are not marking their own homework. Ask for named roles rather than a company name alone, and confirm that the same people will validate findings and retests.
Sample report, redacted
Request a redacted sample report before you commission the test. Check that it states the scope tested, the dates, the testing approach, the severity basis, the evidence for each finding and the recommended remediation. A report that lists scanner output without validation or context will not show an auditor how exposure was evaluated under Annex A control A.8.8.
Handling of sensitive data
Penetration testers often see credentials, personal data and configuration secrets. Ask how the provider stores evidence, who can access it, how long it is kept and how it is deleted at the end of the engagement. Confirm whether testing will use production data, test accounts or synthetic records, and whether any data will leave your environment or your agreed region.
Insurance and confidentiality terms
Confirm the confidentiality terms, the ownership of the report and the limits of the provider's professional liability and general liability cover. Ask for the certificate of insurance and check that the coverage amounts are acceptable to your procurement and legal teams. Agree in writing who may receive the report, since sharing it with auditors, customers or insurers may require specific permissions in the contract.
Retest terms and finding validation
Agree in writing whether retesting is included, how many rounds are covered and how long after the report the retest window runs. Ask how findings are validated before they are reported, so that false positives are removed and exploitable issues are clearly separated from informational items. Confirm how the provider will document that each corrected finding has been verified.
Common questions about penetration testing for ISO 27001
What does a penetration test for ISO 27001 cost and what drives the price?
The price follows from the written scope, so no fixed figure applies. DeployOpen does not publish a price list, and a quote is built from the systems, applications, networks and testing types agreed in writing. The main cost drivers are the number of in-scope systems and applications, the number of user roles and application flows to test, whether testing is external, internal or both, how many environments are covered, and how much retesting is included. Ask for a quote that lists each test type, the in-scope assets, the reporting format and whether a retest is included. Ask separately whether ongoing testing will be recurring, since annual or change-driven tests are a different commitment from a single engagement.
How long does an ISO 27001 penetration test take to complete?
Duration depends mostly on scope and on how quickly the client team responds. The number of applications, network segments and user roles drives the test effort, and so does the amount of access that has to be arranged before testing starts. Scheduling matters as well, because a test is more useful when it runs against a stable build or environment. Your provider should give a timeline in the written scope, covering preparation, testing, reporting and any retest window. Confirm with the provider how long the report takes to deliver after testing ends, and build that into your certification plan.
What does the client team need to provide for a penetration test?
The client team typically provides the scope definition, a named technical contact, test accounts for each user role, network access details or approved source addresses, and a change window that avoids production disruption. For external tests, you confirm which public addresses and domains are owned by the organization and in scope. For application tests, you provide documentation, the environment URLs and any test data rules. You should also agree with your provider how to handle incidents, who can stop testing, and where sensitive findings are sent. Missing accounts or unclear ownership of assets are the most common causes of delay.
Can our internal team run the penetration test instead of an outside provider?
An internal team can run useful security testing, but the question to answer is whether it can meet the independence and skill expectations your auditor and customers will apply. Most certification reviews look for testers who are qualified and organizationally independent from the teams that build and operate the systems under test. An internal team that also administers the systems may struggle to show that independence, and the test report must still clearly describe method, scope and findings. Some organizations run internal scanning and light testing themselves, then commission an external test for the evidence pack. Confirm the auditor's expectations early, and document how the internal work is planned, performed and reviewed.
Is a vulnerability scan enough for ISO 27001 control A.8.8?
A vulnerability scan is one input, but it is usually not enough on its own. Control A.8.8 in ISO/IEC 27001:2022 asks the organization to obtain information about technical vulnerabilities, evaluate its exposure and take appropriate measures. Scanning helps with identifying known weaknesses, while penetration testing checks whether those weaknesses and the combinations of configuration and logic flaws can be used to reach sensitive assets. Many organizations combine regular scanning, which covers the whole ISMS scope, with penetration testing on critical systems. Your risk treatment plan should state which tool or test answers each risk, so the evidence matches the controls you claim.
How should we size the penetration test to the ISMS scope?
Size the test to the systems that fall inside the Information Security Management System boundary, not to the whole company. Start with the scope statement, the asset inventory and the risk assessment, then list the systems, applications, networks and cloud accounts that store, process or transmit the information covered by the ISMS. Include the trust boundaries, remote access paths and any connections to third parties. Exclude systems that are out of scope, but document the reasoning so the auditor can follow it. Revisit the scope when the ISMS boundary changes, when new critical systems are added or after significant architecture changes.
Does ISO 27001 certification require a penetration test?
ISO/IEC 27001:2022 does not name penetration testing as a mandatory activity. It requires a risk-based approach, with controls such as A.8.8 and A.8.29 that expect technical vulnerabilities to be managed and security testing to be part of development and acceptance. Certification bodies therefore look for evidence that your risk treatment plan selected appropriate measures and that those measures operate. Penetration testing is a common way to show that, especially for internet-facing or high-value systems, but the requirement comes from your own risk decisions and the certification body's assessment. Confirm the expectations with your certification body before you commission work.
How does retesting work after findings are reported?
Retesting checks whether the fixes for reported findings actually close the weaknesses. After the client applies remediation, the tester repeats the relevant tests against the changed systems and records the outcome for each finding. The retest report should show which findings are closed, which remain open and any new issues found during verification. Whether retesting is included depends on the written scope, so ask for it explicitly. Keep the original report, the remediation records, the retest evidence and the risk decisions together, since an auditor will expect to see the full chain from finding to closure.
How DeployOpen scopes, tests, reports and retests ISMS engagements
DeployOpen agrees the test boundary with you in writing before any work starts, so the test maps to the systems inside your ISMS scope and to the risk treatment decisions behind them. Engagements are fixed-scope, and the deliverables are documented so your team can show how A.8.8 and A.8.29 were addressed.
How we scope
- The written scope names the ISMS systems, applications, networks and hosting environments included in the test.
- Scope lists which test types apply, such as external, internal, application or cloud testing, tied to the risk assessment.
- Exclusions, third-party hosted components and testing windows are recorded so the boundary is clear to your auditor.
How we build
- Testing follows a defined methodology agreed at the start, so the approach can be explained to an auditor later.
- Findings are rated against your risk criteria, so exploitable issues are separated from lower-risk observations.
- Test activity is coordinated with your change and incident teams so that engineers can recognize authorized testing.
How we hand over
- The report records scope, method, dates, tested systems, findings and the evidence supporting each finding.
- Remediation recommendations are linked to each finding so your owners can assign and track corrective actions.
- Confirm with your certification body which report format and level of detail it expects for your assessment.
How we support
- Retesting verifies that corrected findings are closed, and the retest report becomes part of your ISMS evidence.
- Ongoing support and continuous testing are available as retainers, aligned with your review cycle and changes.
- Scope changes are documented in writing, so updates to the ISMS boundary are reflected in later tests.
