Use this request tracker
Copy the bank’s request into a tracker and assign each item to one owner. Match the requested period and product: a current payment API needs current access and test proof, not a policy from a retired service.
| Item | Check or owner | Evidence |
|---|---|---|
| Buyer question | What control is requested? | Name exact ask |
| Owner | Who can answer? | Assign one person |
| Artifact | What proves operation? | Link version and period |
| Release | Can this be shared? | Redact and approve |
Apply the evidence map
Check that each artifact has a date, version, and sharing approval. Redact tokens and customer records. Keep open findings and their owners visible. Send one indexed version to the bank, then log follow-up requests against that version.
Evidence to keep
Give the bank one answer per question, with an evidence ID and contact who can explain it. If the bank asks about incident response, send the approved plan and a dated exercise summary; do not send unrelated raw incident notes. If it asks about vulnerabilities, send the current test scope and closure status, including open items. A reviewer can then judge control design and operation separately. Keep the request tracker after the audit so the next team can see what the bank accepted and what it asked to refresh.
Answer one request from source records
Synthetic bank request: “Show proof that your payout approvers were reviewed last quarter.” Find the identity system’s role export, the list of people who approved payouts, the review decision for each person, and the date access changed after a removal. Link those records to the request ID. A signed access policy alone does not prove that old staff accounts were removed.
Before sharing, remove customer data and secrets from screenshots. Keep the full record in a restricted internal folder and send only the minimum redacted proof the bank asked for. If a reviewer finds an unapproved account, mark the request as open, revoke access, inspect use during the gap, and retest. Record the bank’s contractual request separately from a direct legal or CBN duty. This keeps the answer accurate and shows who owns the gap.
Keep a request row through acceptance
A synthetic request row reads: BANK-12; payout approver review; period July–September 2026; product partner payout API; owner identity lead; evidence role export E-4, reviewer decisions E-5, access-removal log E-6; gap one inactive account; action revoke under the access policy and inspect its use; status open. Add response due date, sharing approver, submitted version, and bank acknowledgement.
The role export shows assigned access. The reviewer decisions show who checked that access. The removal log shows the decision took effect. Missing any one leaves a different gap. Ask the bank which facts and period it needs, then provide the minimum records that answer that request. Mark contractual asks separately from direct legal duties.
If disclosure of raw proof is restricted, provide a redacted summary and offer controlled review through the agreed channel. Do not replace the requested fact with a broad certificate. After the bank responds, record accepted, follow-up needed, or unresolved, with the exact response date. Retain the sent pack and corrections as new versions so next year’s reviewer can see what was previously accepted.