Runbook 01 — Privacy Impact Assessment & Data Subject Request Operations

Runbook Information

Field	Details
Runbook Type	Privacy Operations / GRC
Primary Roles	Privacy Analyst, GRC Analyst
Supporting Roles	Legal, Security, IT, Data Governance, Procurement, Business Owners
Difficulty	Intermediate
Primary Processes	PIA/DPIA Operations + Data Subject Requests
Execution Model	Event-Driven
Primary Objective	Consistent, Evidence-Based Privacy Operations

Purpose

This runbook provides a repeatable operational process for two of the most important activities in an enterprise privacy program:

01 Privacy Impact Assessment Operations

02 Data Subject Request Operations

The objective is to make privacy work:

Repeatable

Traceable

Risk-Based

Time-Bound

Evidence-Driven

Auditable

rather than dependent on ad hoc emails, spreadsheets, or individual knowledge.

Operational Model

The runbook covers two connected workflows.

Workflow A — Privacy Impact Assessment

New Project / Change
      ↓
Privacy Screening
      ↓
Assessment Level
      ↓
PIA / DPIA
      ↓
Data Mapping
      ↓
Risk Assessment
      ↓
Controls
      ↓
Remediation
      ↓
Residual Risk
      ↓
Approval
      ↓
Reassessment

Workflow B — Data Subject Request

Request Received
      ↓
Register
      ↓
Verify Identity
      ↓
Classify Right
      ↓
Determine Deadline
      ↓
Discover Data
      ↓
Legal / Privacy Review
      ↓
Fulfil Request
      ↓
Quality Assurance
      ↓
Secure Response
      ↓
Evidence
      ↓
Closure

When to Use This Runbook

Use the PIA workflow when:

New Application

New SaaS Platform

New Cloud Service

New AI System

New Data Category

New Processing Purpose

New Vendor

New Country

New Tracking Technology

New Employee Monitoring

Major Architecture Change

Use the DSR workflow when an individual asks to:

Access Data

Know What Is Processed

Correct Data

Delete Data

Restrict Processing

Object to Processing

Export Data

Withdraw Consent

Required Operational Artifacts

Maintain:

01 Privacy Screening Register

02 PIA Register

03 PIA Template

04 Privacy Risk Register

05 PIA Remediation Tracker

06 Privacy Approval Register

07 DSR Register

08 Identity Verification Checklist

09 System Search Matrix

10 DSR Exception Register

11 Vendor DSR Tracker

12 DSR Evidence Repository

Roles and Responsibilities

Role	Primary Responsibility
Privacy	Process ownership and privacy analysis
GRC	Governance, evidence, testing, tracking
Legal	Legal interpretation and exceptions
Security	Security control and incident support
IT	System discovery and technical fulfilment
Business Owner	Processing purpose and remediation
Procurement	Vendor coordination
Data Governance	Data inventory and discovery
Internal Audit	Independent assurance

Part A — Privacy Impact Assessment Operations

1. Receive Privacy Review Trigger

A privacy review may originate from:

Project Management

Architecture Review

Security Review

Procurement

Vendor Onboarding

Cloud Governance

AI Governance

Change Management

Business Request

Immediately create:

PIA Case ID

Example:

PIA-2026-0042

2. Record the Project

Capture:

Field	Required
Project name	Yes
Business owner	Yes
Technical owner	Yes
Description	Yes
Planned go-live	Yes
Systems	Yes
Vendors	Yes
Countries	Yes
Personal data	Initial assessment

3. Perform Privacy Screening

Ask:

Does It Process Personal Data?

Sensitive Data?

Children's Data?

Biometrics?

Location?

Employee Data?

New Purpose?

New Vendor?

AI?

Profiling?

Automated Decision?

Tracking?

Cross-Border Processing?

Large-Scale Processing?

4. Determine Assessment Level

Use:

No Personal Data
      ↓
No Full PIA
Document Decision

