09 Data Subject Rights & Requests

Modern privacy programs must do more than publish privacy policies.

Organizations must be able to respond when individuals ask:

What information do you have about me, how are you using it, can you correct it, and can you delete it?

Depending on applicable privacy laws and jurisdictions, individuals may have rights involving:

Access

Correction

Deletion

Restriction

Objection

Portability

Consent Withdrawal

Information About Processing

These requests are commonly managed through a Data Subject Request (DSR) or Data Subject Access Request (DSAR) process.

A practical enterprise workflow looks like:

Data Subject Request
      ↓
Request Intake
      ↓
Identity Verification
      ↓
Request Classification
      ↓
Scope Determination
      ↓
Data Discovery
      ↓
Legal / Privacy Review
      ↓
Exceptions
      ↓
Fulfilment
      ↓
Third-Party Coordination
      ↓
Quality Review
      ↓
Response
      ↓
Evidence
      ↓
Metrics & Monitoring

Learning Objectives

By the end of this lesson, you will be able to:

• Explain data subject rights.

• Understand common privacy request types.

• Differentiate DSR and DSAR.

• Design a request intake process.

• Verify requester identity appropriately.

• Classify privacy requests.

• Establish request deadlines.

• Perform enterprise data discovery.

• Coordinate searches across cloud and SaaS systems.

• Handle third-party and subprocessor data.

• Assess access requests.

• Assess correction requests.

• Assess deletion requests.

• Understand deletion exceptions.

• Handle restriction and objection requests.

• Support data portability.

• Manage consent withdrawal.

• Protect third-party information.

• Perform response quality assurance.

• Maintain request evidence.

• Track request metrics.

• Automate privacy-rights workflows.

• Test the effectiveness of a DSR program.

1. What Are Data Subject Rights?

Data subject rights are rights that individuals may have regarding the processing of their personal information.

Depending on applicable law, these can include:

Right to Know

Right of Access

Right to Correction

Right to Deletion

Right to Restriction

Right to Object

Right to Portability

Right to Withdraw Consent

The exact rights and requirements depend on:

Jurisdiction

Applicable Law

Type of Organization

Type of Data

Processing Activity

2. What Is a Data Subject Request?

A Data Subject Request (DSR) is a request made by an individual exercising one or more privacy rights.

Example:

Customer
      ↓
"I want a copy
of my personal data."

Another:

Former Employee
      ↓
"Please correct
my contact details."

Another:

Customer
      ↓
"Delete my account
and personal data."

3. DSR vs DSAR

A:

DSR

is the broader category.

A:

DSAR

usually refers specifically to a:

Data Subject
Access Request

Therefore:

DSR
├── Access
├── Correction
├── Deletion
├── Restriction
├── Objection
├── Portability
└── Other Rights

4. Why DSR Management Matters

Privacy rights are meaningful only if organizations can operationally fulfill them.

Weak model:

Privacy Policy
      ↓
"We Respect
Your Rights"

but:

Customer Requests Data
      ↓
Nobody Knows
Where It Is

A mature model:

Privacy Right
      ↓
Defined Procedure
      ↓
System Capability
      ↓
Responsible Owner
      ↓
Evidence

5. The Enterprise Challenge

Personal information may exist across:

CRM

ERP

HR Systems

Email

Databases

Cloud Storage

Data Lakes

Support Platforms

Marketing Systems

Security Logs

Backups

AI Platforms

Third Parties

Therefore:

Privacy-rights management is also an enterprise data-governance problem.

6. Establish a DSR Procedure

Create:

01 Data Subject Request Procedure

Define:

Intake

Verification

Classification

Deadline

Discovery

Review

Approval

Fulfilment

Response

Evidence

Escalation

7. Roles and Responsibilities

A DSR process may involve:

Privacy
      ↓
Process Owner

Legal
      ↓
Exception / Legal Review

GRC
      ↓
Governance & Evidence

IT
      ↓
Data Discovery

Security
      ↓
Identity / Secure Delivery

Business
      ↓
System Knowledge

Vendors
      ↓
Third-Party Searches

8. DSR RACI

Create:

02 DSR RACI Matrix

Example:

Activity	Privacy	Legal	IT	Business	Security
Intake	A/R	C	I	I	I
Verification	A	C	C	I	R
Discovery	A	C	R	R	C
Exception Review	R	A	C	C	I
Response	A/R	C	C	I	C
Evidence	A/R	C	C	C	I

9. Request Intake

Organizations should define approved ways individuals can submit requests.

Examples:

