# Which ISO 27001:2022 Annex A Controls Cyber Underwriters Verify First (and the Three Evidence Formats That Reduce Your Premium)
When a Saudi regulated institution applies for cyber insurance, the underwriter does not read every control in ISO 27001:2022 Annex A. Instead, the underwriter verifies five controls first because historical claims data show these controls predict the frequency and severity of incidents that generate payouts. If the evidence for these controls is missing, incomplete, or presented in a format the underwriter cannot verify quickly, the application moves to a higher-risk tier, the premium increases, or specific perils are excluded before the questionnaire is even scored.
For CFOs and risk managers preparing cyber insurance applications, understanding which ISO 27001 cyber insurance underwriter evidence premium factors matter most—and how to document them—determines whether the institution secures coverage on favourable terms or faces material cost increases and coverage gaps. This article identifies the five Annex A controls underwriters prioritise, the exact evidence each requires, the formats underwriters accept, and the three documentation gaps that trigger exclusions or premium loading.
Why Underwriters Prioritise Five Annex A Controls
Cyber underwriters use actuarial models that correlate specific controls with claims frequency. Five ISO 27001:2022 Annex A controls appear in nearly every underwriting checklist because their absence or weakness is statistically associated with ransomware, business interruption, and data-breach claims:
A.5.24 Information security incident management planning — Underwriters want evidence that the institution can detect, contain, and recover from an incident within hours, not days. Delayed response increases business-interruption losses and the likelihood that the insurer will pay for extended downtime, forensic costs, and regulatory fines.
A.8.8 Management of technical vulnerabilities — This control addresses backup integrity, frequency, and tested restoration. Underwriters know that institutions without verified, offline backups pay ransoms or suffer prolonged outages, both of which generate claims.
A.8.16 Monitoring activities — Continuous monitoring of logs, alerts, and anomalies reduces the time between compromise and detection. Underwriters view monitoring as the earliest predictor of whether an incident will be contained before it becomes a claim.
A.5.23 Information security for use of cloud services — As institutions move workloads to cloud platforms, underwriters assess whether the institution retains visibility and control over data, access, and configuration. Misconfigured cloud storage and unmanaged shadow IT are common causes of data-breach claims.
A.8.7 Protection against malware — Endpoint protection, email filtering, and malware-detection logs demonstrate that the institution can block or detect the initial infection vector in most ransomware and business-email-compromise incidents.
Underwriters verify these five controls before they assess governance, training, or physical security because these five directly reduce the probability that the insurer will pay a claim in the next twelve months.
The Exact Evidence Each Control Requires
For each of the five priority controls, underwriters expect three types of evidence: a policy document, a procedure or configuration standard, and a test record or log sample that proves the control operates as described.
A.5.24 Information security incident management planning
- Policy: An incident-response policy approved by senior management, stating roles, escalation thresholds, and notification timelines.
- Procedure: A documented incident-response plan with step-by-step actions for detection, containment, eradication, recovery, and post-incident review.
- Test record: Evidence of a tabletop exercise or simulated incident conducted within the past twelve months, including the date, participants, scenario, and lessons learned.
Underwriters accept a PDF of the policy, a Word or PDF procedure, and a PDF or spreadsheet summary of the test. Screenshots of calendar invitations or meeting notes are insufficient; the test record must show that technical and business teams practised the plan together.
A.8.8 Management of technical vulnerabilities (backup)
- Policy: A backup policy specifying frequency, retention, encryption, and offline or immutable storage.
- Procedure: A backup schedule and restoration procedure, including the systems covered and the recovery-time objective.
- Test record: A restoration test log from the past six months, showing the date, system restored, time taken, and success or failure.
Underwriters accept a PDF policy, a PDF or spreadsheet backup schedule, and a PDF or screenshot of the restoration test result. If the institution uses a managed backup service, underwriters expect a service report or dashboard screenshot showing successful backups and a recent restore test.
A.8.16 Monitoring activities
- Policy: A security-monitoring policy defining what is logged, how long logs are retained, and who reviews alerts.
- Procedure: A list of monitored events (for example, failed logins, privilege escalation, configuration changes) and the alert thresholds.
- Log sample: A redacted extract of security logs or a SIEM dashboard screenshot covering a recent seven-day period, showing that alerts are generated and reviewed.
Underwriters accept a PDF policy, a spreadsheet or PDF list of monitored events, and a PDF or screenshot of logs. The log sample must include timestamps and evidence of human review, such as analyst notes or ticket references.
A.5.23 Information security for use of cloud services
- Policy: A cloud-security policy stating how cloud services are approved, configured, and monitored.
- Procedure: A cloud-configuration standard covering identity and access management, encryption, logging, and data residency.
- Test record: A cloud-configuration audit or posture-management report from the past six months, showing compliance with the standard.
Underwriters accept a PDF policy, a PDF or Word configuration standard, and a PDF or screenshot of a cloud-security-posture report. If the institution uses multiple cloud providers, underwriters expect evidence for each.
A.8.7 Protection against malware
- Policy: A malware-protection policy specifying endpoint protection, email filtering, and update frequency.
- Procedure: A list of protected assets, the malware-detection tools deployed, and the process for quarantine and remediation.
- Log sample: An endpoint-protection or email-gateway report from the past thirty days, showing detections, blocks, and remediation actions.
Underwriters accept a PDF policy, a spreadsheet or PDF asset list, and a PDF or screenshot of the malware-detection report. The report must show that the tools are active, updated, and generating alerts.
The Three Evidence Formats Underwriters Accept
Underwriters work under time pressure and review dozens of applications each week. They accept evidence in three formats because these formats are easy to verify, version-control, and attach to the underwriting file:
- PDF documents — Policies, procedures, and test reports should be saved as PDF with a document date, version number, and approval signature or metadata. Underwriters can open, annotate, and archive PDFs without compatibility issues.
- Spreadsheets — Backup schedules, asset lists, and monitoring-event tables are clearest in Excel or CSV format, exported to PDF if the underwriter requires a static copy. Spreadsheets allow underwriters to sort, filter, and verify coverage quickly.
- Screenshots — Dashboard views, log extracts, and configuration pages are acceptable as screenshots if they include a visible date, system name, and context. Screenshots must be legible and should be embedded in a PDF with a brief explanation.
Underwriters reject scanned handwritten notes, photographs of screens, and unsecured Word documents because these formats are difficult to verify and easy to alter. If the institution cannot provide evidence in one of the three accepted formats, the underwriter assumes the control is not documented or not operating.
The Three Documentation Gaps That Trigger Exclusions or Premium Loading
Even when the five priority controls are in place, three documentation gaps cause underwriters to increase premiums, apply sub-limits, or exclude specific perils:
Gap one: No test record within the past twelve months — A policy and procedure without a recent test record tells the underwriter that the control exists on paper but may not work under pressure. Underwriters apply a premium loading of ten to twenty per cent or exclude business-interruption coverage if backup-restoration or incident-response tests are older than twelve months.
Gap two: Evidence that does not match the questionnaire answers — If the application states that backups are tested quarterly but the evidence shows only one test in the past year, the underwriter flags the inconsistency and either declines the application or applies a higher rate. Consistency between the questionnaire and the evidence pack is more important than the absolute frequency of testing.
Gap three: Missing evidence for cloud workloads — Many institutions provide strong evidence for on-premises controls but submit no cloud-configuration audit or posture report. Underwriters treat missing cloud evidence as unmanaged risk and either exclude cloud-related losses or apply a separate, higher retention for cloud incidents.
These three gaps are avoidable. Institutions that identify them before approaching the market can close them in weeks, not months, and secure coverage without exclusions or premium penalties.
When an Institution Needs a Cyber Insurance Readiness Assessment
An institution should consider a readiness assessment in three situations:
- Three to four months before renewal — If the current policy is due for renewal and the institution has experienced control changes, incidents, or regulatory findings since the last application, a readiness assessment identifies gaps before the underwriter does.
- Before approaching the market for the first time — Institutions applying for cyber insurance for the first time often underestimate the evidence burden. A readiness assessment prepares the evidence pack and questionnaire answers in advance, reducing the time to bind and improving the terms offered.
- After a declined application or exclusion notice — If an underwriter has declined coverage, applied a large premium increase, or excluded a peril, a readiness assessment shows which controls need remediation and how to present the improvements to the market.
A good outcome is an evidence pack that satisfies underwriter requirements, a remediation plan that closes high-impact gaps quickly, and a readiness score that shows the institution where it stands relative to underwriting expectations.
How the Cyber Insurance Readiness Assessment Works
The Cyber Insurance Readiness Assessment assesses controls the way underwriters do, closes the gaps that drive premiums and exclusions, and prepares the evidence before the institution goes to market.
The assessment follows a four-stage process. First, the firm profiles the institution's business, systems, and current or planned cover. Second, underwriting controls are tested, not just asked about, through document review, configuration checks, and interviews. Third, the firm identifies quick wins and prioritised fixes based on their impact on underwriting decisions. Fourth, an evidence pack and answers for the market are prepared, ready for the broker or underwriter.
The assessment delivers a readiness report and score, an evidence pack for each priority control, and a remediation plan ranked by underwriting impact. The firm reviews the controls insurers ask about, conducts a gap analysis against underwriting expectations, prepares an evidence pack for each control, and identifies prioritised fixes that move premium and terms.
The assessment takes three to four weeks. The firm works with SAMA Cybersecurity Framework, NCA Essential Cybersecurity Controls, and ISO 27001 as the baseline frameworks.
Two common questions arise. First, does the firm sell insurance? No, the firm is not an insurer or a broker and works alongside the institution's broker to improve the institution's position. Second, when should the institution start? Ideally three to four months before renewal or before approaching the market for the first time.
Closing
If your institution is preparing a cyber insurance application or facing renewal, and you want to know which controls underwriters will verify first, what evidence formats they accept, and how to close the gaps that increase premiums, a Cyber Insurance Readiness Assessment provides the roadmap and the evidence pack before you go to market.