or:

Personal Data
+
Low Risk
      ↓
Limited Privacy Review

or:

Personal Data
+
Material Privacy Risk
      ↓
Full PIA

or:

High-Risk Processing
      ↓
DPIA / Enhanced Assessment
Where Applicable

5. Record Screening Decision

Document:

Assessment Required?

Reason

Reviewer

Date

Risk Indicators

Never record only:

PIA Required:
Yes

without rationale.

6. Define PIA Scope

Identify:

Processing Activities

Data Subjects

Personal Data

Sensitive Data

Systems

Cloud Services

Vendors

Subprocessors

Countries

Data Flows

Retention

7. Confirm Processing Purpose

Ask the business owner:

What exactly are we trying to achieve with this processing?

Document each purpose separately.

Example:

Customer Email
      ↓
Account Authentication

and:

Customer Email
      ↓
Marketing

should not automatically be treated as the same purpose.

8. Challenge Necessity

For each data field ask:

Why Is It Needed?

What Happens
If We Do Not
Collect It?

Can We Use
Less Data?

Can We Use
Less Precise Data?

9. Identify Prohibited or Unnecessary Data

Examples:

Password in AI Prompt

Full Payment Card
for Shipping Question

Biometric Data
for Basic Registration

Recommended outcome:

Remove

Mask

Redact

Tokenize

Do Not Collect

10. Build Personal Data Inventory

Document:

Data	Source	Purpose	Classification	Storage	Vendor

11. Build Data Flow

Map:

Data Subject
      ↓
Collection Point
      ↓
Application
      ↓
Database
      ↓
Cloud
      ↓
Vendor
      ↓
Subprocessor
      ↓
Archive / Backup

12. Validate Actual Flow

Do not rely only on architecture diagrams.

Validate against:

Application Design

Cloud Architecture

Vendor Documentation

Network Flow

API Integrations

SaaS Configuration

13. Identify Data Locations

Capture:

Country

Cloud Region

Primary Storage

Backup Region

DR Region

Vendor Region

Subprocessor Region

14. Assess Transparency

Review whether individuals are appropriately informed about:

Data Collected

Processing Purpose

Third Parties

Retention

Rights

AI Processing

Automated Decisions

International Transfers

where applicable.

15. Assess Processing Requirements

Map each processing activity to:

Applicable Privacy Law

Legal / Processing Basis

Consent Requirement

Notice Requirement

Transfer Requirement

Rights Requirement

Avoid copying one privacy framework’s legal model into another without analysis.

16. Assess Privacy Rights Capability

Verify whether the system can:

Find

Access

Correct

Export

Restrict

Delete

an individual’s information where required.

17. Assess Retention

Document:

Retention Period

Retention Trigger

Archive

Backup Treatment

Deletion Method

Check for:

Keep Forever

defaults.

18. Assess Vendors

For each processor/provider evaluate:

Role

Data

Purpose

Security

Location

Retention

Training Use

Subprocessors

Incident Notification

DSR Support

Deletion

19. Assess AI Processing

Where AI is involved, evaluate:

Prompt Data

Uploaded Data

Training Data

Model Provider

Output Data

Prompt Retention

Provider Training Usage

Vector Database

Embeddings

AI Memory

Automated Decisions

Human Oversight

20. Assess Security Controls

Review at minimum:

IAM

Least Privilege

MFA

Encryption

Logging

DLP

Network Controls

Secrets Management

Backup

Incident Response

21. Identify Privacy Risks

Typical risks include:

Excessive Collection

Unauthorized Access

Unexpected Reuse

Incorrect Data

Improper Sharing

Excessive Retention

Vendor Exposure

Cross-Border Risk

AI Leakage

Profiling

Re-identification

Incomplete Deletion

22. Score Inherent Risk

Use the enterprise risk methodology.

Example:

Likelihood:
1–5

Impact:
1–5

