NCSC 10 Steps and 14 Cloud Security Principles

The NCSC's 10 Steps to Cyber Security and its 14 Cloud Security Principles are the two pieces of UK government guidance most often quoted in contracts, audits and board papers, yet they are often cited without being turned into work anyone can check. The 10 Steps (version 1.0, published 11 May 2021) breaks the job of protecting an organisation into ten components and is written for security professionals in medium and large organisations. The Cloud Security Principles (version 2.1, reviewed 7 June 2023) help you choose a cloud or SaaS provider that meets your security needs. This guide turns both into owners, evidence and measures, shows how the cloud principles plug into Step 10 (supply chain) and Step 6 (identity), and calls out where machine identities need more attention than the source text gives them. It sits between the Cyber Essentials Guide (a baseline for commodity attacks) and the NCSC Cyber Assessment Framework (CAF) Guide (outcome-based assessment for essential services).

Key takeaways

Two documents, two jobs. The 10 Steps describes how to run your own security; the 14 Cloud Security Principles describe what to expect from a provider and how to evidence it. Configuring your own cloud tenancy securely is a separate task.
Risk management comes first. Step 1 asks for board-approved policy, a chosen risk method and an understanding of residual risk; the other nine steps are how you act on it.
Baselines are not enough. The NCSC itself says Cyber Essentials does not cover all cyber risks, so tailored risk analysis is still needed on top of it.
Service identities count. Cloud Principle 10 expects service identities to be authenticated as robustly as users, with lifecycle processes so no service credential stays valid indefinitely.
Evidence beats assertion. For each principle, record what the provider claims, how it is backed up (contract, certification, independent test) and what you still own.

Where the 10 Steps and the Cloud Principles sit

UK organisations meet several NCSC products. They are complementary, not competing, and the right starting point depends on size and regulatory position.

NCSC guidance	Audience the NCSC names	What it gives you	Use it for
Cyber Essentials	All organisations, often small	Five technical controls against commodity attacks, with certification	A minimum bar, and a supplier requirement
10 Steps to Cyber Security	Medium to large organisations with someone dedicated to cyber security (smaller firms are pointed to the Cyber Action Toolkit)	Ten components of a security programme with recommended practice	Programme design, gap analysis, board conversation (alongside the Cyber Security Toolkit for Boards)
14 Cloud Security Principles	Anyone buying cloud platforms or SaaS	Goals, differentiators and implementation approaches per principle	Provider selection and assurance, contract schedules
Cyber Assessment Framework	Operators of essential services and others with high-consequence systems	Objectives, principles and indicators of good practice	Regulated assessment and outcome-based maturity

For government and public sector projects the Secure by Design for UK Government Guide lists the 10 Steps and the Cloud Security Principles among the control sets a service may select.

The 10 Steps as owners, evidence and measures

The NCSC pages describe recommended practice in prose. The table below is our conversion of each step into a named owner, the evidence an assessor would ask for and one measure that shows it is working. The owner suggestions and measures are NHI Mgmt Group recommendations, not NCSC requirements.

Step	Core NCSC expectation	Evidence to hold	Measure (ours)
1 Risk management	Board-approved policy; a chosen method or framework; mitigate, accept, transfer or avoid each risk; understand residual risk; reassess when threats or technology change	Risk policy with board approval date, method statement, risk register with owners	Share of top risks with a named owner and a review in the last 12 months
2 Engagement and training	Security that supports people, a positive reporting culture, training that fits roles	Training plan by role, reporting channel, phishing exercise results	Time from staff report to triage
3 Asset management	Know what you have, including data, devices, software and services	Asset register, system diagrams, owners	Share of discovered assets matched to a register entry
4 Architecture and configuration	Design and build systems securely, maintain secure configuration	Architecture decisions, configuration baselines	Drift from baseline on high-value systems
5 Vulnerability management	Automatic updates where practical, an update strategy per system, risk-based triage, unmitigated vulnerabilities in the risk register, segregate unsupported systems	Update strategy per system, scan coverage, risk register entries	Median time to patch internet-facing critical flaws
6 Identity and access management	MFA on online services, tiered admin model, separate admin accounts, joiners movers leavers, regular privilege review, traceable actions	MFA coverage report, admin account list, access review records	Share of privileged accounts with MFA and a separate admin identity
7 Data security	Protect data in transit, at rest and at end of life, with backups	Data classification, encryption settings, tested restores	Restore test success rate
8 Logging and monitoring	Logs that answer incident questions, most important logs kept at least 6 months, tamper protection, alert when logs stop arriving, exercise detection	Log source list, retention settings, pipeline health alerts	Share of critical sources with a "no logs received" alert
9 Incident management	A plan, roles, exercises and lessons learned, aligned with monitoring	Incident plan, exercise reports, post-incident reviews	Actions from last exercise closed on time
10 Supply chain security	List and rank suppliers by risk, proportionate minimum requirements, contract terms for incidents and data return or deletion, include key partners in exercises	Supplier register with tiers, contract clauses, assessment records	Share of top-tier suppliers assessed in the last year

