Penetration testing for cyber insurance

Penetration testing for cyber insurance: what the questionnaire is really asking

An insurer's questions about penetration testing are asking whether your external exposure is known, whether weaknesses are found before attackers find them, and whether they get fixed in a reasonable time. When an application, renewal or questionnaire asks about testing, the accurate answer depends on what the form actually asks and what your policy wording says. This page does not assume any insurer requirement beyond what the policy wording and the insurer's own form state. Read the question literally: does it ask whether a test has been performed, how often, by whom, covering which assets, and whether findings were remediated and verified? Each of those is a separate fact you need to be able to support.

The underlying risks are consistent across insurers even when the wording differs. Internet-facing services that nobody has inventoried, unpatched weaknesses in those services, misconfigurations in cloud or identity settings, and slow remediation after a finding are the conditions that tend to turn an incident into a claim. Penetration testing addresses these by exercising your exposed services the way an attacker would and reporting what can actually be exploited. Before you answer, confirm with your broker or the insurer which assets they consider in scope (for example, all internet-facing systems or only a named list), whether they accept internal testing as well, and what date window a test must fall within. DeployOpen does not issue insurance attestations, certificates or underwriting statements. Your insurer, broker or an independent assessor decides what evidence is acceptable for your policy.

What can be in scope for an insurer-driven penetration test

Insurance questionnaires rarely ask for a test by name. They ask what is exposed to the internet, how it is checked, and how fast findings are fixed, so the scope has to map to those questions. The cards below cover the scoping decisions that connect the test to what the insurer will read.

Internet-facing hosts and services

This is the external attack surface: public IP ranges, DNS names, mail gateways, VPN endpoints and any service reachable from the internet. Insurers usually ask whether external exposure is known and tested, so the asset list should come from discovery and be reconciled against the company's own inventory. Ask whether the questionnaire expects a named list, a count, or a statement of method, and confirm which IP ranges belong to the company and which are hosted by a third party.

Cloud accounts and tenants

Cloud accounts, subscriptions and SaaS tenants often hold more exposed services than the data center does. Confirm which accounts are production, which hold customer data, and which are owned by a business unit. Each provider has its own published rules for testing, and the shared responsibility model determines what the company may test and what the provider controls. Insurers may ask whether cloud environments are included, so record the account identifiers in the scope letter.

Web and API applications

Customer-facing portals, login pages, payment flows and public APIs are where many insurance claims begin. Scope each application by name, version and hostname, and state whether authenticated testing with test accounts is included. Insurers often want to know that internet-facing applications were tested for common weakness categories, so confirm whether the questionnaire asks for application-layer testing or only network-level results.

Internal network segments

Internal testing answers a different question: what an attacker who has reached the network could reach next. Scope by segment rather than by building, and include the segments that hold identity services, backups and business-critical systems. Ask the insurer whether internal testing is required, or whether a segmentation statement and vulnerability management records will satisfy the questionnaire. Document any segments excluded and the reason for excluding them.

Remote access and identity systems

Remote access gateways, single sign-on, directory services and multifactor authentication are frequent subjects of cyber insurance questions because they gate access to everything else. Decide whether these systems are tested from outside, from inside, or both, and whether directory administration accounts are in scope. Confirm with the insurer how they describe access controls, since their questions often focus on MFA coverage rather than on the test itself.

Rules of engagement and contacts

Rules of engagement set the testing window, prohibited actions, escalation contacts and what happens if a critical issue is found during testing. Name the people who can stop testing and the people who receive urgent findings, and agree whether third-party hosts require their own permission. Ask the insurer whether the questionnaire asks for a dated test, and keep the signed rules with the scope letter so the test date and authorization can be shown later.

Which weakness categories an insurer's external test question usually points to

This table maps six weakness categories that penetration tests look for to the vulnerability management and remediation themes insurers typically ask about. Read each row as a pairing of what the test examines, why an underwriter cares, and what evidence to keep. Insurer questionnaires vary, so confirm the exact wording against your policy and application.

