Enterprise Digital Asset Management

Category: Governance and Compliance

Control frameworks that produce evidence rather than intent. Metadata schemas sized to what people will actually populate, taxonomies that survive contact with users, rights and licence expiry held as structured data, and the access, audit and identity controls a security review will test. Written around the assumption that a control depending on someone remembering will fail.

Access control, SSO and audit trails in an enterprise DAM
Access reviews are a strange exercise. Everybody focuses on who can get in, which is the part that is designed carefully and works. Almost nobody tests what happens when someone leaves, which is the part that is nobody’s job and fails silently.

A DAM is unusually exposed here because it has more external users than most systems. Agencies, freelancers, printers, resellers, regional partners. All of those relationships end, and most of them end without anyone telling the DAM administrator.

Short answer: get identity from the corporate directory through single sign-on, derive groups from directory groups, and make the leaver process remove access without any human in the DAM team being involved. Then make sure the audit trail records reads as well as writes, because for a media library the question is usually who downloaded it, not who changed it.

Identity first

Every access problem in a DAM traces back to how identity arrives.

Local accounts are the failure mode. If administrators create users in the DAM by hand, then the DAM’s user list is a snapshot of who worked here at various points over the last five years. Nobody removes accounts, because removal is manual, nobody owns it, and it never causes a visible problem.

Single sign-on fixes it structurally. Identity comes from the corporate directory. Someone leaves, HR terminates the record, the directory revokes, and every downstream system including the DAM loses access without anybody remembering to do anything. That is the whole value: it is not convenience, it is that deprovisioning becomes automatic.

Standards, not proprietary schemes. OpenID Connect over OAuth 2.0, with JWT tokens. SAML is still common in the enterprise and is fine. A vendor’s own authentication scheme is not fine, and it is a reliable predictor of an integration that overruns.

Groups from the directory. Roles should derive from directory group membership rather than being assigned in the DAM. Someone moves from the German team to the French team, their access follows, and no ticket is raised. If roles are assigned locally, they drift out of alignment with the org chart within a year and the access review becomes archaeology.

External users are the actual risk

Internal identity is usually solved by the time a DAM arrives, because the corporate directory already exists. External identity is not, and it is where the exposure sits.

Four practices that address most of it:
- Time-bound access by default. External accounts expire on a date and require renewal. Not a policy, a system setting. If your platform cannot expire an account, the compensating control is a monthly review, and monthly reviews decay.
- Sponsorship. Every external user has a named internal sponsor. When the sponsor leaves or changes role, the external accounts they sponsored surface for review automatically.
- Share links over accounts. For a printer who needs six files once, an expiring link is safer than an account. Accounts are forever unless somebody acts; links expire unless somebody acts. Prefer the default that fails closed.
- Separate the consumption tier. Read-only distribution to a wide partner network should not run through the same mechanism as contributor access. Different risk, different controls, usually different licensing too, which is covered from the commercial side in what enterprise DAM costs.
What the permission model can and cannot do

Be precise here, because there is a persistent gap between how DAM security is described in proposals and what products actually enforce.

In most enterprise DAM platforms, including Cloudinary, permissions are administered at the folder or collection level rather than per individual asset. Folder modes determine how assets inherit from their placement, and that inheritance is the mechanism you design around.

This covers the overwhelming majority of real requirements, and it has a practical implication worth acting on early: your folder structure is your permission structure. Design it to match your entitlement boundaries, which usually means business unit, brand, market and sensitivity, rather than to match a browsing hierarchy. Browsing is what facets are for, and that separation is the argument in designing a taxonomy people actually use.

What this model does not give you is an independently queryable permission set attached to each individual asset that an application can evaluate at request time. If your security design assumes that, validate it against the product before writing it into a control framework, because retrofitting a folder structure after migration is a project and designing it correctly at the start is a workshop.

Separately from library permissions, delivery of the asset itself needs its own control. Public URLs are public, which is correct for a marketing site and wrong for pre-release material. Access control on delivery covers restricted delivery and signed URLs, which is the mechanism that stops an unlisted address from being an open one.

