CISA AI Data Security Guidance: Applying the 2025 Practices

Most AI security failures start with data that nobody can prove is the data they approved. In May 2025 the NSA's Artificial Intelligence Security Center, CISA, the FBI and the national cyber security agencies of Australia, New Zealand and the United Kingdom published a joint Cybersecurity Information Sheet, "AI Data Security: Best Practices for Securing Data Used to Train & Operate AI Systems" (version 1.0, TLP:CLEAR). It gives ten general practices and specific mitigations for three risk areas: the data supply chain, maliciously modified data and data drift. This guide turns that sheet into a working programme: what each practice means in a pipeline, who owns it, how to roll it out and how to measure it. It is for ML platform, data engineering and security teams; for poisoning attack mechanics see the AI Data Poisoning and Backdoors Guide, and for the OWASP framework see the GenAI Data Security Risks and Mitigations Guide.

Key takeaways

Signed provenance is the backbone. The sheet asks for a cryptographically signed, append-only provenance record and signatures on the original dataset and on each revision.
Verify before every training run. It recommends verifying the signed database before training and aborting and auditing if verification fails.
Curated datasets can still be poisoned cheaply. The sheet cites split view poisoning of URL based datasets for about 1,000 US dollars in many cases and 60 US dollars for COYO-700M.
Outputs inherit input classification. AI outputs should be classified at the same level as the data that went in.
Abrupt drift is a security signal. Gradual change suggests ordinary drift; sudden dramatic change suggests someone is trying to compromise the model.

What the guidance is and where it applies

The NSA press release dated 22 May 2025 names the authoring agencies and the audience: system owners and administrators in the Department of Defense, National Security Systems and the Defense Industrial Base. The sheet itself widens that to federal civilian agencies and critical infrastructure owners and operators, and it builds on the earlier NSA joint guidance "Deploying AI Systems Securely". It is guidance, not regulation, but agencies and their suppliers will use it as a reference point.

The sheet uses the six lifecycle stages from the NIST AI Risk Management Framework and maps each risk to them.

Lifecycle stage	Data supply chain	Maliciously modified data	Data drift
1 Plan and design	Yes	No	No
2 Collect and process data	Yes	Yes	No
3 Build and use model	Yes	Yes	No
4 Verify and validate	Yes	Yes	No
5 Deploy and use	Yes	Yes	Yes
6 Operate and monitor	Yes	Yes	Yes

The ten general practices, made operational

The first two columns follow the sheet. The third column is NHI Mgmt Group's suggestion for how to implement it in a typical ML platform.

#	Practice in the sheet	How to implement (our suggestion)
1	Source reliable data and track provenance in a signed, append-only record	Dataset registry where each entry holds source, licence, collection date and content hash; write once storage
2	Verify integrity in storage and transport with checksums and cryptographic hashes	Hash manifests generated at ingest and checked at every pipeline hop
3	Digital signatures on originals and each revision, by the person who made it; quantum resistant standards FIPS 204 and 205; trusted certificate authorities	Signing service with per user and per pipeline keys; record signer identity with each revision
4	Trusted infrastructure: zero trust architecture and secure enclaves	Isolated training environments; confidential computing where data sensitivity justifies it
5	Classify data and apply access controls; outputs at the same level as inputs	Labels carried from datasets to models, embeddings and logs
6	Encrypt with AES-256 at rest, in transit and in processing; TLS with AES-256 or post-quantum encryption in transport	Platform default encryption checked by policy; TLS configuration baseline
7	Store data in systems whose cryptographic modules meet FIPS 140-3	Validated module list in the storage standard
8	Privacy preserving techniques: masking, differential privacy, federated learning with secure multi party computation	Masking at ingest for personal fields; differential privacy only where accuracy loss is accepted
9	Secure deletion per NIST SP 800-88: cryptographic erase, block erase or overwrite	Crypto erase by key destruction for cloud storage; deletion records
10	Ongoing risk assessment using NIST SP 800-37 Rev. 2 and the NIST AI RMF	Data risk review at each major dataset or model change

For deletion obligations across prompts, embeddings and fine tunes, see the AI Data Retention and Deletion Guide.

Risk area 1: the data supply chain

Split view poisoning: curated datasets such as LAION-2B and COYO-700M list URLs, and domains that expire can be bought and made to serve different content. Mitigations in the sheet: curators attach hashes to all referenced raw data, consumers check hashes and discard failures, curators re-scrape periodically and certify datasets at publication.
Frontrunning poisoning: attackers edit crowd sourced pages just before scheduled snapshots. The sheet cites analysis suggesting up to 6.5 percent of Wikipedia could be poisoned this way. Consumers should use only snapshots verified by a trusted party; collectors should randomise snapshot order and freeze edits long enough for review.
Web crawled data: least curated, with no original hashes. The sheet suggests consensus approaches, such as trusting an image and caption pair only if it appears on many independent sites, and says organisations without the resources for due diligence should not use web crawled data until trust infrastructure exists.
Consumer safeguards: verify datasets before ingest and sign them at ingestion; use content credentials for media, noting they show origin and edits but not truth; require foundation model providers to attest to training data sources and certify they contain no known compromised data.

