WikiArtifactsData Subject Request Log

Data Subject Request Log

Document
Updated: 2026-02-13

A Data Subject Request Log centralizes the tracking of individual privacy rights requests (e.g., access, correction, deletion, objection) from intake through identity verification, execution across systems, and final response. Many privacy frameworks expect organizations to respond within defined timelines and to demonstrate accountability through documented handling. This log records key metadata such as request type, date received, verification status, assigned owner, due date, actions taken, and completion outcome. Maintaining a consistent log helps prevent missed deadlines, supports audit readiness, and helps identify recurring data quality or process issues.

DSR Log Entry JSON Schema

A standardized JSON structure for logging a data subject request event.

{
  "request_id": "dsr-2023-001",
  "request_type": "RIGHT_TO_ACCESS",
  "date_received": "2026-02-13T09:00:00Z",
  "data_subject_id": "usr_8821",
  "verification_status": "VERIFIED",
  "assigned_owner": "privacy_team",
  "status": "IN_PROGRESS",
  "due_date": "2023-11-26T09:00:00Z",
  "actions_log": [
    {
      "action": "identity_verified",
      "timestamp": "2026-02-13T10:00:00Z"
    },
    {
      "action": "data_gathering_initiated",
      "timestamp": "2026-02-13T11:00:00Z"
    }
  ]
}

DSR Processing Workflow

A flowchart illustrating the lifecycle of a data subject request.

Rendering diagram...

Effective handling involves establishing a centralized intake mechanism, verifying the requestor's identity, logging the request immediately to track deadlines, and routing it to the appropriate data owners for execution. Implementing data subject request procedure workflows ensures consistent responses and adherence to data subject request compliance standards.

The timeline varies by jurisdiction and request type, but many frameworks require responses without undue delay and within defined statutory periods (often measured in weeks). Organizations should document their internal service targets and track due dates in the request log to ensure deadlines are met.

Identity verification should be proportional to the sensitivity of the data, using existing authentication credentials where possible to avoid collecting excessive data. If reasonable doubt exists, the organization may request additional information to confirm the individual's identity before processing the data access request.

Responses must typically include a summary of the personal data being processed, the purposes of processing, the categories of recipients with whom data has been shared, and any other relevant information regarding the data subject rights exercised, presented in a clear and intelligible format.

Processing should be tracked using a centralized Data Subject Request Log that records the date of receipt, verification status, specific actions taken across systems, internal notes, and the final response date. This data subject request documentation is essential for audits and demonstrating accountability.

Common request types include the right to access (obtain a summary of data), rectification (correction of inaccurate data), erasure (right to be forgotten), grievance redressal, and nomination of individuals to exercise rights in case of incapacity.

For complex requests, organizations may be permitted to extend the response timeline, provided the data subject is notified with reasons. If requests are manifestly unfounded or excessive, some frameworks allow for refusal or charging a reasonable fee, though this must be strictly documented in the data subject request template.

Consequences vary by jurisdiction and regulator, and can include complaints, investigations, corrective orders, and monetary penalties. Keeping a complete request log helps demonstrate good-faith compliance and reduces the risk of missed deadlines or inconsistent handling.

VersionDateAuthorDescription
1.0.02026-02-13WatchDog Security GRC Wiki TeamInitial publication