Security standards
Hosts, runtimes and orchestration built from DISA STIG baselines and CIS Benchmarks Level 2, in code. Mapped onto the NCSC Cyber Assessment Framework and the NCSC secure AI guidelines. Traced to NIST. Every deviation documented.
Why named standards
An accreditor needs to follow a control from a framework they already answer to, through to a scan result or configuration file, without taking anybody's word for it.
So we build to named baselines. Your accreditor cannot assess our opinion of good practice. They can assess a STIG finding ID, a CIS benchmark control and a CAF contributing outcome.
The deliverable is a trail somebody else can check, including where we did not meet the baseline, and why.
What we build to
The framework UK government and critical national infrastructure are assessed against. Four objectives, fourteen principles, judged on outcomes.
What we do about it. We map every AI platform we build onto the CAF objectives, with contributing-outcome commentary your assessor can work from. The AI estate reaches your submission as an assessed system with an owner.
The NCSC-led international guidelines covering secure design, development, deployment, and operation and maintenance of AI systems.
What we do about it. Model provenance, supply-chain verification, adversarial input handling, prompt and output logging and a model update process, designed in and evidenced at each of the four lifecycle stages.
The US Defense Information Systems Agency hardening standards for operating systems, containers and orchestration, applied by finding ID and scanned with SCAP.
What we do about it. Hosts, container runtimes and Kubernetes are built from STIG-hardened baselines in code and scanned before handover. Every deviation carries its finding ID, technical reason and compensating control.
The stricter CIS profile, for environments where security takes priority over convenience and some loss of function is acceptable.
What we do about it. Level 2 is the build target. Where a Level 2 control breaks GPU scheduling or driver operation, the deviation list says which control, why, and what replaces it.
The US control catalogues and risk frameworks most defence and government supply chains use as a shared vocabulary, including the AI Risk Management Framework.
What we do about it. Controls are traced to SP 800-53 Rev 5 families and the four AI RMF functions: Govern, Map, Measure, Manage. That keeps assurance conversations with NATO or US-aligned partners short.
NCSC CAF
The CAF is judged on outcomes: its strength, and why it is awkward to retrofit. We map the platform to it during the build, while the people who made the design decisions can still explain them.
Governance, risk management, asset management and supply chain. On an AI platform, asset management is the awkward part: model weights, container images, embeddings and evaluation datasets are assets with owners and lifecycles, and most inventories do not know they exist.
Service protection policies, identity and access, data security, system security, resilient networks and staff awareness. Where STIG and CIS Level 2 hardening does its work, with tenant separation, secrets handling and the update path for drivers, images and model artefacts.
Security monitoring and proactive discovery. Inference logging must be good enough to reconstruct an individual interaction, and detection use cases must be written for the AI platform. Inherited from the general estate, they miss everything specific to it.
Response and recovery planning, and lessons learned. Air-gapped, that means a tested rebuild from local mirror, a defined rollback to a previously validated model artefact, and a response plan that assumes no supplier can be reached.
NCSC secure AI
The CAF was not written with model artefacts in mind. The NCSC's AI guidelines were. We use both, because each covers ground the other does not.
Threat modelling that covers model-specific risks (prompt injection, training and retrieval data poisoning, model and data extraction) as well as the surrounding web application. Capability versus exposure trade-offs recorded as decisions, with names against them.
Supply-chain control over weights, containers and dependencies. Artefacts pinned by digest, hashes recorded, weights accepted only in formats that do not execute code on load, and a documented provenance position for anything that cannot be signed.
Hardened infrastructure built from code. Least-privilege access tied to existing identity. Tenant and workload separation at the hardware level where available. A release process where what you evaluated is provably what you shipped.
Logging and monitoring designed for model behaviour as well as infrastructure, a model update process that repeats verification and evaluation for every new version, and an incident path that has been exercised.
For AI agents, the NCSC added interim guidance in August 2026: sandboxing, monitoring, attributable activity and an emergency stop. We map it onto controls you can deploy in our guide to NVIDIA OpenShell and Sentry.
Sector regimes
Standards are the build. These processes decide whether your organisation may run it, and they set the timetable.
Central government departments are assessed against the NCSC CAF. We write contributing-outcome commentary for the AI platform itself, so it reaches the submission as an assessed system with an owner and detection coverage.
Both the government and MOD variants move security evidence into delivery, continuously, owned by the delivery team. We work that way on every engagement. A security case assembled afterwards is a worse case, describing a worse system.
Defence supply-chain cyber requirements apply to us as a supplier, as well as to what we build. We expect the risk assessment and supplier assurance questionnaire, and complete them early.
Where the platform sits on a defence network, the relevant defence security and networking policy governs the build. We work to your security assurance coordinator and accreditor.
The Algorithmic Transparency Recording Standard applies to algorithmic tools affecting decisions about the public. We draft the record during the build, while the people who made the design decisions can still explain them.
If you are pursuing certification or a self-assessment, we produce evidence in the shape those schemes expect. We will also say when a certification is not yet worth its cost to you.
The limits
NIST SP 800-53 and the NIST AI Risk Management Framework are catalogues and frameworks. There is no NIST certificate. Alignment means controls are traced to named families and functions so an assessor can follow them. Certification against ISO/IEC 27001 or ISO/IEC 42001 is a separate exercise with an accredited body.
We build to the baseline, produce the evidence and answer the questions. Accepting residual risk is for your security assurance coordinator, your SIRO or your accreditor. A supplier who offers to approve their own work has told you something about the supplier.
Some Level 2 controls conflict with GPU driver operation, container runtime requirements or scheduler behaviour. The realistic position is a hardened baseline with a short, explicit deviation list, each entry carrying the finding ID, the technical reason and the compensating control. Anyone claiming a clean scan on an accelerated compute platform is running a narrow profile or has not looked closely.
A perfectly hardened platform will still serve a confident wrong answer. Evaluation against your own material, with measured results and a documented human decision point, is a separate discipline from infrastructure assurance. We do both, and keep them separate in the evidence pack.
Next step
Supplier assurance questionnaire, CAF submission in progress, or an accreditor with a list: send it over. Better answered now than halfway through a build.