What NIST SP 800-218A asks of teams that build generative AI
NIST SP 800-218A is a voluntary community profile of SSDF version 1.1 for AI model development, meant to be used together with SP 800-218, and no certification is attached to it. When a customer, contract or internal policy asks whether your AI development follows NIST secure development practices, the honest answer starts with that scope. The profile adds practices, tasks and considerations specific to building AI models on top of the general secure software development baseline, so it does not replace SP 800-218. Your first job is to find out which of its three audiences you fall into.
The practical answer depends on your role. If your team trains or fine-tunes models, the model development practices in SP 800-218A apply most directly to your work. If you ship products or services built on models you did not train, the profile speaks to you as a producer of AI systems that use those models. If you only acquire AI systems, it speaks to you as an acquirer, so the questions you put into procurement and vendor review matter more than your build pipeline. Many organizations hold more than one role, and each role needs its own mapping to the profile.
Confirm internally which role each product line and model program holds before you answer any customer questionnaire. Then decide who reviews the claim: an independent assessor engaged by you, or the customer's own review of your evidence. Neither NIST nor DeployOpen issues a conformance statement, so any statement that your development follows SP 800-218A should be backed by documented practices and evidence that a reviewer can test. Keep the claim narrow enough that your evidence supports every word of it.
Which of the three SP 800-218A audiences applies to your team
Model producers are the teams that train, pre-train or fine-tune AI models and decide what data, code and training methods go into them. Their work is closest to the AI model development practices SP 800-218A adds to SSDF version 1.1, so they carry the most new material from the publication. Responsibilities usually include curating training data, controlling the training pipeline, evaluating model behavior before release and documenting what the model was built to do.
- Training data provenance: Record where each dataset came from, under what license, and how it was screened for poisoned or unauthorized content.
- Pipeline integrity: Restrict who can change training code, hyperparameters and checkpoints, and keep logs that tie a released model to its inputs.
- Pre-release testing: Run security and robustness evaluations against the model before release, and record the results and the decisions taken on them.
- Model documentation: Publish known limitations, intended uses and misuse cases so downstream producers can make informed choices.
- Vulnerability handling: Define how reports about the model, such as extraction or jailbreak findings, are received, triaged and fixed.
Customers and assessors typically ask for training data lineage records, change logs for the training pipeline, pre-release evaluation reports and the model card or equivalent documentation. Confirm which of these exist before a customer asks.
System producers build products and services that use an AI model, usually a model made by someone else, and wrap it in prompts, tools, retrieval, interfaces and business logic. SP 800-218A asks them to apply the secure development practices to the system they ship, including how they select, configure and monitor the model they depend on. Their risk often sits in integration: the way untrusted content reaches the model, the permissions the model is granted and the way outputs are handled.
- Model selection and pinning: Record which model, version and source each release uses, and review changes before they reach production.
- Input and output controls: Treat user content and retrieved documents as untrusted, and validate what the model returns before it triggers an action.
- Tool and permission design: Limit what agents and integrations can do, and separate high-impact actions from model-generated suggestions.
- Secure build and release: Apply SSDF practices to the application code, dependencies and containers that surround the model.
- Monitoring after release: Log model interactions in a way that supports incident investigation, and define triggers for rollback.
Ask for a bill of materials that lists the model and its dependencies, the test results for prompt injection and misuse scenarios in your own environment, and the logging and rollback procedures. Confirm with your team which model versions are in production today.
Acquirers are the organizations that buy or subscribe to AI systems and make the decision to adopt them. SP 800-218A includes them because they can set requirements in contracts, ask for evidence and control how the system is deployed in their own environment. Acquirers rarely write the model code, so their practice is mostly about specifying, verifying and governing what they receive.
- Security requirements in procurement: Write secure development expectations, evidence obligations and notification duties into the contract before signature.
- Evidence requests: Ask the supplier for documentation of its development practices, testing results and known limitations, and check that it matches the product.
- Deployment controls: Decide where the system runs, what data it can access and who can change its configuration.
- Vulnerability and change notice: Require advance notice of model changes, security fixes and significant incidents that affect your use.
- Exit planning: Define how you would replace or disable the system if the supplier fails to meet its commitments.
Customers in this role typically ask suppliers for a summary of their secure development program, the scope of their AI testing and the process for model updates. This tab describes a responsibility, not a certification path. Check with your legal and procurement teams which clauses your contracts already contain.
How SP 800-218A builds on SP 800-218 instead of replacing it
SP 800-218A does not stand alone. It adds practices, tasks, recommendations, considerations, notes and informative references specific to AI model development to the Secure Software Development Framework (SSDF) version 1.1 described in SP 800-218, and NIST intends it to be used together with that base document. The practical starting point is therefore the SSDF itself: a team reads the base practices first, establishes which of them already apply to its development process, and only then layers on the AI-specific material from SP 800-218A.
For a training, fine-tuning or model-shipping team, this sequence changes how evidence is organized. The base SSDF practices still cover the secure development lifecycle, so existing artifacts such as secure build records, code review evidence and vulnerability handling records remain relevant. The AI additions then ask for artifacts tied to model development, such as how training data and model artifacts are handled and documented. Teams should confirm with their own assessors or customers how they expect the two layers to be referenced in one document set, because the sources do not prescribe a single documentation format.
A useful gap analysis works in two passes. In the first pass, map the organization's current secure development controls against the base SSDF practices. In the second, go through the SP 800-218A additions and mark which ones apply to each of the three audiences the publication names: producers of AI models, producers of AI systems that use those models, and acquirers of those AI systems. An organization may sit in more than one audience, so each role should be recorded separately. Any mapping between the two layers and other frameworks should be checked against the publications themselves rather than assumed.
Where NIST builds on SP 800-218A in AI security work
SP 800-218A sits inside a wider set of NIST publications. The cards below name the items that reference secure development for generative AI, how each one relates to SP 800-218A, and what to check before relying on it. Several of these items are still in progress, so confirm current status on the NIST pages before citing them.
AI 600-1 governance tools
NIST AI 600-1, the Generative AI Profile, lists secure software development practices in Appendix A.1.2 among the governance tools and protocols that can be applied to generative AI systems. The profile does not restate SP 800-218A's tasks, so teams should map each suggested action to the SSDF practices they already run. Check the appendix wording against the current PDF before writing it into a policy.
COSAiS overlays drawing on SP 800-218A
NIST's Control Overlays for Securing AI Systems project is building SP 800-53-based overlays for AI systems and draws on SP 800-218A, draft NIST AI 800-1 and NIST AI 100-2e2025. For teams that already run SP 800-53 control programs, this is the route by which secure AI development practices may become control language. Overlay drafts change, so confirm the status of each use case on the project page before mapping evidence to them.
Govern function and development decisions
The AI RMF Govern function is cross-cutting and sets the accountability, policy and risk culture that secure development depends on. Decisions such as who may approve a model for release, which third-party weights are acceptable, and how security findings are escalated belong in Govern outcomes. SP 800-218A supplies the development practices, but the organization still needs documented owners and risk tolerances for them.
Manage function and post-release response
The Manage function covers prioritizing risks, responding to newly identified risks, and monitoring third-party AI, including pre-trained models used in development. Secure development ends at release in many SDLC programs, so teams should check how vulnerability reports against a deployed model reach the same triage and response process. Confirm which SP 800-218A practices your release gate and incident process actually cover.
Playbook prompts for development records
The NIST AI RMF Playbook offers suggested actions, documentation prompts and references for each AI RMF subcategory, and states that it is neither a checklist nor a set of steps. Its audit log shows the last content update in August 2023, and AIRC says it will be updated after the AI RMF is revised. Use its prompts to decide what development records to keep, then fill them with evidence from your SSDF and SP 800-218A tasks.
How to use SP 800-218A in an AI development program
This sequence turns SP 800-218A from a reading assignment into a dated, owned record of which secure development practices cover your AI models and where the gaps sit. It ends with evidence an assessor or customer can test.
Confirm your audience under SP 800-218A
Decide whether your organization produces AI models, produces AI systems that use those models, acquires AI systems, or holds more than one of these roles across different products. Engineering leadership and product owners should agree on this in writing, because each role changes which additions matter most. The output is a short scope statement naming each product or model line and its role, approved by the accountable owner for the software development program.
Read SP 800-218 for the base practices
Security architects and the development lead read SP 800-218, the Secure Software Development Framework, before reading the AI additions, since SP 800-218A is written to extend it. Note which practice groups the organization already runs, such as secure design review, code review, testing, vulnerability response and release integrity. The output is a practice-by-practice inventory showing the existing procedure, its owner and where it is recorded.
Map existing controls to the AI-specific additions
Read the practices, tasks, recommendations and considerations that SP 800-218A adds for AI model development, then match each one against the base inventory. Mark each addition as covered, partly covered or not addressed, and cite the existing procedure that covers it. Where SP 800-218A names informative references, record them so an assessor can trace the mapping. The output is a mapping table tied to your scope statement and reviewed by someone outside the team that wrote the procedures.
Record gaps with named owners
For every addition marked partly covered or not addressed, write a gap entry that states what is missing, the risk it leaves open, the proposed control and a named owner who accepts the work. Keep gaps separate from accepted risks so that leadership can see which exceptions were approved and by whom. The output is a gap register that the accountable owner signs off, which becomes the work list for the program.
Close gaps and document the changed procedures
Engineers update the affected procedures, templates and pipeline checks to meet each accepted control, then test the change on a real model build before it is relied on. Document the revised procedure, its version and the date it took effect, so that a later review can see what changed and why. The output is an updated procedure set with a change record for each gap closed, and a note for every gap still open with its approved exception.
Retain model build and release records
For each model or model update, the build team keeps a record of the training or fine-tuning inputs, the configuration used, the software components and their sources, and the checks run before release. Keeping these records in a system with access control and version history lets the team reconstruct any release later. The output is a complete build record for each release, with a named person responsible for completing it before the release is approved.
Retain review sign-offs and vulnerability handling records
Keep the review sign-offs for each release, the results of security testing, and the handling record for every vulnerability reported against a model or its surrounding system, including the decision taken and the fix applied. Confirm with your assessor or customer which retention period and format they expect, since this page does not set one. The output is an evidence set that shows each practice was performed, who performed it and what happened when a problem was found.
Review the program on a set cycle
Schedule a review of the mapping, gap register and evidence set on a cycle the accountable owner sets, and repeat it when SP 800-218A, SP 800-218 or the organization's AI products change. Track changes in NIST's publications on AI security, since NIST continues to build on SP 800-218A. The output is a dated review record that lists the changes made, the gaps reopened or closed and the owner who approved the update.
Who owns SP 800-218A conformance and who can help prepare evidence
The organization that develops, trains, fine-tunes or ships an AI model owns its secure development practices and every statement it makes to customers about them. SP 800-218A does not define a certification or accreditation program, so there is no NIST-issued badge, report or certificate that proves an organization follows it. Any claim that a product or pipeline "conforms to SP 800-218A" is the organization's own claim, and it should be worded and backed by evidence accordingly. Before a customer or contract asks for proof, the accountable owner (usually the head of product security or the engineering leader for model development) should decide which SP 800-218A practices the organization has adopted, which it has tailored, and which it has not yet addressed, and record that decision in writing.
An implementation partner such as DeployOpen can help prepare the systems and records behind those decisions. In practice that can mean configuring build and training pipelines, setting up model and dataset provenance records, wiring security testing into release gates, and organizing the artifacts that show each practice ran. Security testing of the model, its APIs and the surrounding application can also be performed by a partner. A partner prepares the systems and evidence but does not issue reports or certificates, and its work does not make the organization conformant on its own. Confirm in the scope document exactly which artifacts the partner will produce and who keeps custody of them.
Only an independent assessor, or the customer's own audit process where a contract allows it, judges whether the evidence supports a claim. Ask any assessor you engage what standard or criteria they will test against, how they will sample pipeline runs and model releases, and what form their written conclusion takes. Confirm internally whether a customer audit clause, a regulator's expectation or a framework such as the NIST AI RMF is the reason for the review, because that determines the audience for the evidence. Keep the owner of the claim, the preparer of the evidence and the party that judges it as three separate roles in your records.
What to check before you tell a customer you follow SP 800-218A
SP 800-218A adds AI-specific practices to the Secure Software Development Framework, but it does not issue a certificate, and no assessor will tell a customer you comply. The cards below cover what a customer will likely ask to see, how to check each item yourself, and which records tie the claim together.
Named owners for each audience role
SP 800-218A names three audiences: producers of AI models, producers of AI systems that use those models, and acquirers of those AI systems. Confirm that you know which role you hold for each product, and that a named person owns the practices for that role. Check that the owner can show who approved the role assignment and when it was last reviewed. Customers will ask who is accountable for model security, so have the name and the reporting line ready. Assign one owner per role, not one owner per team.
Documented development and release practices
SP 800-218A extends SSDF practices to model development, so your written procedures should cover training, fine-tuning, evaluation and release, not only application code. Check that each step has a documented owner, an entry and exit condition, and a record of the last review. Customers will ask for the procedure and proof that teams followed it for a recent release. A procedure that exists only in a slide deck will not satisfy that request.
Training records for model teams
Staff who train, fine-tune or ship models need secure development training that covers the AI-specific tasks in SP 800-218A, not only general application security. Check that training is tied to roles, that completion is recorded with dates, and that refresher training follows changes to your procedures. Customers commonly ask for training records for the people who touched a specific model release. Confirm whether your training content is current and who approved it.
Model and dataset provenance records
Provenance records show where training data, pre-trained models and third-party components came from, what license applies, and who approved their use. Check that every model version can be traced to its data sources, base model and fine-tuning inputs, with hashes or identifiers where available. Customers will ask how you know a dataset was not tampered with and whether any component came from an unverified source. Gaps here are the most common reason a stated alignment does not hold up under questions.
Vulnerability intake and response procedures
Define how external reports about your models and AI systems reach the team, how they are triaged, and how fixes are released and communicated. Check that the intake channel is published, that severity criteria are written down, and that past reports show dates from receipt to resolution. Customers will ask for your vulnerability handling process and examples of closed reports, with sensitive details redacted. Confirm that the process covers model issues such as data leakage, not only code defects.
An evidence register for every claim
An evidence register maps each SP 800-218A practice you claim to the document, record or system export that shows it, plus the owner and review date. Check that every entry points to a retrievable artifact and that the register is updated at each release. Customers will ask for the register before they ask for anything else, and they will test a sample of entries. Describe your alignment as a self-assessment, and let any independent auditor you engage issue the reports and certificates.
Questions teams ask about SP 800-218A
Is SP 800-218A mandatory for organizations that build AI models?
No. NIST presents SP 800-218A as voluntary guidance, a community profile of the Secure Software Development Framework for teams that develop generative AI and dual-use foundation models. Nothing in the publication itself creates a legal duty to follow it. The question that matters is contractual. A customer, partner or regulator may write SP 800-218A, or a general reference to secure development practices, into an agreement. Read the exact wording before you commit. If the clause says "conform to", "attest to" or "align with" the profile, ask what evidence the counterparty will accept and who decides whether it has been met.
Does SP 800-218A still apply after Executive Order 14110 was revoked?
The publication remains available and NIST has not withdrawn it. SP 800-218A was written in response to Executive Order 14110, which asked NIST for a companion resource to the SSDF for generative AI. Executive Order 14148, signed January 20, 2025, revoked EO 14110. That revocation changed the policy basis for the work, but it did not remove the guidance from NIST's catalog. Teams should treat the document as technical practice material and check whether any procurement rule or contract they face still names it. Confirm the current status on the NIST publication page before you cite it in a contract.
Does an assessor certify an organization against SP 800-218A?
No. SP 800-218A has no certification or conformity assessment program attached to it. An organization owns its development practices and documents how it meets them. An independent auditor, assessor or certification body is the only party that issues a report or certificate, and only if the engagement has been scoped for that purpose. Expect the review to test whether practices exist, are followed and leave records. Ask any assessor which standard or criteria they will test against, what report they will issue, and whether they have a defined method for an SSDF-based review of AI development.
How much effort does SP 800-218A take, and what drives it?
No effort figure is published in the research for this guidance, so treat any number you hear as unverified. The effort depends mainly on how much AI development a team does in-house. Teams that only fine-tune a third-party model face a narrower set of tasks than teams that train foundation models from data. Other drivers include how many pipelines, datasets and model releases are in scope, how much of the SSDF practice set already exists, and how much evidence the team must produce for customers. Ask for a written scope that lists the development environments, model types and deliverables covered, then estimate effort from that list.
Can an internal team apply SP 800-218A without outside help?
Yes, an internal team can apply the guidance without outside help, and many teams start that way. The SSDF and its community profile are public and written as practice descriptions. The harder work is usually cross-team: security, data science, MLOps and procurement each hold part of the evidence. Outside help is most useful for a gap assessment, for building build pipelines that produce records automatically, or for preparing evidence before an independent review. DeployOpen can plan, implement and document self-hosted platforms in a client's own environment and prepare evidence for assessment, but it does not issue reports or certificates.
How does SP 800-218A relate to SP 800-218 and the AI RMF?
SP 800-218A is an add-on to the SSDF, not a replacement for it. It adds practices, tasks and notes specific to AI model development to SSDF version 1.1, and NIST intends it to be used together with SP 800-218. The AI Risk Management Framework is a different kind of document. It covers the whole lifecycle of AI risk through Govern, Map, Measure and Manage. AI 600-1, the Generative AI Profile, lists secure software development practices among governance tools for generative AI systems, which links the two. Use SP 800-218 as the base, SP 800-218A for AI-specific development work, and the AI RMF to organize risk decisions across the program.
Which parties does SP 800-218A address, and which are we?
NIST names three audiences: producers of AI models, producers of AI systems that use those models, and acquirers of those AI systems. An organization that trains or fine-tunes a model usually falls under the first group. A company that builds a product on a model from another provider usually falls under the second. A buyer that deploys an AI system from a vendor falls under the third. Many organizations occupy more than one role, so map each AI product to each role separately. Confirm your role with counsel or the contract team, since the guidance describes audiences and does not assign legal obligations.
How DeployOpen helps teams prepare secure AI development evidence
DeployOpen plans and implements self-hosted open-source platforms inside the client's own infrastructure, and prepares the secure development practices, records and evidence that teams map against NIST SP 800-218A and SP 800-218. The organization owns its development practices; DeployOpen prepares the systems and documentation, and an independent assessor reviews them.
How we scope
- Written scope names which AI model development activities are covered, such as training, fine-tuning or shipping models.
- Scope states which of the three SP 800-218A audiences the client falls under: model producers, system producers or acquirers.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Development pipelines, code review gates and build environments are configured to produce the records that SSDF practices call for.
- Security testing of applications, APIs and AI systems is planned against the practices the written scope covers.
- Controls are implemented inside the client's own cloud accounts, data centers or air-gapped networks.
How we hand over
- Documentation maps each implemented practice to the SP 800-218 and SP 800-218A items it supports.
- Evidence packs list where each record is stored, who owns it and how it is retrieved for an assessor.
- Handover includes a review with the client's team so they can run and maintain the evidence process themselves.
How we support
- Ongoing support, platform upgrades and continuous testing are available as a retainer.
- Retainers can keep evidence current as NIST revises SP 800-218A or the surrounding AI guidance changes.
- Confirm with DeployOpen whether a given assessment or audit requires outside auditor involvement before relying on the evidence.
