Implementation guide
OWASP AISVS v1.01
Training Data Integrity & Traceability · Training Data Origin & Data Security
Watch training data for tampering
Verify that integrity monitoring is applied to guard against unauthorized modifications or corruption of training data.
OWASP AISVS v1.01, requirement 1.1.4
In plain English
Watch approved training data for changes nobody signed off, whether they come from an attacker or a faulty job, and alert someone when one happens. Hashing proves data has not changed. Monitoring tells you at the time when it does.
What good looks like
- Write access to approved training data is limited to a small, named set of people and pipeline identities.
- Every write, overwrite and delete on those stores is logged.
- An unexpected change raises an alert that reaches the data owner, and someone is expected to respond.
- A scheduled job recomputes hashes and compares them with the approved manifest.
How teams usually do it
- Turn on data-access logging for the storage (for example S3 data events in CloudTrail, or the equivalent audit logs elsewhere) and send it to your monitoring.
- Alert on any write to an approved dataset path by anything other than the release pipeline.
- Run a nightly or weekly integrity job that rehashes the data and reports mismatches.
Suggested evidence
- Access policies on the training data stores.
- The alert rules, and a sample alert produced by a deliberate test change.
- Output from recent integrity job runs.
Common mistakes
- Monitoring the code repository closely and the data not at all.
- Sending alerts to a shared mailbox nobody reads.
- Giving every data scientist write access to the approved store because it was easier during the first project.
Not sure which requirements apply to your system? Take the assessment, or browse every guide in this chapter.
Requirement text from the OWASP AI Security Verification Standard, licensed under CC BY-SA 4.0. This guidance is shared under the same licence.