Choosing a DAM: requirements, evaluation and RFP guide

Why it matters

A DAM becomes infrastructure quickly. Within a year it holds the organisation's approved brand assets, rights records and the URLs that websites, emails and partner portals point at. Changing platform later means a migration, retraining and re-integration, so a poor choice is expensive to undo.

Most selection failures come from the process rather than the products:

• Feature checklists that every vendor answers "yes". Real Story Group observes that vendors claim broad applicability but in practice "tend to excel at a subset of business use cases" R16 Unverified (2019 article; the observation is still widely shared). A checklist of yes/no questions cannot reveal that. DAM News makes the same point about binary RFP answers and recommends real-world scenarios instead R20 Unverified (2018).
• Purchase price mistaken for cost. UK government guidance notes that the initial procurement cost is usually only a small part of the total cost of owning and operating an IT product R4 Unverified (2011 document; the principle is unchanged).
• Lock-in discovered at renewal. GOV.UK asks teams to minimise total cost of ownership, including "reducing the chance of getting locked in" to long contracts for specific tools and providers R1. The Digital Preservation Coalition reminds buyers that their own obligations may outlast the commercial provider, so an exit route has to be identified up front R14.
• Integration and security left to the end. Connectors, API limits and identity management often decide whether the DAM fits the organisation's architecture, but they are tested last, after the business has chosen a favourite.

No reliable, freely available statistics on DAM selection outcomes were found, so none are quoted here.

Core concepts

Identity and integration terms used below are defined in the glossary: single sign-on, SCIM, OAuth 2.0, webhook, rate limiting and MCP.

Recommended practices

1. Set up the selection as a project with an owner

Name a business owner (usually the person accountable for brand or content operations), a DAM or metadata lead, and representatives from IT, security, legal or rights, procurement and the main user groups. The DPC warns that without staff who have practical expertise it is hard to write specifications and monitor a contract afterwards R14. Agree the timeline, the decision rule and who signs off before contacting vendors.

2. Gather requirements from people and from data

Combine several methods so that no single group's wish list dominates. The University of Houston Libraries' selection task force interviewed stakeholder focus groups, reviewed the literature and national standards, benchmarked more than forty peer institutions and measured current and projected use before writing any criteria R15 Unverified (2016 case study; the method still applies). In a corporate DAM, the equivalent is:

• Interviews or workshops with each user group: creators, marketers, regional teams, agencies, sales, legal, IT.
• An inventory of what you have: asset counts and volumes by type, metadata fields in use, rights data, integrations and published URLs. The DAM migration guide lists what to measure.
• Your information model: the metadata schema, vocabularies and permission model you need. Draft them first with the metadata schema & governance, taxonomy and folders vs metadata guides, so you can test whether a platform fits them.
• Constraints: data residency, regulatory rules, accessibility obligations, identity provider, budget ceiling.

GOV.UK's Technology Code of Practice frames the same sequence for public bodies: define user needs, then accessibility, open standards, security, privacy, integration and the purchasing strategy R2.

3. Write requirements by category and prioritise them

Group requirements so that each evaluator can own a section. AVP separates functional requirements (written as user stories), non-functional or technical requirements, and file-format requirements, organised by user type R19. The table below is a starting structure for a DAM; delete what does not apply.

Then prioritise. Keep must for genuine reasons to reject. A useful test: if you would still buy a product that fails this requirement because it excels elsewhere, it is a should. GOV.UK recommends trying products before committing, including integration, user experience, accessibility and deployment compatibility R3; mark the requirements that only a trial can prove.

4. Write five to seven usage scenarios

Scenarios are what turn a requirements list into a selection tool. Real Story Group recommends human-centred narratives built around personas rather than task checklists, and suggests five or six of them, made richer at each stage from RFP to demo to bake-off R17. AVP suggests three to seven, written as detailed narratives of real-world use R19. DAM News lists "describe your most important scenarios" as the first step of a DAM RFP, together with providing representative file samples and worst-case examples R20.

A good scenario names the persona, the goal, the starting data and the expected outcome. For example:

Regional marketer, campaign localisation. A marketer in Spain searches for the approved spring campaign key visual, filters by "usable in Spain, social channels, valid in May", finds that the hero image expires on 30 April, picks the alternative, crops it to two social formats, downloads them with embedded credit and copyright, and shares a link with an agency that expires after two weeks. The DAM manager can later see who downloaded what, for which channel.

One scenario like this tests search, rights metadata, expiry, renditions, embedded metadata, external sharing, permissions and audit at once. Write others for ingest by a creative team, a product-image feed to a PIM or e-commerce site, a video review cycle, and an administrator changing the schema.

5. Evaluate integrations and the API as seriously as the user interface

Most DAMs end up connected to other systems, and many limits are only visible in developer documentation. Ask for the documentation during the RFP and have an integrator read it. The wiki's comparison table, the APIs overview and the MCP servers list on the wiki site summarise, per platform, the API style, authentication methods, documented rate limits, webhook support, published specifications and official MCP servers, each with a citation. Use them to prepare questions, not as a verdict.