Privacy Portal

Web Form

Email

Customer Support

Postal Mail

Other Recognized Channels

The process should not depend entirely on the requester using one exact phrase.

10. Recognizing a Privacy Request

Example:

"Send me everything
you have about me."

may represent:

Access Request

Another:

"Stop using my
information for marketing."

may represent:

Objection
or
Consent Withdrawal

depending on context and applicable requirements.

11. Employee Training

Customer-facing teams should know how to recognize potential requests.

This includes:

Customer Support

HR

Sales

Marketing

Security

Legal

Help Desk

12. Request Intake Form

Create:

03 DSR Intake Form

Capture:

Field	Example
Request ID	DSR-2026-001
Requester	Customer
Request Type	Access
Date Received	Date
Jurisdiction	Applicable
Verification	Pending
Owner	Privacy Team
Due Date	Calculated

13. Central DSR Register

Create:

04 DSR Register

Use:

ID	Requester	Type	Received	Due	Status	Owner

14. Request Date

Accurately record:

Date Received

because response deadlines may be calculated from it according to applicable requirements.

15. Request Deadlines

Different privacy frameworks may establish different response timelines.

Therefore avoid building the process around:

One Universal
Deadline

Instead:

Request
      ↓
Determine Jurisdiction
      ↓
Determine Applicable Requirement
      ↓
Calculate Deadline

16. Deadline Matrix

Create:

05 Privacy Rights Deadline Matrix

Use:

Jurisdiction	Request	Deadline	Extension	Source

Legal or Privacy teams should maintain applicable requirements.

17. Deadline Tracking

A mature workflow calculates:

Date Received
+
Applicable Requirement
=
Due Date

Then monitors:

Days Remaining

18. Escalation

Example:

30 Days Remaining
      ↓
Normal

10 Days Remaining
      ↓
Warning

5 Days Remaining
      ↓
Escalation

Overdue
      ↓
Management Escalation

Thresholds should follow organizational policy.

19. Identity Verification

Before releasing personal information:

Verify that the requester is authorized to receive it.

Otherwise the privacy process itself can become a data breach.

20. Verification Principle

Use:

Proportionate
Identity Verification

Avoid requesting significantly more personal information than necessary.

21. Verification Methods

Depending on context:

Authenticated Account

Existing Contact Channel

One-Time Verification

Customer Information

Employee Authentication

Authorized Representative Documentation

22. Identity Verification Checklist

Create:

06 Identity Verification Checklist

Include:

Requester Identified

Existing Account Matched

Verification Method

Verification Completed

Representative Authority

Exceptions

Reviewer

23. Verification Failure

If identity cannot be appropriately verified:

Request
      ↓
Verification Failed
      ↓
Request Additional
Appropriate Information
      ↓
Document

Do not release sensitive information simply because someone knows an email address.

24. Authorized Representatives

Requests may sometimes come through:

Lawyer

Parent / Guardian

Authorized Agent

Representative

Verify:

Identity
+
Authority

before proceeding.

25. Request Classification

After verification, classify the request.

Possible categories:

Access

Correction

Deletion

Restriction

Objection

Portability

Consent Withdrawal

Information Request

26. Multiple Rights

A single message may contain:

"Send me my data
and then delete
my account."

This can create:

Access Request
+
Deletion Request

Both should be tracked appropriately.

27. Scope Determination

Determine:

Who Is the Individual?

Which Accounts?

Which Services?

Which Time Period?

Which Data?

Which Request Type?

28. Scope Clarification

For extremely broad requests, appropriate clarification may help determine what information the individual is seeking where permitted.

But clarification should not become:

Artificial Delay

29. Data Discovery

Now determine:

Where does this individual’s information exist?

Start with:

Data Inventory

Record of Processing Activities

System Inventory

Data Flow Maps

Vendor Register

30. Data Discovery Checklist

Create:

07 Data Discovery Checklist

Review:

Primary Application

CRM

Customer Support

Email

Databases

Cloud Storage

Data Lake

Analytics

Marketing

Logs

Archives

Backups

Vendors

AI Services

31. Search Identifiers

An individual may appear under:

Name

Email

Phone

Customer ID

Employee ID

Account ID

Device ID

Username

Therefore searching only:

Name

may not identify all relevant records.

32. Identifier Mapping

Create:

08 Data Subject Identifier Map

Use:

Identifier	Value	Systems
Customer ID	C12345	CRM, DB
Email	user@example	CRM, Support
Account ID	A8892	Application
Device ID	Device-X	Analytics

