Enterprise Digital Asset Management

Tag: Licensing

Terms, territories and permitted uses held as structured data with a link back to the agreement of record.

  • 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.

  • What enterprise DAM costs, line by line

    What enterprise DAM costs, line by line

    A vendor quotes 180,000 a year. Finance approves it. Two years later the programme has cost roughly double that and nobody can point at the moment it went wrong, because nothing went wrong. The quote was accurate. It was just answering a narrower question than anyone thought.

    Short answer: budget the licence at somewhere between forty and sixty percent of your actual five-year cost. The rest is integration, migration, storage and delivery overage, and the people who run it. The people line is usually the largest single item and it is almost never in the business case, which is why so many DAM programmes are technically successful and commercially disappointing.

    A horizontal stacked bar chart of five cost categories, each split into a cyan quoted portion and an amber not-quoted portion that dominates integration and people

    The full cost stack

    Six lines. Build the model with all of them or you are not comparing vendors, you are comparing quotes.

    1. Platform licence. The number on the proposal. Usually banded by seats, storage, or some composite. Ask specifically what happens on renewal, because year-one discounting is standard and the uplift in year two is where the real price lives.

    2. Implementation and integration. Configuration, schema build, permission model, and connecting the DAM to everything that consumes from it. Vendors will quote the first three and not the fourth, because the fourth depends on your estate. In practice this runs from thirty to a hundred percent of first-year licence, and the variable is how many systems and how good their APIs are. Integration patterns is where that number actually gets set.

    3. Migration. Moving and describing the existing library. Cost scales with how bad your current metadata is, not with how many terabytes you have. Ten terabytes of well-described material is a cheap migration. Two terabytes of IMG_4471_final_v3.jpg is not, and the reasons are in migrating a million assets.

    4. Storage. Usually straightforward and usually small. The trap is not the rate, it is the multiplier. If your platform stores every rendition as a separate file, you are paying for the master plus every crop, every format and every size, forever. A derived-rendition model stores the master only.

    5. Delivery and bandwidth. The line most often underestimated, because nobody models it until they are live. If your DAM also serves your public web traffic, this is a real number that scales with your marketing success. If it does not serve public traffic, you are paying for a separate CDN somewhere else and should count that here too.

    6. People. A DAM manager or information governance lead, plus a share of a developer, plus the taxonomy and cataloguing time that has to come from somewhere. At mid enterprise scale this is typically 0.5 to 1.5 full-time equivalents on an ongoing basis. Fully loaded, that frequently exceeds the licence.

    A five-year cumulative cost chart with a smooth cyan platform line crossed at year two by a steeper amber operating line

    The three commercial models

    Vendors price on one of three bases and they are not equivalent. Which one suits you depends almost entirely on your shape.

    Per seat. Predictable, easy to approve, and it prices the thing you least want to restrict. Every seat you do not buy is a person who emails a colleague for the file instead, which is exactly the behaviour you are paying to eliminate. Watch for the distinction between full users and consumer or read-only users, because the ratio is usually ten to one and the pricing difference is where the negotiation lives.

    Per volume. Storage, bandwidth, transformations, API calls, or a composite unit. Scales with usage rather than headcount, which means adoption success shows up as a cost increase. That is not a reason to avoid it, but it does mean you need a forecast and a monitoring habit, not just a budget line.

    Enterprise agreement. Custom, negotiated, usually unbanded. Fine, and often the right answer at scale, but it removes your ability to benchmark. Get at least one banded quote from a comparable vendor so you know what you are being asked to pay a premium for.

    Cloudinary is a useful reference point on the volume model because its pricing is published rather than gated, which is unusual in this category. The published tiers run from a free plan at 25 credits per month, through Plus at 99 dollars per month for 225 credits, to Advanced at 249 dollars per month for 600 credits, with enterprise agreements custom. The credit is a composite unit, and the definition is worth reading before you model anything: one credit covers 1,000 transformations, or 1 GB of managed storage, or 1 GB of delivered bandwidth, and you spend across those as you use them.

    That composite structure is the part to model carefully. It is genuinely flexible, and it means your bill responds to the mix of what you do rather than to a single dimension. It also means a rough forecast needs three inputs rather than one.

    Two details that materially change the arithmetic: transformations and bandwidth are measured over a rolling thirty-day window while storage reflects your current total, and re-delivery of an already-generated derivative does not count as a new transformation. The second one matters a lot. It means a heavily-cached public site costs far less in transformation terms than a naive calculation suggests.

    Which lines do vendors leave out?

    Reliably four, and none of it is dishonest. They are quoting their product, and these are your costs.

    • Your integration effort. They quote their connector. They do not quote the six weeks your team spends on the other side of it.
    • Delivery at production volume. Pilot traffic is not production traffic. Ask for the overage rate in writing, not just the included allowance.
    • Ongoing cataloguing. Somebody describes the assets. That somebody costs money whether they sit in your team or an agency.
    • The second-year uplift. Ask for a capped renewal in the contract. This single clause is worth more than most of the feature negotiation.
    A fanfold invoice cascading across deep navy under raking light, most lines grey, three circled in amber, one page edge tabbed in cyan

    Where the money actually goes wrong

    Not in the negotiation. In three specific decisions made after signature.

    Storing renditions instead of deriving them. Every stored variant is storage you pay for, a sync problem you own, and a migration item later. If the platform can produce a crop from a URL parameter, use that, and the Cloudinary resizing documentation shows the shape of it. This is the difference between a storage line that grows with your library and one that grows with your library times fifteen.

    Buying seats for people who only download. Most vendors have a cheaper consumer tier or a public collection mechanism. Full seats for the reseller network is the most common single overspend in this category.

    Serving originals. If you deliver the master file to a web page because nobody set up automatic format and quality, you pay for the bandwidth twice: once at the DAM and once in your conversion rate. Automatic format and quality selection is a one-parameter change with a large bandwidth effect, and it is covered from the performance side in delivery is part of your DAM.

    How do you build a number you can defend?

    Do it in this order. It takes about a week and it survives contact with finance.

    1. Count the estate. Masters, renditions, annual growth, and current storage. Not folder size, actual distinct masters. The ratio between the two is itself a finding.
    2. Forecast delivery. Monthly image requests across all channels, plus average delivered size. If you do not have this, your CDN or web analytics does.
    3. List the integrations. Every system that will read from or write to the DAM, with a rough effort estimate each. This is the line that moves most between vendors.
    4. Staff it honestly. Name the roles and the fractions. If nobody is named, the programme has no owner and the adoption risk is your largest unpriced exposure.
    5. Model five years, not one. Total cost of ownership over the realistic life of the decision. Year one flatters the incumbent option and every platform looks cheap in a pilot.

    Then take that model into the business case, where the benefit side gets the same treatment. And when you are comparing the resulting numbers between vendors, the platform comparison is organised by who each one is actually for, which is more useful than a feature grid once the prices are within twenty percent of each other.

    If you are building the requirement list that generates these quotes in the first place, start from the requirements checklist and cut it before you send it. Every requirement you cannot justify is a line item somebody will price. The foundation for all of it is in what enterprise DAM actually is.