Ever scroll: CCPA and CPRA duties for online communities

Mistake 1: Assuming a modest forum is automatically exempt

Treating a small community as automatically exempt is the costliest mistake: coverage depends on the business, not simply the community's size. Check whether a for-profit business does business in California and meets any statutory threshold, then review the totals each year rather than relying on last year's answer.

A covered business meets at least one condition: annual gross revenue above $25 million, adjusted for inflation every odd-numbered year by the California Privacy Protection Agency; buying or selling personal information of 100,000 or more consumers or households; or deriving half or more of annual revenue from selling or sharing personal information. The CPPA raised that figure to $26,625,000 effective January 1, 2025. The next adjustment is due in 2027, so confirm the current number on the agency's site.

The CCPA statutory text is in Civil Code §1798.100 et seq., with regulations at 11 CCR §§7000 et seq. The CPRA amended the CCPA rather than replacing it, adding the California Privacy Protection Agency, correction and sensitive-information rights, and a narrower definition of sale. Read the amended statutory text when a member asks.

Thresholds apply to the business rather than each website, so one owner's three communities are counted together. Nonprofits and government bodies are generally outside the definition of a business, although a nonprofit sharing information with a for-profit partner should put that arrangement in writing. A covered client may also make a community's role as service provider or contractor relevant.

A 4,000-member forum with modest ad revenue will usually sit outside the thresholds, but selling member lists or using retargeting pixels can change the analysis. Decide purpose and governance (see digital community models compared) before drafting notices, because community structure affects who can see member records and what information is gathered.

Mistake 2: Gathering information before explaining its use

Collecting personal information without a clear notice at signup creates a preventable compliance gap. Tell members the categories collected, purposes, sale or sharing status, and retention period at or before collection. Put the disclosure beside the form where information is gathered, not in a footer link.

The regulations set out the required contents, including in 11 CCR §7012. A member entering an email address to join a forum has not thereby agreed to analytics cookies, advertising pixels, or a marketing list unless the notice explains those uses. Keep signup fields to what is needed, usually a display name, email address, and password.

Cookies and tracking pixels also count as collection. If analytics or advertising tools receive member data, identify the information categories and purposes in the notice. The California Attorney General's CCPA materials are a government source rather than a vendor summary. Birthdates, phone numbers, and precise location can add sensitive data categories and duties.

Treat retention as a promise to carry out, not a line added to a policy and forgotten. A stated period could be 24 months after account closure, but the community must actually delete information on that schedule. Explain what happens to posts, comments, and direct messages after closure, including whether content remains visible with the member's name removed.

Mistake 3: Blending the signup notice into the privacy policy

Using one long privacy policy as a substitute for notice at collection misses the distinct purpose of each document. The notice is brief and appears where data is collected; the policy lives at a stable URL and explains rights, retention, third parties, and how members can exercise their rights.

Policy language must reflect the CPRA amendments: correction rights, limits on sensitive-information use, sharing for cross-context behavioral advertising, and browser opt-out preference signals. If the site recognizes a signal such as Global Privacy Control, treat it as a valid request for that browser. If there is no sale or sharing, say so plainly. If there is, the opt-out mechanism is a clearly labeled link on the site, titled "Do Not Sell or Share My Personal Information" or the alternative "Your Privacy Choices" link with the CPPA's opt-out icon. The link must lead to a form the member can complete without creating an account, and the site must also honor a browser opt-out signal such as Global Privacy Control.

Update the policy at least annually and when a vendor, pixel, or data category is added. Keep a dated change log showing what members saw when they joined. Hosting, email, and analytics providers should have service-provider or contractor terms limiting their use of member data to performing the service and preventing use for their own purposes.

Mistake 4: Letting privacy requests disappear into routine moderation

A missed or mishandled request creates avoidable risk. Give members one monitored contact address and one web form, keep moderators out of the request process, and log the date, right invoked, response date, and outcome for every request.

By default a request to know covers the 12 months before the request, but under the CPRA a member can ask for information collected on or after January 1, 2022 from earlier periods, unless that proves impossible or involves disproportionate effort. Members may also delete or correct their information, opt out of sale or sharing, and limit use of sensitive personal information, such as precise location or health details. They also have a right to non-discrimination for using these rights.

Deletion is not absolute. Information needed to complete a transaction, detect security incidents, or meet a legal obligation may be kept. State which exception applies so the member can understand the response. Correction requests apply to details such as a display name or email; update the live system and reasonably accessible backups, then record the change.

Authorized agents may submit a request with the member's written permission, and the request should then be handled like any other. Do not charge a fee unless the request is manifestly unfounded or excessive. Do not deny service, charge a different price, or lower service quality because someone exercised a privacy right; a properly disclosed financial incentive is allowed.

Mistake 5: Making security promises without matching safeguards

A privacy notice cannot promise protections that the community does not actually provide. The CCPA does not specify technical controls, but a breach caused by failure to use reasonable security can lead to a private right of action, making practical safeguards and accurate statements important.

For a small community, reasonable security usually means hashed passwords, encryption in transit, multi-factor authentication on administrator accounts, prompt patching, and a written incident response plan. The FTC's Start with Security guidance supports the principle of making no security promise that the operator cannot keep and documenting the controls that support each promise.

Breach notification is a separate duty under California's data breach law, Civil Code §1798.82. Exposed credentials or financial details may trigger notification obligations as well as the private action described at §1798.150. Administrative penalties are addressed at §1798.155; check the current statutory figures before assessing risk.

Federal and state rules can apply at the same time. The FTC can act on data security failures, while the California Attorney General and California Privacy Protection Agency also have roles in CCPA enforcement. The California DOJ's privacy and data security material tracks the state's position, so read primary sources before accepting a vendor's claim that a practice is standard.

Keep a short record explaining vendor choices, information shared, and how it could be removed. That record supports the community's decisions if questions arise. Security expectations should also match the written notice: if it says access is limited or information encrypted, maintain evidence that those practices are in place.

Mistake 6: Leaving ownership and vendor records undefined

A community without a privacy team still needs named responsibility and current records. Assign one person to own requests, notices, and vendor decisions; otherwise, a shared inbox can go unattended and deadlines can pass without anyone noticing.

Maintain three core artifacts: a notice at collection, a privacy policy, and a request log. Use short sentences and concrete examples so a member can understand what is collected and why. Moderators should not copy member information into personal spreadsheets or chat apps; volunteer roles should also be clearly bounded.

Keep one vendor inventory row for each tool, recording its name, information received, purpose, contract status, and deletion path. Hosting, email, and analytics vendors need terms that restrict their use of member information. A short annual session on request handling, phishing, and administrator account hygiene covers the training described for small operators.

Set these responsibilities before launch or rebuild. Doing this early prevents policy rewrites later, and the digital communities overview shows how governance roles fit together.

Mistake 7: Treating readiness as a one-time task

A policy and request process can become inaccurate when tools or practices change. Review coverage annually, test the request route quarterly, and compare the vendor inventory with the notice after every new tool so the published disclosures match actual collection and sharing.

Submit a deletion request as a member once each quarter and time the response. Check the vendor inventory against the notice because a tool added during the year can make an earlier disclosure inaccurate. A short list that gets completed is more useful than a long exercise that nobody finishes; the digital communities checklist also addresses membership, moderation, and records.

Write down who can approve a policy change, vendor, or deletion decision, and make the privacy owner clear to the team. Practical clear boundaries between platform decisions and member expectations help explain the process. Keep the work manageable, but ensure every request has an owner and every notice reflects current practice.