UGC Rights Management, the GDPR + CCPA workflow

Most UGC programmes start informally. Someone on the social team spots a great customer photo, replies "love this, can we share it?", gets a thumbs-up emoji, and the photo ends up on a product page. Months later it is in a paid ad, the creator has deleted their account, and nobody can say what was agreed. This guide replaces that pattern with a workflow that answers the questions a DPO, a creator or a regulator will eventually ask. It pairs with the broader UGC Rights and Compliance Handbook, which covers licensing windows and FTC/ASA disclosure in more depth; this one concentrates on the data protection side and the day-to-day flow.

Why rights management matters

Customer content is valuable precisely because a real person made it. That same fact is the risk. The photo belongs to the person who took it, the face in it is personal data, and the caption may contain claims or a material connection (a free product, an affiliate code) that has to be disclosed if you republish it. The US FTC's guidance for influencers describes a material connection as including a personal, family or employment relationship, or a financial one such as being paid or given free or discounted products. If a gifted customer's post ends up in your ad, that connection travels with it.

The cost is asymmetric. Asking properly takes a templated message and a log entry. Getting it wrong means pulling live creative mid-campaign, answering an angry creator in public, or failing to produce a record when someone exercises their data rights.

What GDPR and the CCPA actually ask of a UGC programme

Licence and lawful basis are separate. Copyright permission is a matter between you and the creator: they grant you a licence to use their content for stated purposes. Data protection law asks a different question: on what basis are you processing the personal data in that content, and can the person exercise their rights over it? A creator can grant a licence and still ask you to erase their data later, and you need a process for both. Which lawful basis applies to your processing (consent, legitimate interests or another) is a decision for your counsel; many programmes use explicit consent because it is the easiest to evidence, but it carries the withdrawal obligations below.

The ICO's consent test. If you rely on consent under UK GDPR, the ICO says it must be freely given, specific and informed, and an unambiguous indication by a clear affirmative act. Silence, pre-ticked boxes and inactivity do not count. You must keep records that demonstrate consent, people must be able to withdraw as easily as they gave it, and consents should be reviewed and refreshed if your purposes change. For UGC this translates directly: name the brand, name the uses, get an explicit yes, store it, and treat a new use (say, moving from the PDP to paid social) as something that may need a fresh request.

The CCPA's consumer rights. The California Attorney General's CCPA page lists the rights to know, delete, correct, opt out of the sale or sharing of personal information, limit the use of sensitive personal information, and not be discriminated against for exercising those rights. The same page says businesses must respond within 45 calendar days (extendable once by 45 more with notice) and must offer at least two methods for submitting requests. It applies to for-profit businesses that meet one of the thresholds on that page, such as gross annual revenue over $25 million or buying, selling or sharing the personal information of 100,000 or more California residents or households. For a deeper look at reviews specifically, see CCPA and customer reviews.

The practical point in that last row: when a UK or EU creator asks for erasure, the ICO says you must tell recipients of the data unless that is impossible or disproportionate, and where the data was made public online take reasonable steps to inform other controllers. If you have syndicated a creator's post into email, ads or a partner's site, your takedown process needs to reach all of them, not just the gallery. GDPR consent and UGC covers the consent wording side in more detail.

The request flow: DM first, registration page as fallback

The request is where most programmes either create a clean record or lose one. A good request is short enough to be answered on a phone, specific enough to meet the consent test, and ends with a single unambiguous action. The template below is illustrative; adapt the uses, the term and the brand name, and have counsel approve the final wording.

Hi @{handle}, we love this post of the {product}. We are {Brand} and
we would like to show it on our website product pages and in our
marketing emails for the next 2 years, credited to @{handle}.

Our terms for using your content: {short link to rights terms}
Our privacy notice: {short link}

If you are happy for us to do that, please reply #Yes{Brand}.
You can ask us to remove it at any time by replying #Remove{Brand}
or emailing {rights inbox}.

• Name the uses. "Website product pages and marketing emails" is specific. "Our channels" is not. If you intend paid social, say so, because a creator who agreed to a gallery has not agreed to an ad.
• State the term. A defined window (the template uses two years) gives you a natural expiry and a reason to re-ask later.
• Ask for an explicit, unique reply. A reply hashtag like #Yes{Brand} is a clear affirmative act and is easy to match automatically. A like, an emoji or silence is not.
• Put withdrawal in the same message. The ICO test says withdrawing must be as easy as consenting, so give the route up front.
• Link the terms and privacy notice. "Informed" means the creator can see who you are and what you will do before they say yes.

When the DM route stalls. Some creators never see the reply in their message requests, some platforms limit brand-initiated DMs, and some content (reviews, uploads, event photos) has no thread to reply in. The fallback is a registration page: a short form where the creator confirms their handle, ticks an unticked box against the stated uses, and submits. It produces a stronger record than a DM because the consent wording and the timestamp are captured in one place. Hashtag campaigns can use a third route, where posting with the campaign hashtag under published terms counts as the grant; that only works if the terms are genuinely published and linked from the campaign itself. Our Instagram rights request templates and the rights request email sequence have more wording variants.

In Idukki, this is how Rights Management works: consent can arrive by a hashtag entry under published campaign terms, a direct reply to a rights request, or a registration form, and each decision is stored with its source. Posts start as pending, move to approved, rejected or revoked, and an Expired state is computed when the licence window closes (two years by default, configurable per collection). If your team lives in Slack, the Slack integration posts rights answers into a channel as they arrive.

Audit logs your DPO will want

The ICO is explicit that you must keep records that demonstrate consent. In practice the record is what you reach for when a creator says "I never agreed to that" or when a data request arrives. The test for a good audit log is simple: could someone who was not involved reconstruct exactly what was asked, what was answered, and what was done with the asset, from the log alone?

Keep the evidence, drop the extras. A rights record is personal data too: collect what you need to prove the decision, and agree a retention period with counsel. Idukki's rights ledger records creator handle, channel, email, timestamp, comment, consent document and expiry per decision, and the log exports as CSV for a GDPR or CCPA request.

Takedown and erasure SLAs

Three different requests arrive under the heading "take it down", and they run on different clocks. Treat them as one intake and triage from there.

1. 1Hour 0: acknowledge. Reply on the channel the request arrived on. The ICO notes requests can be made verbally or in writing, so a DM counts.
2. 2Within 24 hours: remove. Revoke the record so the asset drops from every live surface at once, then check the places your platform does not reach (sent emails cannot be recalled, but scheduled ones can; ad libraries; partner feeds).
3. 3Within 24 hours: confirm. Tell the creator what you removed and where. Log the revocation with reviewer and reason.
4. 4Within the statutory window: delete data if asked. One month under UK GDPR (extendable for complex cases), 45 calendar days under the CCPA. Remember the ICO obligation to inform recipients.

In Idukki, revoking a record removes the post from every widget it appears in and logs the revocation. Full deletion of a creator's data is an operator action taken per business, so assign a named owner for it rather than assuming the revoke button covers erasure. When a creator deletes the original post on the platform rather than asking you, see what to do when a creator deletes the original post.