Score:
Likelihood × Impact

23. Assess Existing Controls

For each risk determine:

What Control Exists?

Who Owns It?

Is It Designed Well?

Is It Implemented?

What Evidence Exists?

24. Identify Control Gaps

Example:

Risk:
Sensitive Data
Entered into AI

Existing control:

Employee Training

Assessment:

Insufficient

Required enhancement:

Input Filtering
+
DLP
+
Restricted Fields

25. Build Remediation Plan

For every material gap define:

Action	Owner	Due	Priority	Evidence

Separate:

Must Fix Before Launch

from:

Post-Launch Improvement

26. Determine Residual Risk

Reassess risk after planned controls.

Inherent Risk
      ↓
Controls
      ↓
Residual Risk

27. Escalate High Residual Risk

Where high risk remains:

Privacy
      ↓
Legal
      ↓
Risk Owner
      ↓
Management / Governance

according to policy and applicable legal requirements.

28. Determine PIA Decision

Use one of:

APPROVED

APPROVED WITH CONDITIONS

REMEDIATION REQUIRED

ESCALATED

REJECTED

29. Record Approval

Capture:

Decision

Approver

Conditions

Residual Risk

Outstanding Actions

Reassessment Date

30. Validate Pre-Launch Actions

Do not close actions based on email confirmation.

Validate evidence.

Example:

Requirement:
AI Must Not Retain
Sensitive Prompts

Validate:

Configuration

Controlled Test

Logs

Contract

31. Define Reassessment Triggers

Reopen the PIA when there is:

New Data

New Purpose

New Vendor

New AI Model

New Subprocessor

New Country

New Integration

New Automated Decision

Major Architecture Change

Privacy Incident

PIA Escalation Criteria

Immediately escalate where processing may involve:

Large-Scale Sensitive Data

Children

Biometrics

High-Risk AI

Systematic Monitoring

Automated Significant Decisions

Unknown Data Location

Unapproved Cross-Border Processing

Critical Security Gap

Unclear Processing Authority

PIA Closure Criteria

Do not close until:

• screening is documented.

• data inventory is complete.

• data flow is documented.

• risks are assessed.

• mandatory actions are closed.

• evidence is validated.

• residual risk is accepted.

• approval is recorded.

• reassessment triggers are documented.

Part B — Data Subject Request Operations

32. Receive the Request

A request may arrive through:

Privacy Portal

Email

Customer Support

HR

Phone

Postal Mail

Authorized Agent

Do not require exact legal wording.

Examples:

"What data
do you have
about me?"

"Delete my
account."

"Stop using
my information."

may represent privacy-rights requests.

33. Register the Request Immediately

Create:

DSR Case ID

Example:

DSR-2026-0157

Capture:

Field	Required
Requester	Yes
Request type	Yes
Date received	Yes
Channel	Yes
Jurisdiction	Yes
Owner	Yes
Deadline	Yes
Verification status	Yes

34. Preserve Original Request

Keep the original:

Email

Portal Submission

Letter

Support Ticket

as evidence.

35. Determine Applicable Privacy Framework

Identify:

Requester Location

Organization Role

Processing Activity

Applicable Law

Applicable Right

36. Calculate Deadline

Use the applicable requirements matrix.

Do not rely on:

One Global
30-Day Deadline

unless that is explicitly appropriate for the request.

37. Set Internal Deadline

Operationally set:

Legal Deadline
      ↓
Internal Target
Earlier Than
Legal Deadline

to allow for:

QA

Vendor Delays

Legal Review

Technical Issues

38. Verify Identity

Before releasing or changing personal data, verify the requester.

Use:

Risk-Based

Proportionate

Data-Minimized

verification.

39. Verification Methods

Possible methods include:

Authenticated Account

Existing Email

OTP

Known Account Information

Employee Authentication

depending on the risk and context.

40. Avoid Excessive Verification

Do not request:

Passport