Steps 2, 4, 7 and 9 are summarised here from the collection structure; read the NCSC step page before using the row as an audit criterion. For deeper treatment of individual steps see the Vulnerability Management Guide, the Log Management and Retention Guide and the Asset Inventory and CMDB Security Guide.

Details practitioners miss

Step 5 sets no fixed patch deadline: the page asks for security updates "as soon as possible", especially for internet-exploitable systems, and a staggered rollout with a rollback plan. If you need a number for a policy, set it yourself and label it as yours (we suggest 14 days for critical internet-facing flaws, in line with the Cyber Essentials requirement).
Step 5 on legacy: segregate unsupported systems, monitor them proactively and keep patching their other components (browsers, anti-malware) even when the operating system no longer gets updates.
Step 6 on high-access roles: apply admin-grade protection to people who approve payments and developers who can change software, not only to IT administrators.
Step 6 on monitoring: watch failed MFA second steps, logins from unexpected locations, password spraying and unexpected lockouts.
Step 8 on the pipeline itself: alert when logs stop arriving, or when a periodic test event is not captured, and plan storage rollover so full disks do not stop services.
Step 10 on exit: contracts should set out specific requirements for return and deletion of your information and assets.

The 14 Cloud Security Principles and what you still own

Each principle page sets goals, differentiators to look for and suggested implementation approaches. The NCSC is clear that the suggestions are not exhaustive and that you should analyse both the service and the company running it. The right-hand column is our view of the customer-side work that remains however good the provider is; see the Shared Responsibility Models Guide.

No.	Principle	Ask the provider	Customer-side work (ours)
1	Data in transit protection	How data is protected from tampering and eavesdropping across networks	Enforce TLS on your own endpoints and integrations
2	Asset protection and resilience	Data location, physical protection, sanitisation, resilience	Choose regions, configure backups and key management
3	Separation between customers	How separation works across compute, storage, data flows and networking, and what is inherited from underlying services	Separate your own environments and tenants
4	Governance framework	Who directs security of the service through its lifetime	Map provider governance to your risk register
5	Operational security	Vulnerability, monitoring, change and incident management	Subscribe to provider advisories and status feeds
6	Personnel security	Staff vetting and technical controls that audit and limit staff actions	Use provider operator access controls where offered
7	Secure development	Secure design and an automated, audited deployment pipeline	Apply the same to code you deploy on the platform
8	Supply chain security	How third parties are held to the provider's standards	Record sub-processors in your supplier register
9	Secure user management	Tools for managing your use, including role-based access control	Design roles, review membership, restrict console access
10	Identity and authentication	MFA for users, service identities authenticated as robustly as users, service credential lifecycle	Federate users, replace static keys with workload identity, own break-glass
11	External interface protection	How APIs, web consoles and command line interfaces are defended	Restrict which interfaces you expose and to whom
12	Secure service administration	Tiered admin, privileged access management with just-in-time and just-enough access, detailed admin audit	Apply the same pattern to your own administrators
13	Audit information and alerting for customers	What audit data you get, format, retention, deletion protection, and prompt automated security alerts	Ingest logs and alerts into your SOC and test them
14	Secure use of the service	Help to meet your data protection duties; secure by design and default	Configure the service securely and train users

For the operator-access side of Principles 6 and 12 see the Cloud Provider Support and Operator Access Controls Guide.

Where identity fits: Step 6 and Principle 10 for machine identities

The 10 Steps identity page has no dedicated section on service accounts; it mentions device-to-service authentication and the need to protect credentials at rest and in transit. Cloud Principle 10 goes further, and its expectations are useful well beyond cloud buying:

Robust service authentication: service identities should be authenticated as robustly as users, through a cryptographic assertion such as a signature from a private key or a secure key exchange, plus risk factors.
Context: the NCSC says workload service identities used from outside the cloud environment should be rejected and treated as breached. Build detections for cloud workload credentials used from unexpected networks.
Lifecycle: the provider should rotate and revoke service credentials so none stays valid indefinitely, and user credentials should follow joiner, mover and leaver processes.
Exposure alerts: a preferred provider alerts customers when credentials appear in public locations such as code repositories or breach data sites, ideally with a remediation option.
Break-glass: where users are federated to a corporate directory, keep a well-monitored break-glass administrator account.

In practice, extend Step 6 with an explicit inventory of service accounts, API keys, tokens and certificates, each with an owner and an expiry. See the Service Account Security Guide, the Cloud Workload Identity Guide and the Secrets Management Guide.

Assessing a provider against the principles

The NCSC asks you to consider what evidence a provider offers for its claims and whether it has published a response to the principles, which sets out in one place how it believes it meets the goals. A workable assessment record for each principle has four parts.

Claim: the provider's statement, quoted from its published response or security documentation.
Evidence type: contract term, independent certification or audit report, penetration test summary, or self-assertion. For Principle 3 the NCSC looks for externally audited evidence of regular penetration testing, including red and blue team exercises.
Fit: whether the mechanism suits your use. Principle 3 notes that stronger separation matters most where customers can run their own code (normal for IaaS and PaaS, not SaaS), and that containerisation without hardware backing should be limited to functional separation.
Residual action: what you configure, monitor or accept, entered in your risk register under Step 1.

