Unofficial checklist · NIST SP 800-218A
Review how one AI model or AI-enabled system is prepared, protected, produced, and improved. Record implementation evidence, development gaps, and next actions without sending assessment data anywhere.
This project-authored checklist selects and paraphrases tasks and AI-specific guidance from NIST SP 800-218A. Decision Terrain changed the wording, selection, grouping, completion criteria, evidence examples, and interaction format. NIST did not create, review, sponsor, or endorse it. NIST states that the Profile supplements SP 800-218, should not be used alone, and is a risk-based starting point rather than a checklist. Self-reported answers do not establish NIST conformance, certification, compliance, secure development maturity, or readiness to deploy.
A secure development review for one AI boundary
Use In place only when you can point to current implementation evidence. Record the gap and next action when a practice is absent, incomplete, or untested. Explain every Not applicable answer.
Answers stay in this browser’s local storage and are not uploaded by this tool. Export a JSON backup before clearing browser data. Other scripts on this site can access this origin’s local storage. Keep entries unclassified and non-sensitive; do not enter CUI, secrets, or operational details.
Set the requirements, people, toolchains, evidence, and protected environments needed for secure AI model development.
Security requirements explicitly cover AI model development infrastructure and processes, including risk-appropriate model architectures, training techniques, privacy, cybersecurity, and reproducibility considerations.
Evidence to look for: AI development security standard, architecture decision records, training-method criteria, requirements review history.
Related SP 800-218A tasks: PO.1.1
Current requirements for organization-developed AI software cover model development, model operations, data science, data classification, and applicable legal, regulatory, contractual, and standards obligations.
Evidence to look for: Requirements baseline, policy mappings, data classification rules, model or system cards, change history.
Related SP 800-218A tasks: PO.1.2
Contracts, acquisition criteria, and technical requirements communicate the organization's AI model development security expectations to providers of models, data, software components, platforms, and services.
Evidence to look for: Supplier requirements, contract clauses, acquisition checklist, exception approvals, provider attestations.
Related SP 800-218A tasks: PO.1.3
Named roles cover model development, model operations, data science, secure software development, acquisition, and third-party coordination, with responsibilities reviewed as the system and supplier relationships change.
Evidence to look for: Responsibility matrix, role descriptions, supplier agreements, ownership review, escalation paths.
Related SP 800-218A tasks: PO.2.1
People responsible for development, review, acquisition, and operation receive role-based training on AI model vulnerabilities, threat paths, mitigations, and the tools and evidence required for their decisions.
Evidence to look for: Training curriculum, role mapping, completion records, proficiency reviews, updated threat modules.
Related SP 800-218A tasks: PO.2.2
Leadership has visibly committed to secure AI model development and provides authority, staffing, time, infrastructure, and enforcement for the selected practices and release criteria.
Evidence to look for: Leadership directive, funded plan, staffing assignments, governance minutes, unresolved resource risks.
Related SP 800-218A tasks: PO.2.3
A maintained plan defines the security tools and integrations used across AI development, automates repeatable checks at the required scale, and verifies toolchain security at a frequency proportional to risk.
Evidence to look for: Toolchain architecture, pipeline configuration, automated gates, tool inventory, security review schedule and results.
Related SP 800-218A tasks: PO.3.1, PO.3.2
Development tools produce protected artifacts showing that required security practices ran, including relevant integrity, provenance, test, approval, and exception evidence for models and datasets.
Evidence to look for: Pipeline attestations, dataset provenance records, signed test outputs, approval artifacts, evidence retention policy.
Related SP 800-218A tasks: PO.3.3
Documented criteria specify which AI lifecycle checks apply, what passes, what requires human review, how exceptions are approved, and what evidence must be gathered and safeguarded.
Evidence to look for: Security check catalogue, thresholds, human review rules, waiver process, evidence access controls.
Related SP 800-218A tasks: PO.4.1, PO.4.2
Training, build, test, registry, and distribution environments and endpoints are separated and hardened, use least privilege, restrict sensitive data locations and resource use, detect exposed secrets, and alert on suspicious model-related activity.
Evidence to look for: Environment diagrams, segmentation and endpoint baselines, access policies, resource limits, monitoring alerts, secret scans.
Related SP 800-218A tasks: PO.5.1, PO.5.2, PO.5.3
Protect model artifacts, development data, releases, and provenance from unauthorized access or change.
Models, weights, pipelines, reward models, code, and other sensitive elements are stored with least privilege, direct human access is minimized, and reward models are separated from models and data where appropriate.
Evidence to look for: Artifact inventory, repository permissions, indirect access path, reward-model separation, access review records.
Related SP 800-218A tasks: PS.1.1
Training, testing, fine-tuning, and alignment data receive risk-appropriate confidentiality and integrity protection, continuous monitoring, and secure retention when future investigation or reuse requires it.
Evidence to look for: Data access policy, integrity monitoring, encryption settings, retained snapshots, unauthorized-change alerts.
Related SP 800-218A tasks: PS.1.2
Model weights and configuration parameters are separated from development data, continuously monitored for integrity and confidentiality where applicable, and protected with least privilege and risk-proportionate cryptographic or physical controls.
Evidence to look for: Weight registry permissions, separation design, hashes or signatures, encryption, multi-party approval, integrity alerts.
Related SP 800-218A tasks: PS.1.3
Acquirers and integrators receive cryptographic hashes, signatures, or equivalent verification information for each approved model release, its material components, documentation, and subsequent changes.
Evidence to look for: Signed release manifest, hashes, verification instructions, change signatures, consumer verification test.
Related SP 800-218A tasks: PS.2.1
Each release retains protected versions of model artifacts and supporting information, including infrastructure tools, data transformations, model-selection rationale, architecture, preprocessing, and the training process needed for investigation or reconstruction.
Evidence to look for: Release archive, versioned tools, training run record, selection rationale, recovery or reconstruction exercise.
Related SP 800-218A tasks: PS.3.1
Provenance records cover the model, derivatives, libraries, frameworks, pipelines, and known training, testing, fine-tuning, and alignment data, and identify models whose sensitive training data warrants tighter access.
Evidence to look for: Model or AI bill of materials, lineage graph, derivative register, sensitive-data flags, provenance disclosure.
Related SP 800-218A tasks: PS.3.2
Design, build, inspect, and test AI models and their supporting software against defined security risks.
Risk modeling covers relevant AI threats such as data poisoning, malicious input or output, adversarial denial of service, supply-chain compromise, disclosure, weight theft, and pipeline misconfiguration, and is revisited for material versions and derivatives.
Evidence to look for: Threat model, attack-surface map, misuse cases, version review trigger, risk register updates.
Related SP 800-218A tasks: PW.1.1
The team maintains security requirements, risks, waivers, and design decisions and uses established identity, logging, access-control, and vulnerability-management services where appropriate instead of unreviewed proprietary replacements.
Evidence to look for: Decision log, requirements traceability, waiver records, architecture diagram, standard service integrations.
Related SP 800-218A tasks: PW.1.2, PW.1.3
Qualified reviewers who did not create the design, supported by automated checks where useful, confirm that the AI model design meets security requirements and addresses the documented risks before approval.
Evidence to look for: Reviewer independence record, design review checklist, automated findings, approvals, unresolved-risk decisions.
Related SP 800-218A tasks: PW.2.1
Training, testing, fine-tuning, and alignment data are checked for provenance and integrity and analyzed for poisoning, tampering, bias, homogeneity, anomalies, and other risks using suitable automated and human methods.
Evidence to look for: Data-quality report, integrity verification, anomaly and bias results, curation log, human review notes.
Related SP 800-218A tasks: PW.3.1
The team records provenance for all model-development data when known, identifies datasets or portions with unknown provenance, and makes the uncertainty visible in security and release decisions.
Evidence to look for: Dataset lineage, source metadata, unknown-provenance register, risk decision, model documentation.
Related SP 800-218A tasks: PW.3.2
Adversarial samples used for training or testing follow a controlled process with defined purpose, access, handling, guardrails, expected outcomes, and review of unintended effects on the model or pipeline.
Evidence to look for: Adversarial sample inventory, test protocol, access rules, guardrail results, approval and outcome record.
Related SP 800-218A tasks: PW.3.3
The team documents when to reuse or build models and components, then verifies the integrity, provenance, security, and lifecycle requirements of acquired models, datasets, reward models, adaptation layers, and configurations before use.
Evidence to look for: Build-versus-reuse decision, supplier evidence, signatures, component scans, malicious-content tests, acceptance record.
Related SP 800-218A tasks: PW.4.1, PW.4.2, PW.4.4
Secure coding rules address AI-specific risks, log and validate inputs and outputs in context, sanitize or drop problematic content, and encode data before it can reach interpreters or other unauthorized execution paths.
Evidence to look for: Secure coding standard, input and output validation, encoding rules, negative tests, logging and rejection records.
Related SP 800-218A tasks: PW.5.1
Approved serialization, compiler, interpreter, and build configurations reduce malicious-content and executable risks, while their versions and security-relevant features are captured in provenance records.
Evidence to look for: Serialization policy, approved build configuration, tool versions, provenance manifest, unsafe-format tests.
Related SP 800-218A tasks: PW.6.1, PW.6.2
Policies define human and automated review for AI model code and related components, and discovered malware, vulnerabilities, backdoors, and other security issues are recorded, triaged, and remediated in the development workflow.
Evidence to look for: Review policy, scan results, model artifact analysis, issue tickets, remediation and retest records.
Related SP 800-218A tasks: PW.7.1, PW.7.2
A documented test portfolio uses appropriate unit, integration, penetration, use-case, red-team, and adversarial methods, automates regression checks where feasible, and retests after retraining or new data sources.
Evidence to look for: Security test plan, representative cases, automated pipeline results, findings, retraining and new-data retests.
Related SP 800-218A tasks: PW.8.1, PW.8.2
Security-relevant model and system settings have an approved secure baseline, are implemented as defaults without weakening platform protections, and are documented clearly for administrators and integrators.
Evidence to look for: Configuration baseline, default-setting tests, administrator guide, deviation review, deployment verification.
Related SP 800-218A tasks: PW.9.1, PW.9.2
Find, analyze, disclose, remediate, and learn from AI model vulnerabilities throughout the lifecycle.
The organization analyzes model inputs, outputs, security, and performance signals, provides reporting mechanisms to producers and acquirers, watches relevant vulnerability and incident sources, and investigates credible reports.
Evidence to look for: Monitoring plan, alert records, reporting channel, intake and triage log, external advisory watchlist.
Related SP 800-218A tasks: RV.1.1
Models and related components undergo risk-based recurring automated scanning and testing, supported by human review and periodic audits to identify vulnerabilities that earlier development checks missed.
Evidence to look for: Recurring scan schedule, automated findings, audit reports, human review decisions, remediation tracking.
Related SP 800-218A tasks: RV.1.2
Vulnerability disclosure and remediation policies explicitly address AI models, assign roles and response timelines, explain relevant model limitations, and tell users how to report cybersecurity problems.
Evidence to look for: Disclosure policy, AI response playbook, contact channel, user documentation, service-level and escalation records.
Related SP 800-218A tasks: RV.1.3
Each credible issue is analyzed deeply enough to understand exploitability, impact, affected artifacts and derivatives, abnormal model behavior, and the evidence needed to choose remediation or another risk response.
Evidence to look for: Vulnerability analysis, input and output deviation review, affected-version inventory, severity rationale, response decision.
Related SP 800-218A tasks: RV.2.1
Risk response planning accounts for model rebuilding time and cost and defines tested criteria and procedures to stop use, roll back model components, revoke access, and continue essential operations through another means.
Evidence to look for: Response criteria, rollback package, rebuild estimate, kill or revoke procedure, continuity exercise, approval record.
Related SP 800-218A tasks: RV.2.2
Post-incident analysis uses retained data and development records to find root causes, tracks patterns across issues, searches for similar vulnerabilities, and changes the SDLC to prevent the same class from recurring.
Evidence to look for: Root-cause analysis, trend review, class-wide search, corrective action, SDLC update, effectiveness check.
Related SP 800-218A tasks: RV.3.1, RV.3.2, RV.3.3, RV.3.4
Source, scope, and method
The primary source is the July 2024 final publication Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile, NIST SP 800-218A. NIST designed it for AI model producers, AI system producers, and AI system acquirers. It supplements the Secure Software Development Framework version 1.1; consult both publications.
Decision Terrain selected and combined closely related tasks into 34 completion-oriented checks, then added project-authored evidence examples, statuses, system fields, JSON format, and print layout. The task IDs show where to read the complete NIST practice, task, priority, recommendation, consideration, note, and references. Completing a check is not a claim that the cited task or the complete SSDF has been implemented.
The Profile covers data sourcing, model design, training, fine-tuning, evaluation, and integration into other software. NIST places deployment and operation of AI systems, along with most of the wider data governance lifecycle, outside its scope. Pair this review with our general AI RMF checklist, Generative AI Profile checklist, and the relevant LLM or agentic security checklist.
NIST Technical Series works authored by NIST employees are not subject to copyright protection in the United States; foreign rights are reserved. See the NIST Technical Series use and licensing terms. Source citation: Booth et al. (2024), NIST SP 800-218A, doi:10.6028/NIST.SP.800-218A. Project-authored adaptation dated September 24, 2026; source reviewed September 24, 2026.