The record says backup-job-017: completed. Nobody has recorded a restore, inspected recovered dates or checked for duplicate reminders. That is not enough to tell a customer recovery has been tested.
Fictional scenario: Mira operates a small B2B document-expiry app storing document type, expiry date, owner and reminder settings, not original files. All values and records below are fictional. No backup, restore, credential rotation, access review or incident drill was performed; no real product's security is assessed.
Restore: find out whether saved dates are usable
A migration overwrites expiry dates. Mira needs usable records, not just a completed backup job. CISA's small-business guidance recommends regularly testing partial and full restores, not merely scheduling backups.
| Field | Filled example |
|---|---|
| Owner and risk | Mira, fictional operator. Recover document-expiry metadata after a migration overwrites dates. |
| Evidence present in the scenario | backup-job-017 reports completed; backup label bkp-demo-017; environment demo. |
| Decision | Backup completion is recorded. Restore is not observed; “recovery tested” is unsupported. |
| Proposed correction | Restore bkp-demo-017 into isolated demo-restore, then compare the two records below with their expected values. |
| Side-effect boundary | No reminder sender may be enabled in demo-restore. Before the drill, verify that neither a scheduled job nor another sending route can deliver reminders. |
| Observation and duration | Not recorded. The drill has not run; no start time, end time or measured recovery duration exists. |
| Next evidence to collect | Actual restore steps and errors, inspected values, sender-isolation check, measured duration and Mira's follow-up for any mismatch. |
| Record | Expected expiry | Expected owner |
|---|---|---|
doc-101 | 2027-01-31 | user-A |
doc-102 | null, not a replacement date | user-B |
Preserve null: “no expiry date” is not a blank to fill. A matching row count could hide a changed date or swapped owner. Retain and investigate either mismatch before calling this narrow restore successful.
No attachments are collected, so attachment recovery is outside this example. Cross-region and identity-provider restoration remain unexamined. Recovery-time and recovery-point objectives (RTO and RPO) are neither specified nor demonstrated. Restoring these two metadata records would not establish them.
Access: separate an account list from an authorization check
Keep five evidence pockets: access, secrets, restore, logs and an incident route. Each needs an owner and observations; a restore record cannot stand in for the other four.
List accounts across the deployment platform, database, identity provider, backup service and support system. Record each account's role, business reason, MFA state, reviewer and removal action. Distinguish “MFA available” from “MFA enabled.” An old contractor's unnecessary administrator role needs a removal task, not just an inventory row.
OWASP recommends least privilege and deny by default. An account review addresses who holds a role; application checks must separately establish what a request using that role can do. For tenant-level reads and writes, use the two-tenant RLS request specification rather than treating an account list as evidence of isolation.
Secrets: screenshot deletion leaves the exposure unresolved
Fictional exposed-credential record: demo-mail-key-v1 is a nonsecret label, not a usable key. It represents a mail-provider credential exposed in a support screenshot. Mira deleted the screenshot but has no revocation receipt. The exposure remains open.
| Field | Filled example |
|---|---|
| Owner / affected dependency | Mira / the app's reminder-mail integration. |
| Old and proposed labels | demo-mail-key-v1 exposed; demo-mail-key-v2 proposed as a scoped replacement. Both are nonsecret labels, not usable keys. |
| Authorized action to arrange | Revoke v1 through the provider's secret-management process, issue a scoped replacement and update dependent configuration. |
| Evidence still needed | A provider revocation receipt identifying v1 without its value; an authorized isolated check that v1 is rejected and that v2 performs the intended operation with only the intended scope. |
| Current result | No receipt, rejection result or replacement result supplied. No real call was made. |
OWASP's secrets-management guidance covers revocation and rotation, including attempts to use a revoked secret. Verify through the authorized provider process without logging credentials or enabling customer reminders. Screenshot copies and repository-history cleanup need separate investigation: revocation does not remove those copies.
Logs: preserve the access change, not the document
An access-change event should identify the actor, affected membership and request. OWASP's logging guidance calls for purpose-led event selection and excluding sensitive fields such as access tokens.
Fictional metadata event; all values are invented, not observed: operator-demo-admin is separately authorized to revoke memberships in org-B, not a tenant user acquiring cross-tenant power. The accepted result illustrates the format; no revocation happened.
- event_id
- audit-demo-41
- actor_id
- operator-demo-admin
- admin_scope
- authorized membership administration for org-B
- action
- membership_revoked
- target_user_id
- user-B
- organization_id
- org-B
- result
- accepted (fictional)
- correlation_id
- req-demo-19
The example excludes tokens, secret values, email addresses and document bodies. For real events, record actual timestamps, permitted readers, retention periods and storage location. Test delivery and retention before relying on the log during an investigation.
Incident route: decide who can act without the app
If the deployment account is unavailable, an incident plan stored only behind that account is difficult to use. Keep an access-controlled route outside the affected system with a primary decision maker, a backup, verified provider contacts and a customer contact path. Agree how an urgent support report will be checked before anyone resets access or discloses information.
Proposed fictional walkthrough, not performed: reminder-mail credentials are reported exposed while the app is unavailable. Mira owns the revocation decision; her designated backup must find the provider contact and reach her without the app. Record whether the handoff happened, any obstruction and who will fix it.
Use a framework to find omissions
OWASP ASVS listed 5.0.0 as stable when checked on 13 September 2026. Record the version and individual requirements actually reviewed. Citing ASVS is not an assessment, audit or certification of a product.
NIST CSF 2.0 groups outcomes into Govern, Identify, Protect, Detect, Respond and Recover. This taxonomy can reveal omissions, such as backup records with no recovery owner. It neither prescribes an implementation nor establishes that an outcome was achieved.
The linked CISA and OWASP guidance was also checked on 13 September 2026. CISA's page still noted an April 2024 update and explicitly warned that following its advice does not guarantee freedom from incidents. Check applicable versions and page status again when using these references for a product decision.
Produce the missing restore observation
If you only have a backup-job entry, arrange an authorized isolated restore with a named operator and sending disabled. Save restored dates and owners beside their expected values, measured elapsed time and any errors. The next person can then inspect that recovery attempt without mistaking a job status for a restore result.