Digital rights & usage management in a DAM: a practical guide

Why it matters

Most DAM libraries hold assets the organisation does not fully own: stock images, agency photography, licensed music, talent and influencer content, fonts, user-generated content, partner logos. Each comes with terms. When those terms live in email threads and contract folders, the same failures keep happening:

• Use after expiry. A licensed image stays on a website or in a reused template after its term ends, because nothing in the DAM marked it expired or showed where it was used.
• Use outside scope. An image cleared for print in one country is used in a global social campaign. The territory and channel limits were in a PDF, not in a field a rule could read.
• Missing releases. A recognisable person appears in an asset, but no model release can be found, or the release does not cover the new use. The IPTC describes a model release as a document granting the right to use an image of a person depicted, notes that the law on this varies between countries, and says the release should detail the scope of intended use R2.
• Lost credit and copyright information. Files leave the DAM with their embedded metadata stripped. The Embedded Metadata Manifesto says that copyright management information "must never be removed from the files" R3. In the United States, section 1202 of the Copyright Act prohibits intentionally removing or altering copyright management information without authority. The statute's definition includes the author, the copyright owner, the terms and conditions for use, and identifying numbers R12.
• No evidence. When a claim arrives, nobody can show what was licensed, who approved the use or where the asset was published.

Cultural-heritage practice has long treated this as a core duty. The Collections Trust's Spectrum standard, used by UK museums, sets as a minimum requirement that "your system allows you to see when rights or licences have expired" R14. The Digital Preservation Coalition advises treating licences, schedules and rights correspondence as key institutional records R16.

On figures. No independent, freely accessible study was found that measures the cost of rights failures in DAM. Vendor-published figures exist but are not repeated here.

Core concepts

Recommended practices

1. Agree the scope, the owners and the system of record

Why. A DAM can apply rules, but it cannot decide what a contract means. The Digital Preservation Coalition advises addressing rights management during acquisition and building it into institutional strategy, not adding it later R16. Spectrum likewise starts with policy questions, such as how rights are identified for new acquisitions and what to do when rights holders cannot be traced R14.

How.

• Write down which rights types you manage: copyright and licences, model and property releases, music and voice, fonts, trademarks, data-protection consent, and AI training permissions.
• Name a rights owner (legal, brand or a rights specialist) who defines the rules and the controlled values. Name a DAM owner who implements them. The roles split in DAM metadata schema & governance applies here too.
• Decide the system of record. If contracts and talent agreements live in a contract or rights-management system, the DAM should hold a reference and the fields needed to drive rules, synchronised by integration. It should not keep a second, editable copy of the contract terms.
• Agree a default posture: may an asset with unknown rights be shown internally, downloaded, or published? Most organisations choose "visible, not downloadable" or "hidden until cleared".

2. Model rights as linked records, not only as asset fields

Why. One stock licence or photo shoot contract often covers hundreds of assets, and one asset can carry several rights at once: the photograph, the model, the location, a piece of music, a font. If terms are typed onto each asset, they drift apart and nobody can update them all when a contract is renewed. PREMIS models a rights statement as its own entity linked to objects and agents R10. Spectrum asks you to record, for each right, the type, the holder, the start and end dates and where the documentation is kept R15.

How.

• Create a rights record (licence, contract or release) with: identifier, basis (copyright owned, licence, release, public domain, statute, policy), rights holder or licensor, permitted uses, restrictions, start and end dates, required credit, fees or duties, the signed document, and an owner.
• Link each asset to one or more rights records, and let asset-level fields (status, expiry, credit) be derived from them. When several records apply, the most restrictive term should win: the earliest end date and the smallest territory.
• Some platforms support this directly. In the wiki, Wedia documents rights-type and contract resources from which assets inherit rights . Orange Logic documents configurable rights records for music, talent, stock and photographers, with territory restrictions and routing to legal for approval . Where the platform has no rights object, use a linked "contract" asset or an external system, not free text. The solution pages cited in this guide are linked in How DAM platforms support this.

3. Define a core rights field set mapped to IPTC and PLUS

Why. Rights information is only useful outside the DAM if other software can read it. The IPTC Photo Metadata Standard includes a set of rights properties, many of them from the PLUS License Data Format, which the PLUS Coalition (a non-profit) maintains for communicating image licence information R1 R4 R20. Google Images also reads several of these properties to display licence details R13.