33. System Search Matrix

Create:

09 DSR System Search Matrix

Use:

System	Data	Search Method	Owner	Result

34. Structured Data

Structured information may exist in:

Databases

CRM

ERP

HR Systems

Ticketing Platforms

These systems may support:

Search

Export

Correction

Deletion

35. Unstructured Data

Personal information may also exist in:

Email

Documents

Spreadsheets

Chat

Shared Drives

Tickets

Attachments

This can make discovery more difficult.

36. Cloud Data

Cloud environments may contain information across:

Object Storage

Managed Databases

Data Warehouses

Logs

Snapshots

Backups

Analytics Services

37. SaaS Data

Example:

Customer
      ↓
CRM
      ↓
Marketing SaaS
      ↓
Support SaaS
      ↓
Analytics SaaS

The DSR process must account for relevant copies.

38. Third Parties

If a processor or vendor holds relevant information:

Organization
      ↓
Vendor
      ↓
Subprocessor

the organization may need a defined mechanism for coordinating the request.

39. Vendor DSR Tracker

Create:

10 Third-Party DSR Tracker

Use:

Vendor	Request	Sent	Due	Response	Evidence

40. Vendor Contracts

Contracts should appropriately address:

Privacy Rights Support

Search Capability

Correction

Deletion

Export

Response Timing

Evidence

where applicable.

41. Access Requests

An access request generally asks:

What Personal Data
Do You Have
About Me?

The organization may need to identify relevant information and provide it according to applicable requirements.

42. Access Workflow

Access Request
      ↓
Verify Identity
      ↓
Determine Scope
      ↓
Search Systems
      ↓
Collect Records
      ↓
Review
      ↓
Redact Where Required
      ↓
Quality Assurance
      ↓
Secure Delivery

43. Access Response Package

Create:

11 DSAR Response Package

Potential contents:

Response Letter

Personal Data Export

Processing Information

Applicable Explanations

Redactions

Delivery Evidence

44. Third-Party Information

Suppose a record contains:

Requester Information
+
Another Person's Information

The organization may need to protect the other individual’s information.

45. Example

Support ticket:

Customer A
      ↓
Complaint About
Customer B

Customer A submits an access request.

The organization should evaluate:

Customer A Data

Customer B Data

Confidential Information

Applicable Exceptions

before disclosure.

46. Redaction

Where appropriate:

Original Record
      ↓
Review
      ↓
Third-Party Information
Removed / Protected
      ↓
Response Copy

47. Redaction Quality

A common failure:

Black Rectangle
Placed Over Text

while underlying text remains recoverable.

Redaction must actually remove or securely obscure protected content in the delivered file.

48. Sensitive Internal Information

Responses may also require review for information such as:

Security Information

Legal Privilege

Confidential Business Information

Investigation Information

Third-Party Data

depending on applicable requirements.

49. Correction Requests

Individuals may request inaccurate information be corrected.

Example:

Old Address
      ↓
New Address

50. Correction Workflow

Correction Request
      ↓
Verify Identity
      ↓
Identify Record
      ↓
Validate Correction
      ↓
Update Systems
      ↓
Propagate Where Required
      ↓
Confirm Completion

51. Correction Across Systems

Updating:

CRM

may not update:

Billing

Support

Marketing

Data Warehouse

Therefore corrections may need propagation.

52. Correction Tracker

Create:

12 Correction Request Tracker

Use:

System	Existing Value	New Value	Updated	Evidence

53. Deletion Requests

A deletion request asks the organization to remove applicable personal information.

Example:

Customer
      ↓
"Delete my
personal information."

But:

Deletion requests do not necessarily mean every record can immediately be destroyed.

54. Deletion Assessment

The organization must determine:

Which Data Exists?

Which Data Can Be Deleted?

Which Data Must Be Retained?

Which Systems Contain Copies?

Which Vendors Hold Copies?

55. Deletion Decision

Personal Data
      ↓
Deletion Request
      ↓
Retention Requirement?
      │
      ├── No → Delete
      │
      └── Yes
             ↓
Evaluate Applicable
Exception

56. Deletion Assessment Matrix

Create:

13 Deletion Assessment Matrix

Use:

Data	System	Delete?	Retain?	Basis	Action

57. Example

Customer requests deletion.

Records include:

Marketing Profile

Customer Account

Transaction Records

Security Logs

Support Tickets

Possible outcome:

Marketing Profile
      ↓
Delete

Customer Account
      ↓
Delete / Deactivate
as Applicable

Transaction Records
      ↓