For Principle 13 test, not just read: the NCSC suggests providers offer a way to simulate alerts so you can check your handling without waiting for a real incident, and that audit information must not be deletable by you or the provider during the retention period. See the Cloud Logging and Audit Trail Guide.

Decision guidance

Small organisation, no dedicated security role: start with Cyber Essentials and the NCSC's small-business material; read the 10 Steps as a roadmap rather than a checklist.
Medium or large organisation: use the 10 Steps as the programme structure and report to the board against it; add a tailored risk method under Step 1.
Buying SaaS: weight Principles 9, 10, 13 and 14 most, since you cannot run code and most risk sits in user management, identity, audit and configuration.
Buying IaaS or PaaS: weight Principles 3, 11 and 12 as well, because separation and administration interfaces carry more risk where tenants run code.
Regulated essential service: use the CAF for assessment and keep the 10 Steps as the operating model beneath it.

How to implement

Baseline (weeks 1 to 4): score each step as not started, partial or in place, with evidence links. Name an owner per step.
Risk method (weeks 2 to 6): agree the method under Step 1, define risk scores so staff interpret them consistently, and get board approval of the policy.
Quick wins (months 2 to 3): MFA on all online services and admin accounts, separate admin identities, automatic updates where practical, log pipeline health alerts.
Cloud register (months 2 to 4): list cloud and SaaS services from finance and identity provider data, tier them by data and business impact, and assess the top tier against all 14 principles.
Machine identity extension (months 3 to 6): inventory service credentials, set owners and expiry, and move cloud workloads to short-lived federated credentials where the platform supports it.
Exercise and review (ongoing): run an incident exercise including key suppliers, feed lessons back into monitoring, and reassess when threats, technology or use change. Roll back any control that breaks a business process through change management, record the exception and its residual risk, and set a date to revisit it.

Detection and measurement

MFA coverage: percentage of human accounts, and separately admin accounts, with MFA enforced.
Service credential age: share of service credentials older than your rotation target (we suggest 90 days for long-lived secrets where they cannot yet be removed).
Log health: critical log sources with a working "no data" alert, and retention of at least 6 months for the most important logs.
Patch latency: median days to deploy critical updates on internet-facing systems.
Supplier assurance: top-tier suppliers and cloud services with a current assessment against the relevant principles.
Exercise follow-through: actions from the last incident exercise closed by their due date.

Framework mapping

NCSC element	NIST CSF 2.0	NIST SP 800-53 Rev 5
Step 1 Risk management	GV.RM, ID.RA	RA-3
Step 2 Engagement and training	PR.AT	AT-2
Step 3 Asset management	ID.AM	CM-8
Step 4 Architecture and configuration	PR.PS, PR.IR	CM-2, CM-7
Step 5 Vulnerability management	ID.RA, PR.PS	RA-5, SI-2
Step 6 and Principles 9, 10, 12	PR.AA	AC-2, AC-6, IA-2
Step 7 and Principle 1	PR.DS	SC-8
Step 8 and Principle 13	DE.CM	AU-6, AU-9, AU-11
Step 9 Incident management	RS.MA	IR-4
Step 10 and Principle 8	GV.SC	SR-3, SR-6

This mapping is NHI Mgmt Group's own alignment by subject; the NCSC does not publish an official crosswalk on these pages.

Common failure patterns

Quoting the 10 Steps as a certification: there is no 10 Steps certificate. Claims of "10 Steps compliance" in tenders need evidence per step.
Treating a provider's principles response as your assurance: the response is a claim. Record the evidence behind it and the customer-side work that remains.
Ignoring service identities: MFA on people while static API keys and service account passwords never expire leaves the gap Principle 10 warns about.
Short or silent logs: default retention shorter than 6 months, no alert when a source goes quiet, and admins able to delete audit data.
Admin from everyday devices: using the same account and device for email and administration, against the Step 6 advice on separate accounts and restricted web and email on admin devices.
Supplier lists without tiers: assessing every supplier the same way, so the highest-risk providers get no deeper review.

Practitioner checklist

Name an owner and evidence location for each of the 10 Steps.
Get board approval of the risk management policy and define your risk scores.
Enforce MFA on all online services, and separate admin accounts with restricted web and email access.
Inventory service accounts, API keys, tokens and certificates with owners and expiry dates.
Keep the most important logs for at least 6 months, protect them from tampering and alert when they stop.
Write a software update strategy per system and record unmitigated vulnerabilities in the risk register.
Tier suppliers and assess top-tier cloud and SaaS services against all 14 principles, with evidence types recorded.
Add incident reporting and data return or deletion terms to supplier contracts.
Exercise incident response with key suppliers and track the actions to closure.

NCSC 10 Steps and 14 Cloud Security Principles: UK Government Guidance Made Practical