Headless CMSes are great for marketing content, but they’re not databases for customer data. The line between “content” and “PII” (Personally Identifiable Information) matters for GDPR, CCPA, and trust. This guide helps you model content safely and avoid storing PII where it shouldn’t be.
Table of Contents
- What is PII in a CMS context?
- The golden rule: CMS for content, not customer data
- What to model safely (testimonials, case studies, team pages)
- What to exclude (customer data, user profiles, analytics)
- Audit logs and change tracking
- Retention and deletion policies
- Editor training and governance
- Pitfalls to avoid
What is PII in a CMS context?
PII includes:
- names + email addresses
- phone numbers
- physical addresses
- IP addresses (if stored)
- payment info
- customer account data
In a CMS, PII often sneaks in via:
- testimonials with real emails
- case studies with customer names
- contact forms stored as entries
- user-generated content (comments, reviews)
Rule of thumb: if it identifies a person, treat it as PII and have a deletion process.
The golden rule: CMS for content, not customer data
Your CMS should store:
- marketing copy
- blog posts
- product descriptions
- FAQs
- navigation
- reusable page sections
Your CMS should not store:
- customer accounts
- order history
- payment data
- user profiles
- analytics events
- raw form submissions (unless anonymized/aggregated)
If you need customer data, use a proper database/CRM/helpdesk—not your CMS.
What to model safely (testimonials, case studies, team pages)
You can include names and titles if:
- the person gave explicit consent
- it’s public-facing (team page, public testimonial)
- you have a process to remove it on request
Model testimonials like:
name(public name)role(job title)company(company name)quote(testimonial text)avatar(public photo)consentDate(optional: internal record)
Avoid storing:
- personal emails
- phone numbers
- private addresses
For case studies, anonymize customers unless you have written permission to publish details.
What to exclude (customer data, user profiles, analytics)
Never store in CMS:
- Contact form submissions: send to email/CRM/webhook, don’t store as content entries
- User accounts: keep in your app DB or auth provider
- Analytics: use an analytics tool, not CMS entries
- Support tickets: use a support tool
- E-commerce orders: use your commerce platform
If you need “social proof”, publish only what’s consented and intentionally public.
Audit logs and change tracking
For compliance, you need to know:
- who changed what content
- when it changed
- what the previous value was (ideally)
Enable CMS audit logs/version history if available. If not, log:
- admin actions
- publish/unpublish events
- webhook deliveries (for downstream systems)
For GDPR deletion requests (“right to be forgotten”), you need to:
- find all references (entries, media, metadata)
- remove/anonymize
- confirm completion internally
Retention and deletion policies
Set clear rules:
- Draft retention: delete drafts after X months of inactivity
- Media retention: delete unused media after Y months
- Testimonials/case studies: remove on request; document how
If you store any PII temporarily (try not to), enforce TTL deletion (e.g. 30 days).
Editor training and governance
Train editors to:
- never paste customer emails into content
- never store form submissions as “entries”
- use anonymized examples in case studies
- request consent for names/photos
Governance that helps:
- review workflow for testimonials/case studies
- naming conventions (avoid real names in examples)
- a “sensitive content” checklist
Pitfalls to avoid
- Storing form submissions in the CMS “because it’s convenient”
- Mixing private customer info with public marketing content
- No process for deletion requests
- Indexing PII into search/RAG systems
If you’re building AI/RAG features, ensure your indexing pipeline excludes PII and drafts (see the RAG post).