The nine questions security will ask

Have written answers before the review, not during it.
1. How does identity arrive, and from where? SSO from the corporate directory, or you will spend the meeting on this one alone.
2. How is access removed? The question that fails. Answer must be automatic, via the directory.
3. How are roles assigned? From directory groups, not by hand in the DAM.
4. Who has administrative rights, and how many are there? The number should be small and you should be able to name them.
5. How do external users get access, and when does it end? Time-bound, sponsored, reviewed.
6. What is logged, and for how long? See below, this is usually where the second gap is.
7. How do integrations authenticate? Service accounts with scoped credentials, never a person’s login. And any browser-originated write path uses server-side signing so keys never reach a client.
8. Where is data stored, and does that satisfy residency requirements? Relevant under GDPR for any library containing images of identifiable people in the EU.
9. What assurance does the vendor hold? SOC 2 is the usual expectation. Ask for the report, not the badge.
Map the answers to NIST SP 800-53 control identifiers if your organisation reports against that catalogue. It takes an afternoon and it converts a bespoke evaluation into three lines in a register the security team already maintains.

The audit trail, and the part that gets missed

Most systems log writes well and reads poorly. For a media library that is backwards.

The questions that get asked after an incident are almost always about access rather than modification: who downloaded the unreleased product images, when did the agency last retrieve this file, which partner accessed material outside their territory. If your log records uploads and edits but not downloads and deliveries, none of those is answerable.

What to require:
- Reads as well as writes. Downloads, deliveries, share link access. Volume is higher, retention may be shorter, and it is the half that matters.
- Identity on every entry, including for integrations. An entry attributed to a shared service account tells you a system acted, not which user caused it, so pass through the acting user where the API allows.
- Retention that matches your obligations, not the vendor default. Ninety days is common and frequently insufficient; contract disputes surface a year later.
- Exportable. The log must leave the platform and reach your SIEM. A log you can only read in a vendor interface is a log your security team does not have.
- Immutable. Administrators should not be able to alter or remove entries. If they can, the trail is evidence of nothing.
Test the controls, once a year, deliberately

Design is not operation. The controls that fail are the ones nobody has exercised.

Four tests, half a day:

Deprovisioning. Pick a genuine recent leaver. Confirm access is gone, including any share links they created and any integration running under their credential. This test fails more often than any other.

External expiry. Confirm an expired external account cannot authenticate and that its share links no longer resolve.

Audit retrieval. Ask for every download of a specific asset in the last six months. Time how long it takes to produce. If it takes more than an hour, you do not have an audit capability, you have log storage.

Delivery restriction. Take a restricted asset and confirm its delivery URL does not resolve without authorisation. Public-by-default delivery is a common and quiet misconfiguration.

Record the results. That record is what turns your governance framework from a document into evidence, and it is what an auditor is actually asking for when they ask whether the control operates.

The rights half of the compliance picture is in rights and expiry as first-class asset data, the architectural reason deletion and takedown are executable at all is in single source of truth is an architecture, and the wider context is in what enterprise DAM actually is.
July 6, 2026
Rights and expiry as first-class asset data
An agency invoice arrives with a demand attached. A photograph on your German landing page has been in use for fourteen months beyond its licence. Nobody did anything wrong. The person who negotiated the licence left, the person who built the page never saw the contract, and the contract itself is a PDF in a system the marketing team does not have access to.

That is not a compliance failure caused by carelessness. It is a data model failure, and it is entirely preventable.

Short answer: rights have to be structured fields on the asset, not a document filed somewhere near it. Licensor, licence type, permitted uses, permitted territories, start date, end date, and the identifier of the underlying agreement. Then expiry has to fire an event that changes the asset’s state automatically, because a report that expiry has happened is not a control. It is a notification that a control was absent.

The gap, precisely

Draw the chain for a licensed photograph and the break is obvious.

The contract lives in a contracts or procurement system, owned by legal. The asset lives in the DAM, owned by marketing operations. The published page lives in the CMS, owned by the web team. Three systems, three owners, and no field anywhere that joins them.