Government ID

Sensitive Documents

unless justified by the risk and applicable process.

41. Authorized Representative

Where a request comes from another person, verify:

Identity of Requester

Identity of Subject

Authority to Act

42. Classify the Right

Identify:

Access

Know

Correction

Deletion

Restriction

Objection

Portability

Consent Withdrawal

A single request may contain multiple rights.

43. Define Request Scope

Identify:

Account

Email

Customer ID

Employee ID

Time Period

Service

Requested Data

44. Build Identifier Map

Map the subject across:

Name

Email

Phone

Account ID

Customer ID

Employee ID

Username

Device ID

45. Start Enterprise Discovery

Search:

Primary Application

CRM

Support

ERP

HR

Database

Data Lake

Cloud Storage

Email

Logs

Analytics

Marketing

AI

Archives

Vendors

according to applicability.

46. Use the System Search Matrix

For every system record:

System	Owner	Search	Result	Evidence

Do not rely on:

"Nothing Found"

without recording the search.

47. Search Unstructured Information

Where relevant, include:

Email

Documents

Spreadsheets

Attachments

Chat

Shared Drives

48. Coordinate Vendors

If a vendor holds the data:

Send Vendor Request
      ↓
Record Date
      ↓
Track Vendor SLA
      ↓
Receive Response
      ↓
Validate
      ↓
Retain Evidence

49. Track Vendor Dependencies

Record:

Vendor

Request Sent

Vendor Due Date

Response

Action Completed

Evidence

50. Handle Access Requests

Workflow:

Verify
      ↓
Discover
      ↓
Collect
      ↓
Review
      ↓
Redact
      ↓
QA
      ↓
Secure Delivery

51. Review Third-Party Information

Before disclosure identify:

Other Individuals' Data

Legal Privilege

Security Information

Confidential Information

Investigation Data

and apply appropriate legal/privacy review.

52. Validate Redaction

Do not simply cover text visually.

Verify underlying information cannot be recovered from the delivered version.

53. Handle Correction Requests

Workflow:

Identify Record
      ↓
Validate Correction
      ↓
Update Primary System
      ↓
Update Downstream Systems
      ↓
Vendor Update
      ↓
Evidence

54. Handle Deletion Requests

Do not immediately delete everything.

First determine:

What Data Exists?

Is It Eligible
for Deletion?

Is Retention Required?

Is There
a Legal Hold?

Do Vendors
Hold Copies?

55. Build Deletion Decision

Data
      ↓
Deletion Request
      ↓
Retention Requirement?
      │
      ├── No → Delete
      │
      └── Yes
             ↓
Document Basis
             ↓
Retain Only
as Required

56. Check Legal Holds

Before deletion:

Legal Hold?
      │
      ├── No → Continue
      │
      └── Yes → Preserve

57. Track Deletion Across Systems

Check:

Application

CRM

Support

Marketing

Cloud

Data Lake

AI

Vendor

Archives

according to applicable requirements.

58. Handle AI Data

Where AI is involved, search for:

Conversation History

Prompt Logs

Uploaded Files

Vector Database

Embeddings

AI Memory

Provider Logs

Deleting the source document may not automatically remove all derived AI records.

59. Handle Backups

Follow approved backup privacy procedures.

Do not promise:

"Deleted from
every backup immediately"

unless that is technically and contractually true.

Document how expired/deleted records are handled when backups are restored.

60. Handle Objection

Where applicable:

Objection Received
      ↓
Identify Processing
      ↓
Assess Requirement
      ↓
Stop / Restrict
Applicable Processing
      ↓
Evidence

61. Handle Consent Withdrawal

Where processing depends on consent:

Consent Withdrawn
      ↓
Update Consent Record
      ↓
Stop Relevant Processing
      ↓
Propagate Preference
      ↓
Verify

62. Handle Portability

Where applicable:

Identify Applicable Data
      ↓
Export
      ↓
