Show the policy, the enforced configuration, a log that proves it ran, a sample of real changes, and the exceptions with approvals. A template and a slide are intent. Evidence that the check ran on real pull requests is the control.
What an auditor tests
Auditors generally test two things: that a control is designed to address a risk, and that it operated as described. A golden path is a design. Operation is shown by records. If you work toward a framework report, ask your auditor what sample they will draw and over what period, and build your evidence to match. Do not assume the framework names golden paths at all; map your controls to the requirements you are asked about.
The evidence set
| Evidence | What it shows | Where it comes from |
|---|---|---|
| Written policy | What is required and by whom | Policy document with an approval date |
| Template and config | The control is set up by default | Repository history for the template |
| Enforcement setting | The check cannot be skipped casually | Ruleset or branch protection export |
| Run records | The check ran on real changes | CI logs or check run history |
| Sample of pull requests | Findings were handled | Pull requests with scan results and decisions |
| Exception register | Deviations were approved and expire | Register with owner and end date |
| Coverage report | How many services are on the path | Catalog or inventory export |
Keep each item dated and exportable. A screenshot is weaker than an export with a timestamp.
Steps to prepare
- Write the one page policy first and have it approved.
- Export the enforcement settings quarterly and store them with dates.
- Choose a sample method yourself: for example ten random pull requests per quarter, with the scan result and decision attached.
- Reconcile your coverage report. A number like "most services" invites questions; a list with counts and named gaps does not.
- Keep exceptions in one place with approvals and end dates, and show that expired ones were closed or renewed.
- Rehearse with someone outside the team, asking them to find the weakest item.
Common weak spots
- A check that is on in the template but was turned off in some repositories. Compare settings across repos, not just in the template.
- Bypass lists that nobody reviews.
- Logs that expire before the audit period ends. Check retention.
- Policy dated after the period it claims to cover. Keep version history honest.
Be accurate about status
If your audit is in progress, say so plainly. Do not describe a report as complete or imply a certification you do not hold. Say what exists today, what is underway and what is planned, with dates.
Where Safeguard fits
Safeguard offers compliance and evidence automation, policies and gates, and SBOM generation, which can help collect the run records and exports above. Try a free scan at gold.safeguard.sh/scan.
Try it yourself
Open the mapping demo and see how one control can be tied to the requirements of more than one framework.
Click through it at your own pace, or open it full screen.
Quick check
Is a screenshot of the template enough?
Usually not. It shows design, not operation. Add dated exports and run records.
Should the sample of pull requests be chosen by the team?
Choose a method in advance and apply it consistently, and ask your auditor what they will sample.
Last reviewed: 19 October 2026.
