Paste-ready master data management requirements (multidomain, match and merge, survivorship, stewardship, hierarchies, real-time APIs), vendor questions, a scoring rubric and a proof-of-concept plan.
See the structure before you download. The Word file has every section listed below, ready to fill in.
The sections in the document, in order.
Use this MDM RFP template when you're selecting a master data management platform to build trusted golden records for customers, products, suppliers, locations or assets, and keep them in sync across your ERP, CRM and other systems.
It's written for the data governance, architecture and procurement team running the evaluation, and it covers the whole process: when to issue an RFI first, the requirements to send, the questions that separate vendors, and how to score a proof of concept on your own data.
If you meant mobile device management, use the Mobile Device Management (MDM) Software RFP Template listed under related templates below.
Download the editable Microsoft Word version below. Every requirement, vendor question and scoring weight on this page is in the document, ready to tailor and send.
An MDM evaluation stands or falls on how well a platform handles your own data, so the most important preparation is agreeing on domains, sources and what counts as a duplicate before vendors get involved. The example schedule below runs about 14 weeks from kickoff to contract award; extend it if the first phase covers several domains or regions.
Each line is written to paste straight into your RFP. Must-have means a vendor that cannot meet it is out; Nice-to-have earns extra points. Change the priorities to fit your situation, and delete what doesn't apply.
| ID | Requirement | Priority |
|---|---|---|
| F1 | Master data for the domains we need in one platform: [customer, product, supplier, location, asset; delete those not in scope], with relationships between domains (for example, which supplier provides which product, or which assets sit at which location). | Must-have |
| F2 | A data model we can change through configuration rather than custom code: add entities, attributes, relationships and validation rules per domain without breaking upgrades. | Must-have |
| F3 | Matching with configurable rules per domain, combining exact and fuzzy comparison of names, addresses, phone numbers, email addresses and identifiers, with match scores and thresholds that separate automatic merges from matches sent to a data steward for review. | Must-have |
| F4 | Survivorship rules at attribute level (for example, by source trust, most recent update, completeness or steward override) to build each golden record, showing which source supplied each value. | Must-have |
| F5 | Cross-references from each golden record to every contributing source record and its source-system ID, and an unmerge that restores the original records without data loss. | Must-have |
| F6 | Data quality profiling, standardization and validation rules, applied both when records are created and in batch, with quality scores per record, attribute and domain shown on dashboards. | Must-have |
| F7 | Address verification and geocoding, and enrichment from third-party reference data such as business registries or Legal Entity Identifiers (LEI, ISO 17442). State which sources are included and which cost extra. | Nice-to-have |
| F8 | Stewardship workflows: task queues for match reviews, data quality exceptions and change requests, routed by domain, region or source, with approval steps, due dates and escalation. | Must-have |
| F9 | A steward interface to search, compare records side by side, merge, unmerge, edit and bulk-update records without IT involvement, with every action kept in the record's change history. | Must-have |
| F10 | Governed creation and change of master data: a search-before-create check that flags likely duplicates as a record is entered, plus request and approval workflows (for example, onboarding a new supplier). | Must-have |
| F11 | Hierarchy management: several hierarchies per domain (for example, legal-entity, sales-territory and product-category hierarchies) that stewards can maintain, with effective dates and version history. | Must-have |
| F12 | Reference data management for shared code lists such as country, currency, unit of measure and payment terms, including mappings between each source system's codes and the standard values, and support for standards such as ISO 3166 and ISO 4217. | Must-have |
| F13 | For product data: attribute sets by product category, classification against standards such as GS1 Global Product Classification (GPC) or UNSPSC, and GTIN validation. | Nice-to-have |
| F14 | AI-assisted matching that suggests match decisions or match-rule changes based on past steward decisions, explains each suggestion, and can run in review-only mode. | Nice-to-have |
| ID | Requirement | Priority |
|---|---|---|
| T1 | Support for our intended implementation style: [registry / consolidation / coexistence / centralized]. Describe how the platform supports each style, and how we could move from one style to another later without re-implementing. | Must-have |
| T2 | Deployment as [SaaS / customer-managed cloud / on-premises]. For SaaS, state whether the service is multi-tenant or single-tenant and which cloud regions host it, and identify any feature that differs between deployment options. | Must-have |
| T3 | Separate development, test and production environments, with configuration (data model, match and survivorship rules, workflows and hierarchies) promoted between them under version control. | Must-have |
| T4 | Capacity for [number] source records and [number] golden records per domain at our year-3 volumes. State response times for real-time search and match-on-entry, and run times for batch matching of a full load, for a comparable configuration. | Must-have |
| T5 | Incremental processing, so new and changed source records are matched and merged without reprocessing the full data set. | Must-have |
| T6 | Hosting of our data, backups and any AI processing in [list your regions], to meet data-residency requirements. | Must-have |
| T7 | High availability for the production environment, tested backup and restore, and stated recovery point and recovery time objectives (RPO and RTO). | Must-have |
| T8 | Prebuilt data models and match rules for common domains such as customer, product and supplier, which we can extend as a starting point. | Nice-to-have |
| ID | Requirement | Priority |
|---|---|---|
| I1 | Single sign-on with our identity provider via SAML 2.0 or OIDC, and user and group provisioning via SCIM or a documented API. | Must-have |
| I2 | Documented REST APIs to search, match, create, read, update, merge and unmerge master data, with stated rate limits. | Must-have |
| I3 | Publication of change events (create, update, merge and unmerge) to our event-streaming or messaging platform, so subscribing systems receive changes in near real time. State how event ordering, retries and failed deliveries are handled. | Must-have |
| I4 | Bulk load and bulk extract through files (CSV, JSON or XML) and database connections, with handling and reprocessing of rejected records. | Must-have |
| I5 | Connectors or documented integration patterns for our key systems: [ERP, CRM, e-commerce, procurement, PLM]. State which connectors are included and which need partner or custom work. | Must-have |
| I6 | Delivery of golden records, cross-references and hierarchies to our data warehouse, lakehouse or analytics platform, in batch or near real time. | Must-have |
| I7 | Integration with our data catalog and governance tools [name them], or an equivalent built-in capability, exchanging the data model, business glossary terms, data ownership, quality scores and lineage from sources to golden records. | Must-have |
| I8 | For product data: publication of product records to trading partners through a GS1 GDSN certified data pool, either built in or through an integration. | Nice-to-have |
| ID | Requirement | Priority |
|---|---|---|
| S1 | A current SOC 2 Type II report and ISO/IEC 27001 certification covering the proposed service, available under NDA. | Must-have |
| S2 | Sector-specific assurances where they apply, such as FedRAMP authorization for public-sector use or a HIPAA business associate agreement for health data. Make this Must-have if your sector requires it. | Nice-to-have |
| S3 | Isolation of our tenant's data, encryption in transit and at rest, and a documented key-management approach. State whether customer-managed keys are supported. | Must-have |
| S4 | Access control by role down to domain, record and attribute level (for example, by region or source), with masking of sensitive attributes such as tax IDs and personal contact details. | Must-have |
| S5 | Access through SSO with MFA, and an audit trail of every change to master data, the data model, rules and configuration, including merges and unmerges, showing who made it, when, and the old and new values. The trail must be exportable. | Must-have |
| S6 | Support for our privacy obligations (for example, GDPR) for personal data: find every source and golden record for a person, export them, and erase or anonymize them on request, with the change sent to subscribing systems. | Must-have |
| S7 | A data processing agreement, a current list of sub-processors, and a contractual commitment to notify us of security incidents affecting our data within a defined time. State the time. | Must-have |
| S8 | If AI features are proposed: our data is not used to train models used by other customers, and each AI feature can be switched off for our tenant. | Must-have |
| ID | Requirement | Priority |
|---|---|---|
| M1 | A phased implementation plan starting with [domain] and [source systems], with named roles and the effort expected from both sides, including our data stewards and source-system owners. | Must-have |
| M2 | Identification of who delivers the implementation (vendor, partner or both) and the named team's experience with the proposed domains and implementation style. | Must-have |
| M3 | Initial data load and match tuning with our stewards on our data, with acceptance criteria agreed before go-live (for example, steward review of a sample of merged and unmerged pairs). | Must-have |
| M4 | A service-level agreement for the availability of the production environment and APIs, with service credits. State how availability is measured. | Must-have |
| M5 | 24×7 support for critical issues, such as a production outage or stopped real-time synchronization, with response-time targets by severity. State your targets. | Must-have |
| M6 | Advance notice and release notes for platform updates, with updates applied to a non-production environment before production so we can test them. | Must-have |
| M7 | Training and documentation for data stewards, administrators and developers. | Must-have |
| M8 | Optional services to help set up data ownership, stewardship roles and data standards, and periodic service reviews covering data quality trends and steward backlog. | Nice-to-have |
| ID | Requirement | Priority |
|---|---|---|
| C1 | Pricing broken down by module or domain, metric and term, showing list price, discount and net price. | Must-have |
| C2 | A definition of how the pricing metric is counted (for example, source records or golden records, inactive and historical records, API calls, consumption units and non-production environments), with pricing at our year-1 and year-3 volumes. | Must-have |
| C3 | Terms that apply if we exceed licensed record volumes, API calls or consumption units. | Must-have |
| C4 | Prices for adding domains, source systems, environments or users mid-term, co-terminated with the main agreement. | Must-have |
| C5 | A cap on price increases at renewal. State the cap. | Must-have |
| C6 | Pricing that ramps with the implementation phases, so we don't pay for every domain before it goes live. | Nice-to-have |
| C7 | A proof of concept on our sample data at no charge, with the vendor's engineering support. | Nice-to-have |
| C8 | Exit terms covering export of golden records, cross-references, hierarchies, change history and configuration (data model, match and survivorship rules) in documented formats, plus transition assistance. | Must-have |
These questions are designed to separate vendors, not to collect brochure answers. Ask for evidence: a demo, a document or a reference.
Score each criterion from 1 to 5, multiply by its weight, and add the results. The weights below are a starting point; agree on your own before any proposals arrive so the scoring can't be bent around a favorite.
| Criterion | Weight | What a strong response shows |
|---|---|---|
| Match, merge and data quality on our data | 25% | A proof of concept on your sample data with few false or missed matches, clear survivorship lineage and a clean unmerge. |
| Multidomain model, hierarchies and reference data | 15% | Your domains and relationships modeled through configuration, with hierarchies and code mappings that stewards can maintain. |
| Stewardship and governance workflows | 15% | Task queues, approvals and a steward interface business users can work in without IT help, plus working catalog integration. |
| Integration and real-time synchronization | 15% | Documented APIs, change events with reliable delivery, and connectors for your key source and consuming systems. |
| Architecture, security and privacy | 10% | Support for your implementation style and deployment model, attribute-level security, residency options and a workable process for erasure requests. |
| Implementation and support | 10% | A credible phased plan, an experienced named team, match tuning built into the plan, and clear SLAs and support targets. |
| Commercials and total cost | 10% | A clear definition of how records are counted, pricing at year-3 volumes, a renewal cap, and fair overage and exit terms. |
| Total | 100% |
Scoring scale
Your domains, source systems and record volumes; the implementation style you plan to use; requirements for matching, survivorship, data quality, stewardship, hierarchies and reference data, marked Must-have or Nice-to-have; integration requirements for APIs, real-time change events and batch loads; security, privacy and support terms; a pricing table that makes vendors explain how they count records; and the rubric you'll score with. This template includes all of them.
The four styles are registry, consolidation, coexistence and centralized. Registry links records across sources through cross-references without changing them; consolidation copies source data into golden records, mainly for reporting and analytics; coexistence also sends golden records back to the sources so they stay in sync; and centralized makes the MDM platform the place where master data is created and changed. State the style you plan to start with in your RFP, and ask vendors how their platform supports moving to another style later.
A CDP is built for marketing: it collects customer profiles and behavioral data such as web and app events, resolves identities, builds audiences and sends them to marketing channels. Customer MDM governs the core customer, account and contact records used across operational systems such as ERP, CRM and billing, with match rules, survivorship, hierarchies and stewardship workflows. The two can work together, with MDM supplying trusted customer records to the CDP; if your goal is marketing personalization rather than consistent operational data, a CDP RFP is the better fit.
Product information management (PIM) manages the content you sell with: marketing descriptions, images and other digital assets, channel-specific attributes, and publishing to e-commerce sites and marketplaces. Product MDM governs the core product record that operational systems share, such as identifiers, classifications, units of measure, supplier links and ERP item data. Some platforms cover both; if your main goal is e-commerce content, write PIM requirements instead of, or alongside, this template.
The example schedule in this template runs about 14 weeks from kickoff to contract award, including three weeks for vendor responses and four weeks for a proof of concept on your own data. Allow more time if several domains are in the first phase, or if extracting and masking sample data needs privacy approval.
Paste-ready virtualization platform requirements (hypervisor, clustering and HA, storage, networking, VM migration, automation, security), vendor questions and a weighted scoring rubric.
A free, vendor-neutral RFP for hiring an agency or development partner to build custom software, with user stories, delivery questions, code ownership…
Paste-ready Microsoft 365 backup requirements (Exchange Online, OneDrive, SharePoint, Teams, Entra ID, restore, immutability, legal hold), sharp vendor questions and a scoring…
Please provide your feedback below.
"*" indicates required fields