Security standards
Hosts, runtimes and orchestration built from DISA STIG baselines and CIS Benchmarks Level 2, in code. Platforms mapped onto the NCSC Cyber Assessment Framework and the NCSC secure AI guidelines. Controls traced to NIST. Every deviation documented rather than quietly dropped.
The point of this
Nobody in defence or government is impressed by a logo. What they need is to be able to follow a control from a framework they already answer to, through to a scan result or a configuration file, without taking anybody's word for it.
That is the whole reason we build to named baselines rather than to our own opinion of good practice. Our opinion is not something your accreditor can assess. A STIG finding ID, a CIS benchmark control and a CAF contributing outcome are.
The deliverable is not "we are secure". It is a trail somebody else can check, including the parts where we did not meet the baseline and said why.
What we build to
The framework UK government and critical national infrastructure are assessed against: four objectives, fourteen principles, outcome-based rather than checklist-based.
What we do about it. We map every AI platform we build onto the CAF objectives and hand over a contributing-outcome commentary your assessor can work from, rather than leaving the AI estate as an unassessed gap in a departmental submission.
The NCSC-led international guidelines covering secure design, secure development, secure deployment, and secure 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 are designed in against the four lifecycle stages, and evidenced stage by stage.
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, scanned before handover, with every deviation carrying a documented technical justification rather than being quietly skipped.
The stricter CIS profile, intended for environments where security is prioritised over convenience and some functionality loss is acceptable.
What we do about it. Level 2 is the build target, not Level 1 with good intentions. Where a Level 2 control genuinely breaks GPU scheduling or driver operation we say which, why, and what compensating control replaces it.
The US control catalogues and risk frameworks that most defence and government supply chains now use as a common vocabulary, including the AI-specific Risk Management Framework.
What we do about it. Controls are traced to SP 800-53 Rev 5 families and the AI RMF functions (Govern, Map, Measure, Manage), which is what makes an assurance conversation with a NATO or US-aligned partner short rather than long.
NCSC CAF
The CAF is outcome-based rather than a checklist, which is a strength and the reason it is awkward to retrofit. We map the platform to it during the build, while the people who made the design decisions are still available to explain them.
Governance, risk management, asset management and supply chain. For an AI platform the awkward part is asset management: model weights, container images, embeddings and evaluation datasets are assets, they have 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. This is where STIG and CIS Level 2 hardening does its work, along with tenant separation, secrets handling and the update path for drivers, images and model artefacts.
Security monitoring and proactive discovery. Inference logging has to be good enough to reconstruct an individual interaction, and detection use cases have to be written for the AI platform rather than inherited from the general estate, where they will miss everything specific to it.
Response and recovery planning, and lessons learned. On an air-gapped platform this 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, and the two are complementary rather than competing. 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) rather than only the surrounding web application. Trade-offs between capability and exposure 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 it is available, and a release process where the thing you evaluated is provably the thing you shipped.
Logging and monitoring designed for model behaviour as well as infrastructure, a model update process that repeats verification and evaluation instead of trusting a version number, and an incident path exercised rather than written.
Sector regimes
Standards are the build. These are the processes that decide whether your organisation is allowed to run it, and they are the ones that set the timetable.
Central government departments are assessed against the NCSC CAF. We produce contributing-outcome commentary for the AI platform itself, so it does not arrive at the submission as an unassessed system with no owner and no detection coverage.
Both the government and MOD variants move security evidence into delivery, continuously, owned by the delivery team. We work that way regardless, because assembling a security case retrospectively produces a worse case and a worse system.
Defence supply-chain cyber requirements apply to us as a supplier, not only to what we build. We expect the risk assessment and the supplier assurance questionnaire, and we would rather complete them early than discover a gap at contract award.
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 rather than around them.
The Algorithmic Transparency Recording Standard applies to algorithmic tools affecting decisions about the public. We draft the record during the build, which is when the people who made the design decisions can still explain them.
Where you are pursuing certification or a self-assessment, we produce evidence in the shape those schemes expect rather than in ours, and we will tell you honestly when a certification is not worth its cost to you yet.
Straight talk
NIST SP 800-53 and the NIST AI Risk Management Framework are catalogues and frameworks, not certification schemes. There is no NIST certificate to hold up. 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, and we will tell you when it is worth doing and when it is not yet.
We build to the baseline, produce the evidence and answer the questions. The decision to accept residual risk belongs to your security assurance coordinator, your SIRO or your accreditor, and it should. A supplier who tells you they can approve their own work has told you something useful about the supplier.
Some Level 2 controls conflict with GPU driver operation, container runtime requirements or scheduler behaviour. The honest position is a hardened baseline with a small, 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 either running a narrow profile or has not looked closely.
A perfectly hardened platform will still serve a confidently wrong answer. Evaluation against your own material, with measured results and a documented human decision point, is a separate discipline from infrastructure assurance and neither substitutes for the other. We do both, and we keep them distinct in the evidence pack for the same reason.
If you have a supplier assurance questionnaire, a CAF submission in progress or an accreditor with a list, send it over. We would rather answer it now than discover halfway through a build that we cannot.