So the question “is this image licensed for this use, today” cannot be answered by any single system, and answering it requires a person to hold all three contexts at once. That person exists in most organisations, knows this is a problem, and is one resignation away from the whole thing becoming unanswerable.

The fix is not to move contracts into the DAM. It is to put the terms on the asset, as data, with a reference back to the agreement of record.

The field model

Nine fields. This is the smallest set that answers the questions that get asked.
- Rights status. Controlled list: owned, licensed, restricted, expired, unknown. Unknown is a legitimate and important value. Assets whose provenance you cannot establish exist in every library and pretending otherwise just hides them.
- Licensor. Who granted it. Controlled where possible, because agency names spelled five ways defeat every report you will want to run.
- Agreement reference. The identifier in the contracts system. Not the PDF. A link that survives the PDF being reorganised.
- Licence type. Royalty free, rights managed, editorial only, work for hire, employee-created. Determines which of the remaining fields matter.
- Permitted uses. Controlled list: web, print, paid social, out of home, internal. Multi-select.
- Permitted territories. Controlled list from whatever market codes your organisation already uses. Do not invent a second geography vocabulary.
- Start date and end date. Actual dates, indexed and queryable. Perpetual is a null end date, not the string “perpetual” typed into a text box.
- Depicted persons or property. Whether identifiable people or private property appear, and whether releases exist. This is the field that connects to privacy obligations.
- Restrictions note. Free text for the things a controlled list cannot express. Every rights model needs one escape hatch and exactly one.
Every one of those except the note is filterable, which is the entire point. Rights status = licensed AND end date < 90 days from now is a query that takes a second and replaces a quarterly panic.

The enforcement mechanics matter as much as the model. Fields defined loosely at the interface but not at the API are fields your integrations will populate incorrectly, which is why typed, centrally defined metadata with validation on every write path is worth checking for specifically. The general argument is in the metadata schema an enterprise actually needs.

What has to happen on expiry

This is where most implementations stop short, and the shortfall is the whole risk.

A date field with no behaviour attached produces a report. Reports get emailed to a distribution list, the list contains people who have moved roles, and the report is read for two months and then never again. Meanwhile the asset stays live.

What expiry has to do, in order:
1. Change the asset state to expired, automatically, at the boundary. Not “flag for review”. Change the state.
2. Remove it from search defaults, so nobody picks it for a new placement. It should still be findable by someone deliberately looking for expired material, because that is a legitimate archival need.
3. Emit an event so downstream systems can react. Unpublish the placement, purge the cache, notify the page owner. Notification hooks are the standard mechanism, and the integration patterns for consuming them are in integration patterns for an enterprise DAM.
4. Notify at 90, 30 and 7 days, to a named owner rather than a list. Renewal is often possible and cheap; discovering the need on the expiry date is neither.
Point three is the one that separates a DAM that reduces risk from one that documents it. If the asset can expire in the DAM while remaining live on a page, you have moved the problem rather than solved it, and the reason that happens is almost always that the CMS holds a copy instead of a reference. That is the argument in single source of truth is an architecture.

Where privacy obligations attach

Worth being clear about, because it is regularly missed: an image of an identifiable person is personal data. The obligations under GDPR attach to the photograph itself, not only to the database row that references it. Similar reasoning applies under the CCPA framework in California.

Practically that means three things your rights model has to support:
- Identifying which assets depict a given person, so that a deletion or objection request can actually be executed. If you cannot query this, you cannot comply with it.
- Recording the lawful basis, usually a model release, and where it is held.
- Executing deletion across derivatives, which is straightforward when renditions are derived from one master and genuinely hard when fifteen copies live in five systems.
That last point is a good argument for the derived-rendition model on grounds nobody expects. Deleting one master removes every derivative. Deleting one master in a stored-variant estate starts a search.

What a DAM does not do

Two honest limits, because the category oversells here and it is worth knowing before you write a policy around it.

It does not enforce rights outside itself. Once a file has been downloaded it is gone. Watermarking, tracking pixels and access logging tell you what was taken, not what was done with it afterwards. Anyone selling you enforcement rather than governance is selling you a feeling.