Supplier attestations fit into your AI bill of materials; see the AI Supply Chain and AI-BOM Guide and the Model Supply Chain Guide.

Risk area 2: maliciously modified data

Sub-risk in the sheet	Mitigations in the sheet
Adversarial machine learning (poisoning, adversarial examples, model inversion)	Anomaly detection before training; sanitisation before every training or fine tuning run; secure training pipelines; ensemble methods; anonymisation
Bad data statements (missing or tampered metadata)	Metadata governance; completeness and consistency validation before training; enrichment from trusted reference data
Statistical bias	Regular training data audits; representative data; non-overlapping training, development and evaluation splits; a repository of observed bias
Inaccurate information	Remove where feasible; verify provenance; augment with non-malicious data during training; integrity checks and statistical deviation analysis
Duplicates	Deduplication with fuzzy matching, hashing or clustering

Risk area 3: data drift

The sheet defines drift as change in the statistical properties of an operational system's inputs over time, and treats it as expected. Its causes include upstream pipeline changes (units switching from miles to kilometres), new data types the model has never seen (a new malware family) and changed input to output relationships (a merger altering access patterns). Mitigations are a data management strategy that tracks new data elements, data quality tools for training data selection, input and output monitoring that compares training and live distributions with statistical methods, and retraining, cleansing or ensembles. Check frequency depends on the use case; the sheet says high stakes uses such as healthcare need continuous monitoring. The key security point: gradual change suggests drift, abrupt change suggests attack, so route abrupt drift alerts to the security team, not only to data science.

Where identity fits

Signing, provenance and access control all depend on identities that are mostly non-human: ingestion jobs, training pipelines, feature store connectors and the signing service itself. Our recommendations: give each pipeline stage its own workload identity with write access only to its own output location; keep signing keys in a hardware security module or managed key service and never in pipeline variables; and review which identities can write to approved datasets, because a poisoning attack usually needs write access to something you own. The AI data access review guide covers the review process.

Rollout plan

Inventory: list training, fine tuning and retrieval datasets with owner, source and classification.
Hash first: generate hash manifests for approved datasets and verify them in pipelines in report only mode for one release cycle.
Sign: introduce signing at ingest and on each revision; start with the highest risk model.
Enforce: switch verification to blocking, so a failed check stops training and opens an audit ticket, as the sheet recommends.
Supplier attestations: add data source attestation clauses to foundation model and dataset contracts.
Drift monitoring: deploy input and output distribution monitoring with separate thresholds for gradual and abrupt change.
Rollback: keep the last verified dataset and model versions so a failed verification or abrupt drift can revert quickly.

Decision guidance

Using a third party foundation model only: focus on supplier attestations, retrieval data integrity and drift; most of practices 1 to 3 apply to your fine tuning and retrieval data.
Fine tuning on internal data: full signing and verification on the fine tuning set; classification of the resulting model at the level of its data.
Training on web scale data: follow the sheet's caution; without curation capacity, avoid web crawled data.
Small teams: start with hashing, write access reduction and verification gates before investing in enclaves or post-quantum signatures.

Metrics

Provenance coverage: percentage of datasets used in production models with a signed provenance record.
Verification gate: percentage of training runs that passed a blocking integrity check.
Write access: number of identities with write access to approved datasets.
Supplier attestations: percentage of model and dataset suppliers with a data source attestation.
Drift response: median time from an abrupt drift alert to a security triage decision.

Common failure patterns

Hashes stored next to the data: an attacker who can change the dataset can change the manifest too; sign manifests and store them separately.
Verification in report mode forever: checks that never block training give a false sense of control.
Retrieval sources left out: teams secure training data but let anyone write to the documents a RAG system retrieves.
Outputs declassified by default: embeddings and model outputs are stored at a lower level than the data that produced them, against practice 5.
Drift alerts only to data science: abrupt shifts are investigated as quality issues instead of possible attacks.

Framework mapping

Framework	Reference	Practice
MITRE ATLAS	AML.M0025 Maintain AI Dataset Provenance	Practices 1 to 3
MITRE ATLAS	AML.M0007 Sanitize Training Data	Maliciously modified data
MITRE ATLAS	AML.T0020 Poison Training Data	Threat addressed
NIST SP 800-53 Rev 5	SR-4, SI-7	Provenance; information integrity
NIST SP 800-53 Rev 5	AC-3, SC-8, SC-28, MP-6	Access, encryption in transit and at rest, sanitisation
NIST CSF 2.0	ID.AM-07, PR.DS-01, PR.DS-02, DE.CM-09	Data inventory, data protection, monitoring

Practitioner checklist

Build a dataset inventory with owner, source, classification and hash.
Store provenance in a signed, append-only record kept apart from the data.
Sign datasets at ingest and on each revision, recording the signer.
Make integrity verification a blocking gate before every training and fine tuning run.
Classify models, embeddings and outputs at the level of their input data.
Reduce write access to approved datasets to named workload identities.
Require data source attestations from model and dataset suppliers.
Monitor drift and route abrupt changes to security triage.

CISA AI Data Security Guidance Guide: Applying the 2025 Joint Best Practices for Securing Data Used to Train and Operate AI Systems