Enterprise Digital Asset Management

Tag: Compliance

Obligations that attach to visual material: rights, privacy, retention, and the evidence a regulator or auditor will ask for.

  • Rights and expiry as first-class asset data

    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.

    A wax-sealed contract with a visible date stamp on a matte black surface under a raking cyan light, with a wall of out-of-focus print proofs behind and one lit amber

    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.

    A gantt-style rights timeline with cyan licensed windows, a vertical today rule, and three amber expired bars still in use

    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.

    An engineering schematic of a rights clearance gate with three sequential interlocks, one token stopped amber at the second and vented to a hold tank

    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.

  • A DAM governance framework that survives an audit

    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.

    An empty corporate boardroom at night with one closed folder on the table and a wall control board of indicator lights, four of them amber

    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.

    A control framework figure of four concentric rings labelled policy, process, system and asset, with amber manual control points clustered on the outer rings

    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.

    A fan of off-white audit request sheets with an empty checkbox column, two cyan ticks near the top and one amber annotation at the bottom

    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.