When a prototype becomes a product, keep dated records of who reviewed it, which dependencies were approved, who has access, how changes are controlled and how issues were fixed. Customers and auditors ask for evidence of how you build software, and records created at promotion are far easier than reconstructing them later.
Why evidence starts at promotion
Early buyers send security questionnaires. They ask how code is reviewed, how vulnerabilities are handled and who can change production. If your product began as a weekend prototype, you may have good practices today and no record of when they began. Collecting evidence as you promote costs minutes. Recreating it costs days and often cannot be done honestly.
NIST's Secure Software Development Framework is a common reference for what to record. It describes a core set of high-level practices that can be integrated into any development life cycle model, which makes it a handy checklist for the types of records to keep.
The evidence set
| Area | What to keep | Where it lives |
|---|---|---|
| Ownership | Named owner and backup | Repository file |
| Code review | The review record from promotion and later pull requests | Pull request history |
| Change control | Branch protection settings and required checks | Repository settings export |
| Dependencies | Lockfile, SBOM and approval notes | Repository and artifact storage |
| Vulnerabilities | Scan results, decisions and fix dates | Tracker or scanner |
| Access | Who can deploy and who has admin rights, with review dates | Access review record |
| Secrets | Rotation date after promotion | Ticket |
| Data | What is stored, where, and retention | Data note |
Branch rules as evidence
GitHub documents that protected branches can require pull request reviews and status checks before merging. A screenshot or export of those settings, dated, shows that change control is enforced rather than hoped for.
Be accurate in what you say
Evidence supports statements, but it does not stretch them. If you started reviews last month, say so. If an audit is in progress, say it is in progress. Do not describe a framework as met or a report as complete when it is not, and do not claim a certification you do not hold. Your compliance advisor can help word things correctly.
A light routine
- At promotion, export the repository settings and save the review record.
- Each month, store a fresh scan result and note decisions.
- Each quarter, review access and save the outcome.
- Keep everything in one folder with dates in the filenames.
Where Safeguard fits
Safeguard provides compliance and evidence automation, SBOM generation and dependency scanning, and policies with gates, which can produce dated records as a by-product of normal work. Try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how one piece of evidence maps to more than one framework control.
Quick check
Can I backfill evidence for the prototype period?
You can document what you know, labelled with the true date it was written. Do not backdate records or imply controls existed when they did not.
Do I need an audit to keep evidence?
No. Keeping evidence is good practice on its own, and it makes any later audit or questionnaire easier.
Sources
Last reviewed: 19 October 2026.