Permissions are usually not per asset. In most platforms, including Cloudinary, access is administered at the folder or collection level, with folder modes determining inheritance, and delivery restriction handled separately through mechanisms like access control on delivery. That combination covers the great majority of real requirements. What it does not give you is an independently queryable permission set attached to each individual asset, so if your rights design assumes that, validate it against the product before it becomes a control in a framework. Structure your folders to match your entitlement boundaries and this is a non-issue; retrofit it later and it is a project.

Start with the assets that already scare you

Do not begin by modelling the whole library. Begin by answering one question: which currently published assets carry third-party rights, and when do they end?

In most organisations that is a few hundred assets, not a few hundred thousand. Capturing rights properly for those takes days rather than months and removes almost all of the near-term exposure. Everything else can be filled in as assets are touched.

That is also the finding an auditor will ask for first, which makes it the highest-value thing in the whole governance framework to have working. How the rights state fits into the wider set of state transitions is in the asset lifecycle, the access half of the problem is in access control, SSO and audit trails, and the case for the whole category is in what enterprise DAM actually is.
May 12, 2026
Designing a taxonomy people actually use
The taxonomy workshop produces a beautiful structure. Seven levels deep, mutually exclusive at every branch, exhaustively covering the material. The person who built it can find anything in it in four seconds.

Nobody else can find anything in it at all, and within a year half the assets are sitting in a top-level folder called To Be Sorted.

Short answer: stop building a tree and build facets. A tree forces one classification and requires the user to guess the designer’s mental model. Facets let several independent dimensions intersect, so anyone can start from whichever one they happen to know. Three to six facets with governed vocabularies will outperform any hierarchy you can design, and they are far easier to maintain.

Why deep hierarchies fail

Three reasons, and only the third is about the design.

Users do not know where things go. A hierarchy asks you to reproduce the classifier’s reasoning. Is a photograph of a product being used by a customer filed under Product, under Lifestyle, or under Campaign? Any answer is defensible, which means the filer guesses and the searcher guesses differently.

Real material does not partition cleanly. Taxonomy in the strict sense) requires mutually exclusive categories. Marketing assets are not mutually exclusive. A single image is simultaneously product photography, spring campaign, German market, approved, and licensed until 2027. A tree makes you pick one of those as primary and hide the rest.

Depth multiplies error. Each level is a decision with a failure rate. Seven levels at ninety percent accuracy each gives you a bit under fifty percent chance the asset is where anyone expects. That is not a training problem, it is arithmetic.

The facet model

Replace the single hierarchy with a small number of independent dimensions. A query is the intersection.

A typical enterprise set:
- Asset type. Photography, illustration, logo, video, document, icon. Shallow and closed. Rarely more than a dozen values.
- Business context. Brand, business unit, or product line, depending on how your organisation is actually shaped. This one mirrors the org chart and therefore needs a refresh path when the org changes.
- Subject. What is depicted. The largest vocabulary and the one most worth basing on a standard rather than inventing, since the Getty vocabularies already cover most subject, material and place terms.
- Market or locale. Where it may be used. Closed list, taken from wherever your organisation already maintains market codes.
- Status. Draft, in review, approved, superseded, expired. Small, closed, and the single most valuable facet in the set, because it is what turns a library into something you can trust.
- Rights. Owned, licensed, restricted, expired. Also small, also closed, and it carries the legal exposure described in rights and expiry as first-class asset data.
Six facets, each shallow, each independently selectable. That structure answers “approved product photography cleared for Germany” without anyone knowing a folder path, and it answers “everything expiring next quarter” too, which no tree does.

Note what is not in the list: date and campaign. Both are usually better as filters over structured fields than as facets, because they are continuous or unbounded, and unbounded facets become scroll lists nobody reads.

How deep should a facet go?

Two levels. Three at the absolute limit, and only for subject.