Retention Review

Security Logs
      ↓
Retention Review

Support Tickets
      ↓
Assess

Actual decisions depend on applicable requirements.

58. Legal Retention

Some information may need to remain because of:

Legal Requirement

Regulatory Requirement

Contractual Requirement

Legal Claim

Investigation

59. Legal Hold

Deletion workflow must check:

Legal Hold?

before destroying information.

Deletion Eligible
      ↓
Legal Hold?
      │
      ├── No → Delete
      │
      └── Yes → Preserve

60. Deletion Exception Register

Create:

14 DSR Exception Register

Use:

Request	Data	Exception	Basis	Reviewer	Status

61. Exception Documentation

If data cannot be deleted, document:

What Data

Why Retained

Applicable Requirement

Retention Period

Decision Maker

62. Restriction Requests

Restriction may require limiting certain processing while retaining information.

Conceptually:

Data Retained
      ↓
Processing Restricted

instead of:

Data Deleted

63. Restriction Control

Systems may require:

Restriction Flag

Processing Block

Marketing Suppression

Workflow Control

64. Objection Requests

Individuals may object to certain processing depending on applicable privacy requirements.

Example:

Individual
      ↓
Objects to
Direct Marketing

The organization needs an operational mechanism to enforce the result.

65. Suppression

A common marketing pattern is:

User Opts Out
      ↓
Suppression List

rather than simply deleting the email and accidentally re-importing it later.

66. Consent Withdrawal

If processing relies on consent and consent is withdrawn:

Consent Withdrawn
      ↓
Identify Processing
      ↓
Stop Applicable Processing
      ↓
Update Systems
      ↓
Maintain Appropriate Evidence

67. Consent Withdrawal Register

Create:

15 Consent Withdrawal Register

Use:

Subject	Processing	Withdrawal	Systems	Completed

68. Data Portability

Where applicable, individuals may request information in a:

Structured

Commonly Used

Machine-Readable

format.

Potential formats can include:

CSV

JSON

Other Appropriate
Structured Formats

depending on the data and requirement.

69. Portability Workflow

Request
      ↓
Verify
      ↓
Identify Applicable Data
      ↓
Export
      ↓
Validate
      ↓
Secure Delivery

70. Secure Response Delivery

DSR responses may contain highly sensitive information.

Avoid:

Sensitive Export
      ↓
Unprotected Email

where inappropriate.

Consider:

Secure Portal

Authenticated Download

Appropriate Encryption

Controlled Transfer

71. Response Verification

Before releasing the package:

Verify Recipient
Again

especially for sensitive access requests.

72. Quality Assurance

Before responding, verify:

Correct Person?

Correct Scope?

All Systems Searched?

Third-Party Data Reviewed?

Redactions Complete?

Exceptions Approved?

Files Open Correctly?

Secure Delivery Ready?

73. DSR QA Checklist

Create:

16 DSR Quality Assurance Checklist

Use:

Identity Verified

Scope Confirmed

Search Complete

Vendor Search Complete

Legal Review Complete

Redactions Validated

Response Approved

Delivery Secured

74. AI Systems

AI creates new challenges for privacy-rights operations.

Personal information may exist in:

Prompts

Conversation History

Uploaded Documents

Vector Databases

AI Memory

Model Inputs

Generated Outputs

Logs

75. AI DSR Assessment

Ask:

Can We Find
the Individual's Data?

Can We Export It?

Can We Correct It?

Can We Delete It?

Is It in
Provider Logs?

Is It in
Vector Storage?

Was It Used
for Training?

76. AI Vendor Capability

Before deploying enterprise AI:

AI Vendor
      ↓
Privacy Rights
Capability Assessment

should evaluate:

Search

Export

Deletion

Retention

Training Usage

Tenant Isolation

Subprocessors

77. Vector Databases

AI applications may store personal information in:

Embeddings

Chunks

Metadata

Vector Indexes

Deleting the original document may not necessarily remove all derived representations.

Therefore deletion architecture must consider the complete AI data pipeline.

78. AI Data Flow

Example:

User Document
      ↓
Chunking
      ↓
Embeddings
      ↓
Vector Database
      ↓
LLM Context
      ↓
Logs

Each location may require evaluation.

79. Backups

Backups create a practical deletion challenge.

Production Data
      ↓
Deleted

while:

Backup Copy
      ↓
Still Exists

Organizations should define how backup copies are handled under applicable requirements and retention policies.

80. Backup Restoration Risk

Suppose:

Customer Deleted
      ↓
Production Clean

