What are the principles of a secure cloud architecture?

A secure cloud architecture starts from the shared responsibility model and then tests the provider against a fixed set of questions. The UK National Cyber Security Centre (NCSC) publishes 14 Cloud Security Principles for that purpose. They help you choose a provider. Configuring the service securely is a separate job that stays with you.

What do the 14 principles cover?

The NCSC says the principles apply to cloud platforms and to software as a service. For each, it describes the goal, the differentiators that increase confidence, ways a provider might meet it and what you should consider. They fall into themes:

Protecting data and assets

• Principle 1, data in transit protection: data is protected from tampering and eavesdropping inside and outside the cloud, through encryption, service authentication and network protections.
• Principle 2, asset protection and resilience: data and the assets holding it are protected against physical tampering, loss, damage or seizure, including the legislation your data is subject to.
• Principle 3, separation between customers: a malicious or compromised customer cannot reach another's service or data.

Governing and operating the service

• Principle 4, governance framework: the provider coordinates security through a governance framework.
• Principle 5, operational security: vulnerability management, protective monitoring, configuration and change management, and incident management.
• Principle 6, personnel security: where provider staff can reach your data, you need confidence in their trustworthiness and in technical controls that audit and constrain them.
• Principle 7, secure development: a sound software development lifecycle with an automated, audited pipeline.
• Principle 8, supply chain security: the provider's suppliers meet the same standards, including where a third party has access to data or the provider depends on third-party hardware and software.

Access and interfaces

• Principle 9, secure user management: tools to manage your own use of the service, usually role-based access control.
• Principle 10, identity and authentication: all access to service interfaces is tied to a securely authenticated and authorized identity, human or machine.
• Principle 11, external interface protection: external or less-trusted interfaces, including APIs, web consoles and command line interfaces, are identified and defended.
• Principle 12, secure service administration: the provider's administration systems follow enterprise good practice, recognizing their value to attackers.

Visibility and usability

• Principle 13, audit information and alerting for customers: you can identify incidents and have the information to find how and when they happened.
• Principle 14, secure use of the service: the provider makes it easy for you to meet your data protection responsibilities, with secure by design and by default behavior.

What does the shared responsibility model add?

The NCSC's shared responsibility guidance says that in a cloud service you delegate some security responsibility to the provider, and how much depends on the service type. It advises delegating as much as you can to a trusted provider, for example making the provider responsible for security updates to all software your organization did not write. It also says you are always responsible for three things: making sure the service can meet your security needs, configuring the chosen services securely, and deciding which data you store in them.

It prefers software as a service where it fits, platform as a service in preference to infrastructure as a service for hosting your own application, and suggests replacing IaaS components such as storage, identity, logging and monitoring with managed services where possible.

A constructed example

A company comparing two storage services scores each against the principles. Both encrypt in transit (principle 1). One offers customer-held encryption keys and clear separation guarantees (principle 3), and provides audit logs in a format the company's tooling can read (principle 13). The other offers neither. The company still has to configure access roles (principle 9), turn on multi-factor authentication for administrators (principle 10) and decide which data goes there. The principles shaped the choice, and the responsibilities set the follow-up work.

What do the principles not tell you?

They do not rank providers or give a score. The NCSC says different approaches create different risks to consider, and that the listed implementation ideas are only suggestions. It stresses evidence: how has the provider shown it meets each goal, such as through independent assurance or documentation? The principles also stop at the edge of the provider's share. Your own configuration, data classification and application code are outside them.

How to check or apply this

1. Write down what you must protect and the laws that apply to it, before you look at providers.
2. For each candidate, ask for evidence against each principle and note gaps rather than scoring them away.
3. Record the shared responsibility split for the service type you chose, in a table with named owners on your side.
4. Check the defaults. Principle 14 says secure should be the default, so list what you must change on day one.
5. Require audit logs and alerts to flow into your own monitoring (principle 13).
6. Re-review when the service, your data or the provider's evidence changes.

Safeguard supports one slice of this on the software side: dependency scanning, reachability analysis and policy checks for applications you deploy to the cloud. It does not assess cloud providers, and it is not a cloud configuration or network security product.

Quick check

Sources

• NCSC, The cloud security principles
• NCSC, Cloud security shared responsibility model

Last reviewed: 18 October 2026.