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.
Unknownis 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.
Perpetualis 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:
- Change the asset state to expired, automatically, at the boundary. Not “flag for review”. Change the state.
- 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.
- 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.
- 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.