then:

Old Backup Restored

The deleted record could return.

Mature processes account for this risk.

81. Archives

Archived information should also be considered.

Active System

Archive

Records Repository

may each contain personal data.

82. Security Logs

Security logs can contain:

Username

IP Address

Device ID

Authentication Events

Deletion requests involving security logs may require careful retention and legal analysis.

83. Email

Email searches can become difficult because personal information may appear in:

Inbox

Sent Mail

Shared Mailboxes

Archives

Attachments

Legal Holds

84. Employee Requests

Employees may exercise privacy rights under applicable requirements.

HR systems may contain:

Personnel Records

Payroll

Performance

Benefits

Access Records

Emails

Security Logs

85. Former Employees

Former employees can create especially complex discovery requirements because:

Account Disabled

Mailbox Archived

HR Record Retained

Security Logs Retained

Backups Exist

86. Children and Guardians

Where requests concern children:

Requester
      ↓
Parent / Guardian?

appropriate authority verification may be required.

87. Deceased Individuals

Rights concerning deceased persons differ between jurisdictions.

Do not assume the same rules apply universally.

88. Fraudulent Requests

Privacy requests can be abused for:

Identity Theft

Account Takeover

Social Engineering

Information Gathering

Therefore identity verification is also a security control.

89. Insider Threat

An employee processing DSRs may gain access to large amounts of personal information.

Controls should include:

Least Privilege

Logging

Approval

Segregation of Duties

Monitoring

90. DSR Access Logging

Track:

Who Searched?

Which Systems?

Which Records?

What Was Exported?

Who Downloaded?

Who Approved?

91. Evidence

A mature program should retain appropriate evidence demonstrating how requests were handled.

Create:

17 DSR Evidence Repository

Suggested structure:

01 Intake

02 Verification

03 Classification

04 Search Evidence

05 Vendor Responses

06 Legal Review

07 Exceptions

08 Response Package

09 Approval

10 Delivery Evidence

92. Evidence Principle

The organization should be able to answer:

What Was Requested?

When?

What Did We Search?

What Did We Find?

What Did We Delete?

What Did We Retain?

Why?

When Did We Respond?

Can We Prove It?

93. DSR Automation

Manual DSR processing becomes difficult at scale.

Automation may support:

Request Intake

Deadline Calculation

Identity Verification

System Search

Task Assignment

Vendor Requests

Deletion Workflows

Evidence Collection

Reporting

94. Automated Discovery

Conceptually:

Verified Subject
      ↓
Identifier Mapping
      ↓
CRM Search
      ↓
Database Search
      ↓
SaaS Search
      ↓
Cloud Search
      ↓
Result Aggregation

95. Automated Deletion

Example:

Approved Deletion
      ↓
CRM Delete
      ↓
Marketing Delete
      ↓
Support Delete
      ↓
Application Delete
      ↓
Vendor Request
      ↓
Evidence

Automation still requires governance and appropriate exception handling.

96. Privacy Engineering

Mature organizations design applications so that privacy rights are technically supportable.

Instead of:

Build Application
      ↓
Later Ask:
"How Do We Delete
One User?"

design:

User Identifier
      ↓
Data Mapping
      ↓
Export Function
      ↓
Correction Function
      ↓
Deletion Function

97. Privacy Rights by Design

For every new system ask:

Can We Find
One Person's Data?

Can We Export It?

Can We Correct It?

Can We Restrict It?

Can We Delete It?

Can We Prove
What Happened?

98. DSR Program Testing

GRC and Privacy teams should periodically test the operational process.

99. Test — Request Population

Population:

500 DSRs

Sample:

50 Requests

Verify:

Verification

Deadline

Search

Decision

Response

Evidence

100. Test — Timeliness

Example:

100 Requests Due

Completed on time:

94

Calculate:

94
─── × 100
100

= 94%

Investigate overdue requests.

101. Test — Verification

Sample:

30 Access Requests

Verify all contained evidence of appropriate identity verification.

102. Test — System Coverage

Request search included:

CRM

Support

Database

but omitted:

Marketing SaaS

Potential finding:

Data subject discovery procedures do not cover all systems processing personal information.

103. Test — Vendor Coverage

Select requests involving external processors.

Verify:

Vendor Notified

Request Tracked

Response Received

Action Completed

Evidence Retained

104. Test — Deletion

Sample:

20 Completed
Deletion Requests

Verify:

Primary System

CRM

Marketing

Support

Cloud

Vendor

as applicable.

105. Test — Exceptions

