Cyber Resilience
Cloud security risks: the ones that are yours, not your provider's
Seven cloud risks on your side of the shared responsibility model, each with the control and the evidence regulated customers will ask for.
Key takeaways
The biggest cloud security risks for a UK SaaS firm sit on the customer's side of the shared responsibility model: misconfiguration, weak identity and key management, SaaS sprawl, logging gaps, insecure APIs, data location and exit, and dependence on one provider. Financial services customers must manage these risks through their suppliers under FCA FG16/5 and DORA, so they ask for evidence of each.
- Shared responsibility model
- The NCSC says the provider almost always maintains the availability and physical protection of its servers, while the customer always configures the service securely and decides which data goes in.
- FCA FG16/5
- FCA guidance for firms outsourcing to the cloud. Firms keep full accountability for their regulatory responsibilities, cannot delegate it to the provider, and should hold documented, fully tested exit plans.
- DORA Article 30
- DORA has applied since 17 January 2025. Article 30 requires EU financial entities' ICT contracts to state where data is processed and stored, and to cover data return and termination rights.
- Cloud log retention
- The NCSC advises keeping your most important cloud logs for at least six months, because it can be months before an incident is detected.
Your largest prospect's third-party risk team has sent a cloud security questionnaire, and question after question asks for evidence you are not sure you hold. This list covers the cloud security risks that are yours to manage, not your provider's, for UK SaaS firms of 25 to 100 people selling into financial services.
The biggest cloud security risks sit on the customer's side of the shared responsibility model: misconfigured storage and services, weak identity and key management, and missing logs. The provider secures the infrastructure; you secure how it is configured and used. Regulated customers will ask for evidence of each.
The seven risks below were chosen against one test. Each sits on the customer's side of the model for a firm hosted on AWS, Azure or Google Cloud. Each is also something an enterprise or financial services customer can ask you to evidence. Risks the provider carries, such as the physical security of its data centres, are left out.
What are the biggest cloud security risks for a UK SaaS firm?
The biggest cloud security risks for a UK SaaS firm are seven customer-side failures: misconfiguration, weak identity and key management, unmonitored SaaS sprawl, logging gaps, insecure APIs and integrations, unplanned data location and exit, and dependence on one provider. Each has a control you own and evidence a customer can ask to see.
| Risk | Whose responsibility | The control | The evidence customers ask for | ISO 27001 reference |
|---|---|---|---|---|
| 1. Misconfigured storage and services | Customer | Secure baselines and guardrails that block risky changes | Configuration standard and drift reports | A.8.9 |
| 2. Weak identity and key management | Customer, using the provider's tools | Least-privilege roles, MFA and managed secrets | Access review sign-offs and key management procedure | A.5.15, A.8.24 |
| 3. Unmonitored SaaS sprawl | Customer | A register of approved SaaS, each with an owner | SaaS inventory and leaver records | A.5.23 |
| 4. Logging gaps | Shared: the provider supplies logs, the customer keeps and reviews them | Protected, retained activity logs with alerting | Retention settings and alert review records | A.8.15, A.8.16 |
| 5. Insecure APIs and integrations | Customer | Managed service identities instead of long-lived keys | Interface inventory and penetration test summary | A.8.26 |
| 6. Data location and exit | Shared: the provider offers regions and export, the customer chooses and plans | Recorded data locations and a tested exit plan | Data location statement and exit test record | A.5.23 |
| 7. Dependence on one provider | Customer | A concentration assessment and tested recovery | Recovery test results and the recorded decision | A.5.30 |
What does the shared responsibility model mean for your cloud risks?
The shared responsibility model splits cloud security between provider and customer. The NCSC says the provider will almost always look after the availability and physical protection of its servers. You are always responsible for checking the service meets your needs, configuring it securely and deciding which data goes into it.
The NCSC's guidance on the shared responsibility model adds that the split depends on the type of service. You hold the most on infrastructure services and the least on SaaS.
| Security layer | Who owns it |
|---|---|
| Data centres, hardware and server availability | Provider |
| Operating systems and platform software | Customer on infrastructure services; mostly the provider on platform and software services |
| Configuration of the services you use | Customer |
| Identities, access and keys | Customer, using the provider's tools |
| The data you store and where it lives | Customer |
| Monitoring of your own use | Customer, using the provider's logs |
ISO 27001 treats the customer side as a control in its own right: Annex A 5.23 covers information security for the cloud services you use, from choosing them to leaving them.
A provider's certificate covers the provider. It says nothing about how you configured what you rent.
Which cloud security risks are yours to manage?
Seven cloud security risks sit with you rather than your provider. Each item below gives what it is, when it matters and what to do, with the evidence a customer's third-party risk team will usually ask for. Most need a written standard, a named owner and a record that the control ran, not new technology.
1. Misconfigured storage and services
What it is. Cloud resources set up in a way the provider allows but your risk appetite does not: storage open to the internet, default settings left in place, test environments holding live data.
When it matters. From the first deployment and at every change. The risk grows with every engineer who can change production by hand.
What to do. Write a configuration baseline for each service you use and deploy through infrastructure as code. The NCSC's guidance on using a cloud platform securely advises using the provider's native guardrails to stop changes such as exposing data storage to the internet before they happen. Keep the drift reports: they are your evidence.
2. Weak identity and key management
What it is. Too many people and services with too much access to the cloud console, and API keys, passwords or encryption keys stored where they can leak. The NCSC says a service identity's credentials should be a random, high-entropy secret, not a password.
When it matters. Always, and most as the team grows. Access granted to early engineers is easy to forget and rarely reviewed.
What to do. Grant access through roles under your access control policy, require MFA for all console access and keep secrets in the provider's managed secrets service. Review access on a fixed cycle and keep the sign-off. This item covers the controls customers check, not how attackers abuse identities.
3. Unmonitored SaaS sprawl
What it is. SaaS applications adopted by teams without a security review, each holding company or customer data in a tenancy nobody configures or offboards. The NCSC's guidance on using SaaS securely reminds customers they remain responsible for the configuration specific to their use of the application.
When it matters. As soon as customer data can reach a tool outside your core platform, such as the support desk or an AI assistant.
What to do. Keep a register of approved SaaS with an owner, the data it holds and whether it uses single sign-on. Connect each application to your identity provider, so a leaver loses access everywhere at once.
4. Logging gaps
What it is. Activity logs that are switched off, incomplete, short-lived or editable by the people they record. The NCSC advises keeping your most important logs for at least six months, because incidents can take months to detect.
When it matters. On the day of an incident, or when a customer asks how you would detect one.
What to do. Collect provider, service and application logs in one place, restrict who can change them and set retention to match your contracts. Review alerts against a written process, as Annex A 8.16 expects for monitoring.
A log you never collected cannot answer the question an incident asks.
5. Insecure APIs and integrations
What it is. The interfaces your product exposes to customers, and the integrations you connect to other services. Each one is a route to your data. The NCSC prefers the provider's own service identity features to primitive methods such as API keys or passwords.
When it matters. When you publish an API, add a third-party integration or let a customer connect their systems to yours.
What to do. Keep an inventory of external interfaces and integrations, authenticate each with a managed service identity and include the API in your penetration test scope. Customers will ask for the latest test summary and how the findings were closed.
6. Data location and exit
What it is. Not knowing which regions hold customer data and backups, or how you would move both to another provider. DORA requires a financial entity's ICT contracts to state where data is processed, including where it is stored.
When it matters. When a customer asks where its data lives, when you add a region or a sub-processor, and when a contract includes exit and return-of-data clauses.
What to do. Record data locations for each service, including backups and sub-processors, and tell customers before they change. Write an exit plan that shows how data would be returned and deleted, then test it.
An exit plan nobody has tested is a hope, not a plan.
7. Dependence on one provider
What it is. Your whole service, and so part of your customers' service, depending on one provider, one region or one account. The FCA's FG16/5 asks firms to monitor concentration risk and consider what they would do if the provider failed.
When it matters. When a single regional outage would take your service down, and when your customers' regulators treat you as an important supplier.
What to do. Work out which failures would stop the service, decide which you accept and test recovery for the rest, for example into a second region. Record the decision; customers ask for the reasoning as well as the design.
What must financial services customers ask cloud suppliers under FG16/5 and DORA?
Financial services firms stay accountable for what they outsource, and they meet that duty through their suppliers. FCA guidance FG16/5 and DORA Articles 28 to 30 tell them to assess suppliers, secure audit and data access rights, plan exit and watch concentration. Those duties reach a UK SaaS supplier through contract terms and due diligence questionnaires.
FG16/5 is the FCA's guidance for firms outsourcing to the cloud and other third-party IT services. It says firms "retain full accountability" and "cannot delegate responsibility to the service provider". It asks them to secure access to data for themselves, their auditors and the regulator, and to hold exit plans that are documented and fully tested. The FCA also says new rules for firms to notify it of material third party arrangements apply from 18 March 2027.
The FCA says banks, building societies, payment and e-money institutions and some investment firms follow the EBA outsourcing guidelines instead. FG16/5 remains relevant to all other firms.
DORA (Regulation (EU) 2022/2554) has applied to EU financial entities since 17 January 2025. Three articles shape what they ask you:
- Article 28 requires a register of all ICT service contracts and exit strategies for services supporting critical or important functions.
- Article 29 requires an assessment of concentration risk before contracting for services that support critical or important functions, including whether the provider is easily substitutable.
- Article 30 sets minimum contract terms: the services described, data locations, access to and return of data, help during incidents and termination rights. Contracts for critical or important functions add unrestricted access, inspection and audit rights and a transition period on exit.
DORA binds the financial entity, not you, but the financial entity must write these terms into its contract with you. Expect audit rights, data location clauses and exit terms in the first draft. Your own supplier management, set out in Annex A 5.19, is what their due diligence will test.
How do the NCSC cloud security principles apply to your firm?
The NCSC's 14 cloud security principles are the UK reference for judging a cloud service. They help you choose a provider that meets your security needs, and the NCSC notes that you separately need to configure the services securely. Four of the principles point straight at the customer side, and your customers can apply all 14 to you.
The cloud security principles most relevant to the risks above are:
- Principle 9, secure user management (items 2 and 3);
- Principle 10, identity and authentication (items 2 and 5);
- Principle 13, audit information and alerting for customers (item 4);
- Principle 14, secure use of the service (item 1).
Read them from both sides. When a customer uses a cloud service run by a supplier, the NCSC says the supplier must give it confidence that the application and the platform underneath meet its security needs. For your customers, you are that supplier. Some providers publish a written response to the principles; a SaaS firm can do the same and answer a large part of every questionnaire once.
How to use this list
Start with items 1, 2 and 4. They are the three in the opening answer and the ones a cloud security questionnaire is most likely to probe. Then work through items 3 and 5. Items 6 and 7 become urgent when a financial services customer sends its contract.
For each item, name an owner, write down the evidence that proves the control runs and set a review date. Keep the evidence where your sales team can share it under NDA, so the next questionnaire is answered from records, not memory. If you hold ISO 27001, the reference column shows where each item sits in your Statement of Applicability.
Your cloud providers are suppliers too. We recommend assessing them the same way you assess everyone else, and our supplier security policy template sets out how.
Frequently asked questions
Both, in different layers. The provider secures its data centres and hardware; the customer always secures configuration, access and data. The NCSC advises delegating as much as you can, for example making the provider responsible for security updates to all software you did not write.
No. A provider's ISO 27001 certificate or SOC 2 report covers the provider's share of the model. FG16/5 notes that assurance from international standards is unlikely to be sufficient on its own for critical or important operational functions or material outsourcing. Your customers will still ask for evidence of your own configuration, access and logging controls.
Not directly, in most cases. Most of DORA's duties fall on EU financial entities. An ICT provider is overseen directly only if the European Supervisory Authorities designate it as critical under Article 31. The criteria start with the systemic impact of its failure. A UK SaaS firm selling to EU banks, insurers or investment firms will usually meet DORA through Article 30 contract terms and the due diligence before them.
Usually a configuration standard, access review records, logging and retention settings, a penetration test summary, a statement of data locations and an exit plan. Financial services customers also write audit and data access rights into the contract. Larger customers often ask for an ISO 27001 certificate or SOC 2 report covering your own service, not your provider's.