Validate Format
      ↓
Secure Delivery

Possible formats may include:

CSV

JSON

depending on context and requirements.

63. Perform Legal / Privacy Review

Before closing the request, review:

Exceptions

Retention

Third-Party Rights

Confidentiality

Legal Holds

Security Risks

Request Completeness

64. Perform Quality Assurance

Use:

DSR QA Checklist

Verify:

• correct individual.

• correct request.

• all required systems searched.

• vendors completed.

• exceptions approved.

• third-party information protected.

• response complete.

• response files work.

• delivery channel secure.

• deadline still achievable.

65. Approve Response

Use an approved privacy/legal review level based on:

Request Type

Sensitivity

Complexity

Exception

Jurisdiction

66. Deliver Securely

For sensitive information use appropriate:

Authenticated Portal

Encrypted File

Secure Transfer

Controlled Download

Do not expose sensitive response packages unnecessarily.

67. Confirm Delivery

Retain evidence of:

Date Sent

Recipient

Method

Delivery Status

68. Close the Request

Before closure confirm:

Request Fulfilled

Response Issued

Vendor Actions Complete

System Actions Complete

Exceptions Recorded

Evidence Complete

69. Build DSR Evidence Package

Maintain:

01 Original Request

02 Verification

03 Deadline Calculation

04 Identifier Map

05 Search Evidence

06 Vendor Evidence

07 Legal Review

08 Exceptions

09 Fulfilment Evidence

10 Response

11 Delivery Evidence

12 Closure Approval

DSR Escalation Criteria

Immediately escalate when:

Identity Cannot
Be Reliably Verified

Sensitive Data
Is Involved

Large Data Volume

Request Is Complex

Legal Hold Exists

Requester Threatens
Litigation / Regulator

Security Incident
Discovered

Deadline At Risk

Vendor Is Unresponsive

Cross-Border Issue
Identified

Possible Fraud

DSR Closure Criteria

Do not close until:

• request is registered.

• identity is appropriately verified.

• deadline is calculated.

• search scope is documented.

• required systems are searched.

• vendors are addressed.

• exceptions are reviewed.

• fulfilment is complete.

• QA is complete.

• response is securely delivered.

• evidence is retained.

Part C — Operational Incident Scenarios

Scenario 1 — Project Launch Without PIA

A new marketing analytics tool is discovered in production.

It processes:

Customer Email

Device ID

Browsing Activity

No PIA exists.

Response

Open PIA Case
      ↓
Determine Processing
      ↓
Assess Risk
      ↓
Determine Immediate
Containment
      ↓
Perform PIA
      ↓
Remediate
      ↓
Formal Approval

Potential escalation:

Production Privacy
Governance Bypass

Scenario 2 — AI Provider Changed Terms

Existing approved AI provider updates terms to allow:

Customer Content
for Model Improvement

Response

Identify Change
      ↓
Suspend / Limit
Affected Processing
if Required
      ↓
Open PIA Reassessment
      ↓
Legal Review
      ↓
Vendor Review
      ↓
Approve or Reject

Scenario 3 — DSR Deadline at Risk

Request due in:

5 Days

Vendor has not responded.

Response

Escalate Vendor
      ↓
Escalate Procurement
      ↓
Privacy Management
      ↓
Assess Applicable
Extension / Response Options
      ↓
Document Actions

Scenario 4 — Access Request Reveals Security Incident

During DSR discovery, analyst identifies:

Unauthorized Employee
Viewed Customer Record

Response

Do not treat this as only a DSR issue.

Open:

Security / Privacy
Incident Workflow

while continuing appropriate DSR handling.

Scenario 5 — Deletion Request Under Legal Hold

Customer requests deletion.

Relevant account records are subject to:

Active Litigation Hold

Response

Do Not Delete
Held Records
      ↓
Delete Other
Eligible Records
      ↓
Document Exception
      ↓
