Use this operational contract checklist
Read the draft against the real data flow. If a vendor receives ID images, contract terms should cover access, purpose, subprocessors, breach notice, return, and deletion of those images and copies.
| Item | Check or owner | Evidence |
|---|---|---|
| Access and use | Can vendor use data beyond service? | Set instructions |
| Incident notice | Who calls whom and when? | Name contacts and trigger |
| Subprocessors | Can new parties join? | Require notice and review |
| Exit | Can data and keys be recovered? | Test export and deletion |
Apply the evidence map
Give counsel the system map and a list of operational questions. Ask the vendor to show an exit export and a test deletion before the contract is relied on. This checklist guides review; it does not claim that one clause text fits every licence or deal.
Make a clause testable
A contract term should name the party that performs the control and the evidence a buyer can request. For example, an incident notice clause needs a trigger, contact, timeframe from the signed agreement, and a record of the notice sent. A subprocessor clause needs an approved list, change notice, and the buyer’s review path. Do not copy a generic clause that conflicts with the actual service. In a renewal exercise, ask for the latest access review, breach exercise, and deletion certificate under the agreed scope. Mark “cannot provide” as a gap for commercial and legal review. A clause without a way to verify performance is weak operational evidence.
Keep a versioned list of each service the vendor actually provides. The contract review should follow the live data flow, since a vendor may use a subprocessor only for one feature.
Evidence to keep
Separate terms that allocate responsibility from evidence that a vendor can perform them. An incident clause might name a contact and notice route; test the route with a harmless drill. A deletion clause might promise return or destruction; ask for a sample export and deletion result. Counsel can then review wording with evidence from operations. If the vendor cannot meet a requested step, record the gap, any alternate control, and the person accepting risk before sending live data.
Turn a notice clause into a clock
Synthetic vendor incident: a cloud support vendor discovers that an employee exported customer tickets. The contract says “promptly notify,” but nobody can tell when the controller will hear. Define the trigger, first contact, secure channel, minimum first facts, follow-up cadence, and named backup contact. Keep the vendor’s obligation distinct from the controller’s own duty under the NDP Act.
Run a tabletop test. The vendor sends a first notice with discovery time, data category, affected systems, containment, and unknowns. The controller records receipt time and starts its own risk and reporting decision. If the notice goes to an inactive mailbox, repair the contact path. A useful clause also covers audit access, subprocessor changes, data return, deletion proof, and service exit. Tie each promise to a test or delivery record.
Set acceptance fields for the signed terms
NDP Act Section 29 requires the written processing arrangement; GAID Article 34 lists agreement content. Give counsel the actual purpose, location, data flow, security measures, and party roles. A general commercial promise is not a substitute for those processing terms.
For each operational term, record clause ID, actor, trigger, agreed clock, first deliverable, evidence, and failure action. For incident notice, the clock starts at the event defined in the agreement and must support the recipient’s own legal duties. Do not invent a universal vendor deadline. Require a working primary and backup contact, secure first notice, and updates for missing facts. Test the route before sending live records.
For new subprocessors, define notice, information supplied, review path, and the contract’s action if the customer objects. For exit, specify export format, access revocation, live deletion, backup restrictions, expiry, and proof. A vendor that cannot meet a term needs an explicit gap and decision; stronger wording alone cannot make the promised operation work.