Secure AI Lifecycle Self-Assessment
Work through a checklist built on the CISA/NCSC Guidelines for Secure AI System Development and their four lifecycle stages — Secure Design, Secure Development, Secure Deployment and Secure Operation & Maintenance. Each stage uses the guidelines' own sub-themes, with items cross-referenced where they fit to the NIST SSDF (SP 800-218 / 800-218A for generative AI) and ISO/IEC 5338. You get a banded 0–100 maturity score, a radar of where you are strong and weak, and the gaps ranked so you close the ones that matter most first. The weighting is a transparent heuristic, nothing is uploaded, and the result is shareable by permalink.
Secure-AI practices are informal or missing across the lifecycle. Threats are unmodelled, the supply chain is unverified, and there is little to catch a compromise once the system is live. Start with the Design and Development stages — a threat model and a verified supply chain are the foundations everything else rests on.
Score per lifecycle stage (0–100)
Prioritised gaps
Highest-weight, lowest-scoring controls first — spend remediation effort here.
- Secure design · unanswered
Build and maintain a threat model that treats the training data, model/weights, prompts and serving infrastructure as part of the attack surface.
Reference: CISA/NCSC — Secure design
- Secure development · unanswered
Verify the provenance of every model, library, dataset and external API before use, and source them only from trusted suppliers.
Reference: NIST SSDF PS — Secure development
- Secure deployment · unanswered
Segment and harden the model-hosting infrastructure and lock down the serving endpoints; treat the model API as a sensitive, internet-exposed surface.
Reference: NIST SSDF PS — Secure deployment
- Secure operation & maintenance · unanswered
Monitor model behaviour and outputs in production for drift, degradation and signs of compromise or misuse — not only uptime.
Reference: CISA/NCSC — Secure operation
- Secure design · unanswered
Brief the design and development teams on AI-specific threats (poisoning, inversion/extraction, prompt injection, adversarial inputs) so design decisions account for them.
Reference: CISA/NCSC — Secure design
- Secure design · unanswered
Define security requirements as first-class design inputs (alongside functionality and performance) rather than bolting them on after a model is chosen.
- Secure design · unanswered
Add security trade-offs (provenance, licence, known weaknesses, dual-use foundation-model risk) to the model-selection criteria beside accuracy and cost.
Reference: NIST SP 800-218A (GenAI)
- Secure development · unanswered
Inventory your AI assets (models, weights, data, prompts, pipelines) and put access controls around each; an untracked asset cannot be protected.
Reference: ISO/IEC 5338
+ 10 more gaps in the full export.
Secure design · weight 27
Stage 1 of the CISA/NCSC guidelines. Decisions made before a line is written: raise staff awareness of AI-specific threats, model the threats to the system, design for security alongside functionality and performance, and weigh security trade-offs when choosing the model.
Staff involved in building the AI system understand AI-specific threats — data poisoning, model inversion/extraction, prompt injection and adversarial inputs — not just conventional app-security risks.
A threat model for the AI system exists and is kept current — covering attacker goals and the full attack surface: training data, the model and its weights, prompts, and the hosting infrastructure.
Security requirements are set alongside functionality and performance before model selection — security is a design input, not a retrofit.
Model selection weighs security trade-offs — provenance, licence, known weaknesses and dual-use foundation-model risk — not just accuracy and cost.
The intended use, users and explicit boundaries of the system (what it must not do) are documented, so design decisions can be judged against them.
Secure development · weight 27
Stage 2 of the guidelines. Securing the build: a trustworthy supply chain, identifying and protecting assets, documenting data/models/prompts, and managing technical debt instead of letting security shortcuts accumulate.
The AI supply chain is secured — models, libraries, datasets and external APIs come from trusted, verified sources with provenance checks, not pulled in unvetted.
Assets — models, data, prompts, weights and pipelines — are identified, inventoried and access-controlled; you know where each lives and who can touch it.
Data, models and prompts are documented for traceability — training-data sources and handling, model cards, and prompt templates — so the system can be audited and reproduced.
Technical debt is tracked and managed across the lifecycle, with a plan to remediate security shortcuts rather than carry them indefinitely.
Development, training and build environments are protected — least privilege, separation from production, and managed secrets/credentials.
Secure deployment · weight 23
Stage 3 of the guidelines. Shipping safely: protect the infrastructure the model runs on, protect the model continuously against tampering and theft, have incident-management procedures for AI-specific failures, and release the model responsibly.
The infrastructure hosting the model and its APIs is secured — segmentation, hardened access, and protected model-serving endpoints.
The model is protected continuously against tampering and theft — integrity checks on weights, and controls against model extraction or query abuse.
Incident-management procedures cover AI-specific failure modes (model compromise, poisoned data, harmful or leaked output) with defined roles and escalation.
The model is released responsibly — security evaluation and red-teaming before release, and users are given the information needed to use it safely.
Secure operation & maintenance · weight 23
Stage 4 of the guidelines. Life after launch: monitor the system’s behaviour and its inputs, respect privacy, apply updates with a secure-by-design change process, and collect and share the lessons learned.
The system’s behaviour and outputs are monitored in production for drift, degradation and signs of compromise, misuse or harmful output.
System inputs are monitored and logged — prompt-injection attempts, adversarial or anomalous inputs and abuse — with alerting, while respecting user privacy.
Updates to the model, data and dependencies follow a secure-by-design change process — tested, with rollback — and automated model updates are treated with care.
Lessons from incidents and findings are collected and shared with vendors and the wider community, and fed back to improve the system.
Heuristic self-assessment. The stage weights are a transparent judgement framework for structured self-reflection, not a measurement, certification or legal advice. This tool maps to the four stages of the CISA/NCSC Guidelines for Secure AI System Development and references the NIST SSDF (SP 800-218 / 800-218A for generative AI) and ISO/IEC 5338 by name only; it quotes no figures, performs no scan, and runs entirely in your browser — nothing is uploaded. Your answers are stored only in the shareable link you choose to copy.
What this assessment is
- A free, 100% in-browser self-assessment mapped to the CISA/NCSC "Guidelines for Secure AI System Development" (Nov 2023) and their FOUR lifecycle stages: Secure Design, Secure Development, Secure Deployment, and Secure Operation & Maintenance.
- Four weighted dimensions — one per stage — each built from the guidelines’ own sub-themes: threat modelling and model-selection trade-offs (design); supply-chain security and asset/documentation discipline (development); infrastructure and continuous model protection, incident management and responsible release (deployment); behaviour and input monitoring, careful updates and shared lessons (operation).
- As a secondary overlay the items are tagged, where they fit, to the NIST Secure Software Development Framework (SP 800-218, practice groups PO/PS/PW/RV) — augmented for generative AI and dual-use foundation models by SP 800-218A — and to ISO/IEC 5338, the AI-system life-cycle process standard.
- Every question maps to a concrete next action; gaps are prioritised lowest-score, highest-weight first. You get a banded 0–100 maturity score (Ad-hoc / Managed / Secured / Hardened), a radar and per-stage bars.
- Educational self-assessment — not a certification, audit or legal advice. Nothing is uploaded. Export to Markdown or CSV, and share the exact scorecard with a base64url permalink.
Security is a property of the whole AI lifecycle
AI systems fail securely or insecurely at every stage, not just at deployment. A model chosen without weighing its provenance, a training pipeline fed from an unverified supply chain, weights served from an exposed endpoint, or a production system nobody is watching for drift and prompt injection — each is a different stage of the same lifecycle. The CISA/NCSC guidelines break that lifecycle into four stages so the question stops being “is our AI secure?” and becomes “where, across design, development, deployment and operation, are we strong and where are we exposed?” This assessment turns those stages into a structured checklist so the gaps are visible stage by stage.
The four dimensions are weighted on purpose — Secure Design and Secure Development carry slightly more, because secure-by-design decisions and a trustworthy supply chain shape everything downstream and are expensive to unwind once a system is live. That weighting is a heuristic, shown openly so you can argue with it and adjust it to your environment. Items are cross-referenced to the NIST Secure Software Development Framework (SP 800-218, with SP 800-218A augmenting it for generative AI and dual-use foundation models) and to ISO/IEC 5338 for AI-system life-cycle processes, by name, for orientation. It is a self-assessment framework, not a certification, it quotes no invented statistics, and it is not legal advice.
Frequently asked questions
What does the Secure AI Lifecycle Self-Assessment measure?
It measures how systematically security is addressed across the whole life of an AI system, using the four stages of the CISA/NCSC Guidelines for Secure AI System Development: Secure Design, Secure Development, Secure Deployment, and Secure Operation & Maintenance. You answer each item as in place, partial, or no, and the tool produces a weighted 0–100 maturity score with a band (Ad-hoc, Managed, Secured, Hardened) and a prioritised gap list.
Which frameworks does it draw on?
Its structure is the CISA/NCSC Guidelines for Secure AI System Development (published November 2023 and co-sealed by agencies from multiple countries), which organise secure AI into four lifecycle stages. As a secondary overlay, individual items are tagged where they fit to the NIST Secure Software Development Framework (SP 800-218 and its practice groups PO, PS, PW and RV), to SP 800-218A which augments the SSDF for generative AI and dual-use foundation models, and to ISO/IEC 5338, the standard that defines AI-system life-cycle processes. These are named for orientation only; no text or figures are reproduced from them.
Is the score a real benchmark or certification?
No. It is a transparent heuristic for structured self-reflection, not a measurement, benchmark, audit, certification or legal advice, and it predicts no outcome. The stage weights (Design and Development carry slightly more, because secure-by-design choices and a trustworthy supply chain shape everything downstream) are shown openly so you can adjust them to your own risk model. The value is the structured review and the prioritised to-do list, not the exact number.
Does it scan anything or send my answers anywhere?
No. The assessment runs entirely in your browser. It performs no scan and touches no system. Your answers are never uploaded — they live only in the shareable permalink you choose to copy (encoded in the URL, base64url) and in any Markdown or CSV file you export yourself.
What are the four stages, briefly?
Secure Design: raise staff awareness of AI-specific threats, model the threats, design for security alongside functionality and performance, and weigh security trade-offs when selecting the model. Secure Development: secure the supply chain, identify and protect assets, document data/models/prompts, and manage technical debt. Secure Deployment: protect the infrastructure, protect the model continuously, run AI-aware incident management, and release responsibly. Secure Operation & Maintenance: monitor behaviour and inputs, respect privacy, update with care, and collect and share lessons learned.
This tool is free and always will be. Would a Pro workspace — saved designs, team sharing and exports — be worth paying for?
Show me Pro →No account needed to use this tool — this just tells us whether Pro is worth building out.