How. Map the asset-level fields that should travel with the file. Labels, identifiers and cardinality below are from the IPTC Photo Metadata Standard 2025.1 R1; controlled values are from the PLUS specification R4.

Keep the following DAM-only (or in the rights record): licence start and end dates, territories, channels, exclusivity, internal rights status, contract reference, cost centre and internal notes. These drive rules, but they are often confidential and not meant to be embedded in files sent to partners. Record this classification in your data dictionary (see the metadata schema guide linked above).

For collections where the question is copyright status rather than a licence (archives, heritage images), RightsStatements.org offers 12 standard statements with stable URIs, in three groups: in copyright, no copyright, and other or unclear status. They are not meant for licensing your own works; for that, its guidance points to Creative Commons licences R11.

4. Use controlled values for every field that drives a rule

Why. A rule can only test a value it can recognise. "EU only", "Europe", "EMEA excl. UK" and "see contract" cannot drive a download block. PLUS publishes controlled vocabularies with stable identifiers for release status and data mining, for example MR-LMR for "Limited or Incomplete Model Releases" R2 R4.

How.

• Rights status: a short list such as owned, licensed, open licence, public domain, restricted, expired, unknown. Define each value in writing.
• Territory: a code list such as ISO 3166 country codes, plus named groupings you define once (for example "EU-27"). Store a list of values, not one text string. A vendor guide makes the same point: capture territory clearances as structured data at ingest, not in free-text notes R23 (vendor publication).
• Channel / media: a shared list (print, web, social, paid media, broadcast, in-store, internal). The PLUS Coalition also publishes a Media Matrix of media categories with shared identifiers R20.
• Release status: use the PLUS values directly.
• Dates: typed date-time fields with a time-zone policy. An embargo that lifts "at midnight" must say which midnight.

Govern these lists like any vocabulary: see Taxonomy, controlled vocabularies & thesauri.

5. Capture rights at ingest and make "unknown" explicit

Why. Rights are cheapest to record when the asset arrives: the photographer, agency and contract are known then. Spectrum's minimum requirements include documenting new acquisitions promptly to avoid backlogs, and recording the reasonable enquiries made when a rights holder is unknown R14.

How.

• Make rights status mandatory on every ingest path (web upload, bulk upload, API, connectors, migration). Make the other rights fields conditionally mandatory: if status = licensed, require the licence record, licensor and end date; if people are recognisable, require the model release status.
• Pre-fill from the source wherever possible: upload presets per agency or shoot, values read from embedded IPTC/PLUS fields, or values copied from the brief or purchase order.
• Never treat an empty field as permission. Default to unknown, and give unknown a restrictive rule.
• When the holder cannot be found, record the due-diligence research (who was contacted, when, the result), as Spectrum recommends R15.
• For older libraries, plan a rights backfill: prioritise high-use and externally published assets, and restrict the rest until they are reviewed.

6. Handle model and property releases as controlled documents

Why. Releases are often the weakest point. They may be missing, cover only some people, or be limited in use. The IPTC user guide recommends using the "Unlimited Model Releases" value sparingly and checking the wording of the release thoroughly before choosing it R2. Releases also contain personal data. Spectrum notes that data-protection rights can be attached to photographs of living people R14.

How.

• Give every release a unique identifier and record it in the release ID field of each asset it covers. The IPTC suggests adding an ID to releases that do not have one, so they can be cross-referenced R2. A professional photographers' association, ASMP, advises archiving scanned releases with the image files R18.
• Store the signed release in a restricted location (a protected asset type or the contract system), not as an attachment visible to everyone who can see the photo.
• Record the scope of each release (uses, media, duration, territory) in the linked rights record. Use Limited or Incomplete whenever any person lacks an unlimited release.
• Flag assets that show minors with the Minor Model Age Disclosure property and apply stricter rules.
• Where use relies on consent under data-protection law, plan for withdrawal. For example, UK ICO guidance on UK GDPR consent says that withdrawing consent must be as easy as giving it, and that processing based on consent must stop once it is withdrawn R17. In the DAM this means being able to find every asset and every published use linked to one person. Ask your data-protection officer which rules apply to you.

7. Turn expiry and embargo into automated actions

Why. A date nobody acts on protects no one. Spectrum asks that your system lets you see when rights or licences have expired R14. A vendor guide lists the decisions to make near expiry: review, renew, replace, archive or restrict R22 (vendor publication).

