When the form is the friction: introducing AuthenticatedID

Recent CalPrivacy settlements have made one thing clear: regulators expect businesses to honor rights requests and to ensure the intake process itself no longer gets in the way. AuthenticatedID removes the form, the verification dance, and the lookup scramble for consumers who are already signed in.

AuthenticatedID is a Ketch capability that lets a signed-in consumer submit a data subject request — a formal ask to access, delete, correct, or opt out of the sale of their personal data — without filling out a new form or re-verifying an identity the business already confirmed at login. It extends the trust already established at sign-in into rights fulfillment, so verification happens once instead of twice.

Recent settlements have made one thing clear: regulators do not just want businesses to honor rights requests. They want intake to stop getting in the way of that right. AuthenticatedID removes the form, the verification dance, and the lookup scramble for consumers who are already signed in.

The quiet contradiction in most subject rights pages

A signed-in consumer whose identity the brand has already verified clicks "Manage my data" and is immediately presented with a form. Full name, email, and sometimes a government ID upload are requested again. Sometimes a verification code is sent to the same inbox the consumer just used to log in.

The form gets submitted, the request enters a fulfillment queue, and somewhere downstream, an identity verification step runs to confirm that the person who just authenticated is, in fact, the person who just authenticated.

Friction dressed up as a privacy program is still friction. Regulators have noticed, and the cost of not noticing is no longer theoretical.

This is not a California-only problem. State privacy laws with rights-request provisions — Virginia, Colorado, Connecticut, and others — generally require businesses to respond to verified requests within a set window, and most allow businesses to rely on "reasonable" verification methods rather than a one-size-fits-all form. 

An authenticated login is exactly the kind of reasonable method regulators have in mind, yet most rights intake flows still ignore it and default to the same static form regardless of whether the requester ever logged in.

What the settlements are actually telling us

Recent California AG and California Privacy Protection Agency (CalPrivacy) enforcement actions are required reading for anyone running a data subject request, or DSR, intake program.

In October 2025, the California Attorney General reached a $530,000 settlement with the streaming service Sling TV, which reads like a case study in rights-request intake friction. Sling TV routed consumers submitting a request, in this case an opt-out of sale and sharing, through a webform demanding name, address, phone number, and email, including consumers who were logged into their Sling TV accounts at the time.

The AG's complaint called this out directly: these were "already-identified consumers" asked to re-enter information the business already held. Under Civil Code §1798.135(c)(1) and 11 CCR §7026(c), a business cannot require more information than necessary to process a request, and for a logged-in user, the login is the identification. The form added a barrier without adding verification.

The injunctive terms are where this settlement turns from a cautionary tale into a product spec. The judgment requires that logged-in consumers have a toggle or a similarly simple method, with no web form and no identification fields, and that a single request apply account-wide across every device and browser tied to that consumer.

Set that beside CalPrivacy’s $632,500 Honda action, and the pattern is unmistakable: regulators now treat an authenticated session as sufficient identity for a rights request, and every field a business adds beyond that point is friction the business will be asked to justify. If the form is the friction, the form is the finding.

The pattern is clear. Regulators no longer treat rights intake as a checkbox to be checked once and forgotten. The intake experience is itself part of the compliance posture, and enforcement is starting to score it that way. For more on how the CCPA specifically treats verification and deletion rights, see Ketch's breakdown of the CCPA right to delete.

Where DSR friction compounds

There are three points in a typical DSR workflow where friction builds up, and each one adds time, cost, or risk on its own:

• Intake. The consumer is asked to provide information that the business already has: name, email, and account identifier, all of which are already associated with the active session. Every field is a chance to abandon the request, mistype an identifier, or create a record that doesn't match the one on file. This is the exact practice the Sling TV judgment now prohibits for that company: a web form demanding contact details from consumers who were logged in at the time.‍
• Verification. A second identity check runs on the person the system just authenticated. This step adds days to the request timeline, costs money per verification, and introduces its own failure modes: expired links, codes sent to old email addresses, and ID uploads rejected due to glare.‍
• Fulfillment. The workflow stalls waiting on a verification step that adds time and cost without adding certainty, and every manual touch along the way is another place for a request to fall through the cracks. A request honored on one device but not another is a request that wasn't honored at all, which is why a single opt-out that applies account-wide across all devices and browsers tied to the consumer is required.