Explain Response
as Appropriate

Scenario 6 — Wrong Person’s Data Included

During DSAR QA, analyst discovers:

Another Customer's
Information

inside the response package.

Response

Stop Delivery
      ↓
Remove Information
      ↓
Revalidate Package
      ↓
Document QA Issue

If already disclosed, assess as a potential privacy incident.

Operational Metrics

Track both PIA and DSR operations.

PIA KPIs

PIA Screening Coverage

PIAs Completed
Before Launch

High-Risk PIAs
Completed

PIA Actions
Closed on Time

PIA KRIs

Projects Deployed
Without PIA

High Residual Risks
Without Approval

Overdue Critical
PIA Actions

DSR KPIs

Requests Completed
on Time

System Search Coverage

Vendor Completion

Deletion Completion

DSR KRIs

Overdue Requests

Incomplete Discovery

Unverified Responses

Incomplete Deletion

Vendor Delays

Operational Dashboard

Metric	Target
Projects Privacy-Screened	100%
Required PIAs Before Launch	100%
Critical PIA Actions Closed	100%
DSRs Within Applicable Deadline	100%
Required Systems Searched	100%
Required Vendor Actions Complete	100%
High Residual Risks Without Approval	0
DSRs Released Without Verification	0

Evidence Standards

Evidence should be:

Relevant

Current

Complete

Traceable

Reliable

Weak:

"Engineering
confirmed it."

Stronger:

Configuration

System Report

Test Result

Log

Approved Contract

Naming Convention

Use consistent case IDs.

PIA:

PIA-YYYY-####

Example:

PIA-2026-0042

DSR:

DSR-YYYY-####

Example:

DSR-2026-0157

Folder Structure

Recommended:

Privacy-Operations/
│
├── PIA/
│   ├── Screening/
│   ├── Active/
│   ├── Approved/
│   ├── Remediation/
│   └── Evidence/
│
└── DSR/
    ├── Intake/
    ├── Verification/
    ├── Discovery/
    ├── Exceptions/
    ├── Responses/
    └── Evidence/

PIA Quick Checklist

• Trigger recorded.

• project owner identified.

• screening completed.

• assessment level determined.

• personal data identified.

• data flow mapped.

• purpose assessed.

• minimization completed.

• privacy rights assessed.

• retention assessed.

• vendors assessed.

• transfers assessed.

• AI assessed where applicable.

• security controls reviewed.

• inherent risk scored.

• remediation tracked.

• residual risk assessed.

• approval obtained.

• evidence validated.

• reassessment triggers recorded.

DSR Quick Checklist

• request registered.

• original request retained.

• applicable right determined.

• deadline calculated.

• identity verified.

• identifiers mapped.

• systems identified.

• search completed.

• vendors contacted.

• exceptions reviewed.

• legal hold checked.

• fulfilment completed.

• AI data considered.

• QA completed.

• response approved.

• secure delivery completed.

• evidence retained.

• case formally closed.

Common Operational Mistakes

Mistake 1 — PIA Is Just a Form

The objective is privacy risk management, not form completion.

Mistake 2 — PIA Starts After Development

By then important architectural decisions may already be difficult to change.

Mistake 3 — Privacy Team Owns the Business Risk

Business owners must remain accountable for their processing activities.

Mistake 4 — Vendor Review Stops at Contract

Technical behavior and processing practices must also be understood.

Mistake 5 — AI Added Without PIA Reassessment

AI can materially change the purpose, data flow, vendor relationships, and privacy risk.

Mistake 6 — DSR Deadline Starts When Privacy Notices It

The request receipt date must be determined according to applicable requirements, not internal convenience.

Mistake 7 — Search Only CRM

Personal information usually exists across multiple systems.

Mistake 8 — Delete Everything

Legal retention and legal holds must be considered.

Mistake 9 — Keep Everything as an Exception

Exceptions must have a valid documented basis.

