A membership site, whether it runs on Patreon, Memberful, MemberPress, Substack, Kajabi, or a self-hosted setup with Circle or a Discord community bolted on, collects three distinct categories of personal data under one account: what you charge someone, what they access, and how they participate. A generic ecommerce privacy policy covers the first category reasonably well and mostly ignores the other two, which is exactly where a membership site's real disclosure gap sits.
Device and session data for entitlement enforcement
Beyond content-access logs, many membership platforms also track device and session information specifically to enforce account-sharing limits, how many devices are logged in concurrently, whether the same login is being used from unusually distant locations in a short window, and similar signals used to flag a shared or resold login. This is a narrower, more security-adjacent form of tracking than general analytics, closer in purpose to fraud prevention than to audience measurement, but it's still personal data tied to a specific member's account, and it belongs in the same disclosure as the rest of your entitlement-enforcement data rather than left out because it feels like a backend implementation detail rather than something a member would think to ask about.
Recurring billing data
Membership platforms process payment through Stripe, PayPal, or a processor built into the platform itself. Card numbers are tokenized and never touch your own systems directly, which keeps you out of the heaviest PCI DSS scope, but a meaningful amount of billing data still lives in your membership platform and your processor's dashboard regardless: billing name, email, address, subscription tier, renewal date, payment history, and failed-charge or dispute records.
Your privacy policy needs to name the actual payment processor, not just say "we process payments securely," and it needs to state how long billing records are kept. Most businesses retain transaction records for around seven years for tax and accounting purposes, well beyond how long the membership itself might last, and that retention period needs to be disclosed rather than left implicit.
Gated-content access logs
This is the category a generic policy almost always misses entirely. Membership platforms log which member accessed which piece of gated content, and often how far into it, video watch progress, download completion, which modules of a course were opened. That logging exists for a legitimate reason, enforcing tier-based entitlements and understanding which content is actually being used, but it's still personal data: a record tying a specific person's identity to a specific pattern of content consumption.
That distinction matters because access logs can reveal more than a billing record does. A payment history says someone is a paying member. An access log can say what they're interested in, which content they returned to, and how engaged they are, information you should disclose you collect and explain you use for entitlement enforcement and content-performance analysis, not leave undocumented as an internal implementation detail.
Community and forum data
Many membership sites layer a discussion space on top of content access, a forum, a Circle space, a private Discord or Slack. That surface introduces its own data category: usernames (frequently different from the billing name), post and comment content, direct messages between members, and moderation logs kept to enforce community guidelines. IP addresses tied to individual posts, retained specifically to support abuse investigation, are common here too and worth naming explicitly rather than folding into a vague "technical data" catch-all.
Community data also tends to outlive an individual membership in a way billing data doesn't. A canceled member's forum posts usually stay visible, since removing them would break the conversation for everyone else who participated, even though the poster is no longer an active member. That's worth explaining plainly: what happens to a person's contributions after they leave, since it's a reasonable thing for a departing member to wonder about and rarely addressed anywhere.
Where membership site data actually comes from
| What it includes | Typical source | |
|---|---|---|
| Recurring billing | Name, email, tier, payment history | Stripe, PayPal, or the platform |
| Access logs | Content viewed, watch/download progress | The membership platform itself |
| Community data | Posts, DMs, usernames, moderation logs | Forum, Circle, Discord, or Slack space |
Re-engagement emails to lapsed members
Most membership platforms make it easy to send a win-back campaign to canceled or lapsed members, an email nudging them to resubscribe, often automated based on how long it's been since they left. That's still marketing by electronic means, which brings the same ePrivacy consent question any newsletter faces: a canceled member's original signup consent generally doesn't automatically extend to being re-contacted indefinitely after they've left, and treating a churned subscriber as a standing marketing list without a clear opt-out and a defined re-engagement window is a common gap between what a membership platform makes technically easy and what the applicable consent rules actually allow.
Who else touches member data
A membership site rarely has just one system involved. Team members and moderators need access to billing status to resolve support requests, community managers need access to forum data to enforce guidelines, and if you run a separate email marketing tool alongside the membership platform itself, member tier and engagement data often syncs there too. Each of those is a real data-sharing relationship worth naming, not because any of it is unusual, but because "who has access to my information" is one of the more common questions a paying member actually asks, and a policy that only names the payment processor leaves the rest unanswered.
Platform-hosted billing vs. self-hosted billing changes what you control
Not every membership platform puts you in the same relationship with the payment processor. Patreon and Substack process payments themselves and hold the primary billing relationship with the member, your privacy policy needs to disclose that the platform (not just a processor you chose) sees and controls this data. Memberful and MemberPress, by contrast, typically connect to a Stripe account you own directly, which means you hold more of the billing relationship yourself and have more direct control over retention and deletion requests. That distinction matters for how confidently your privacy policy can promise things like data deletion timelines: promises are only as good as the access you actually have to the underlying systems.
What happens on cancellation
Cancellation is where the three data categories diverge most. Content access is usually revoked immediately or at the end of the paid period. Billing records generally can't be deleted on request even under GDPR's right to erasure, because Article 17(3)(b) carves out an exception for data a business is legally obligated to retain, tax and accounting law being the common example. Community contributions typically stay put for the reasons above. A privacy policy that treats "cancel my membership" as one uniform deletion event misrepresents what actually happens to each category, and a member who specifically requests erasure deserves an answer that reflects the real distinction between what can be deleted immediately and what has to be retained.
Our Privacy Policy Generator builds a policy that separates billing, access, and community data into their own disclosures rather than one generic "account information" paragraph, and covers the retention and cancellation questions membership site owners get asked most. If your membership site also runs its own tracking or a marketing pixel on the public-facing pages, our Cookie Policy Generator documents that layer separately.
For the recurring-billing side of this in an ecommerce context, see our guide on writing a privacy policy for a Shopify store, which covers the same payment-processor disclosure pattern applied to one-time purchases instead of subscriptions.
The information in this article is for informational purposes only and should not be construed as legal advice on any matter, and does not create a lawyer-client relationship.