Sample retained records.

Verify:

Exception Basis

Legal Review

Retention Period

Approval

106. Test — Response Package

Verify:

Correct Subject

Correct Data

Third-Party Data Protected

Files Accessible

Secure Delivery

107. DSR Compliance Gap Register

Create:

18 DSR Compliance Gap Register

Use:

Finding	Request	Risk	Severity	Owner	Due

108. Example Finding — Missed System

Access request searched:

CRM

Application

Support

but not:

Marketing Platform

Root cause:

Marketing Platform
Not Included
in Data Inventory

109. Correction

Search Marketing
Platform

and update the current request where necessary.

110. Corrective Action

Update Data Inventory
      ↓
Update DSR Search Matrix
      ↓
Assign System Owner
      ↓
Test Future Requests

111. Example Finding — Late Response

Requirement:

Applicable Deadline

Actual:

Response Issued
After Deadline

Root cause:

Vendor Response
Was Delayed

112. Corrective Action

Implement:

Vendor SLA
      ↓
Internal Deadline
      ↓
Automated Reminder
      ↓
Escalation

113. Example Finding — Identity Failure

An access response was sent after verifying only:

Email Address

even though sensitive information was involved.

Risk:

Unauthorized Disclosure

114. Corrective Action

Develop:

Risk-Based
Verification Standard

based on request sensitivity.

115. Example Finding — Incomplete Deletion

Deletion request completed in:

Primary Application

but data remained in:

Marketing SaaS

Root cause:

Deletion Workflow
Did Not Include
Third Parties

116. Corrective Action

Integrate:

Vendor Register
+
Data Inventory
+
Deletion Workflow

117. DSR Dashboard

Track:

Metric	Target
Requests Logged	100%
Requests Verified	100%
Responses Within Applicable Deadline	100%
Required Systems Searched	100%
Applicable Vendors Included	100%
Deletion Actions Completed	100%
Overdue Requests	0
Unapproved Exceptions	0

118. KPI — On-Time Completion

Requests Completed
Within Deadline
────────────────── × 100
Requests Due

119. KPI — Search Coverage

Required Systems
Successfully Searched
───────────────────── × 100
Required Systems

120. KPI — Vendor Completion

Vendor Actions
Completed on Time
───────────────── × 100
Vendor Actions Due

121. KRI — Overdue Requests

Number of DSRs
Beyond Applicable
Response Deadline

122. KRI — Incomplete Discovery

Requests Where
Required Systems
Were Not Searched

123. KRI — Verification Failure

Responses Released
Without Appropriate
Identity Verification

124. KRI — Incomplete Deletion

Deletion Requests
Marked Complete
While Data Remains
in Applicable Systems

125. Practical Activity — Access Request

Use fictional organization:

CloudPay

A customer requests:

“Send me all personal information CloudPay holds about me.”

Their information may exist in:

Customer Portal

CRM

Support Platform

Marketing SaaS

Payment System

Security Logs

Data Lake

Build the complete DSAR workflow.

126. Practical Activity — Identity Verification

Requester emails from:

Unknown Email Address

asking for:

Account History

Payment Information

Support Records

Determine an appropriate verification approach before disclosure.

127. Practical Activity — Deletion

Customer says:

“Delete everything about me.”

CloudPay finds:

Marketing Data

Account Profile

Transactions

Security Logs

Support Tickets

Backups

For each determine:

Delete?

Retain?

Why?

For How Long?

Which Evidence?

128. Practical Activity — Vendor

CloudPay’s CRM provider stores customer data.

Customer requests deletion.

Build:

Internal Approval
      ↓
Vendor Request
      ↓
Vendor Confirmation
      ↓
Evidence
      ↓
Request Closure

129. Practical Activity — AI

CloudPay uses an AI support assistant.

Customer information exists in:

Conversation History

Prompt Logs

Vector Database

Uploaded Documents

Provider Logs

Determine how the privacy-rights workflow should discover and address each location.

130. Practical Activity — Employee Request

Former employee requests access to personal information.

Potential systems:

HR

Payroll

Email

Performance System

Security Logs

Access Management

Archived Mailbox

Build the search and review workflow.

Data Subject Rights Operational Checklist

Governance

• DSR procedure established.

• roles assigned.

• RACI documented.

• applicable rights identified.

• jurisdiction requirements maintained.

• escalation process defined.

Intake

• approved intake channels established.

• customer-facing teams trained.

• requests centrally registered.

• received date captured.

• request type classified.

• due date calculated.

Verification

• requester identity verified.