The reason is that a facet is displayed as a list you scan, not a path you traverse. Past about thirty visible values, scanning fails and people stop using the facet. If a dimension genuinely needs more values than that, it wants type-ahead search rather than a browsable list, and that is a different interface affordance.

The practical rule I use: if a facet value has fewer than about five assets under it and is not going to grow, it should not be its own value. Merge it upward. A vocabulary with two hundred terms where a hundred and forty are used once is a vocabulary that has failed and is generating noise.

Governing the vocabulary

This is the part that determines whether the taxonomy is alive in three years or fossilised.

Someone owns each vocabulary. Named. With a documented process for proposing, approving and retiring terms. Unowned vocabularies grow monotonically, because adding is easy and removing is frightening.

Additions require a case. Not a hard case, but a stated one: what search failed without this term. That single question kills most requests and improves the rest.

Synonyms map to a preferred term. Auto, Car, Vehicle and Automobile should be one concept with three non-preferred labels, not four terms. ANSI/NISO Z39.19 is the standard covering exactly this construction and is worth reading once before you build.

Deprecation is a state, not a delete. Retire a term and remap existing assets. Never delete a term that is in use, because the assets do not disappear, they just become uncategorised.

Review quarterly, with data. Term usage counts, zero-result searches, and facet click-through. Half an hour of numbers prevents years of drift.

Where does free tagging fit?

Somewhere between “useful” and “a slow-motion disaster”, depending entirely on governance.

Open tagging feels democratic and produces product, products, Product, product-shot and prodshot inside a quarter, at which point the tag facet is noise and people ignore it. If you want the flexibility, the workable compromise is a two-tier arrangement: a governed vocabulary that drives facets and filters, plus a free-text keyword field that feeds full-text search only and never appears as a facet. Users get to write what they like, and the navigation stays clean.

Automated tagging changes this calculation somewhat, and it is worth being precise about how. Machine analysis is consistent, which is its main advantage over human tagging: it will call the same thing by the same name every time, which is exactly what human taggers fail to do. It is also frequently generic, and it does not know your business vocabulary. Cloudinary’s asset analysis will reliably tell you an image contains a person, a chair and daylight. It will not tell you it is the Q3 campaign key visual.

So the sensible split is: machine tags populate the subject facet and full-text search, humans populate business context, status and rights. Machines are good at what is in the frame and useless at what it is for.

How do you tell if the taxonomy is working?

Four numbers, collected quarterly. Same discipline as the schema review in the metadata schema an enterprise actually needs, and often the same meeting.
- Zero-result rate. Proportion of searches returning nothing. Above about ten percent and your vocabulary does not match how people talk. Read the actual failed queries; they will tell you which terms are missing in the users’ own words.
- Facet usage distribution. Which facets get clicked. A facet nobody uses should be demoted to a plain field. This is the metric that gives you permission to remove things.
- Term concentration. If ten percent of your terms carry ninety percent of the assets, the vocabulary is too coarse in the middle. If most terms have one asset, it is too fine.
- Time to first useful result. Hard to instrument precisely, easy to observe. Sit with five people, watch them find something, and count the steps. Twenty minutes of observation beats a month of analytics.
Do not do this in a workshop

The most reliable way to build an unusable taxonomy is to design it in a room with the six people who know the material best. They share assumptions the rest of the organisation does not have.

Build the first draft from evidence instead: the search logs you already have, the folder names people actually created, and the words used in the briefs that commissioned the material. Then test it on people who were not in the room, with real retrieval tasks, before it goes anywhere near production.

The taxonomy is not a deliverable, it is a running service. Treating it as a project that finishes is the reason so many of them are dead by year two, which is one of the mechanisms behind why DAM rollouts fail. It also has to survive the state changes described in the asset lifecycle, and it only matters at all because of the argument in what enterprise DAM actually is.
May 10, 2026
A DAM governance framework that survives an audit
The auditor asks a simple question. Show me every asset published to a customer-facing channel in the last quarter that used third-party licensed material, and show me the licence was valid on the publication date.

If answering that takes three weeks and four people, you do not have governance. You have a policy document and a lot of goodwill.

