A customer asks whether backups are tested. “Our provider takes backups” sounds reassuring until nobody can name the last restore, the destination used or the records checked. The control is the backup. The evidence is the restore record.
Scope one fictional product
Illustrative scenario: a tiny B2B SaaS stores document type, expiry date, owner, reminder settings, user accounts and audit events. It does not need the original document. Choosing not to collect that file is a product-specific minimisation decision, not a universal rule and not a description of a real PBT system.
Draw the assets and paths before collecting badges: browser session, identity provider, application, database, exports, logs, backup provider, deployment platform and support route. Name an owner for each. Exclude what is genuinely outside the review and record that exclusion.
Build five evidence pockets
1. Access: who can enter the critical rooms?
Threat: a phished founder account or an old contractor retains access. Control direction: named accounts, least privilege, MFA where available, offboarding and recovery ownership. Evidence: a dated inventory listing service, account, role, reason, MFA state, reviewer and removal action.
OWASP’s Authorization Cheat Sheet, observed 28 July 2026, recommends least privilege, deny by default and access checks. It does not verify your account list or application routes.
2. Secrets: what can a leaked credential do?
Threat: an API key reaches a repository, screenshot or support ticket. Control direction: centralised handling, scoped credentials, restricted access, auditing and rotation. Evidence: purpose, owner, scope, storage location, rotation trigger and dated rotation record—never the secret value.
Deleting the visible string is not the same as rotating an exposed credential. OWASP’s Secrets Management Cheat Sheet supports the control direction; it is not proof that any deployment follows it.
3. Restore: can the product recover usable state?
Threat: a migration, operator mistake or dependency failure damages records. Control direction: backups, an isolated restore path and ownership. Evidence: backup selected, environment, steps attempted, records checked, failures found, duration measured by your team and follow-up owner.
No restore result is supplied here. “Backups enabled” supports a narrower claim than “recovery tested.”
4. Logs: can you investigate without creating another data leak?
Threat: too little evidence hides an access change; too much customer content widens exposure. Control direction: choose events and fields from the threat model, restrict access, define retention and exclude secrets or unnecessary content. Evidence: a redacted sample event, event purpose, access list, retention decision and one investigation drill.
OWASP’s Logging Cheat Sheet supports purpose-led logging and warns about sensitive data. It does not prescribe one universal event set.
5. Incident route: can the right person act when the main system is unavailable?
Threat: a security report or account-recovery request arrives through support and nobody owns it. Control direction: named internal decision maker, verification and escalation path, customer contact route and provider contacts. Evidence: a dated walkthrough using fictional inputs, with decisions and gaps recorded outside the system it may need to replace.
Connect threat, control, evidence and claim
| Evidence present | Maximum narrow statement to verify | Statement still forbidden | |
|---|---|---|---|
| Access | Dated account and MFA review | Named accounts in the recorded scope were reviewed on the stated date. | “Only authorised people can ever gain access.” |
| Secrets | Inventory and rotation record | The named credential was rotated under the recorded scope. | “No secrets are exposed.” |
| Restore | Completed isolated restore record | The specified backup and records were restored in the stated environment. | “All data is always recoverable.” |
| Logs | Reviewed events and access | The listed events and fields were inspected on the stated date. | “Monitoring detects every incident.” |
| Incident route | Walkthrough and named owner | The fictional report reached the named owner through the tested route. | “We are prepared for every incident.” |
Use frameworks as maps, not borrowed assurance
CISA’s small-business guidance recommends ownership, incident planning, MFA, patching, backups and restore testing, while explicitly rejecting a guarantee that incidents will not happen. NIST CSF 2.0 organises risk management around Govern, Identify, Protect, Detect, Respond and Recover. OWASP ASVS 5.0.0 provides versioned technical verification requirements for web applications.
These sources can reveal a missing pocket. They do not certify a product. If you use ASVS, cite the exact version and requirements checked, retain a scope-and-evidence matrix and avoid “ASVS aligned” unless an authorised review supports that exact statement. Check the current version and update date of any framework or guidance page before using it for a product decision.
Keep the first evidence folder narrow
Ignore a giant compliance spreadsheet, a security badge, polished policy prose and controls that have no owner or artifact. Do not claim encryption everywhere, industry-standard security, certification or compliance from a hygiene pass. Privacy disclosures also need their own runtime and legal review; a security folder does not settle them.
Index the evidence, not the aspiration
| Index field | What the record must say |
|---|---|
| Scope | Product, environment, assets, flows, owner, review date and explicit exclusions. |
| Threat | The concrete path to harm this record addresses. |
| Control | The setting, process or design choice inspected or exercised. |
| Evidence | Authorised redacted artifact, method, result and unresolved gap. |
| Supported statement | The narrow sentence the evidence could support, plus the broader sentence it cannot. |
The memory test
The folder must survive the founder’s memory. If the only proof of a restore, key rotation or access removal is “I remember doing it,” the next incident starts with archaeology.
Stop where the evidence stops
Choose one real product and create five dated records: access review, secret review, restore test, log review and incident-route walkthrough. Until those artifacts exist, the honest status is “review pending.” Do not turn it into a security, audit or compliance claim.
Standards behind the evidence folder
- CISA, Cyber Guidance for Small Businesses, observed 28 July 2026; the page recorded an April 2024 update, so check its current status before relying on it.
- OWASP, Secrets Management, Logging and Authorization cheat sheets, observed 28 July 2026; use the current versions when updating the evidence folder.
- OWASP, Application Security Verification Standard 5.0.0, observed 28 July 2026; cite exact requirements if used.
- NIST, Cybersecurity Framework 2.0, observed 28 July 2026; a risk-management map, not a certification.