CF05-014: AI Training Data Poisoning Prevention & Detection

AI Control Library / CF-05: Data Governance & Privacy

Designation: Core | Control types represented: Operational and Technical

Control requirement

Prevent and detect unauthorized or harmful changes to AI training and adaptation data through controlled intake, provenance, access, quality checks and versioned evaluation. Investigate suspicious content before it influences accepted model behavior.

Why this matters

An attacker can affect a model without changing its code by influencing examples, labels or feedback used for learning. Ordinary data validation may miss a targeted change that looks plausible in isolation.

How the control types work together

Operational controls define scope, authority and the actions required when conditions are not met. Technical controls produce evidence or enforce the relevant boundaries. Both must apply to the same deployment and operating conditions.

When it applies

Training, fine-tuning, feedback and continuous-learning data paths, including supplier and community contributions that enter accepted datasets.

Define the assessed boundary, dependencies and evidence limitations. Tailor depth and review frequency to potential impact, and document why a particular safeguard or exclusion is appropriate to the actual deployment.

Ownership

The data and model owners are accountable; security, annotation and pipeline teams operate intake and investigation controls.

Implementation guidance

Map data contributors and learning paths, defining trusted sources, allowed changes and separation between raw intake and accepted datasets.
Protect write and labeling access, record provenance and maintain approved versions with integrity references.
Check anomalous labels, duplication, source shifts and suspicious triggers using suitable review and evaluation; quarantine uncertain contributions.
Test representative poisoning scenarios with safe synthetic fixtures and compare model behavior before approving data or training changes.

How to verify it

Use representative records and authorized controlled tests. Identify the relevant version, operating conditions and expected result before testing, and retain enough evidence to support the conclusion.

Test	Expected result
Attempt an unauthorized dataset modification	Access or integrity controls detect or prevent it.
Submit a controlled suspicious contribution	Intake identifies and quarantines it according to defined criteria.
Trace a model behavior change	The training dataset and significant transformations remain attributable.

Record a finding when required results cannot be demonstrated or practice differs materially from the approved conditions. Missing evidence limits the conclusion; it should not be treated as a successful test.

Evidence to retain

Data threat and provenance records
Intake and access controls
Quarantine and evaluation findings
Version and training-run links

Protect evidence according to its sensitivity, access needs and retention rules. Avoid unnecessary copies of personal information, secrets or confidential material, while preserving the records needed for authorized review.

If the control fails

Quarantine affected data and notify model and security owners. Assess trained derivatives and deployment exposure rather than assuming source removal corrects an already trained model.

Example in practice

Hypothetical example: A feedback pipeline receives repeated examples promoting an attacker-selected response. Review isolates the source and evaluates trained versions before allowing the feedback back into model improvement.

Related controls

Framework mappings

CSA AICM (DSP-21)
NIST AI RMF (MAP 1.6)
ISO 42001 (Cl. 8.2, A7.1)
MITRE ATLAS

Review and maintenance

Review at the interval approved by the control owner and after relevant changes, incidents or failed assessments. Update affected procedures and configuration, address evidence gaps and verify corrective action before closing findings.

Back to Data Governance & Privacy

Version 1.0