Short answer: DAM governance is a set of named controls, each with an owner, each producing evidence as a by-product of normal operation rather than on request. If a control depends on a person remembering to do something, it will fail, and it will fail silently. Design so that the evidence is a side effect of the workflow, and the audit becomes a query.

What governance is not

Three things get mistaken for governance and none of them is.

A policy document. Necessary, insufficient. A policy that is not enforced by a system is a statement of intent, and auditors have learned to treat it that way. The question is never “do you have a policy”, it is “demonstrate the control operated”.

A steering committee. Useful for decisions, useless as a control. A committee that meets quarterly cannot govern an operation that ingests two thousand assets a month.

Permissions. Access control is one control among a dozen. It answers who could act, not whether what happened was correct. Plenty of compliant-looking libraries are full of expired material that everybody had every right to upload.

The control set

Six control families, in the order they tend to fail. Each one needs a named owner, an operating frequency, and a defined evidence artefact.

1. Ingest control. Nothing enters without required metadata and a declared rights status. This is the cheapest control in the entire framework and the one with the highest leverage, because everything downstream depends on the fields being there. Enforce it at the API, not just the upload form, or your integrations become the hole. The field model this depends on is in the metadata schema an enterprise actually needs.

2. Approval control. An asset is not publishable until a named role has approved it, and the approval is recorded with an identity and a timestamp. The common failure here is approval by email, which is an approval that does not exist as far as the system is concerned.

3. Rights control. Licence terms are held as structured data with a real expiry date, and expiry triggers an action rather than a report. Reports are read by nobody. This deserves its own treatment and gets it in rights and expiry as first-class asset data.

4. Access control. Identity comes from the corporate directory, groups derive from directory groups, and the leaver process removes access without anyone in the DAM team being involved. Anything else and your access review is fiction. Covered properly in access control, SSO and audit trails.

5. Retention and disposal control. Assets have a defined retention period and something happens at the end of it. This is where most frameworks stop being real, because deletion is frightening and nobody wants to own it. Records management as a discipline has thought about this for a century and the general principles transfer directly.

6. Change control. Schema changes, vocabulary changes and permission model changes go through a documented path. Without this, the taxonomy quietly mutates and your historical data stops meaning what it meant.

Automated versus manual, and why it matters more than it sounds

Sort every control into two buckets: those the system performs, and those a person performs.

The manual ones will degrade. Not because people are careless, but because manual controls depend on load, staffing and attention, and all three vary. A control that runs correctly ninety-five percent of the time is a control with a five percent finding rate, and auditors sample.

So the design instruction is straightforward. Any control that can be automated must be, and the ones that cannot be automated need compensating detection. If a human decides whether an asset is on-brand, you cannot automate the judgement, but you can automate the fact that the judgement was recorded, by whom, and when.

This is why the platform choice is a governance choice rather than a procurement one. Controls you can express in the system hold. Controls you express in a wiki page do not.

Two capabilities carry most of the automation weight in practice:
- Upload presets or equivalent, so that ingest rules are enforced server-side regardless of which client is uploading. Cloudinary upload presets are a workable reference for the pattern: the rule lives with the platform, not with each integration.
- Event notifications, so that a state change can trigger downstream action rather than waiting for someone to notice. Webhook-style notifications turn expiry and approval from reports into workflow.
Neither is exotic. Both are worth confirming in a demo, because “we support that” and “show me the server rejecting a non-compliant upload” produce different answers surprisingly often.

A note on what governance cannot do at asset level

Be careful about what you promise the risk committee here, because there is a gap between how governance is usually described and what most platforms actually enforce.

In most enterprise DAM products, including Cloudinary, permissions are administered at the folder or collection level rather than per individual asset, with folder modes determining how assets inherit their placement. That is a perfectly workable model, and it is how the majority of real deployments run. It is not the same thing as per-asset entitlement that a system can evaluate at request time.

If your control design assumes each asset carries its own independently queryable permission set, validate that assumption against the product before you write it into a framework. Designing your folder structure to match your permission boundaries is the practical answer, and it is much easier to do at the start than to retrofit.