How.

1. Before expiry: send alerts to the asset owner and the rights owner with enough lead time to renew or replace (for example 60, 30 and 7 days). Provide a saved search "expiring in the next N days".
2. At expiry: apply a defined action: change the status, block downloads, hide from portals and share links, watermark previews, or move to an archive. Platforms differ, as the wiki shows. Adobe Experience Manager Assets documents automatic unpublishing and flagging of expired assets . Brandfolder hides expired assets from guests, share links, collections and CDN embeds . MediaBeacon blocks download, crop, e-mail and check-out for assets outside a configured saved search, such as an expiry rule .
3. After expiry: list the places where the asset is still published (see practice 10) and assign take-down or replacement tasks.
4. Embargo: the same mechanism in reverse. Keep the asset hidden or non-downloadable until a date and time, then release it automatically. Check that embargoed assets do not leak through renditions, previews, search thumbnails or public links.
5. Derivatives: crops, resized versions and composites inherit the most restrictive rights of their sources. Make sure the expiry rule reaches them too.

8. Enforce rights at every point where assets leave the DAM

Why. Rights metadata only reduces risk if it changes what users and systems can do. Enforcement that covers the web interface but not the API, a connector or a public link gives a false sense of control.

How.

• List every exit point: download, share links, brand portals, CDN or dynamic-media URLs, API, CMS, PIM and design-tool connectors, e-mail, export.
• Choose a control for each rights status: full access, low-resolution only, watermark, download on request with approval, acceptance of terms before download, or no access. Wiki examples: Sitecore Content Hub documents rights profiles where restricted assets need a compliant intended use or an approved download request, and public links to restricted assets return 404 . Frontify documents licence records with optional acceptance before download .
• Capture the intended use at download for restricted or licensed assets (channel, market, campaign). It supports both the rights check and the audit trail.
• Test each exit point with a sample of expired, embargoed and restricted assets after every platform release. Include the API and connectors used by integrators.

9. Keep rights information in delivered files

Why. Once a file leaves the DAM, its embedded metadata is often the only rights information that goes with it. The Embedded Metadata Manifesto asks that copyright management information never be removed, and that other metadata be removed only with the copyright holder's agreement R3. In the United States, removing CMI can also have legal consequences R12.

How.

• On download and export, write back at least the copyright notice, creator, credit line, usage terms, Web Statement of Rights and licensor. Do not embed confidential contract terms.
• Point Web Statement of Rights to a stable page that explains the terms or how to obtain a licence. Google uses this property and the Licensor URL to show licensing details in image search R13.
• For openly licensed content, build the credit line from title, author, source and licence. Creative Commons calls this "TASL" and recommends linking each element where possible R19.
• Check that renditions and CDN transformations keep the rights fields. Many image pipelines strip metadata to reduce file size. Run the same round-trip tests as for other metadata (see DAM metadata schema & governance, practice 7).
• AI provenance is a separate but related layer: the IPTC DigitalSourceType property and C2PA Content Credentials are covered in Content provenance in DAM: C2PA & IPTC DigitalSourceType.

10. Track where assets are used, and log who did what

Why. You cannot take down what you cannot find. When a licence ends, a release is withdrawn or a claim arrives, you need to know where the asset was published and who approved it. PREMIS links rights statements to the agents involved and records events with their agents R10. Spectrum asks for outbound licences to be referenced in catalogue records R14.

How.

• Log downloads and shares with user, date, rendition and declared intended use.
• Record placements: which page, product listing, campaign or document uses the asset. Integrations with a CMS or e-commerce platform can report this automatically. For example, OpenText Digital Asset Management documents a usage tab recording the application, category and published URL where an asset is used .
• Keep a history of rights changes: who cleared an asset, who changed a status or date, and on which evidence. Rights fields should be editable only by trusted roles.
• Record rights out as well: licences you grant to press or partners, with licensee, scope and dates R15.

11. Use machine-readable rights expressions where they pay off

Why. Structured fields cover most needs inside one DAM. When rights must be exchanged between organisations or checked automatically by several systems, a rights expression language helps. ODRL represents policies (sets, offers, agreements) made of permissions, prohibitions and duties, refined by constraints R5. Its vocabulary includes constraints such as date and time, spatial (territory), purpose, media and delivery channel, and duties such as attribute and compensate R6. RightsML, the IPTC profile of ODRL, targets media cases such as geographic, time-based and channel restrictions R7 R8.