• verification proportionate to risk.

• representative authority verified.

• verification evidence retained.

Discovery

• identifiers mapped.

• system inventory reviewed.

• data flows reviewed.

• cloud systems searched.

• SaaS systems searched.

• unstructured data considered.

• vendors identified.

• AI systems considered.

Access

• relevant information collected.

• third-party information reviewed.

• exceptions assessed.

• redactions validated.

• response package reviewed.

Correction

• inaccurate record identified.

• correction validated.

• relevant systems updated.

• downstream propagation considered.

Deletion

• applicable data identified.

• retention requirements reviewed.

• legal holds checked.

• deletion exceptions documented.

• applicable systems updated.

• vendors included.

• evidence retained.

Other Rights

• restriction requests supported.

• objection requests supported.

• consent withdrawal supported.

• portability supported where applicable.

Third Parties

• vendor responsibilities defined.

• vendor requests tracked.

• vendor SLAs established where appropriate.

• completion evidence collected.

Security

• DSR access restricted.

• activities logged.

• response packages protected.

• recipient verified.

• secure delivery used where appropriate.

AI

• prompt data considered.

• conversation history considered.

• uploaded files considered.

• vector stores considered.

• provider retention considered.

• model-training implications considered.

Quality Assurance

• identity rechecked.

• search completeness reviewed.

• redactions checked.

• exceptions approved.

• files validated.

• response approved.

Evidence

• intake evidence retained.

• verification evidence retained.

• search evidence retained.

• vendor evidence retained.

• exception evidence retained.

• response evidence retained.

• delivery evidence retained.

Monitoring

• deadlines monitored.

• overdue requests escalated.

• request samples tested.

• deletion effectiveness tested.

• vendor performance reviewed.

• KPIs and KRIs reported.

131. Common DSR Mistakes

Mistake 1 — Requests Only Accepted Through Privacy Portal

A valid privacy request may arrive through another recognized business channel.

Teams must know how to route it.

Mistake 2 — Weak Identity Verification

Access Request
      ↓
No Verification
      ↓
Sensitive Data Released

This can itself create a privacy incident.

Mistake 3 — Excessive Verification

The opposite is also problematic.

Do not unnecessarily collect additional sensitive information just to process the request.

Mistake 4 — Searching Only the Primary System

CRM Searched
      ↓
Request Complete

while information remains in:

Marketing

Support

Cloud

Analytics

Vendors

Mistake 5 — Ignoring Unstructured Data

Email, documents, attachments, and shared drives may contain relevant information.

Mistake 6 — Ignoring Vendors

Third-party systems can contain substantial amounts of personal information.

Mistake 7 — Delete Everything Automatically

Some records may have legitimate retention requirements or legal holds.

Mistake 8 — Retain Everything as an Exception

Exceptions should not become a mechanism for avoiding deletion obligations.

Mistake 9 — Poor Redaction

Redaction must actually protect information, not merely visually cover it.

Mistake 10 — No Evidence

The organization cannot demonstrate:

What Was Searched

What Was Deleted

Why Data Was Retained

When Response Was Sent

Mistake 11 — Ignoring AI Data

Personal information may exist in prompts, vector stores, chat history, uploaded files, and provider logs.

Mistake 12 — No Privacy Engineering

Systems are deployed without the technical ability to:

Find

Export

Correct

Restrict

Delete

individual records.

132. Weak DSR Program

Email Request
      ↓
Privacy Team
      ↓
Manual Emails
      ↓
Manual Search
      ↓
Spreadsheet
      ↓
Response

133. Strong DSR Program

Request Intake
      ↓
Automated Registration
      ↓
Identity Verification
      ↓
Deadline Calculation
      ↓
Identifier Mapping
      ↓
Enterprise Discovery
      ↓
Vendor Coordination
      ↓
Legal / Privacy Review
      ↓
Automated Fulfilment
      ↓
Quality Assurance
      ↓
Secure Response
      ↓
Evidence
      ↓
Continuous Monitoring

134. GRC Analyst Responsibilities

A GRC professional supporting privacy-rights management may:

• maintain the DSR procedure.

• maintain applicable-rights requirements.

• maintain deadline matrices.

• monitor request registers.

• coordinate system owners.

• maintain data-discovery matrices.

• coordinate vendor requests.

• review retention requirements.

• track deletion exceptions.

• maintain evidence.

• test DSR controls.

• review overdue requests.

• analyze recurring issues.

• monitor vendors.

• support audits.

• prepare privacy dashboards.

• track corrective actions.

