Use this system-by-system sample schedule
Set a row for each data class and system. Include the event that starts the period, the source for the period, the deletion trigger, backup lag, and proof of deletion. Do not copy a sample number into a policy.
| Item | Check or owner | Evidence |
|---|---|---|
| KYC store | Identity files | Owner and legal basis |
| Payment ledger | Transaction records | Owner and legal basis |
| Support tool | Chats and attachments | Owner and legal basis |
| Logs and backups | Copied identifiers | Deletion mechanism |
Apply the evidence map
Test one closed account through the main database, support attachments, logs, vendor exports, and backups. Mark any copy that cannot be erased at once and the reason. Review the schedule when a new product or legal requirement changes the need to keep data.
Decide when deletion is complete
A retention date is only useful if the system can enforce it. For one synthetic customer, list the primary row, document store, search index, logs, analytics, and backup copies. Mark the event that starts the clock for each record: account closure, final settlement, dispute closure, or another stated trigger. When a delete job runs, check the live stores and log the job ID, count, and errors. Backups may follow a separate expiry cycle; record that cycle and limit restoration access. If a hold applies, suspend deletion only for the named records and give the hold an owner and review date. A failed deletion needs a retry queue and an alert.
Evidence to keep
A sample row needs a trigger that software can detect. “Five years after closure” is not enough if closure is a manual label that never reaches the deletion job. Name the closing event, source system, job, and proof log. Test a seeded record whose period has ended, then restore a backup and see whether it reappears. If an old copy returns, the restore process needs a deletion replay. This is a design choice the schedule should state so a backup does not undo a privacy action.
Test deletion through a backup cycle
Synthetic record: a closed support chat contains an old identity document. The schedule says the live copy expires after the approved period, but the search index and backup keep copies longer. Use linked rows for all three stores, each with its own deletion method and owner. Record the legal or business reason for each period, the deletion trigger, the owner, and the method used to verify removal. Do not invent a single retention period for every fintech record.
Run a test with fake data. Let the live record pass its expiry, then search the app, export API, index, and next restored backup. If a backup cannot support selective deletion, document its expiry and limit access until then. A deletion request needs a decision that accounts for lawful retention duties and all copies. The NDP Act requires personal data handling to follow stated purposes and retention rules; the team must also check any separate financial-record duty that applies to its licence.
Apply the source rule before setting a period
Section 24(1)(d) of the NDP Act limits retention to what is needed for the lawful basis. GAID Article 49(3) adds a six-calendar-month limit after the original purpose is met in storage-limitation cases where no timebound legal duty is provided. Article 49(4) addresses protected storage for legal claims or due diligence. The privacy owner must assess those conditions alongside the record’s sector duties; six months is not a universal fintech retention period.
Keep linked rows for live storage, index, export, and backup, each with its own owner and rule. A legal hold pauses deletion only for named records and purposes. Add hold authority, start, review date, and release event. After release, recalculate eligibility from the original clock and delete due copies; do not restart retention without a valid rule.
Restore a fake expired record in an isolated environment. Replay deletion markers before that restored system serves users or exports data. Record marker version, job result, and residual backup expiry. Alert on failed deletion and retry the exact record set. This prevents restoration from undoing a privacy action.