How.

• Start with clear structured fields (practices 3 and 4). Design them so that each one maps to an ODRL concept: party, action, constraint, duty.
• Use ODRL or RightsML when you syndicate content, receive rights from agencies that publish them, or need the same policy enforced by several systems. You can embed the expression in the file, or link to it, with the IPTC Encoded Rights Expression properties R1.
• Keep a human-readable summary next to it (Rights Usage Terms). People still need to read the terms.

12. Manage AI and data-mining permissions explicitly

Why. Rights holders increasingly specify whether their content may be used to train AI models. The IPTC Data Mining property, with PLUS values, can state "allowed", "prohibited", "prohibited for AI/ML training", "prohibited for generative AI/ML training", "prohibited except for search engine indexing", or "prohibited with constraints" R2 R4. For web content, the W3C TDMRep community report defines a reservation protocol (a /.well-known file, HTTP headers, HTML meta tags, and XMP in PDF). It explains that it responds to Article 4 of the EU's 2019 copyright directive, which allows text and data mining unless rights holders have reserved their rights in an appropriate manner, such as machine-readable means R9. TDMRep is a Community Group report, not a W3C Standard.

How.

• Add the Data Mining property to your schema, filled from the licence for incoming assets and from your organisation's policy for assets you own.
• Apply the same value to your own use: do not send licensed assets to internal AI tools (auto-tagging, generative editing, model fine-tuning) if the licence prohibits it. The tagging side is covered in AI auto-tagging in DAM: governance & quality control.
• Publish the policy for your public assets consistently: embedded metadata on files, and site-level signals for web delivery.

13. Review rights data on a schedule

Why. Rights change: contracts are renewed, holders change, copyright terms end. Spectrum recommends reviewing and updating rights records as circumstances change R15.

How. Run regular reports: assets with unknown status by age and use; licensed assets without an end date; assets with people but no release status; expiring and expired assets still published; rights fields edited outside the expected roles. Fix causes at the source, such as an upload preset or an agency feed, not only the records.

Common pitfalls

• Empty means free. Assets without rights data are treated as cleared. Default to unknown with a restrictive rule.
• Terms in free text or only in PDFs. Nothing can be enforced or reported. Extract the terms that drive rules into controlled fields.
• Rights typed per asset instead of linked to a contract. Renewals and corrections never reach all assets. Use linked rights records (practice 2).
• Expiry dates with no action. Assets expire silently while still being downloaded or published. Define alerts and actions (practice 7).
• Only the web interface is controlled. Share links, CDN URLs, connectors or the API still serve restricted assets. Test every exit point (practice 8).
• Derivatives escape the rules. Crops and composites lose the link to their source rights.
• Metadata stripped on delivery. Credit and copyright information disappear from web renditions. Test write-back and the image pipeline.
• Release forms visible to everyone. Personal data in releases is exposed. Store them with restricted access.
• "Unlimited" chosen by default. Release status is set to Unlimited without reading the release. Use Limited or Incomplete when in doubt.
• No usage tracking. When a licence ends, nobody knows where the asset is live.
• Treating metadata as legal clearance. A field value records a decision; it is not the decision. Keep the evidence linked.

How DAM platforms support this

Each solution page in the wiki has a Rights & governance section that documents, with citations, how the platform handles expiry, embargo, rights records, watermarking, permissions and audit. The examples below illustrate the practices in this guide. They are not a ranking and not an exhaustive list.

• Rights records and contracts: Wedia (rights inherited from contract resources) and Orange Logic (rights records with licence terms, expiration and embargo dates, territory restrictions and routing to legal).
• Expiry and embargo actions: Adobe Experience Manager Assets (automatic unpublishing of expired assets), Brandfolder (expired assets hidden from share links and CDN embeds) and MediaBeacon (downloads conditioned on a saved search).
• Enforcement at download: Sitecore Content Hub (intended use or approved request for restricted assets) and Frontify (licence acceptance before download, download requests and watermarks).
• Usage tracking: OpenText Digital Asset Management (where an asset is used).

Several of these pages also document integrations with a dedicated rights-management system, for organisations that keep contracts and talent rights outside the DAM. Where a page says Unknown (for example, embargo or retention behaviour on some platforms), ask the vendor and test it yourself. Migrating rights data between platforms will be covered in the planned DAM migration guide.