Auditors accept evidence that a control operates, not statements that it does. For third party models, keep six records: an inventory, approval records, pinned versions with hashes, results of checks, a change log and retirement records. Dated, exportable records beat screenshots taken the week before an audit.
What the control is, in plain words
The control is simple to state: we know which third party models we use, we approved them before use, we run the approved version, and we notice and review changes. Evidence shows each part is true over a period of time, not at one instant. This post does not describe any specific framework requirement, so check the wording of the framework you are assessed against and ask your auditor what they accept.
The evidence list
| Record | What it proves | Where it comes from |
|---|---|---|
| Model inventory | You know what is in use | Inventory file or system, with owner, source, hash and location |
| Approval record | Someone reviewed before use | Ticket or pull request with named approver and date |
| Pinned revisions | The approved version is what runs | Version controlled config with full commit hashes |
| Hash manifest and check results | Files match what was approved | CI logs from verification steps |
| Format and loader review | Risky formats and code were considered | Checklist attached to the approval |
| Change log | Upstream changes were reviewed | Alerts and tickets with outcomes |
| Retirement record | Unused models are removed | Dated entries with owner |
| Incident record | Problems were handled | Tickets and post incident notes |
Make the evidence a by product of the work
Evidence collected by hand late is expensive and weak. Build it into the steps. A pull request template that asks for source, hash, license and approver produces the approval record automatically. A CI check that verifies hashes produces logs with timestamps. A webhook that opens tickets on upstream changes produces the change log.
Sampling is how audits work
Expect an auditor to pick a few models and ask you to walk through each one: where it came from, who approved it, what version runs, and what happened when it changed. Make sure any model you pick can be explained from records alone.
Common weaknesses
- An inventory that exists but is stale.
- Approvals in chat messages that cannot be exported.
- Models loaded by name with no pin, so the record cannot prove what ran.
- No record of retirements, so old models are unaccounted for.
Be careful with claims
Describe what you do, with dates. Do not describe a certification or report you do not hold, and do not imply a vendor's attestation covers your own use of a model.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a control links to the evidence that supports it.
Safeguard's compliance and evidence automation can collect records from your software pipeline, and policies and gates produce dated enforcement records. Try the free scan.
Quick check
Is a screenshot of the inventory enough?
Weak evidence. Prefer dated, exportable records that show the control operating over time.
Do I need evidence for models called through an API?
Scope depends on your framework and auditor. Ask them what they expect for hosted models.
Last reviewed: 19 October 2026.