Test the critical paths yourself during the proof of concept: create an asset with metadata, search for it, receive the event, fetch a rendition, update rights fields, and export everything again.

6. Ask security and privacy questions that require evidence

Start from a recognised framework instead of writing a questionnaire from scratch. The UK National Cyber Security Centre's fourteen cloud security principles cover data in transit, asset protection and resilience, separation between customers, governance, operational security, personnel, secure development, supply chain, user management, identity and authentication, external interfaces, service administration, audit information and secure use by default. The NCSC advises checking what evidence the provider gives for each one R5. CISA's Secure by Demand guide, written for organisations buying software, adds pointed questions, for example whether the manufacturer supports standards-based SSO "at no additional cost", and whether SaaS providers keep security logs available to customers for at least six months at no additional charge R6.

For a DAM, ask at least:

• Certifications and reports. Which certifications apply, to which legal entity, product and data centres, and when they were last renewed? Ask for the latest independent report under NDA. A SOC 2 report covers controls relevant to security, availability, processing integrity, confidentiality or privacy at a service organisation R21. The wiki's comparison table lists certifications that vendors state publicly, with sources; it cannot verify their scope.
• Identity. SSO protocols supported, whether SSO costs extra, MFA for local accounts, user provisioning and de-provisioning, roles for external users.
• Logs. What is logged (logins, downloads, permission changes, API calls), for how long, and how you can export it.
• Data protection. Hosting regions, sub-processors, encryption, backups and restore tests, breach notification. Under the GDPR, a processor contract must cover, among other things, documented instructions, security, sub-processors, assistance, audits and deletion or return of personal data at the end of the contract R8. DAMs hold personal data: faces, names in captions, model releases, user accounts.
• Delivery surface. Public URLs, CDN links and share links are external interfaces too. Ask how they are protected, expired and revoked.

7. Estimate total cost of ownership over the contract and beyond

UK government guidance groups TCO items into acquisition (selection, evaluation, licences, integration), operation (data and user migration, maintenance, upgrades, support, training, scaling, customisation) and end of life (retirement, disposal, migration out). It suggests using high, medium and low estimates when exact figures are not available, as long as every option is assessed the same way R4. Applied to a DAM:

Pricing models differ a lot between vendors, which is why a like-for-like quote requires your real volumes. The wiki records the publicly documented model for each platform: for example, Frontify prices by monthly active users and, from 2026-09-01, also counts authenticated usage through MCP workflows and supported integrations; MediaValet includes unlimited users and prices on storage, modules and integrations; Wedia bills its Media Delivery module on monthly credits per view, play or download; Acquia DAM has a monthly API call allowance by plan, separate from its rate limit. Each fact is cited on the linked page. Aprimo's TCO article lists similar hidden-cost categories, such as migration and cleansing, integration maintenance, training and storage overage R23, but the categories above do not depend on it.

TCO is not the decision on its own. The same UK document notes that TCO says nothing about how well a solution meets requirements or fits strategy, and that the cheaper option is not always the better one R4.

8. Script the demos and score them consistently

• Send the scenarios and sample files in advance and ask vendors to follow them in order. Real Story Group advises allowing substantial time per demo, keeping all demos within a short window, having the whole team attend every demo, using a standard evaluation form, appointing a firm session chair and keeping a list of unanswered questions. It warns that vendors are skilled at skipping difficult sections and steering towards their strongest features R18 Unverified (2019).
• Use your own content: your real largest files, your messiest metadata, a few assets with rights restrictions, non-Latin characters and long file names.
• Ask to see configuration, not slides. When a vendor says "that is configurable", ask them to configure it, or to show where and by whom it is done.
• Score immediately, individually, then reconcile. A simple scale works. The University of Houston task force scored each feature from 0 (none) to 3 (high), totalled scores by category, then ran a facilitated session on advantages and disadvantages before making its recommendation R15. Agree category weights before the first demo, not after.
• Include end users. DAM News warns against keeping vendors at arm's length from the people who will use the system R20.

9. Run a proof of concept with the finalists

Demos show what a vendor's expert can do; a PoC shows what your team can do. GOV.UK recommends product trials covering integration, user experience, accessibility and deployment compatibility before committing R3. The Houston task force narrowed twelve candidates to three for in-depth testing in test environments, and dropped one of the three when its setup timeline proved prohibitive R15. For a DAM PoC:

• Load a representative sample (all file types, real metadata, restricted assets) and time the ingest.
• Implement one real integration end to end through the API.
• Let ten to twenty real users run the scenarios without the vendor in the room, and record task success and time.
• Configure your draft schema, one approval workflow and your permission model.
• Export everything and check that nothing is lost: files, metadata, relationships, versions, audit data.
• Check accessibility of the main user journeys against the WCAG level you require. WCAG 2.2, a W3C Recommendation since 2024-12-12, defines levels A, AA and AAA R9. Vendors may supply an Accessibility Conformance Report based on ITI's VPAT template, which exists in editions for WCAG, Section 508 and EN 301 549 R10; treat it as a claim to test, not a result.

