Keep answers consistent with a claims register: one row for each statement you make about security, with an owner, a link to evidence, a scope, the date last verified and a review date. Answer new questionnaires from the register, and retire any claim that no longer has fresh evidence.
What a claims register is
It is a table, not a program. Each row is a sentence you have told a customer or published, such as "we scan dependencies on every pull request". Next to it you record how you know that is true. If the evidence goes away, the claim goes away.
Columns to include
| Column | Example |
|---|---|
| Claim | We require review before merging to the main branch |
| Scope | Production repositories, listed in the inventory |
| Owner | Head of engineering |
| Evidence | Branch protection export, file 04 |
| Last verified | 2026-10-12 |
| Next review | 2027-01-12 |
| Where used | Questionnaire answers, trust page, sales deck |
The last column is easy to skip and very useful. When a control changes, you know every document that needs updating.
How to build it in an afternoon
- Collect your last three questionnaires and your public pages.
- Pull out every factual security statement. Ignore marketing adjectives.
- For each, find the setting, file or report that proves it. If you cannot find one, mark it unverified.
- Fix or soften unverified claims before using them again. Replace absolutes with limited statements.
- Assign an owner to each row.
- Set review dates, quarterly for fast moving controls and yearly for stable ones.
Handling drift
Controls change: a tool is replaced, a team grows, a repository is added. When that happens, update the row first, then the documents listed in its where used column. Add a line to your engineering change checklist: does this alter a security claim?
Quarterly, the owner re-checks the evidence. If a setting no longer matches, either fix the setting or correct the claim. Never leave both in place.
What to do when an answer was wrong
Mistakes happen. Correct the register, then decide whether the customer needs to be told. If an answer was materially untrue, tell them promptly and plainly. This is an honest business practice, not legal advice, so involve counsel where a contract is at stake.
Why this beats memory
Teams without a register rely on whoever remembers what was said. Registers survive turnover, speed up the next questionnaire and make audits and customer reviews calmer because the evidence is already linked.
What not to put in it
Do not record claims you hope will be true, certifications you do not hold, or customer names you have no permission to use. Keep the register internal. It can reference sensitive evidence.
Safeguard's compliance and evidence automation can keep the evidence side current, such as dated dependency inventories and scan results, which you then reference from each row. A free scan is at https://gold.safeguard.sh/scan.
Quick check
How many claims should a startup have?
Often 30 to 60 statements. Fewer, well evidenced claims are better than a long list nobody maintains.
Who should edit the register?
Claim owners edit their own rows, and the process owner reviews changes.
Is a spreadsheet enough?
Yes at this size. Use version history so you can show what you said and when.
Last reviewed: 19 October 2026.
