A store that forgot it needed an end date.
Section 1798.100(a)(3) asks a business that collects personal information to disclose the intended retention period for each category, or the criteria used, and not to keep that information longer than reasonably necessary for the disclosed purpose. Code can show whether a store has any enforcement of an end date. It cannot prove the notice is complete or that the period you picked is justified.
The shapes the same control failure takes.
The change is almost never 'keep this forever on purpose'. It is a missing half of an otherwise reasonable store. These are the shapes that recur.
A new store ships with no bound
A table, bucket, or log of identified events is added with no TTL, no purge job, and no mention in the existing retention path.
A purge job is removed
A scheduled delete or a cache TTL is dropped in a refactor, so a store that used to age out now accumulates.
A window quietly disappears
A numeric retention config is deleted or set to null, so the previous bound is gone without a replacement criterion.
Soft delete keeps the row forever
A delete becomes a deleted_at flag and nothing later removes the personal information, so the store still holds it.
A copy is added outside the existing bound
An export, warehouse, or search index receives the same personal information and is not covered by the job that ages out the primary store.
An events table with no purge.
Product analytics wants identified events. A migration adds product_events with user_id and a jsonb payload. The existing nightly purge is not updated.
+ CREATE TABLE product_events (+ user_id uuid NOT NULL,+ payload jsonb NOT NULL,+ created_at timestamptz NOT NULL DEFAULT now());This store holds identified payloads with no visible retention enforcement. § 1798.100(a)(3) expects a disclosed period or criterion per category, and retention no longer than reasonably necessary for that purpose. Compare the table with the period you disclosed before merge. A missing TTL is not, by itself, a determination that the statute was violated.
What a privacy reviewer would verify
A privacy review compares the stores of personal information with the periods or criteria you disclosed. Code can show that a store has no enforcement, or that a bound was removed. It cannot show that the disclosed period is complete or justified. The useful question on the pull request is: does this store still match the retention decision you already wrote down.
A review, not a retention schedule.
A pull-request review can identify code and configuration that may conflict with an established privacy design. It cannot determine whether an organization is subject to the CCPA, whether a category was disclosed, or whether a period is reasonably necessary. Select CCPA in org config if this is a duty you want reviewed. These pages are illustrative.