tools

Customer Data Platform RFP Template

By Art Kukharenko · Published 2026-10-17 · Updated 2026-10-18

Use this worksheet to record your own requirements, assumptions and evidence. The supplied rows are research or illustrative examples, not a regulatory filing, vendor quote or completed assessment.

How to use this worksheet

Download the CSV and preserve the source and assumption columns.
Replace example values with your own documented information.
Review the result with the accountable technical, procurement or legal owner.

Read the supporting guide for context and return to the tools library.

Customer Data Platform RFP Template

Research snapshot checked on 2026-10-17. Sort any column and retain source dates when reusing records. iAge dataset reuse terms cover the original compilation; third-party source rights remain separate.

Search records

50 of 50 records match.

Scroll horizontally to compare all columns ↔

Customer Data Platform RFP Template

1	Data ingestion and contracts	Validates every inbound event against a versioned, customer-owned schema (for example JSON Schema) and quarantines violations with a reason code.	Bad events silently corrupt profiles, segments and audit trails. A contract at the door is cheaper than cleaning downstream.	Demo with 20 synthetic events, 5 malformed and 3 on a changed schema version: show quarantine queue, reason codes and replay of fixed events. Schema registry documentation.	4	0: no validation. 2: validation optional or after load. 3: enforced per source, no versioning. 4: versioned and quarantined, no replay. 5: versioned contracts, quarantine with reason codes and replay of fixed events, shown live.
2	Data ingestion and contracts	Supports streaming (HTTP, SDK or message bus), scheduled batch files and database or warehouse sync, with documented limits for each mode.	Regulated estates mix core-system batch feeds with web and app streams. Gaps become custom code you maintain.	Ingestion and connector documentation; live load of one streaming and one batch source (1M synthetic rows); stated rate limits per mode.	4	0: one mode only. 3: all modes, limits undocumented. 5: all modes with documented limits, two shown live including a 1M-row batch file.
3	Data ingestion and contracts	Documents its deduplication key, deduplication window and handling of late and out-of-order events.	Window-bounded deduplication lets duplicates through after the window, and at-least-once senders retry. Unknown windows mean double sends and double counts.	Documentation naming key and window; live test sending the same event twice 1 hour apart and 48 hours apart, plus one event with an old timestamp.	4	0: no deduplication. 2: payload-hash deduplication only. 3: key-based with a short fixed window, late events dropped silently. 5: configurable key and window, late events processed or flagged by rule, behaviour proven in the test.
4	Data ingestion and contracts	Can replay stored raw events after an outage or schema fix without re-triggering downstream sends.	Stateless pipelines cannot replay, so recovery means data loss or manual reloads.	Demo: replay one hour of synthetic events with downstream suppression on; show retained raw store, retention setting and replay audit entry.	4	0: no replay. 2: replay by support ticket. 3: self-service replay that re-triggers destinations. 5: self-service replay with downstream suppression and an audit entry.
5	Data ingestion and contracts	Every profile attribute is traceable to its source, timestamp and the rule or model that produced it.	Disputes, subject access requests and audits all ask where a value came from.	Demo: pick any attribute on a synthetic profile and show its history; lineage API or export.	3	0: none. 3: source system only. 5: source, timestamp, rule or model version and history, queryable by API.
6	Identity resolution	Deterministic matching on customer-defined keys with configurable priority, conflict handling and per-key confidence.	Banks and payers need predictable merges on verified keys; opaque matching creates wrong-person errors.	Rule configuration demo; conflict-handling documentation; test set with three deliberately conflicting synthetic records.	5	0: fixed vendor rules. 3: configurable keys, fixed conflict handling. 5: configurable keys, priority and conflict rules, with a dry-run showing merge outcomes before activation.
7	Identity resolution	Probabilistic matching is optional, shows a score and threshold per match, and can be disabled per use case.	Probabilistic merges can be inappropriate for regulated decisions; you need the choice and the score to defend it.	Documentation; demo of a threshold change and the match-score view on synthetic records.	3	0: always on, or absent without explanation. 3: optional, no scores. 5: optional per use case with visible scores and thresholds.
8	Identity resolution	Merges are reversible; wrongly merged profiles can be split, with history and opt-out status preserved.	A merge can silently re-enable messaging to someone who opted out. Reversal must be possible and audited.	Demo: merge two synthetic profiles where one has opted out; confirm suppression persists; unmerge and show audit entries.	5	0: merges irreversible. 2: reversal by support ticket. 4: self-service unmerge. 5: self-service unmerge, opt-out preserved through merge and split, all audited.
9	Identity resolution	Identity graph, keys and merge history are exportable in a documented open format.	The identity graph is the hardest asset to rebuild; if you cannot take it with you, you are locked in.	Sample export of a synthetic graph with schema; stated export time at 10M profiles.	4	0: not exportable. 2: profile attributes only. 4: graph and keys in a proprietary format. 5: graph, keys and merge history in a documented open format, tested at volume.
10	Consent and privacy	Records consent per purpose and channel with timestamp, source, policy version and proof, and attaches the consent state to each decision.	Regulators ask for the consent state at the moment of each message, not today's setting.	Demo: consent history for a synthetic profile at two dates; export format; policy-version handling.	5	0: single opt-in flag. 3: channel-level flags with timestamps. 5: purpose and channel level, versioned policy, source and proof, queryable as of any date.
11	Consent and privacy	Applies consent and suppression before any send or export, including to downstream destinations, with a documented propagation time for withdrawal.	Enforcement, not recording, protects you. A withdrawal must reach every channel within a stated time.	Test: withdraw consent for a synthetic profile and show blocked sends on three channels; measured propagation time.	5	0: manual. 3: enforced in platform channels only. 5: enforced across platform and destinations, with measured propagation inside your limit.
12	Consent and privacy	Supports access, erasure and portability requests across the profile store, event store, derived data and (where destination APIs allow) destinations, and explains backup handling.	Erasure that skips events, backups or destinations is incomplete.	Demo: erase a synthetic subject; show removal from profile, events, segments and one destination; backup deletion policy.	5	0: manual database work. 3: profile store only. 5: all stores plus destination deletion calls, backup policy documented, completion report generated.
13	Consent and privacy	Honours browser and platform opt-out signals, such as Global Privacy Control, wherever law or policy requires.	Opt-out preference signals are increasingly expected by privacy regulators; the signal must change processing, not only be logged.	Demo: send events with the signal set and show the resulting change in processing and activation.	3	0: not supported. 3: signal stored. 5: signal changes processing and activation rules and is audited.
14	Consent and privacy	Classifies fields, masks or tokenises sensitive fields (health, payment card, government ID), and blocks prohibited fields at ingestion by policy.	Keeping prohibited data out is cheaper than proving it was handled correctly once inside.	Demo: send synthetic card-number-like and diagnosis-code fields; show block or tokenise; classification documentation.	4	0: none. 3: manual masking in views. 5: policy-based classification, blocking or tokenisation at ingestion and per-destination exclusion, shown live.
15	Segmentation and decisioning	Rule-based segmentation with nested logic, time windows, exclusions and versioning, usable by non-engineers.	Marketing teams need self-service; auditors need to know which version ran.	Scripted exercise: build three segments from a written spec in 30 minutes; show version history.	3	0: SQL only. 3: visual builder, no versioning. 5: visual builder with nesting, windows, exclusions and version history, exercise completed in time.
16	Segmentation and decisioning	States and demonstrates event-to-segment-membership latency (p50, p95, p99) for real-time and batch segments.	A real-time claim with no percentile is marketing. Journeys and risk-adjacent rules depend on the tail.	Latency report from a load test at your stated volumes; PoC measurement.	3	0: no figures. 3: median only. 5: percentiles measured at your volume in the PoC and within your target.
17	Segmentation and decisioning	Decision rules and next-best-action logic can be simulated against historical data before release and need approval to go live.	A rule that sends the wrong offer to a million customers is an incident; simulation and approval are the control.	Demo: dry-run a rule on a synthetic history; show predicted audience and the approval step.	3	0: edit in production. 3: dry-run count only. 5: dry-run against history with audience difference, two-person approval and rollback.
18	Segmentation and decisioning	Segment membership and decisions can be reproduced as of a past date for audit or dispute.	Complaints arrive months later; you need to show who was in the audience then and why.	Demo: query a synthetic segment as of a past date and compare with the logged send list.	4	0: current state only. 3: snapshots for a limited number of days. 5: as-of reproduction across the retention period, matching the send log.
19	Activation and destinations	Provides native connectors for your required destinations and an open API, webhook or SDK path for custom ones.	Missing connectors turn into custom builds. Open APIs keep you able to switch.	Connector list mapped to your destinations; API reference; demo of a custom webhook destination.	4	0: fewer than half of required destinations. 3: most native, custom path undocumented. 5: every required destination native or via a documented API path, custom destination built in the demo.
20	Activation and destinations	Delivers at least once with retries, exponential back-off, dead-letter handling and per-destination monitoring, and applies back-pressure when a destination is down.	Destinations fail. Without retries and a dead-letter path, messages disappear or flood.	Failure-injection test: a stub destination returns errors for 10 minutes then recovers; show retries, dead letters and final delivery count.	5	0: fire and forget. 3: retries, no dead-letter visibility. 5: configurable retries, dead-letter queue with replay, alerts, and no loss in the failure test.
21	Activation and destinations	Per-destination field mapping and filtering, so only permitted fields and purposes reach each destination.	Data minimisation is enforced at the exit door. Every destination is a copy.	Demo: configure an allow-list for one destination; show the payload sent and a blocked field.	4	0: all-or-nothing payloads. 3: field filter per destination. 5: allow-lists per destination linked to consent purposes and audited.
22	Activation and destinations	Generates a current inventory of every outbound flow: destination, fields, purpose, volume and owner.	Records of processing and, for financial entities, registers of ICT third-party arrangements need this list; hand-kept lists drift.	Sample inventory export from the demo environment.	4	0: none. 3: list of destinations. 5: destinations, fields, purposes, volumes and owner, exportable and diffable.
23	AI and explainability	Lists every AI or ML feature, where each model runs (inside your boundary, vendor cloud or third-party API) and what data it receives.	AI can mean customer data sent to a third-party model API. Regulated buyers must know before signing.	Written AI feature register; architecture diagram of inference paths; sub-processor list for model providers.	5	0: refuses to say. 2: marketing description only. 4: register without data flows. 5: register with data flows, locations and sub-processors, and a switch to disable each feature.
24	AI and explainability	Model-driven decisions carry reason codes or feature contributions stored with the decision record.	Automated decisions with significant effects need explanations, and some customer-facing uses of AI are classed as high-risk under EU rules.	Demo: show reason codes for one decision; retention of reason codes; documentation.	4	0: black box. 3: global feature importance only. 5: per-decision reason codes stored, retrievable and retained like the decision.
25	AI and explainability	AI agents act through scoped, least-privilege tools; proposed changes need human approval; actions are logged; a kill switch exists. Open protocols such as the Model Context Protocol (MCP) are supported with the same controls.	An agent with broad write access can change audiences or send campaigns. Controls must be technical, not policy documents.	Demo: an agent proposes a segment change; show approval, a denied out-of-scope action, the audit entry and the kill switch.	4	0: agents run with the user's full rights. 3: logging only. 5: scoped tool permissions, mandatory approval for writes, full logging and a tested kill switch.
26	AI and explainability	Models are versioned and evaluated; you can bring your own model or disable AI features; your data is not used to train vendor models without written consent.	Training on customer data creates confidentiality and data-protection exposure; versioning enables rollback.	Contract clause; model version log; evaluation and bias-testing documentation.	4	0: silent. 3: opt-out by request. 5: contractual no-training, model versioning, evaluation reports and feature-level disable.
27	Security and access	SAML or OpenID Connect single sign-on, multi-factor authentication and SCIM provisioning (RFC 7644) for users and groups.	Joiner, mover and leaver control must live in your identity provider.	Demo with your identity provider's test tenant; SCIM conformance statement.	4	0: local passwords. 3: SSO only. 5: SSO, enforced MFA and SCIM group sync, tested with your identity provider.
28	Security and access	Role- and attribute-based access control with separation of duties (marketing, data engineering, security, audit) and field-level restrictions.	Least privilege is a control auditors test; coarse roles fail it.	Role matrix; demo of a marketer who cannot see restricted fields or export raw data.	5	0: admin or user only. 3: roles without field-level control. 5: custom roles, field-level restrictions, enforced separation of duties and an exportable role report.
29	Security and access	Encryption in transit and at rest; customer-managed keys in your key management system; documentation of cryptographic modules (FIPS 140-3 validated where you require it).	Key custody decides who can read data when the vendor, a court or an attacker asks.	Key architecture diagram; demo of key revocation making test data unreadable; module validation certificates.	5	0: vendor-held keys only. 3: customer-managed keys for part of the data. 5: customer-held keys for all stores and backups, revocation tested, module validation evidence if required.
30	Security and access	Documents secure development practice, penetration-test results, a software bill of materials and patch timelines for critical vulnerabilities.	In a customer-operated deployment you inherit the patch stream; you need to know what is in the box and how fast fixes arrive.	Latest penetration-test summary; SBOM sample; patch-timeline clause; security contact and disclosure policy.	4	0: nothing shared. 3: summary letter. 5: independent test summary under 12 months old, SBOM, written patch timelines and disclosure policy.
31	Security and access	Vendor staff access to your data requires your approval, is time-boxed and logged; for customer-operated deployments the default is no vendor access.	If vendor staff can read data during support without your credentials, it is not customer-owned.	Support access procedure; sample access log; contract clause.	5	0: standing vendor access. 3: access on request, logs not visible to you. 5: approval, time limit and session logs visible to you; no standing access.
32	Deployment model and data residency	States which deployment models are generally available (multi-tenant SaaS, vendor-operated single-tenant, customer VPC on AWS, Azure, GCP or OCI, on-premise, air-gapped) and who operates each.	Vendors use private cloud loosely; the operator and the location decide compliance.	Deployment matrix; reference customer per model; reference architecture.	5	0: SaaS only when you need private. 3: option exists, no references. 5: your required model is generally available, with a reference customer and a reference architecture.
33	Deployment model and data residency	Lists the region and operator for each data class: profile store, event store, backups, logs, support tickets and AI inference.	Residency obligations cover copies, backups and telemetry, not only the main database.	Data-flow diagram; sub-processor list with locations.	5	0: region for the database only. 3: database and backups. 5: every class including logs, support data and inference, with sub-processors and regions.
34	Deployment model and data residency	Discloses vendor legal entities, governing law, parent-company jurisdiction and exposure to foreign access requests, and how a customer-operated option removes it.	Residency is where data sits; sovereignty is whose law reaches it.	Written statement; legal-entity chart; transparency report if any.	4	0: evasive. 3: statement without mitigation. 5: clear statement plus a deployment option where the vendor has no technical access to data.
35	Deployment model and data residency	Ships as containers with Helm or Terraform artefacts, lists every third-party dependency and its licence, and avoids proprietary cloud services.	Hidden dependencies (databases, brokers) add licences and migration cost.	Installation guide; dependency bill of materials with licences; minimum sizing guide.	3	0: manual install. 3: scripted install, partial bill of materials. 5: reproducible install from artefacts, full dependency and licence list, sizing guide.
36	Audit and compliance evidence	Append-only, tamper-evident audit log of admin actions, data access, configuration changes and automated decisions, exportable to your SIEM.	An editable log is not evidence.	Demo: perform an action, find it in the log, try to alter it; SIEM export format.	5	0: operational logs only. 3: audit log editable by admins. 5: append-only with integrity verification, complete coverage and SIEM export.
37	Audit and compliance evidence	For any single send or decision, reconstructs inputs, rule or model version, consent state, destination and time.	This is the question regulators and complainants ask.	Live exercise: pick a message from the previous synthetic run and trace it end to end.	5	0: cannot. 3: partial, from several systems. 5: single-query trace with all five elements in under five minutes.
38	Audit and compliance evidence	Provides current independent assurance (for example SOC 2 Type II, ISO/IEC 27001 with scope statement) and does not claim to be HIPAA certified.	No certification of software as HIPAA compliant exists; scope statements show whether the product you are buying is covered.	Reports under NDA; certificate and scope statement; bridge letter.	4	0: none. 3: report for a different scope. 5: report or certificate covering the product and deployment model you buy, issued within 12 months.
39	Audit and compliance evidence	Supplies a data processing agreement, a business associate agreement where relevant, DORA contract provisions (Article 30) and the data needed for your register of information and records of processing.	Missing contract terms are discovered at signature, when your leverage is lowest.	Draft contract pack and completed vendor questionnaire.	4	0: refuses. 3: standard DPA only. 5: DPA, BAA and DORA terms offered at your tier, plus data for your register.
40	Performance and scale	Sustains and bursts at your peak event rate (state it in events per second) with published results or a PoC load test.	Size for the peak, not the average: launch days and bonus days break systems sized on averages.	Load-test report; PoC test at 2x your peak using synthetic events.	4	0: no data. 3: vendor figures for a different workload. 5: tested at your volume in the PoC with no loss and 2x headroom.
41	Performance and scale	Tested profile count, identity-graph size and attributes per profile at or above your three-year forecast, with query performance.	Many systems degrade non-linearly with graph size.	Benchmark at 1.5x your forecast; reference customer at similar scale.	4	0: untested. 3: reference at half your size. 5: benchmark at or above your forecast plus a reference at similar scale.
42	Performance and scale	High-availability design, stated RPO and RTO, multi-zone or multi-region options and a tested restore procedure.	Recovery is an operational-resilience topic for financial entities; untested backups are not backups.	Architecture diagram; restore-test report with timings; disaster-recovery runbook.	4	0: no targets. 3: targets, no test evidence. 5: targets, last restore-test report with timings, and a runbook you can execute.
43	Performance and scale	Defined behaviour when ingestion exceeds capacity: queueing, shedding and priorities, including priority for consent and suppression updates.	At overload, a consent withdrawal should not wait behind marketing events.	Documentation; PoC overload test with suppression updates mixed in.	3	0: undefined. 3: queues without priorities. 5: documented overload behaviour with priority for suppression and no silent drops, shown in the test.
44	Operations and support	Exposes metrics, logs and traces through open standards (for example OpenTelemetry), pipeline-health dashboards and alerting hooks.	You will run this beside your own monitoring; closed dashboards leave blind spots.	Telemetry documentation; demo of an alert on a stalled pipeline in your tooling.	3	0: vendor dashboard only. 3: metrics export. 5: metrics, logs and traces through open standards into your stack, plus health alerts.
45	Operations and support	Published release cadence, backward-compatibility policy, staged rollout and rollback; for private deployments, who performs upgrades and with what downtime.	Upgrades are the main ongoing operations cost of a customer-operated platform.	Release notes for the last four releases; upgrade runbook; downtime figures.	4	0: undefined. 3: cadence stated, rollback manual. 5: cadence, compatibility policy and tested rollback documented, with upgrade effort estimated.
46	Operations and support	Response and resolution targets by severity, 24x7 coverage options, named engineer, escalation path, and how support works without network access to your environment.	The support boundary decides whether a night-time incident is yours or theirs.	Support terms; sample incident reports; escalation matrix.	3	0: best effort. 3: business-hours targets. 5: severity targets, 24x7 critical coverage, named contacts and a remote-access-free support procedure.
47	Operations and support	Typical implementation timeline, vendor and customer roles, partner ecosystem and documentation quality, with two references of similar scope.	Implementation effort is one of the ten lines of total cost; vague answers become change orders.	Sample statement of work; two references; documentation walkthrough.	3	0: no plan. 3: plan, no similar references. 5: plan with role split, two comparable references and documentation that answers your PoC questions.
48	Commercial terms and exit	Lists every metering unit and charge (profiles, monthly tracked users, events, credits, storage, destinations, API calls, environments), overage rates and renewal price caps.	Unlisted units are where bills grow; compare cost per unit of work, not list price.	Completed price sheet for your volumes at 1x, 2x and 5x load; renewal clause.	5	0: tier-one quote only. 3: units listed, no scenarios. 5: price sheet at 1x, 2x and 5x volume, all units named, renewal cap in the contract.
49	Commercial terms and exit	Explains annual and perpetual options, update-entitlement scope, what happens at non-renewal, price protection and source-code escrow or an equivalent continuity mechanism.	A perpetual licence without defined update and support terms is a snapshot. Know what you keep.	Sample licence; entitlement description; escrow or continuity terms.	4	0: undefined. 3: clear licence terms, no escrow or price protection. 5: clear terms, defined non-renewal rights, price protection and an escrow or continuity mechanism.
50	Commercial terms and exit	Export of all data, identity graph and configuration in open formats within a stated period, assistance at stated rates, no switching charges beyond cost, and certified deletion.	Exit terms are written while you can still walk away. EU rules cap and then abolish switching charges for data-processing services from 12 January 2027, so scope matters.	Exit clause; export sample; exit test in the PoC (export, then load into another system).	5	0: no commitments. 3: export on request in a vendor format. 5: contractual open-format export of data, graph and configuration within a stated period, assistance rates, deletion certificate, tested in the PoC.

Download full CSV

General information, not legal advice. Read the supporting analysis.

Put this evaluation into practice.

Assess your deployment requirements

This article is general information, not legal advice.

Customer Data Platform RFP Template

How to use this worksheet

Customer Data Platform RFP Template

Further reading