Use this processor question list
Draw the processing chain before reading the contract. Identify the controller’s purpose, the processor’s tasks, data classes, storage sites, support access, and subprocessors. Check the vendor’s evidence against that chain.
| Item | Check or owner | Evidence |
|---|---|---|
| Purpose | What data and instructions? | Written processing purpose |
| Subprocessors | Who else receives data? | Named list and change notice |
| Security | How is access limited? | Control evidence and test date |
| Exit | How is data returned or deleted? | Export and deletion proof |
Apply the evidence map
Ask for a safe demonstration of one access review and one deletion request. Test the incident contact before an event occurs. Keep the written instructions, transfer decision, and exit steps with the vendor record. The law is the source for duties; the questions here are review aids.
Evidence to keep
Compare the vendor answer with the service behavior. If the contract promises deletion after exit, ask how an active record, search index, support attachment, and backup copy are handled. If the processor uses a subprocessor, identify the data sent and the access that party gets. Mark “unknown” where proof is missing. The review should end with an owner and a condition for onboarding, such as a tested deletion workflow or a narrower data feed. That is more useful than a score with no action.
Test the exit path before signing
Synthetic vendor: a support platform will hold customer tickets, attachments, and search indexes. Ask the vendor to show where each copy is stored, which staff roles can read it, which subprocessors receive it, and how deletion reaches backups and indexes. Put each answer beside the contract clause and a piece of proof. A general “secure by design” statement does not answer who can export a ticket.
Run one test ticket with fake data. Create it, export it through the normal user role, revoke that role, then request deletion. The pass result is no later access through the app or export API and a documented path for any backup copy until it expires. Keep the vendor’s deletion receipt and the known backup limit. If the vendor cannot explain a copy or subprocessor, treat it as an open procurement item. The NDP Act sets the controller and processor duties; the test turns contract promises into observable work.
Tie each answer to the processing agreement
Section 29 of the NDP Act covers engaged processors, including security measures, support for data-subject rights, compliance information, notice of new processors, and a written agreement. GAID Article 34 adds the data-processing agreement fields. Map your review to those sources rather than treating a vendor certificate as the agreement.
Make one review row for purpose, data fields, processing location, access roles, subprocessors, incident contact, retention, and exit proof. For each row, store the vendor answer, evidence ID, date, gap, owner, and onboarding condition. A new image-review tool needs its own data path and contract review even if the main KYC provider stayed the same.
Check whether the vendor also uses data for its own purpose. A processor label on a quote does not answer who decides why data is used. Ask about product analytics, model training, and onward sharing, then have the privacy lead assess each role. For the fake-record exit test, revoke user and export access, check active indexes, and document restricted backup expiry. A live-delete receipt does not prove immediate backup erasure.