Data Subject Requests

What it does

Data Subject Requests records a person's request about their own data and walks it through intake, verification, collection, redaction, delivery and closure. Each request is given a 30-day deadline when it is received.

What exists now

• An account holder files and withdraws their own requests in Data requests; the six types are access, rectification, erasure, portability, objection and restriction.
• Staff move a request forward one step at a time (intake, verified, collecting, redacting, delivered, closed); the database refuses any other step, and a closed or withdrawn request cannot change.
• Erasure is performed by a database function: it deletes the contact address, replaces the display name, ends sessions, factors, passkeys and grants, locks the credential, and replaces the address in token and delivery rows with a marker. The request records what was erased and what was kept, with the basis.
• Audit and attempt records are not altered.

Operating needs

• PostgreSQL; the erasure function runs as the table owner and takes only the request id.
• A staff member who works the requests before their deadlines.

Limits

• The platform erases the data it holds. Copies in backups follow the backup retention stated in the privacy notice.
• Whether a request must be granted is a legal decision for the controller; the platform records the decision and its basis.

Availability

Data Subject Requests is running on RJV's own platform. RJV does not sell a licence for it as a separate product today: the commercial terms state what is on sale. It can be part of the result of an engineering engagement, where the written proposal names it, its licence terms and what you would hold at the end. To discuss it, use Work with Us.

Evidence

The state machine and the erasure outcome are covered by the platform's own database tests. The evidence register lists the graded claims.