Underwriters scrutinise multi-tenant cloud controls more closely in 2025 because breaches in shared infrastructure drive the largest claims. When a single vulnerability in a public cloud environment exposes multiple tenants, the financial impact multiplies, and insurers respond by tightening coverage terms or excluding cloud-related incidents altogether. For CISOs and IT directors at Saudi firms using public cloud infrastructure, the challenge is no longer whether you have controls in place but whether you can prove them in the format underwriters accept. ISO 27001 cloud security cyber insurance applications now require specific evidence artefacts that demonstrate how your organisation manages the unique risks of multi-tenant environments.
ISO 27001:2022 Annex A 5.23 addresses information security for use of cloud services. The control requires organisations to establish and implement processes for the acquisition, use, management and exit from cloud services in accordance with the organisation's information security requirements. Underwriters interpret this control through a narrow lens: they want to see that you understand the shared-responsibility model, that you have verified your cloud service provider's security posture, and that you have implemented compensating controls for the risks you cannot transfer. General statements about "cloud security" or "vendor management" do not satisfy this requirement. Insurers ask for four specific artefacts, each in a defined format and reviewed at a defined frequency.
The Four Evidence Artefacts Underwriters Request
1. Tenant-Isolation Architecture Diagram
The first artefact is a tenant-isolation architecture diagram that shows how your workloads are logically or physically separated from other tenants in the same cloud environment. Underwriters want to see network segmentation, identity boundaries, and data-storage partitions. The diagram should identify which isolation mechanisms are provided by the cloud service provider and which you have implemented yourself.
Acceptable formats include a network diagram annotated with security zones, a data-flow diagram that highlights tenant boundaries, or a reference architecture that maps your deployment to the provider's shared-responsibility model. The diagram must be current—underwriters typically accept diagrams reviewed within the past twelve months. If your environment has changed since the last review, the diagram is out of date.
The diagram should answer three questions. First, can data from one tenant flow to another tenant without passing through a controlled boundary? Second, can an identity from one tenant access resources in another tenant? Third, if the cloud service provider suffers a control failure, which of your workloads are exposed? If the diagram does not answer these questions, underwriters will request a supplementary narrative or reject the submission.
2. Cloud Service Provider Audit Reports
The second artefact is an independent audit report of your cloud service provider's controls. Underwriters accept SOC 2 Type II reports or ISO 27017 certifications. SOC 2 Type II reports must cover the security and availability trust-services criteria and must be issued within the past twelve months. ISO 27017 is the code of practice for information security controls based on ISO 27002 for cloud services, and certifications must be current.
You must obtain these reports directly from your cloud service provider or through a secure portal the provider maintains. Underwriters will not accept summaries, marketing materials, or attestations that do not include the auditor's opinion and the detailed control descriptions. If your provider does not publish SOC 2 Type II or ISO 27017 reports, underwriters may accept an ISO 27001 certificate for the cloud service, but only if the scope statement explicitly includes the infrastructure you use.
The audit report must cover the specific services you consume. If you use compute, storage and database services but the audit report covers only compute and storage, the gap will be noted. Underwriters may exclude claims arising from the uncovered service or apply a sub-limit. Review the scope statement in the audit report and compare it to your actual usage before you submit it.
3. Encryption-Key-Management Policy Showing Customer-Managed Keys
The third artefact is your encryption-key-management policy, and it must demonstrate that you use customer-managed keys for data at rest in the cloud. Underwriters distinguish between provider-managed keys, where the cloud service provider controls the encryption keys, and customer-managed keys, where you retain control. Customer-managed keys reduce the insurer's exposure because a breach of the provider's key-management system does not automatically compromise your data.
The policy document should specify which data classifications require customer-managed keys, how keys are generated and stored, the rotation schedule, and the process for key recovery in the event of a disaster. Underwriters expect to see that keys are stored in a hardware security module or a dedicated key-management service separate from the data they protect. If you use the cloud provider's key-management service, the policy must show that you control access to the keys and that the provider cannot decrypt your data without your explicit authorisation.
Acceptable formats include a standalone key-management policy or a section within your broader encryption policy. The policy must be approved by an accountable executive and reviewed at least annually. Underwriters will ask when the policy was last reviewed and whether it reflects your current cloud deployments. If the policy describes services you no longer use or omits services you have recently adopted, it signals weak governance.
4. Incident-Response Playbook for Cloud-Specific Scenarios
The fourth artefact is an incident-response playbook that addresses cloud-specific scenarios. Generic incident-response plans that do not distinguish between on-premises and cloud environments are insufficient. Underwriters want to see that you have documented the steps to investigate and contain an incident when you do not control the underlying infrastructure.
The playbook should cover at least three scenarios: unauthorised access to cloud management consoles, data exfiltration from cloud storage, and compromise of a cloud workload leading to lateral movement. For each scenario, the playbook must identify the roles responsible for response, the evidence sources you will examine (such as cloud audit logs or flow logs), the containment actions you can take without provider assistance, and the escalation path to the cloud service provider's support or incident-response team.
Underwriters expect the playbook to reference the specific logging and monitoring services you have enabled. If your playbook describes reviewing "system logs" but you have not enabled the cloud provider's audit-logging service, the playbook is theoretical. Include screenshots or configuration exports that prove the logging services are active and that logs are retained for the period your playbook assumes.
The playbook must be tested. Underwriters will ask when you last conducted a tabletop exercise or simulated incident using the playbook. An untested playbook is treated as non-existent. Document the date of the last test, the scenario tested, and any changes made to the playbook as a result.
File Formats and Review Frequency Insurers Accept
Underwriters accept evidence in PDF, Microsoft Word or Microsoft Visio formats. Architecture diagrams may also be submitted as PNG or JPEG images, provided they are legible when printed on A4 or letter-size paper. Do not submit evidence in proprietary formats that require specialised software to open.
Each artefact must include a document-control footer showing the version number, the date of last review, the date of next review, and the name of the approving authority. If an artefact does not include this information, underwriters may request it separately or reject the submission.
Review frequencies vary by artefact. Tenant-isolation architecture diagrams must be reviewed at least annually or whenever the cloud environment changes materially. Cloud service provider audit reports must be current, meaning issued within the past twelve months. Encryption-key-management policies must be reviewed annually. Incident-response playbooks must be reviewed annually and tested at least once between reviews.
When These Artefacts Become Mandatory
These four artefacts are not requested for every cyber-insurance application. Underwriters escalate their scrutiny when one or more of the following conditions apply.
First, your organisation processes, stores or transmits personal data or payment-card data in a public cloud environment. The potential for a multi-party breach increases the insurer's exposure, and underwriters require proof of isolation.
Second, your organisation uses infrastructure-as-a-service or platform-as-a-service offerings where you share responsibility for security controls with the provider. Software-as-a-service applications, where the provider manages the entire stack, attract less scrutiny unless you store sensitive data in the application.
Third, your organisation is applying for cyber-insurance limits above a threshold the insurer considers elevated risk. That threshold varies by insurer and by market conditions, but requests for limits in the millions of US dollars typically trigger detailed cloud-security questions.
Fourth, your organisation has experienced a cloud-related security incident in the past three years, even if no claim was made. Underwriters review prior incidents during the application process, and a history of cloud compromise raises questions about current controls.
Fifth, your organisation operates in a sector that underwriters consider high-risk for cloud breaches, including financial services, healthcare, telecommunications and government. Sector-specific regulations in the Kingdom—such as the National Cybersecurity Authority's Essential Cybersecurity Controls or the Saudi Central Bank's Cyber Security Framework—often impose cloud-security requirements that align with what underwriters expect.
What a Good Outcome Looks Like
A good outcome is a cyber-insurance policy that does not exclude cloud-related incidents and does not apply a sub-limit to cloud claims. Many policies issued in recent years include exclusions for "failure of a third-party cloud service provider" or sub-limits that cap cloud-related claims at a fraction of the overall policy limit. These exclusions and sub-limits appear when the underwriter is not satisfied that you have mitigated multi-tenant risk.
A good outcome also includes a premium that reflects your actual risk posture rather than the worst-case assumption. Underwriters price cloud risk on a spectrum. At one end, they assume you have no visibility into your cloud environment and no compensating controls; at the other end, they assume you have implemented defence-in-depth and can demonstrate it. The difference in premium between these two positions can be material.
Finally, a good outcome means you do not spend the first weeks of the underwriting process scrambling to produce evidence. Insurers operate on tight timelines, especially at renewal. If you cannot provide the four artefacts within the timeframe the underwriter sets, your application may be declined or the insurer may issue terms based on incomplete information.
How to Prepare Before You Approach the Market
Preparation begins three to four months before renewal or before approaching the market for the first time. Start by confirming that the four artefacts exist, are current, and are stored in a location you can access quickly. If any artefact is missing or out of date, schedule the work to produce or update it.
Next, review each artefact from the underwriter's perspective. Does the tenant-isolation architecture diagram show the boundaries an underwriter cares about, or does it show only the technical details your infrastructure team uses? Does the encryption-key-management policy prove that you control the keys, or does it describe a configuration you plan to implement? Does the incident-response playbook reference the logging services you have actually enabled, or does it assume capabilities you do not have?
Then, verify that your cloud service provider's audit reports are current and that the scope covers the services you use. If the provider has published a new report since you last checked, obtain it. If the provider does not publish the reports you need, consider whether you can migrate to a provider that does or whether you can accept the underwriting consequences.
Finally, test your incident-response playbook. A tabletop exercise that takes two hours will reveal whether your playbook is practical and whether your team knows how to execute it. Document the test and file the documentation with the playbook.
Closing the Gap with a Cyber Insurance Readiness Assessment
If you are uncertain whether your evidence will satisfy underwriters, or if you have identified gaps but are unsure which to prioritise, a structured readiness assessment closes the gap before you go to market. The assessment profiles your business, systems and current or planned cover, then tests the controls underwriters ask about rather than simply asking whether they exist. Quick wins and prioritised fixes are identified, and an evidence pack is prepared for each control. The deliverables include a readiness report and score, the evidence pack, and a remediation plan ranked by underwriting impact. The assessment takes three to four weeks and is designed to improve your position before you approach insurers, ideally three to four months before renewal or before approaching the market for the first time.
