NCSC cloud principles give boards a supplier-assurance lens for AI: know where data, models, logs and administration access sit; require evidence for operational security; and make secure configuration, monitoring, incident response and human ownership conditions of approval.
The National Cyber Security Centre describes its cloud security principles as guidance for choosing, configuring and using cloud services securely, and says they apply to both cloud platforms and Software as a Service. For AI governance, that matters because most board-approved AI is not a model on a laptop. It is a vendor feature, an API, a hosted workflow, a fine-tuning pipeline, a logging stack and an administration console.
Key takeaways
- Cloud-based AI governance should start with a map of data, derived data, models, logs, administration access and customer configuration responsibilities.
- The NCSC guidance turns supplier assurance into evidence questions: where is the data, who can access it, how is the service monitored, and what does the customer still have to configure?
- Boards should require control evidence, not supplier assertions: access reviews, configuration baselines, incident runbooks, change records and risk acceptances with expiry dates.
- ISO/IEC 42001 gives the management-system spine, NIST AI RMF gives the risk cycle, and UK GDPR or ICO expectations bind the privacy evidence where personal data is involved.
- The easiest first test is one live AI service traced from provider assurance to board minute, using the controls table above.
Who this applies to
This applies to boards, risk committees, company secretaries and executives approving AI systems that use cloud services: generative AI assistants, SaaS products with embedded AI, model APIs, managed machine learning platforms and internally built systems running on cloud infrastructure.
It also applies where the board does not control the engineering details. The NCSC's secure AI system development guidance is written for providers of systems that use AI, whether built from scratch or built on tools and services provided by others. The NCSC's machine learning principles are aimed at developers, engineers, decision-makers and risk owners, and cover design, development, deployment, operation and end of life.
The board's role is not to inspect every tenant setting. It is to decide what evidence is required before an AI service is approved, who owns that evidence, and what changes when the evidence is weak. For the wider UK regulatory frame, see our guide to what boards govern where the UK has no single AI Act.
What the board needs to decide
The decision is not "are we comfortable with the cloud?" The decision is whether the specific AI service can be governed with enough evidence to match the risk it creates.
- What is the AI system using or producing? The NCSC's asset-protection principle says overlooked data types include credentials, configuration data, derived metadata and logs, and that derivatives such as verbose logs and machine learning models should be included unless sensitive aspects have been intentionally excluded or removed.
- Where is the data stored, processed, managed and supported from? The same NCSC principle asks organisations to know where their data is, who can access it, which countries are involved and which legal jurisdictions apply.
- Which party runs each security control? The NCSC's secure-use principle says configuration remains the user's responsibility even when a provider takes a secure-by-default approach.
- Which administration paths can alter the AI service? The NCSC's secure service administration principle treats provider administration systems as high-value targets.
- What evidence will the board accept? The NCSC says customers should consider what evidence gives enough confidence in provider statements, not treat assertions as assurance.
The strongest board paper is therefore short and evidential. It names the service, the data involved, the legal and operational locations, the provider controls, the customer controls, the missing evidence and the go/no-go decision.
How NCSC cloud principles apply to AI systems
The principles become useful when they are translated into AI-specific questions. A standard SaaS tool may hold customer records. An AI SaaS tool may also hold prompt history, embeddings, evaluation data, feedback labels, model outputs and logs that reveal sensitive context. The NCSC's asset protection and resilience principle is explicit that derived metadata, logs and machine learning models should not be overlooked.
For operational risk, the NCSC's operational security principle points boards to vulnerability management, protective monitoring, incident management, and configuration and change management. In an AI system, those are not abstract cyber headings. They determine how model-serving dependencies are patched, how suspicious prompt activity is detected, how a compromised integration key is contained, and how a changed model or retrieval index is reviewed before use.
For administration, the NCSC's secure service administration principle is the prompt to ask who can change tenant settings, safety controls, API permissions, logging retention, data-export routes and model configuration. A board does not need console screenshots in the pack, but it does need a named owner who can produce the access model and the latest privileged-access review.
For customer responsibility, the NCSC's secure use of service principle asks whether the service is secure by design and by default, what the customer still needs to configure, whether configuration can be set and audited through infrastructure as code or an API, and whether deployed resources and configurations are visible to humans. That is the bridge from security guidance to AI governance: the board should approve the service only when the operating configuration is part of the approval evidence.
Controls and evidence to ask for
Boards should not ask management for a generic statement that the supplier is secure. Ask for the control, the evidence and the owner.
| Board question | Control to require | Evidence to minute | Owner |
|---|---|---|---|
| Where do prompts, outputs, logs, embeddings and models sit? | Data-location and derivative-data register for the AI service | Provider region statement, internal data map, transfer assessment if relevant | Data protection lead and system owner |
| Can the AI service alter production data? | Read-only role or transaction for analytical access where write access is not needed | Configuration extract, database role policy, test showing attempted writes fail | Technical owner |
| Who can administer the service? | Least-privilege admin roles, MFA, joiner-mover-leaver process and privileged-access review | Access review record, admin-role list, exception log | Service owner and IT security |
| How are AI-specific incidents detected? | Logging and monitoring for abnormal prompt, API, export and admin activity | Monitoring rule list, sample alert, incident runbook | Security operations |
| How are model, prompt and retrieval changes controlled? | Change gate for model version, system prompt, retrieval index and safety configuration | Change record, test result, approval minute | Product owner |
| What happens when supplier evidence is incomplete? | Risk acceptance route with expiry date and compensating control | Risk register entry, board or committee decision, review date | Executive sponsor |
The second row is where engineered controls matter. A provider assurance answer may say a model is instructed not to write to data. A stronger answer is a structural control, such as read-only database access by construction, where the system cannot perform the unwanted action even if the model produces it. The same evidence principle is visible across our case studies: useful AI governance leaves artefacts that can be inspected.
Framework mapping and next step
The cloud guidance is not a separate AI governance programme. It should sit inside the board's existing AI governance framework, with the controls mapped to the standards and regulatory principles the organisation already uses.
| Framework or regime | How it maps to cloud-based AI | Evidence the board should see |
|---|---|---|
| NCSC cloud security guidance | Provider selection, shared responsibility, secure configuration, operational monitoring and administration control | Supplier evidence pack, configuration baseline, admin review and incident runbook |
| NCSC secure AI and ML guidance | Secure design, secure development, secure deployment, secure operation, model and dataset lifecycle | Threat model, lifecycle record, model-change log and vulnerability process |
| ISO/IEC 42001 | BSI describes the standard as helping organisations establish, implement, maintain and continually improve an AI management system | AI system register, risk treatment plan, control mapping and management review |
| NIST AI RMF | NIST's AI RMF Core is organised around Govern, Map, Measure and Manage, with governance as a cross-cutting function | Risk context, test results, monitoring record and risk-response decision |
| UK GDPR, ICO and UK principles | The ICO's AI guidance covers accountability, transparency, lawfulness, accuracy, fairness, security, data minimisation and individual rights; the UK government response confirmed five cross-cutting AI principles | DPIA where required, lawful-basis record, transparency notice, human review route and evidence of contestability |
Three mistakes recur in board packs. First, a supplier's AI safety page is treated as evidence for cloud configuration. It is not enough unless it answers the data, access, monitoring and administration questions above. Second, logs and derived metadata are omitted from the data map, despite the NCSC naming them as data types that are often overlooked. Third, the board approves the AI use before management can explain which security responsibilities remain with the customer.
The practical next step is to run one live AI system through the table. If the board lacks a baseline, start with the Board AI Scorecard. If the gaps need an assessed plan, the AI governance diagnostic maps systems, suppliers, evidence and board actions. For the control standard we hold ourselves to, read our trust posture and our services.
Sources: NCSC cloud security guidance; NCSC asset protection and resilience principle; NCSC operational security principle; NCSC secure service administration principle; NCSC secure use of service principle; NCSC secure AI system development guidance; NCSC machine learning principles; BSI ISO/IEC 42001 standards page; NIST AI RMF Core; ICO guidance on AI and data protection; GOV.UK AI regulation government response