Mistake 10 — DSR Response Sent Without QA

One wrong record can turn a privacy-rights response into a data breach.

GRC Analyst Responsibilities

During PIA operations, a GRC analyst may:

• track privacy screening.

• coordinate evidence.

• maintain PIA registers.

• support risk assessment.

• track remediation.

• verify control evidence.

• maintain approval records.

• monitor overdue actions.

• prepare metrics.

During DSR operations, a GRC analyst may:

• maintain DSR registers.

• track deadlines.

• coordinate system owners.

• maintain search evidence.

• coordinate vendor tracking.

• maintain exception evidence.

• monitor completion.

• support QA.

• report KPIs and KRIs.

Privacy Operations Maturity

Level 1 — Reactive

Email

Spreadsheet

Manual Search

Level 2 — Documented

Procedures

Templates

Registers

Checklists

Level 3 — Governed

Workflow

Risk Scoring

Approval Gates

Vendor Integration

Evidence

Level 4 — Automated

Automated Screening

DSR Workflow

System Integrations

Deadline Alerts

Evidence Automation

Level 5 — Continuous Privacy Operations

Continuous Discovery

Privacy Engineering

Automated PIA Triggers

Automated DSR Fulfilment

Continuous Evidence

Continuous Assurance

Operational Mindset

For every new project ask:

What Personal Data?

Why?

Do We Need It?

Where Does It Go?

Who Receives It?

How Long?

Which Rights Apply?

What Could Go Wrong?

What Must Be Fixed
Before Launch?

Who Accepts
Residual Risk?

For every privacy request ask:

Who Is Asking?

Which Right?

Which Deadline?

Have We
Verified Them?

Where Is
Their Data?

Which Vendors
Have It?

What Can
We Fulfil?

What Must
Be Retained?

Has QA
Been Completed?

Can We Prove
What We Did?

That is the operational mindset behind repeatable enterprise privacy management.

Key Takeaways

• PIAs should be triggered by new or materially changed personal-data processing.

• Privacy screening determines the appropriate level of assessment.

• PIA work should happen before production whenever possible.

• Data purpose, necessity, flows, vendors, retention, rights, and security all form part of privacy-risk assessment.

• High-risk processing may require enhanced assessment or DPIA depending on applicable requirements.

• Privacy findings should be converted into tracked remediation actions.

• Residual risk should receive explicit approval.

• Material changes should trigger PIA reassessment.

• Data subject requests require centralized intake, verification, deadline management, discovery, fulfilment, QA, and evidence.

• Identity verification is essential before disclosing or changing personal information.

• Enterprise discovery must include cloud, SaaS, vendors, AI, archives, and other applicable repositories.

• Deletion requests require retention and legal-hold analysis.

• Access responses require careful protection of third-party information.

• AI introduces additional privacy-rights challenges involving prompts, vectors, memories, logs, and provider processing.

• Strong privacy operations depend on evidence, not verbal confirmation.

• GRC helps make privacy processes measurable, repeatable, traceable, and auditable.

What’s Next?

➡️ Next: Runbook 02 — Privacy Incident, Breach & Regulatory Response Management

In the next runbook, you will move from routine privacy operations into managing privacy incidents and personal-data breaches.

You will work through:

Privacy Incident
      ↓
Detection
      ↓
Containment
      ↓
Personal Data Assessment
      ↓
Affected Individuals
      ↓
Risk Assessment
      ↓
Applicable Regulations
      ↓
Notification Decision
      ↓
Regulator / Individual Response
      ↓
Evidence Preservation
      ↓
Root Cause
      ↓
Corrective Action
      ↓
Post-Incident Monitoring

You will build and operate practical artifacts including a Privacy Incident Register, Breach Assessment Matrix, Regulatory Notification Decision Log, Affected Individual Register, Evidence Pack, Root-Cause Analysis, Corrective Action Tracker, and Post-Incident Privacy Review.