10. Structure the RFP so that answers are comparable

An RFP that asks open questions and demands evidence gets better answers than one that asks for ticks. A workable structure, consistent with AVP's outline (overview, requirements spreadsheet, usage scenarios, vendor questionnaire) R19 and with Brandfolder's guidance on context, scope, roles and process instructions R22:

1. Context: the organisation, the problem, objectives, current systems, asset volumes and growth, user groups and numbers, timeline.
2. Instructions: deadlines, format of answers, how questions are handled, evaluation stages, criteria and weights, confidentiality.
3. Scenarios: the five to seven narratives, with the sample files vendors will receive for the demo.
4. Requirements matrix: one row per requirement with its priority; answer options such as standard, configuration, custom development, partner product, roadmap (date), not available, plus a free-text explanation and a documentation link.
5. Integration and API questionnaire: section 5's questions, plus the named systems you must connect.
6. Security and privacy questionnaire: section 6's questions, with requested evidence.
7. Implementation and support: method, team, partner involvement, training, support hours and languages, SLA and service credits.
8. Commercial: a price schedule built on your volumes for every year of the contract, every pricing driver, optional modules, services rates, renewal terms, and exit assistance.
9. References: customers of similar size, sector and use case, ideally ones that migrated in and one that left.

Ask vendors to mark answers that rely on third-party products or on features not yet released. A roadmap answer should never satisfy a must.

11. Negotiate the exit at the start

Write the exit into the contract before signature. GOV.UK guidance on purchasing strategy recommends, where economic, a break clause at a maximum of two years with minimal exit costs, and avoiding automatic extensions R3. The DPC suggests asking what data retrieval will cost and whether the contract can be ended in a minimally disruptive way R14. For customers in the European Union, the Data Act has applied since 2025-09-12: providers of data processing services, including platform and software as a service, must remove obstacles to switching, make open interfaces available and export data in a commonly used, machine-readable format, and switching charges, including data egress charges, disappear from 2027-01-12 R7. Have your legal team check how it applies to your contract.

In practical DAM terms, the contract or an annex should state:

• What is exported: original files, every version, all metadata including system fields and IDs, vocabularies, collections, relationships, rights records, user and permission data, audit logs.
• In which formats, by which means (bulk job, API, storage transfer), within what time and at what price.
• How long the service stays available read-only after termination, and when data is deleted, with confirmation.
• What happens to public URLs and embeds during the transition.

12. Decide, document and hand over

Record the decision with the scores, the risks accepted and the conditions agreed (for example a roadmap item with a date). Hand over the scenarios, test data and PoC results to the implementation team: they become acceptance tests. Define in advance how you will measure success after go-live (usage, reuse, search success, metadata completeness); a guide on DAM KPIs, ROI & user adoption is planned.

Common pitfalls

• The 400-line yes/no spreadsheet. Everyone answers "yes"; nothing is learnt. Replace most lines with scenarios and evidence R17 R20.
• Letting vendors run their standard demo. You see their strengths, not your problems R18.
• Testing with clean sample data. Your oldest, largest, worst-described files are where products differ.
• Choosing before IT and security have looked. API limits, SSO, provisioning and logs then become post-signature surprises.
• Comparing headline licence prices. Models built on users, active users, storage, delivery or API calls cannot be compared without your volumes and growth R4.
• Ignoring people costs. A DAM needs administrators, a metadata owner and training, whatever the platform.
• Accepting roadmap promises as features. Make them contractual with dates, or treat them as absent.
• No exit clause. Export formats, timing and costs are hardest to negotiate after signature R3 R14.
• Confusing certification with fit. A certificate covers a defined scope at a point in time; it does not answer your specific data-protection questions R5.
• Over-buying. Real Story Group's point that most tools excel at one or two primary use cases cuts both ways: buy for the scenarios you actually have R16 R17.

How DAM platforms support this

The wiki is built to support the fact-finding part of a selection, not the decision. The comparison table and the "A vs B" comparison pages on the wiki site show only sourced, publicly documented facts (deployment, pricing model, API style, specifications, webhooks, MCP, SSO, certifications), each traceable to a solution's sources page. They contain no scores or rankings, and a fact missing from a vendor's public documentation is shown as Not public or Unknown, which is itself a good question to ask in an RFP. Each solution's API page covers authentication, limits, webhooks and quirks, and each Features page has an Administration section on SSO and provisioning.

A few examples show the kind of difference that only appears when you read the documentation. They are illustrations, not a shortlist.

Always check the date in each page's last_verified field and the linked sources before relying on a fact in a contract.