Implementation worksheet · 7 min read
A Lifecycle Platform Procurement Handoff Checklist
Hand procurement, legal and security a packet, not a recommendation: every requirement with the evidence behind it and its evidence class (tested in your trial, documented by the vendor, or said in a demo), projected volumes per channel for the contract term, the personal data the platform will process and where, the sub-processors, the exit terms you need, and the open risks with owners. Each row names the contract term or document that would make it binding. Anything resting only on a verbal claim gets written confirmation or a contract clause before signature, including which plan tier it belongs to.
Scope: the evaluation team (lifecycle lead, analyst, engineer) handing a chosen lifecycle or engagement platform to procurement, legal and security. Starting state: a preferred vendor, trial notes and demo recordings. Boundary: the handoff packet and its test matrix; the negotiation itself stays with procurement. Intended outcome: no requirement reaches signature without either tested evidence or a written commitment.
Put it into practice
1. Turn requirements into rows with an evidence class
For each requirement, record what you observed and how: tested in your trial with your own data, documented in the vendor's published material, or stated verbally in a demo. The class matters more than the claim, because only the first two survive a staff change on either side.
2. Model volumes for the whole term
Contacts, monthly active users and messages per channel per month, with growth. Vendors price on different units, and the overage terms are where a quote that fits year one stops fitting year two.
3. Describe the personal data the platform will process
Categories of data and of data subjects, purposes, storage location and retention. If the GDPR applies and the vendor processes personal data on your behalf, Article 28(3) requires a contract that sets out the subject-matter, duration, nature and purpose of the processing, the type of personal data and the categories of data subjects, with obligations that include processing only on documented instructions, confidentiality, security, help with data subjects' requests, and deletion or return of the data at the end.
4. List sub-processors and how changes are notified
Article 28(2) says a processor may not engage another processor without the controller's prior specific or general written authorisation, and under a general authorisation it must tell you about intended changes and give you the chance to object. Record the vendor's current list and the route by which changes reach you.
5. Write the exit terms you need now
Export formats for profiles, events, consent records with their timestamps, and message history; the timeline for export; and deletion at the end. Exit terms cost little to agree before signature and a great deal to negotiate afterwards.
6. Record open risks with owners and dates
Anything unresolved, such as a security report still pending or a capability demoed but not tested, goes into the packet with a named owner and the date it must close by, so it doesn't disappear into an email thread.
7. Worked example (illustrative)
An evaluation packet has ten rows. Three rest on tested evidence, four on vendor documentation, one on a verbal claim, and two have no evidence yet. The verbal one, cross-channel frequency capping, turns out on written confirmation to belong to a higher plan tier than the one quoted, so the quote is revised before signature instead of the gap being discovered during rollout. The two rows without evidence, deletion at the end of the contract and the security report, go to legal and security with dates.
Procurement handoff test matrix (illustrative)
Copy this structure into your review document and record your observed result for each row.
| Requirement | Evidence so far | Evidence class | What makes it binding | Owner |
|---|---|---|---|---|
| Triggered journeys fire promptly on our events | Measured in the trial on our own event stream | Tested | Service levels in the order form or technical schedule | Engineer |
| Consent records import with timestamp and source | 5,000 test records imported and spot-checked | Tested | Statement of work | Lifecycle ops |
| Suppression applies across all journeys | Tested with a seeded suppressed contact | Tested | Statement of work | Lifecycle ops |
| Cross-channel frequency cap | Shown in a demo; not tried with our data | Verbal claim | Written confirmation of the plan tier before signature | Lifecycle lead |
| Processing terms | Vendor's standard data processing agreement received | Documented | Agreement covering the GDPR Article 28(3) terms | Legal |
| Sub-processor list and change notice | Published list; changes notified by email | Documented | Notice-and-objection process in the agreement (Article 28(2)) | Legal |
| Pricing unit and overage | Quote priced on contacts; message overage rate not shown | Documented, incomplete | Overage schedule in the order form | Procurement |
| Data export at exit | Documentation covers profiles only | Documented, with a gap | Exit clause covering events, consent records and message history | Legal |
| Deletion at end of contract | Not yet discussed | None yet | Deletion-or-return clause (Article 28(3)(g)) | Legal |
| Security review | Report requested | None yet | Completed questionnaire and report | Security |
A failure worth checking
The demo feature on the wrong tier. The frequency cap shown in the demo sat on a higher plan than the one quoted. Nobody asked, the contract was signed, and the gap surfaced during rollout when the team tried to configure it. The fix at that point is an upgrade negotiated after signature, with little left to bargain with, or a workaround built in-house. Verification: before signature, convert every 'verbal claim' row into tested or documented evidence with the plan tier or product code named, or strike it from the requirements.
Common questions
Isn't this procurement's job?
Procurement negotiates. Only the evaluation team knows which claims were tested and which were only said. The packet is how that knowledge gets into the contract instead of staying in someone's notes.
Do we need an Article 28 agreement if the vendor is outside the EU?
If the GDPR applies to your processing and the vendor processes personal data on your behalf, Article 28(3) requires the contract terms it lists, wherever the vendor is based. Transfers of personal data outside the EU are governed separately, by Chapter V. Confirm the scope with counsel.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.