How do you make the audit a query?

Work backwards from the questions you will be asked. There are usually about eight, and they are stable across audits.
1. Who has access to what, and when was that last reviewed?
2. What changed, by whom, when?
3. Which published assets carry third-party rights, and were those valid at publication?
4. What is past its retention date and still present?
5. Which assets were approved, and by whom?
6. What was deleted, by whom, and was it authorised?
7. Which integrations can write to the system, and under whose credentials?
8. When did we last test that the controls above actually operate?
For each one, name the query and the person who can run it. If the answer involves exporting to a spreadsheet and reconciling by hand, that control is not operating, it is being reconstructed. The difference matters enormously to an auditor and not at all to anyone else, which is why it goes unnoticed until the week it does not.

Mapping to the frameworks you are already assessed against

You almost certainly do not need a bespoke DAM control framework. You need to express DAM controls in the language of the frameworks your organisation already reports against.

NIST SP 800-53 gives you the control catalogue with identifiers your security team already uses, and the NIST Cybersecurity Framework gives the functional grouping. If you report SOC 2, the trust services criteria map onto the access, change and monitoring controls above almost directly. Where personal data is depicted in your assets, and in a photography library it always is, GDPR obligations attach to the images themselves, not only to the database rows.

Doing the mapping is a day of work and it removes an entire category of argument. Your controls stop being a DAM thing that security has to evaluate from scratch and become three lines in a register they already maintain.

Who owns this

One person. Named. With time allocated.

Governance distributed across everyone is governance owned by nobody, and it is the single most reliable predictor of a framework that looks complete on paper and produces findings in practice. The role is usually a DAM manager or information governance lead, it is roughly a third of a full-time job at mid enterprise scale, and leaving it unstaffed is the most common reason rollouts fail after a successful launch.

If you are still assembling the case for the platform underneath all this, the foundation is in what enterprise DAM actually is.
April 25, 2026
The metadata schema an enterprise actually needs
Every metadata workshop follows the same arc. Someone asks what we should capture, everyone answers honestly, and ninety minutes later there is a whiteboard with forty-three fields on it. All of them are genuinely useful. The schema ships. Eighteen months later, five fields are populated and the rest are empty columns in an export nobody reads.

Short answer: design the schema around what will actually get filled in, not around what would be nice to know. That means a small required core, a conditional layer that only appears when it applies, and everything else either inferred by the system or left out. A schema with twelve real fields beats one with forty aspirational ones, every time, because search quality depends on completeness rather than richness.

Why big schemas fail

Three mechanisms, and they compound.

Every required field is a tax on contribution. A twenty-field upload form does not produce twenty fields of data. It produces fewer uploads, and it produces n/a, TBC, and the same value copy-pasted down the column. You have converted a data quality problem into a data quality problem with more rows.

Fields designed for one department are noise to everyone else. The photographer’s release number matters enormously to legal and not at all to the person looking for a header image. Put both on the same flat form and you have made the form worse for both.

Unpopulated fields poison search. This is the part that surprises people. If a field is filled in thirty percent of the time, filtering on it hides seventy percent of the matching material. Users learn quickly that the filters lie, and they stop using them. A field that is inconsistently populated is worse than no field, because it actively produces wrong answers with confidence.

The three-tier model

Structure the schema in tiers rather than as one flat list.

Tier one: required, always, no exceptions. Five to eight fields, every one of which someone will genuinely use to find something. Typically: asset type, owning business unit, subject or product, approval state, and rights status. If you cannot explain in one sentence which query a required field serves, it is not tier one.

Tier two: conditional. Fields that appear only when a tier one value makes them relevant. If rights status is “licensed”, then licensor, licence expiry and permitted territories become required. If the asset type is “product photography”, then SKU becomes required. The form stays short for everyone and gets long only for the cases that warrant it.

Tier three: inferred or optional. Dimensions, format, colour profile, dominant colours, detected objects, extracted text. Nobody should type any of this. It is either read from the file or produced by analysis, and modern platforms will do it on ingest. Cloudinary exposes this through its asset analysis capabilities, which populate descriptive attributes automatically rather than asking a human to.