GRC connects:

Privacy

Legal

Security

IT

Cloud

HR

Marketing

Customer Support

Data Governance

Vendor Management

AI Governance

Internal Audit

135. DSR Maturity Model

Level 1 — Reactive

Requests
Handled Manually
When Received

Level 2 — Documented

DSR Procedure

Request Register

Basic Verification

Level 3 — Governed

System Search Matrix

Vendor Workflow

Exception Management

Evidence

Metrics

Level 4 — Automated

Automated Intake

Deadline Tracking

System Integration

Deletion Workflows

Vendor Automation

Level 5 — Privacy Rights by Design

Data Discovery

Automated Fulfilment

Privacy Engineering

Continuous Evidence

Continuous Monitoring

136. Data Subject Rights Mindset

For every request ask:

What Is
the Request?

When Was
It Received?

Which Requirement
Applies?

When Is
It Due?

Who Is
the Requester?

Have We
Verified Them?

Which Identifiers
Belong to Them?

Where Does
Their Data Exist?

Which Systems?

Which Cloud Services?

Which SaaS Platforms?

Which Vendors?

Which AI Systems?

Which Backups?

Can We
Access It?

Can We
Correct It?

Can We
Delete It?

Must Anything
Be Retained?

Is There
a Legal Hold?

Does the Response
Contain Another
Person's Data?

Has It Been
Quality Checked?

How Will We
Deliver It Securely?

Can We Prove
Everything We Did?

That is the practical enterprise mindset for managing data subject rights.

Key Takeaways

• Privacy rights require operational processes, not merely privacy-policy statements.

• DSR is a broad term covering multiple privacy-rights requests; DSAR generally refers to access requests.

• Request intake should account for recognized requests arriving through multiple channels.

• Applicable response deadlines must be identified and monitored.

• Identity verification protects against unauthorized disclosure.

• Verification should be proportionate and should not unnecessarily collect additional personal information.

• Enterprise data discovery is essential for complete responses.

• Data inventories, data-flow maps, and system inventories support DSR fulfilment.

• Cloud, SaaS, vendors, subprocessors, archives, backups, and AI systems must be considered.

• Access responses require careful review of third-party and protected information.

• Correction may need to propagate across multiple systems.

• Deletion requests require retention, exception, and legal-hold analysis.

• Restriction, objection, portability, and consent withdrawal require operational capabilities.

• DSR response packages should be securely delivered.

• AI introduces new challenges involving prompts, vector stores, uploaded documents, logs, and model providers.

• Mature organizations design privacy-rights capabilities directly into applications.

• Every request should leave sufficient evidence demonstrating how it was handled.

Knowledge Check

Before continuing, make sure you can answer:

1. What are data subject rights?

2. What is a DSR?

3. What is a DSAR?

4. Why is identity verification important?

5. Why should verification be proportionate?

6. How should DSR deadlines be determined?

7. Why is identifier mapping important?

8. Why should organizations maintain a system search matrix?

9. What is the challenge with unstructured information?

10. Why must SaaS and vendors be included?

11. What should happen during an access request?

12. Why might information require redaction?

13. How should correction requests propagate across systems?

14. Why does a deletion request not always mean immediate deletion of every record?

15. What role does a legal hold play?

16. What is a deletion exception?

17. How can restriction differ from deletion?

18. Why can suppression be useful for marketing objections?

19. What challenges do backups create?

20. What new DSR challenges can AI systems introduce?

21. Why are vector databases relevant?

22. Why should responses undergo quality assurance?

23. What evidence should be retained?

24. How can DSR workflows be automated?

25. What does Privacy Rights by Design mean?

What’s Next?

➡️ Next: 10 — Privacy Compliance Monitoring

In the next lesson, you will move from processing individual privacy-rights requests to continuously evaluating whether the organization’s overall privacy program is operating as designed.

You will examine:

Privacy Requirements
      ↓
Control Framework
      ↓
Control Owners
      ↓
Monitoring Activities
      ↓
Evidence Collection
      ↓
Control Testing
      ↓
Privacy Metrics
      ↓
Exceptions & Findings
      ↓
Corrective Actions
      ↓
Management Reporting
      ↓
Continuous Improvement

You will build practical artifacts including a Privacy Compliance Monitoring Plan, Privacy Control Matrix, Monitoring Calendar, Privacy Evidence Register, Privacy Compliance Testing Workbook, Privacy Findings Register, Corrective Action Tracker, Privacy KPI/KRI Dashboard, and Management Privacy Compliance Report.