Enterprise Digital Asset Management

Tag: Governance

Named controls with named owners, producing evidence as a by-product of normal operation rather than on request.

  • Why DAM rollouts fail after a successful launch

    Why DAM rollouts fail after a successful launch

    Launch week is good. Attendance at training is high, the login numbers are strong, the executive sponsor sends a note. Everything is working.

    Month four, uploads have flatlined. Month six, the brand team has a folder again. Nothing broke. Nobody complained. The system simply stopped being where the work happened.

    Short answer: DAM rollouts fail because the DAM is a cost to contributors and a benefit to consumers, and nobody funds the contribution side. Uploading and describing an asset takes real minutes and delivers value to someone else, later. Unless that cost is removed, paid for, or made unavoidable, contribution decays to zero and the library ages out. Everything else people call an adoption problem is downstream of this.

    An isometric scene of a polished cyan-edged building with an empty entrance ramp, and a well-worn amber dirt path leading round it to a cluster of improvised sheds

    The asymmetry, precisely

    Two populations, opposite incentives.

    Consumers get immediate value. They find something in thirty seconds that used to take fifteen minutes. They need no persuading and they will use the system happily forever.

    Contributors pay the whole cost. Uploading, categorising, filling in rights fields, attaching approval evidence. It takes minutes per asset, it produces no benefit to the contributor, and the beneficiary is an anonymous colleague at an unspecified future date.

    Every metric that looks like adoption failure follows from this. Login counts stay high because consumers keep coming. Upload counts fall because contributors stop paying. And because consumption looks healthy on the dashboard, the decay is invisible for two quarters.

    An adoption curve chart with a cyan logins line spiking at launch then decaying, and an amber assets-uploaded line that never leaves the floor

    The four failure mechanisms

    1. Contribution is unfunded. Nobody’s objectives include cataloguing. The studio manager is measured on output, the agency is paid for deliverables, the campaign lead is measured on the campaign. Describing assets is the thing everyone does last and therefore does not do.

    2. The system is not where the work is. If contributing requires opening a second application, the fraction of people who do it is much smaller than you would guess. This is not laziness, it is context switching cost, and it is why the embedded picker pattern in integration patterns is an adoption intervention rather than a technical one.

    3. Search does not work well enough, early enough. Consumers give it two or three chances. If the first searches fail because the library is thin or the metadata is sparse, they revert to asking a colleague and never come back. Adoption is won or lost in the first month of consumer experience, which is why launching with a small well-described library beats launching with a large badly-described one.

    4. Nobody owns it. The programme had a project manager. The project ended. The role did not become a job, so schema drift, vocabulary sprawl and permission decay accumulate with nobody watching, and the governance framework becomes a document about a system nobody is running.

    The operating model

    Four roles. They do not each need a person, but each needs a named owner with allocated time.

    Platform owner. Accountable for the system: roadmap, vendor relationship, integrations, budget. Usually part of a marketing operations or digital function. Roughly 0.3 to 0.5 FTE at mid enterprise scale.

    Librarian. Owns the schema, the vocabularies and data quality. Reviews the metrics, approves vocabulary changes, fixes what is broken. This is the role most often left unfilled and the one whose absence is most visible after eighteen months. Between 0.5 and 1.0 FTE depending on ingest volume.

    Contributors. The studios, agencies and campaign teams who put material in. The critical design question is not who they are but whether contributing is in their brief and their contract.

    Consumers. Everyone else. Need nothing from you except that search works.

    The two that get missed are librarian and the contractual half of contributor. If your agency contracts do not specify that assets are delivered into the DAM with completed metadata, they will be delivered by email in a zip file, and you will pay someone internally to do the cataloguing that the agency was better positioned to do.

    Change your agency statement of work at the next renewal. It is the highest-leverage single intervention available and it costs nothing.

    An operating model figure with owner, librarian, contributor and consumer role cards, the contributor card amber with a broken dashed connector

    Removing the contribution cost

    Since contribution is the bottleneck, most of your effort should go into making it cheaper rather than into persuading people it matters.

    Automate every field you can. Dimensions, format, colour, detected subject, extracted text. None of these should ever be typed. Machine analysis on ingest, such as automatic asset analysis, populates the descriptive layer so humans only supply the business context that machines cannot know. This alone can halve the fields on the form.

    Set defaults from context. If the upload comes from the German product studio integration, market and business unit are known. Do not ask. Server-side upload presets let you bind those rules to the ingest path rather than to the person.

    Cut the form. Six required fields, not twenty. The reasoning is in the metadata schema an enterprise actually needs, and the adoption argument is simply that every field is a cost multiplied by every asset.

    Ingest where the work already happens. Watched folders, direct connectors from the studio’s tools, automated delivery from the agency’s system. The best upload is the one nobody performed.

    Catalogue at the point of highest knowledge. The person who commissioned the shoot knows what it is for. Two months later, nobody does. Capturing metadata from the brief at commissioning time, before the asset exists, is unusual and it works remarkably well.

    How do you tell if adoption is actually failing?

    Not from login counts. Four measures that tell the truth:

    • Contribution rate. New assets per month against your estimate of assets created per month. The gap is your shadow library, and it is the single most important number in the whole programme.
    • Metadata completeness on new assets. Falling completeness means people are gaming the form, which means the form is too long or the fields are unclear.
    • Zero-result search rate. Rising means the library is not keeping up with what people need, which is the consumer-side symptom of a contribution problem.
    • Proportion of published placements referencing the DAM. If your CMS can tell you how many images on the live site come from the DAM versus uploaded locally, that number is the closest thing to ground truth you will get. It is usually sobering.

    Review these monthly for the first year. Not because you will act every month, but because the decay is gradual and only visible as a trend.

    What actually works, in order

    Make the DAM the only path. Not a policy, an architecture. If the CMS can only place images that come from the DAM, the shadow library has nowhere to go. This is uncomfortable and it is the single most effective intervention available. Introduce it after search is good, never before.

    Fund the librarian. A funded 0.6 FTE beats a policy document and an all-hands presentation, every time.

    Launch small and well described. A thousand assets that are findable creates advocates. Fifty thousand that are not creates a reputation that takes two years to shake off. This is also why migration should leave most of the library behind.

    Fix agency and studio contracts. Metadata is a deliverable. Write it in.

    Publish the numbers. Monthly, to the sponsor, including the bad ones. A programme that reports honestly gets support when it needs it. One that reports only launch metrics gets quietly defunded at the next budget round.

    None of this is about training. Training is necessary and it is not the constraint. The constraint is that somebody has to pay the contribution cost, and until you decide who, the answer will be nobody.

    The taxonomy discipline that keeps search working is in designing a taxonomy people actually use, the state model behind it is in the asset lifecycle, the funding argument belongs in the business case, and the foundation 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.