Weakness category	What the test examines (defensive view)	Why it matters to underwriting questions
Exposed management interfaces	Whether administrative consoles, remote management ports and vendor portals are reachable from the internet and whether they are restricted to approved sources	Insurers ask which services are internet-facing and how exposure is limited, so an unexplained management interface is a common question
Outdated or unsupported software	Version identification of internet-facing and internal systems, and whether vendor-unsupported components are still in use	Questions on patch timeliness and end-of-life software go directly to vulnerability management and risk acceptance records
Weak authentication on remote access	Whether VPN, remote desktop and cloud sign-in paths enforce strong authentication, lockout and multi-factor controls	Remote access is a frequent focus of cyber insurance applications, and evidence of multi-factor coverage is often requested
Misconfigured cloud storage and identity settings	Publicly readable storage, overly broad roles and permissive trust relationships found through configuration review alongside external testing	Underwriters ask how cloud configuration is governed and monitored, so test findings here support questions on configuration management
Flawed access control in web applications and APIs	Whether users can reach data or functions outside their authorization, tested against the OWASP Top 10 and ASVS categories	Questions on application security and customer data exposure depend on whether authorization defects were found and corrected
Weak segmentation between zones	Whether network boundaries between production, corporate, backup and management zones hold when tested from a lower-trust position	Insurers ask how a single compromise is contained, so segmentation test results support answers on lateral movement and blast radius

How a penetration test is run from scoping to retest

The sequence turns an insurer's question about external testing into a documented test, a prioritized list of findings and retest evidence that shows the exposure was actually reduced. Each phase has a defined output, so the policyholder can show what was tested, what was fixed and what remains.

Agree scope and rules of engagement in writing
Before any testing starts, the client and the provider agree in writing which external addresses, domains, applications, internal segments and cloud accounts are in scope, which are excluded, what test types are allowed, and when testing windows run. The rules of engagement name a client contact, an escalation path for critical issues and a process for stopping a test. The output is a signed scope document that the insurer or broker can read, and it should state which systems are internet-facing because insurer questions usually focus on that exposure. Confirm with your broker whether the policy wording or application form names any specific test type or frequency, since requirements vary by insurer and policy.
Map exposure and run agreed tests
The tester first identifies what is reachable from the internet or from the internal network position agreed in scope, such as hosts, services, web applications, APIs and remote access points. Testing then proceeds against that inventory using the methods in the scope document, combining automated scanning with manual analysis to check whether weaknesses can be used to reach data or systems. Activity is logged, and any unexpected impact on a live system is reported to the client contact at once. The output is a set of raw observations and a test log that records what was attempted, when and from where.
Validate and rate each finding
Each candidate issue is checked by hand to remove false positives and to confirm whether it is exploitable in the client's environment, not just present in a software version. The tester then rates severity, usually with a documented method such as CVSS combined with business context, and records the affected asset, the conditions required and the effect on confidentiality, integrity or availability. The output is a validated findings register in which every item has evidence, a rating and a rationale, so the client can separate critical items from informational ones.
Deliver the written report
The provider issues a report that describes the scope, the methodology, the test dates, the testers' qualifications where the client asks for them, a summary for leadership and a technical section for each finding with reproduction at a defensive level, impact and recommended remediation. The report should avoid exploit code and step-by-step payloads so it can be shared more widely. The output is a dated final report, and the client should confirm whether a separate summary letter is needed for the broker or insurer, because full reports usually carry sensitive detail.
Track remediation under the vulnerability process
The client assigns each finding to an owner, sets a remediation plan based on the rating, and records any risk acceptance or compensating control for items it does not fix. This is where the requirement to manage technical vulnerabilities, described in ISO/IEC 27001:2022 Annex A control A.8.8, meets the test: the organization must obtain information about vulnerabilities, evaluate its exposure and take appropriate measures. The output is a remediation tracker with owners, dates and status, plus approvals for any accepted risk, which the client keeps as part of its vulnerability management records.
Retest to confirm fixes
Once the client reports that fixes are in place, the tester repeats the relevant checks to confirm each finding is closed or to record that it remains open. A retest is limited to the findings in question, but the tester may also check whether a fix introduced a new exposure in the same area. The output is a retest letter or appendix listing each finding with its status and the evidence reviewed. Retest records give the insurer or broker a clearer picture than the original report alone.
Schedule the next annual test
The engagement closes by setting the next test date and the trigger for an earlier one, such as a significant change to internet-facing systems. CIS Safeguards 18.2 and 18.5 describe external and internal penetration tests at least annually, and the next cycle should be booked before the current report is filed. The output is a dated calendar entry and a short record of what changed since the last test, which the client can present to the insurer at renewal. Confirm the exact cadence the policy requires with the broker.

What drives the cost and duration of an insurance-driven test

This table compares the cost components of an insurance-driven penetration test, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to build a like-for-like quote request, since no DeployOpen prices or durations appear on this page.