‍

Each stage inherits the friction of the one before it. A cluttered intake form produces mismatched records, mismatched records trigger manual identity review, and manual review stretches fulfillment timelines toward statutory deadlines.

Introducing AuthenticatedID

AuthenticatedID is a capability in Ketch DSR intake that treats a consumer's active, authenticated session as the identity verification for their rights request. When a signed-in consumer submits a request from your privacy center or account settings, Ketch attaches the authenticated identity to the request and carries it through the fulfillment process. No form, no secondary verification, no manual lookup.

The capability is available to customers already running Ketch Consent Management or Ketch Permission Vault, and it uses the authenticated context those products already carry. There is no new identity verification stack to stand up, and no integration project. The capability turns on, and the workflow gets shorter.

The practical difference is easiest to see side by side. The old way: a signed-in customer fills out a form, waits for a verification email, clicks a link, and their request enters a queue where an analyst matches the submitted details against account records before fulfillment begins. The Ketch way: the same customer clicks a request inside their account, and fulfillment begins with the authentication event already recorded as the verification source.

For businesses, the math is straightforward: faster fulfillment, lower per-request verification costs, fewer manual interventions, and an intake posture that aligns with the direction regulators are already moving. The Sling TV and Honda actions are not outliers. They are early signals of how this category of enforcement will be scored going forward, and intake is where the cost of each request and the trust of each customer meet.

Proof in production: rights automation at scale

Ketch customers running high-volume consumer programs have already made this trade. IMAX automated its subject rights workflow to keep pace with request volume without adding headcount to the privacy team, a pattern covered in Ketch's DSAR automated decision-making case study. 

Read further: Ketch + IMAX: respecting people’s privacy choices everywhere

The lesson from that work applies directly here: once a rights workflow is automated end to end, the remaining friction usually isn't in fulfillment, it's in intake. AuthenticatedID extends that same automation logic one step further, into the moment a consumer is already inside an authenticated account, closing the gap between a fast backend and a slow front door.

What the AuthenticatedID workflow looks like

Here is the consumer-facing journey, mapped against what happens in the system behind it.

Consumer-facing steps:

1. The consumer signs into their account, just as on any other day.
2. They navigate to account preferences or the privacy center inside the authenticated experience.
3. They click a request — "delete my data," "export my data," or "limit how my sensitive data is used."

That is the entire consumer-facing journey: no form, no fields, no second email, no government ID upload, and no re-verification.

What happens behind the scenes:

1. Ketch receives the request with the AuthenticatedID attached.
2. The fulfillment workflow recognizes the authenticated context and bypasses redundant identity verification.
3. The system uses the AuthenticatedID and connected APIs to call the relevant downstream systems and pull the consumer-specific data scoped to the request.
4. The workflow executes — deletion, export, correction, or opt-out — and produces a single audit-ready record that includes the authentication event as the verification source.

‍

‍

The result is fewer human touches, less time to fulfillment, and less risk that a friction point along the way becomes an enforcement finding.

Permissioning infrastructure, built for this moment

AuthenticatedID runs on the same permissioning infrastructure that already governs consent, identity, and rights across the Ketch platform. Consent state, identity, and rights status live in a single governed layer, so an authenticated login can be trusted the same way everywhere else in the program that already trusts it.

Privacy programs that treat consent management, identity, and rights fulfillment as three separate tools will continue to produce the kind of friction that regulators now penalize. Stitching those tools together after the fact usually means a custom integration project, a separate identity vendor, and a fulfillment workflow that still can't explain, in one audit-ready record, why a request was trusted. 

AuthenticatedID is one expression of what a unified permissioning layer makes possible instead: no-code rights automation that starts from data already inside the system, not a form asking for it again, and a verification trail that traces back to a single authentication event rather than a patchwork of logs across tools.

Get started

If your team already runs rights intake through Ketch, AuthenticatedID can be enabled — talk to your Ketch contact about scoping the rollout to your existing intake flows.

If you're evaluating how to align your rights program with the direction enforcement is moving, this is a good place to start. The fastest way to reduce intake friction is to stop asking signed-in consumers for things the business already has.

FAQs