Use this evidence owner map
Build the index around four questions: what moves money, who can access customer data, how the team detects misuse, and how it restores service. Link each answer to a dated record. Add the last access review and a failed restore drill if either is missing; a pack that lists only successes hides the work still open.
| Item | Check or owner | Evidence |
|---|---|---|
| Asset and data-flow inventory | Engineering | Current architecture diagram and revision date |
| Access control test | Security | Test IDs and redacted result |
| Incident runbook | Operations | Owner, exercise date, and escalation path |
| Pentest closure | Engineering | Finding ID, fix commit, and retest result |
Test and retest
Hand the pack to someone who did not build it. Ask them to find proof for one transfer, one support access, and one incident alert. If they cannot follow the path from policy to test to owner, fix the index before sharing it. Keep an internal version with raw details and a redacted buyer version.
Check the pack before sharing
Open every evidence link as a reviewer with the planned access level. Confirm that each file shows its system version and test date, and that the link will still work during review. A broken link makes a valid control hard to verify. Keep a manifest with the file ID, control, owner, date, and share level. Run a search over the redacted pack for tokens, account numbers, internal hostnames, and personal contact details. Ask the owner to approve any exception before release.
Keep the buyer copy separate from raw test traces. The buyer copy should show scope and outcome; the restricted copy can hold requests, logs, and exploit steps for named reviewers. Record who received each version. If the payout API changed after the last test, label that result historical and schedule a new check. This keeps a true old test from becoming a false current claim.
Evidence to keep
Check a second path: account recovery. Link the recovery decision rule, support identity check, a denied takeover attempt, and the audit event. This path often lives outside the payment team, so the pack needs both teams to name owners. For each path, mark whether proof is design, operation, or test. A policy can be current while its last exercise is old. A pack passes internal review when each claim points to the right kind of proof and a reader can tell which gaps remain.
Follow one payment change through the pack
Synthetic example: a new payout feature lets an operations user raise a daily limit. Start the evidence row with the actual API route, the role that may call it, and the database value it changes. Link the design rule to a test that submits the same request as a customer and as an operations user. The customer call must fail without changing the limit. The operations call must create one approval and one audit event with the old and new value.
Now trace the same change into a release. Save the commit and deployed build ID, a redacted request and response, the audit event ID, the tester, and the test time. The screenshot of a settings page alone proves little: it does not show that the server enforces the role. If the route changed after the test, inspect whether its control and release path changed. Record that impact check and retest the affected paths before claiming current coverage. OWASP’s authorization testing guide recommends checking role and data access as features change.
Use one row per claim
A useful manifest row reads: control PAY-APPROVAL; claim “maker cannot release an unapproved payout”; owner payments lead; route release API; build R-18; test date 1 October 2026; evidence E-17; result denied with zero provider calls; reviewer security lead; sharing redacted buyer copy. Add a link to the allowed-user test on the same build. This is a synthetic row, not a claim about a live product.
Label each artifact by what it proves. A role policy is design evidence. A completed access review is operating evidence. A denied request and unchanged provider state are test evidence. If the pack holds only the policy, mark the test missing. Put the missing item, owner, and next action in the manifest; a folder full of nearby files does not answer the claim.
Set change triggers against the control. A new API guard, worker release path, or identity provider calls for a new test. A heading edit needs a documented impact check, not an automatic claim that the old security result is invalid. Test access to the shared copy with a reviewer account and confirm restricted links stay restricted.