Cost component	Who is paid	One-time or recurring	What drives it
Scoping and rules of engagement	Testing provider, for agreeing assets, exclusions and test windows	One-time per engagement	Number of external IP addresses and domains, number of cloud accounts, and whether third-party hosted assets need owner consent
External network testing	Testing provider	Recurring if the insurer or policy year requires an annual test	Count of internet-facing IP addresses, hosts and services, and how many are in scope for a single policy year
Internal network and Active Directory testing	Testing provider	Recurring, usually tied to the same annual cycle	Number of internal segments, sites, domain controllers, and whether a privileged-access or assumed-breach scenario is included
Application and API testing	Testing provider	Recurring when applications change or the annual cycle applies	Number of applications, roles or user types tested, authenticated versus unauthenticated depth, and API endpoint count
Cloud configuration review	Testing provider	Recurring, often alongside the annual test	Number of cloud accounts or subscriptions, services in use, and whether a configuration review or only a test is requested
Test depth and methodology	Testing provider	Set per engagement	Whether testing is a credentialed scan with manual validation or a full manual test, and the time allowed for exploitation analysis
Reporting and evidence pack	Testing provider	One-time per report, repeated per cycle	Whether the insurer or broker needs a summary letter, a full technical report, or an executive summary with a remediation tracker
Retest after remediation	Testing provider	One-time per retest round	Number of findings to verify, whether retests are limited to critical and high findings, and how many rounds are expected
Remediation support bought separately	Client's internal team or a separate provider	Varies, often recurring if ongoing	Whether the client wants hands-on fixes, which are outside the test itself and billed separately if bought from DeployOpen or another firm

How the policy wording, the questionnaire and adjacent frameworks shape the answer

The policy wording and its endorsements are the only binding statement of what the insurer requires. A questionnaire is usually a underwriting input, and a framework is a standard you may or may not be assessed against, so neither overrides the policy. Before you commission a test to satisfy cover, ask your broker to identify any clause that mentions testing, scanning, patching, or security conditions, and to confirm whether those conditions are warranties, conditions precedent, or disclosure obligations. Ask whether a condition applies at inception, at renewal, or after a claim.

Testing or scanning clauses: Check whether the wording names penetration testing, vulnerability scanning, or a required frequency, and whether it specifies who must perform the work.
Endorsements and schedules: Endorsements can add or change conditions. Read them with the main wording rather than in isolation.
Timing and notification: Confirm the deadline for providing evidence and whether a material change, such as a new internet-facing system, must be reported.
Remediation expectations: Establish whether the wording requires findings to be fixed within a set period, and how it treats findings you accept as residual risk.
Definitions: Confirm how the policy defines the insured systems, which determines the scope a test should cover.

Check every clause with your broker and insurer in writing before relying on a test result for cover.

What the client receives and which parts answer insurance questions

A penetration test produces several separate artifacts, and each answers a different part of an insurer's questionnaire. Keep them together as one evidence set, because a questionnaire answer about cadence or remediation is only as strong as the document behind it.

Written scope and rules of engagement

This document fixes which external IP ranges, domains, applications and internal segments are in scope, the test window, the testing methods allowed, and the emergency contacts. For insurance purposes it shows that the test had a defined boundary, which is what a reviewer checks when a questionnaire asks which assets were tested. Check that the scope lists the same assets your policy declaration and asset inventory describe, and note any exclusions in writing.

Full technical report with severity ratings

The full report lists each finding with its severity rating, affected assets, evidence, business impact and recommended fix, plus the test dates and tester roles. Insurers and their technical reviewers often ask for this level of detail when they want to confirm that external testing actually took place and covered the stated assets. Ask the provider to explain its severity method, since a rating scale that is not defined makes findings hard to compare across years.

Executive summary for board and insurer discussion

The summary condenses scope, overall risk, the number of findings by severity, and the priority actions in plain language. It suits board reporting and first-round insurer conversations, where a reader needs the picture without the technical detail. Confirm with your broker or insurer whether a summary alone is accepted, since some underwriting teams ask for the full report during claims or renewal review.

Remediation tracker

The tracker records each finding, its owner, target date, status and the evidence used to close it. It is the record that answers questions about how quickly exploitable weaknesses were fixed, so it should be kept current after the report is issued. Keep the tracker under version control and retain closed items with their closure evidence, not only open items.

Retest results

Retesting confirms whether the corrected findings are actually closed and records any that remain open. This is the document that shows remediation was verified rather than assumed, which matters when a questionnaire asks about follow-up testing after a finding. Agree in the scope whether retest is included, how many rounds are covered, and what evidence the tester returns for each closed item.