The rule of thumb that has held up for me: if a field can be derived, deriving it is always better than asking, even when asking would be more accurate. Accuracy at thirty percent coverage loses to approximation at ninety-eight.

Do not invent your vocabulary from scratch

There are standards for this, they are free, and reusing them buys you interoperability you will need later.

Dublin Core gives you the fifteen-element descriptive base that most systems already understand, with the full property set published as DCMI Terms. IPTC Photo Metadata is the standard the photography and publishing supply chain actually uses, so if you receive material from agencies it is already arriving in that shape. For controlled vocabularies covering subject, materials and geography, the Getty vocabularies are the reference set, and ANSI/NISO Z39.19 is the guidance on constructing your own controlled lists if you have to.

Map your fields to these rather than parallel to them. It costs a day and it means that when you export, migrate, or feed a partner, the mapping already exists.

The place to depart from the standards is your own operational vocabulary: business unit, brand, campaign, approval state, product code. Those are yours and no standard covers them. Everything descriptive should sit on a standard.

Free text, controlled lists, and where to draw the line

The single highest-leverage schema decision is which fields are typed and which are chosen.

Controlled list anything you will ever filter, group, or report on. Brand, market, asset type, approval state, rights status, channel. If two people can spell it differently, it must be a list. US, USA, United States, us and U.S. are five values and one country, and no amount of search cleverness recovers from that.

Free text the description and the title, and nothing else. These exist for human reading and full-text search, not for filtering.

Tags are the tempting middle ground and they are a trap at enterprise scale unless governed. Open tagging produces product, products, product-shot, productshot and prod within a quarter. If you want tags, run them from a managed vocabulary with an approval path for additions, and accept that this needs an owner. The mechanics of keeping that vocabulary usable are in designing a taxonomy people actually use.

How do you know if the schema is working?

Measure three things quarterly. They are cheap to collect and they tell you everything.
- Completeness per field. Percentage of assets with a non-null, non-junk value. Anything under eighty percent on a tier one field is a broken field, not lazy users. Either it is unclear, or it is not actually required, or the form is asking at the wrong moment.
- Filter usage. Which facets people actually click. A field with high completeness and zero filter usage is dead weight and should be demoted to tier three. This is the metric that gives you permission to delete fields, which is the hardest political act in metadata work.
- Zero-result rate. Proportion of searches returning nothing. High zero-result rates usually mean the vocabulary in the schema does not match the vocabulary in people’s heads, which is a naming problem rather than a coverage problem.
Publish these. A schema that nobody reviews becomes a schema nobody trusts, and this is the whole reason governance needs a standing owner rather than a launch project.

Where the schema has to live

One point that gets missed in the design and then costs a migration later: the schema needs to be a first-class, queryable structure in the platform, not a bag of key-value pairs stapled to the side.

The practical test is whether you can define a field once, with a type and a controlled list, and have it enforced at the API as well as in the interface. If validation only exists in the upload form, every integration becomes a hole in your data quality, and integrations are how most assets arrive at enterprise scale. Cloudinary handles this through structured metadata fields with defined types and validation, which is the shape to look for regardless of vendor: typed, centrally defined, enforced everywhere the asset can enter.

Ask that question in every demo. “Show me the field definition, then show me the API rejecting a bad value.” Most platforms pass. The ones that do not will cost you a data cleanup project in year two.

Start smaller than feels right

If you are building this now, my advice is to ship six required fields and be ruthless about it. You will be told this is not enough. It will be enough, because six fields at ninety-five percent completeness supports better search than thirty fields at twenty percent.

Add fields when a specific failed search justifies one, and make the justification write it down. That keeps the schema tied to real retrieval need rather than to what a workshop imagined, and it makes the asset lifecycle tractable, because a small schema is one you can actually maintain across a state change.

The broader case for why the fields matter more than the storage is in what enterprise DAM actually is, and if your fields include anything about permissions or expiry, read access control, SSO and audit trails before you finalise the model.
April 10, 2026