Data subject rights
The list of things a user can legally demand about their own data: see it, fix it, delete it, export it, or make you stop using it.
See it
What it is
The named set of things a person can demand about data you hold on them. GDPR lists eight: to be informed, access, rectification, erasure, restriction of processing, portability, objection, and protection from purely automated decisions with legal or similarly significant effects. California's list overlaps but is shaped differently: know, delete, correct, opt out of sale or sharing, limit use of sensitive personal information, and no discrimination for asking.
Read the list as a product backlog, because every right is a feature you either build now or improvise badly at 2am. Access and portability are two different builds, and teams collapse them constantly. Access means handing over a copy of the person's data plus the explanation of how you use it, in any intelligible form. Portability is narrower: data the person supplied, processed by automated means under consent or contract, delivered in a structured, commonly used, machine-readable format. One pipeline can serve both, but only if you scope the two outputs on purpose. Rectification means editable profile fields. Erasure means a delete path that reaches your warehouse and your vendors. Objection and opt-out mean a toggle that your tag manager and your email sender genuinely obey. Restriction means the ability to freeze a record so it stays stored but stops being used, which is the one nobody designs for.
Gotcha: rights are not absolute, but silence is never the answer. You can refuse erasure of invoices you are legally required to keep, and you can push back on manifestly unfounded or repetitive requests. What you cannot do is ignore the request. You owe a reasoned answer inside one month under GDPR or 45 days under CCPA, and 'we were busy' is the violation regulators actually see.
Ask AI for it
Turn data subject rights into a product spec for this app. For each right (informed, access, rectification, erasure, restriction, portability, objection, automated decision-making, plus California's opt out of sale or sharing and limit use of sensitive personal information) give me one row containing: the concrete feature that satisfies it, the endpoint or screen it lives on, the database tables and third-party systems it must reach, the response deadline, and the lawful grounds on which we may refuse. Then write the actual implementation plan for the two cheapest wins. First, two distinct outputs from one export pipeline: an access response covering every record tied to the user plus the processing information owed alongside it, and a separate portability file limited to data the user supplied that we process automatically under consent or contract, emitted as JSON with a stable schema. Say explicitly which fields qualify for portability and which do not. Second, a restriction state that keeps the record stored and still permits the processing the law allows during restriction (storage, legal claims, consent-based use) while blocking the prohibited uses, rather than a blanket read gate that also breaks billing and audit. Call out where the current schema makes a right impossible to honor.