Summary letter on request

A summary letter is a short statement from the tester that the test took place, its dates and scope, and that findings were reported. Clients use it when they want to share proof of testing without disclosing the full report to a broker, customer or insurer. Ask the tester what the letter states and does not state, and do not treat it as a substitute for the report if an insurer requests the underlying detail.

What your team should prepare before the test starts

Preparation decides how quickly scoping closes and how defensible the evidence is when the policy renews. Before the test starts, your team should name a technical contact who can answer questions about the in-scope hosts and applications, and an escalation contact who can approve a change of scope or stop testing if a system degrades. Both names should appear in the written scope so the tester knows who to call at 2 a.m. and who can sign off on out-of-hours work. Agree the asset inventory in writing as well: external IP ranges, domains, cloud accounts, and the internal segments in scope, with a named owner for each. An inventory that matches what the insurer's questionnaire describes as your external footprint makes the report easier to map to the questions you were asked.

Next, prepare the access and the calendar. For web applications and APIs, provide test accounts at each privilege level the application supports, with the roles documented, so authenticated testing covers what an attacker with a valid login could reach. Confirm approved testing windows with operations staff and record them in the rules of engagement. Where your hosting or cloud provider has testing rules that require notice or pre-approval, check those rules and make the notification yourself or confirm who will; a provider's rules govern what the tester may do in its environment, and your contract with the tester does not override them. If production stability is sensitive, agree a change freeze for the window so the test results reflect a stable system rather than a moving target.

Finally, decide who owns remediation before a single finding exists. Name the person who will triage findings, the owners who will fix each category of issue, and the approver who will accept a risk where a fix is not feasible. Set a target for critical and high findings that you can defend to the insurer, and keep the retest in the calendar. Insurers and their reviewers tend to ask whether exploitable findings were fixed and verified, so a clear owner and a dated retest are what turn a report into evidence. Ask your tester to confirm in the proposal how the report will record each finding's status, and keep the change tickets, patch records and retest results together from the start.

What to check when choosing a penetration testing provider

Insurers, auditors and customers will read your test report as evidence, so the provider's scope, people, method and reporting need to hold up under that scrutiny. The checks below help you compare providers on the points that make a report usable as evidence.

Written scope before work starts

Ask for a written scope that names the external IP ranges, domains, applications, cloud accounts and internal segments in the test, along with what is excluded. Your policy wording or insurer questionnaire rarely lists assets, so the scope document is what later shows which systems were covered. Confirm that the scope is agreed and signed before testing begins, and that any change to it is recorded in writing.

Named testers with relevant experience

Ask who will do the work, not only which firm is contracting. Request the names or roles of the testers, the technology they have tested in the last few years, and how the lead tester reviews findings. For a cloud-hosted web platform, for example, ask whether the team has tested that stack before. Confirm that staffing will not change without notice to you.

Methodology that cites public standards

A credible method names the public standards it follows, such as the OWASP Web Security Testing Guide for web applications or the PTES for network work, and explains how each phase is performed. Ask the provider to describe its approach to authenticated testing, automated scanning and manual validation. Methodology that only says "industry best practice" gives an insurer or auditor nothing to check.

Report separating validated findings

Ask for a sample report before you sign. A useful report separates validated findings, where the tester confirmed exploitability or impact, from observations and hardening suggestions. Each finding should carry its affected asset, evidence, severity rationale and recommended fix. Mixing scanner output with confirmed issues makes it hard to show a remediation trail, which is what most questionnaires ask about.

Retest included or priced separately

Remediation is where insurers and customers look for evidence, so clarify early whether one retest of corrected findings is included in the fee or quoted separately. Ask how long after the original report a retest is available and what form its output takes, such as a letter listing closed and open findings. Retest terms affect both cost and the timing of your next questionnaire response.

Independence from remediation work

Ask whether the provider will also implement, configure or operate the fixes it reports on. If it does, the test loses some of its value as independent evidence, because the same team is grading its own work. Confirm the boundary in writing. Also ask providers to confirm any certifications or memberships in writing rather than assuming them, and check each one against the issuing body.

Questions buyers ask about insurance penetration tests

How much does a penetration test for cyber insurance cost?

The cost follows the written scope, and DeployOpen does not publish a price list. The main drivers are the number and type of in-scope targets (external addresses, web applications, APIs, internal network segments, cloud accounts), the depth of testing, how much access the tester receives, and whether a retest is included. Most of the fee pays for tester time, so a larger or more complex environment takes longer. A penetration test is typically one-time per engagement, but insurers and frameworks often expect it to recur, so budget for the annual cycle and for retests after significant changes. Ask for a quote that itemizes testing, reporting, retest and any remediation support as separate lines.

