NCSC Secure AI Guidance for Procurement

The UK National Cyber Security Centre's Guidelines for secure AI system development organise AI security into four lifecycle areas: secure design, secure development, secure deployment, and secure operation and maintenance. For buyers, those areas are useful because they turn a broad request for “AI security” into evidence that can be asked for, evaluated and carried into the contract.

This guide is a procurement interpretation of the public NCSC guidance. It does not replace a security assessment, penetration test, sector requirement or the buyer's own risk decision.

1. Secure design: ask how risk was understood before the product was built

Useful questions include:

• What intended uses and reasonably foreseeable misuse cases were considered?
• What AI-specific and conventional cyber threats were included in threat modelling?
• What security trade-offs were made between model capability, data access, tool access and user convenience?
• Which model providers, APIs, retrieval sources and infrastructure components form part of the security boundary?
• What controls prevent the system from taking actions outside its authorised scope?

Evidence can include current architecture diagrams, threat models, risk records, design decisions and documented authority boundaries for agentic functions.

2. Secure development: examine the supply chain, documentation and change process

An AI service can inherit risk from foundation models, open-source packages, model-serving infrastructure, datasets and external APIs. Procurement should therefore establish what the supplier depends on and how those dependencies are controlled.

Ask for evidence of:

• software and model dependency management;
• secure development and code-review practices;
• vulnerability handling;
• model, prompt, retrieval and configuration change control;
• asset inventories and ownership;
• third-party and supply-chain security;
• documentation sufficient to reproduce the evaluated service boundary.

A statement that the supplier “uses a secure cloud” is not a substitute for evidence about the supplier's own design and operating controls.

3. Secure deployment: test how the evaluated service will be protected in production

The buyer should distinguish the supplier's platform controls from configuration choices that remain the buyer's responsibility.

Evidence areas can include:

• authentication and privileged access;
• tenant and data separation;
• secrets and key management;
• model and infrastructure protection;
• network and integration boundaries;
• tool and agent permissions;
• logging and incident investigation capability;
• secure release and rollback processes;
• production configuration compared with the evaluated configuration.

For higher-impact deployments, use a controlled go-live review rather than assuming procurement-time evidence remains accurate at launch.

See also: Deploy purchased AI safely.

4. Secure operation and maintenance: make security a post-award obligation

The NCSC guidance treats security as a lifecycle activity. Procurement contracts and supplier management should therefore cover the information needed after go-live.

Consider requiring:

• material vulnerability and incident notification;
• relevant security monitoring information;
• model, provider, infrastructure and subprocessor change notification;
• controlled update and regression processes;
• evidence refreshes after material changes;
• lessons learned from incidents;
• clear support and escalation routes.

See also: Monitor AI suppliers after award.

5. Do not ignore AI-specific attack surfaces

Standard SaaS due diligence remains necessary, but AI can add additional attack surfaces. Depending on the system, buyers may need evidence covering prompt injection, unsafe tool use, retrieval manipulation, model or data leakage, poisoning, excessive agency, insecure output handling and abuse of connected systems.

The precise test plan should follow the architecture and intended use rather than a generic checklist.

6. Evidence strength matters

For each material security statement, distinguish:

1. Claim only — supplier assertion. 2. Documented — policy, architecture or technical documentation supports it. 3. Demonstrated — operational evidence or testing shows the control working. 4. Independently verified — an appropriate independent party has checked the relevant evidence.

This prevents a procurement matrix from giving the same weight to a marketing answer and a verified control.

7. Carry findings into the contract

Where security evidence was important to the award, preserve the relied-on facts contractually. Relevant controls may include material-change notification, incident timescales, evidence rights, audit cooperation, data restrictions, model/provider controls, remediation obligations and exit rights.

See: Contract for AI services.

How AI TrustMark fits

AI TrustMark can independently verify evidence within the supplier, product and operational scope and map verified evidence to buyer requirements. It does not create NCSC accreditation, government approval or a guarantee that a product is suitable for a particular use.

The public guide explains the evidence areas. Organisation-specific security crosswalks, tailored tender questions, evidence-gap analysis, verification, contract schedules and procurement packs are professional services.

Return to the AI Procurement Knowledge Base or use the AI Procurement Route Finder if you are unsure what workstream comes next.