How long does it take to get the penetration test report?

The timeline depends on the scope, how quickly access and test accounts are provided, and how many review cycles the report needs. DeployOpen agrees timelines in the written scope before work starts, so confirm the kickoff date, testing window, draft report date and final report date in that document. Build in time for the client to review the draft, challenge findings and confirm severity ratings. If your policy renewal or an insurer submission has a fixed date, work backward from it and confirm with your broker how much lead time the submission needs.

What does a penetration test need from our team?

The engagement needs a named technical contact, a confirmed asset list, and a decision-maker who can approve scope changes. Most tests also need test accounts at the privilege levels in scope, network access or VPN credentials, agreed testing windows, and a change freeze on the target systems if production stability matters. Your team should also be available to answer questions during testing and to tell the tester about known sensitive systems. Name an owner for remediation before the test starts, because findings that no one owns are the most common reason evidence goes stale.

Can our own team run the penetration test internally?

Whether an internal team can perform the test depends on what your insurer or broker accepts, and that is set out in the policy wording or the submission requirements, so confirm it with them before you decide. Internal staff can run vulnerability scanning and fix findings, but an independent tester usually carries more weight as evidence. Where a framework applies, it may set its own rules: PCI DSS, for example, requires that the tester has organizational independence. If you do use internal staff, record their qualifications, the methodology they followed, the scope and the date, and keep the same evidence you would expect from an external report.

Will an automated vulnerability scan satisfy an insurer question?

A scan and a penetration test answer different questions, so confirm with your broker whether the questionnaire asks for one, the other, or both. Automated scans identify known vulnerabilities and misconfigurations across many assets, and they support questions about vulnerability management and patch cadence. A penetration test adds human analysis of whether weaknesses can be chained, how authentication and business logic behave, and whether the findings are exploitable in your environment. Frameworks often ask for both: CMMC Level 3, for example, names automated scanning tools alongside testing by subject matter experts. Keep scan reports with dates, scope and remediation tracking either way.

How often should we retest after a penetration test?

Retest whenever a finding is corrected, and repeat the full test on a regular cycle. PCI DSS requirement 11.4.2 sets a baseline of internal and external tests at least every 12 months and after significant changes, and requirement 11.4.4 requires corrected exploitable findings to be verified by repeated testing. Insurers may set a different cycle or none at all, so confirm the expectation in your policy wording. Between full tests, retest after significant architecture changes, new internet-facing services, or a critical finding. Agree in the scope whether retest is included and how many verification rounds it covers.

How do we answer a questionnaire when a finding is still open?

Answer accurately: state that the finding exists, its severity, the affected scope, the owner, the target date and any interim controls that reduce exposure. Do not describe the finding as closed until a retest or verification confirms the fix. Keep dated records of remediation progress, compensating controls and the retest result so you can show how the answer changed over time. Because the wording of a questionnaire can create a representation to the insurer, have your broker or counsel review any answer that involves an open critical or high finding before you submit it.

How DeployOpen scopes, tests, reports and retests

DeployOpen approaches penetration testing for cyber insurance as a fixed-scope engagement agreed in writing before work starts. The written scope sets which systems, external and internal exposure, and test types are covered, so the evidence produced can be matched to the questions your insurer or broker actually asks. Each step is documented so the output is usable by your team and by the underwriter reviewing it.

How we scope

Confirm the exact policy wording and any insurer questionnaire items before fixing the test boundary.
Define external IP ranges, domains, internet-facing applications and internal segments in the written scope.
Agree test types, rules of engagement, tester access and named contacts before testing begins.

How we test

Run external and internal penetration tests against the agreed scope using a documented methodology.
Cover application and network layers where the scope includes them, with findings tied to affected assets.
Record exploitable conditions and proof of impact in a way your technical team can reproduce and fix.

How we report and hand over

Deliver a written report with an executive summary, technical findings, severity ratings and remediation guidance.
Document scope, dates, methodology and tester details so the report can be shared with an underwriter.
Keep a findings register that tracks remediation status, owners and evidence of each correction.

How we retest and support

Retest agreed findings after remediation and issue written confirmation of which items are closed.
Ask your insurer whether it accepts retest letters, and confirm the format before the engagement starts.
Ongoing support, upgrades and continuous testing are available as a retainer if your testing cadence must repeat.