08 Privacy Impact Assessments (PIA)

Organizations continuously introduce:

• New applications
• Cloud services
• SaaS platforms
• AI systems
• Mobile applications
• Analytics platforms
• Employee technologies
• Customer services
• Vendors
• New data-processing activities

Each change can introduce new privacy risks.

A mature privacy program therefore asks:

What privacy risks will this project create before we deploy it?

This is the purpose of a Privacy Impact Assessment (PIA).

Depending on the organization, jurisdiction, and applicable privacy framework, similar assessments may also be called:

Privacy Impact Assessment (PIA)

Data Protection Impact Assessment (DPIA)

Privacy Risk Assessment

Privacy Review

Privacy-by-Design Assessment

A practical lifecycle looks like:

New Project / Change
      ↓
Privacy Screening
      ↓
Personal Data Identified
      ↓
Processing Purpose
      ↓
Data Flow Mapping
      ↓
Privacy Requirements
      ↓
Risk Identification
      ↓
Risk Assessment
      ↓
Privacy Controls
      ↓
Residual Risk
      ↓
Approval
      ↓
Implementation
      ↓
Continuous Review

Learning Objectives

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

• Explain the purpose of a PIA.

• Understand when privacy assessments should be performed.

• Differentiate PIA screening from a full assessment.

• Understand the relationship between PIA and DPIA.

• Identify personal and sensitive data.

• Document processing purposes.

• Map personal-data flows.

• Identify privacy stakeholders.

• Assess collection and data minimization.

• Evaluate notice and transparency.

• Assess consent and other processing requirements.

• Review data sharing and third parties.

• Assess retention and deletion.

• Evaluate security safeguards.

• Identify privacy risks.

• Determine inherent and residual risk.

• Develop privacy remediation plans.

• Perform cloud, vendor, and AI privacy assessments.

• Establish PIA approval workflows.

• Maintain PIA evidence.

• Test the effectiveness of the PIA program.

1. What Is a Privacy Impact Assessment?

A Privacy Impact Assessment is a structured process used to:

Identify
      ↓
Analyze
      ↓
Evaluate
      ↓
Mitigate

privacy risks associated with a project, system, service, technology, or processing activity.

The goal is not simply:

Complete a Questionnaire

The goal is:

Identify privacy risk early enough to influence the design of the solution.

2. Why PIAs Matter

Without privacy review:

Business Idea
      ↓
Design
      ↓
Build
      ↓
Deploy
      ↓
Privacy Problem Discovered

At this point remediation can be:

Expensive

Complex

Disruptive

Legally Risky

A better model is:

Business Idea
      ↓
Privacy Assessment
      ↓
Privacy Requirements
      ↓
Secure / Privacy-Aware Design
      ↓
Build
      ↓
Deploy

3. Privacy by Design

PIAs support:

Privacy by Design

Instead of adding privacy controls after implementation:

Build
      ↓
Deploy
      ↓
Add Privacy

organizations integrate privacy into:

Requirements
      ↓
Architecture
      ↓
Development
      ↓
Testing
      ↓
Deployment
      ↓
Operations

4. PIA vs DPIA

Organizations may use the terms differently.

A PIA is generally a broad privacy-risk assessment.

A DPIA commonly refers to a more formal assessment required under certain privacy laws when processing is likely to create higher privacy risk.

Conceptually:

Privacy Screening
      ↓
Privacy Risk Identified
      ↓
PIA
      ↓
High-Risk Processing?
      ↓
Formal DPIA
Where Required

Do not assume that every PIA automatically satisfies every jurisdiction’s DPIA requirements.

5. When Should a PIA Be Performed?

Privacy assessments should be considered when introducing or significantly changing:

Applications

Websites

Mobile Apps

Cloud Platforms

SaaS Services

AI Systems

Analytics

Monitoring Technologies

Employee Systems

Customer Platforms

Vendors

Data-Sharing Arrangements

6. Example Triggers

Possible triggers include:

New Personal Data Collection

New Sensitive Data

New Processing Purpose

New Vendor

New Country

New Cloud Platform

New AI Capability

New Tracking Technology

New Automated Decision

New Data-Sharing Arrangement

Major System Change

7. PIA Trigger Matrix

Create:

01 PIA Trigger Matrix

Example:

Change	PIA Screening	Full PIA
New public webpage	Maybe	Usually not
New HR system	Yes	Likely
New customer CRM	Yes	Likely
New analytics tracking	Yes	Depends
New biometric system	Yes	High priority
New AI processing PI	Yes	Likely
Minor UI change	Maybe	Usually not

Actual requirements should follow organizational policy and applicable law.

8. Privacy Screening

Not every project requires the same level of assessment.

Organizations often begin with:

Privacy Screening Questionnaire

The screening determines whether:

No Further Review

Limited Privacy Review

Full PIA

DPIA / Enhanced Assessment

is required.

9. Build a Privacy Screening Questionnaire

Create:

02 PIA Screening Questionnaire

Ask:

Does the project collect personal data?

Does it process sensitive data?

Does it introduce a new purpose?

Does it use a new vendor?

Does data leave the country?

Does it use tracking?

Does it involve children?

Does it use biometrics?

Does it perform profiling?

Does it use AI?

Does it make automated decisions?

Does it monitor employees?

Does it process data at large scale?

10. Screening Workflow

Project Submitted
      ↓
Privacy Screening
      ↓
Personal Data?
      │
      ├── No → Document Decision
      │
      └── Yes
             ↓
Assess Risk Indicators
             ↓
Determine Assessment Level

11. Project Information

A PIA should begin by understanding:

What Is Being Built?

Why?

Who Will Use It?

Who Owns It?

Where Will It Operate?

What Data Will It Process?

12. PIA Register

Create:

03 PIA Register

Use:

PIA ID	Project	Owner	Data	Risk	Status	Approval

13. Business Owner

Every assessment should have a:

Business Owner

The Privacy or GRC team should not become the owner of the business processing activity.

The business owner remains accountable for:

Purpose

Business Need

Implementation

Risk Treatment

14. Privacy Stakeholders

A PIA may involve:

Business

Privacy

Legal

GRC

Cybersecurity

Architecture

Engineering

Cloud

Procurement

Vendor Management

Data Governance

15. Understand the Processing Purpose

One of the first questions is:

Why are we processing this information?

Example:

Customer Email Address

Purpose:

Account Authentication

Another purpose:

Marketing

These are not necessarily the same processing activity.

16. Purpose Register

Create:

04 Processing Purpose Register

Use:

Data	Purpose	User Group	System	Owner

17. Purpose Limitation

A fundamental privacy concept is:

Purpose Limitation

Data collected for one purpose should not automatically be reused for unrelated purposes without appropriate assessment.

Example:

Email Collected
for Account Security

does not automatically mean:

Use Email
for Marketing

18. Identify Personal Data

Determine whether the system processes information such as:

Name

Email

Phone Number

Address

Account ID

Device ID

IP Address

Location

Employee ID

Customer ID

depending on applicable privacy requirements.

19. Sensitive Data

Higher-risk information may include:

Health Information

Biometric Data

Financial Information

Authentication Information

Government Identifiers

Precise Location

Children's Data

depending on applicable laws and context.

20. Data Inventory

For the project, create:

05 PIA Data Inventory

Use:

Data Element	Category	Source	Purpose	Classification

21. Data Source

Determine where information originates.

Examples:

Customer

Employee

Mobile Device

Third Party

Public Source

Business Partner

Existing Database

AI System

22. Data Collection

Ask:

What Are We Collecting?

Why?

From Whom?

How?

Is It Necessary?

23. Data Minimization

One of the most valuable PIA questions is:

Do we actually need every data element being collected?

Example:

Application asks for:

Name
Email
Phone
Date of Birth
Home Address
Gender
Location

But business purpose requires only:

Name
Email

The remaining collection may create unnecessary privacy risk.

24. Data Minimization Review

Create:

06 Data Minimization Matrix

Use:

Data	Purpose	Necessary?	Justification	Action

25. Minimize Before Protecting

Security asks:

How Do We Protect
This Data?

Privacy should also ask:

Why Do We Have
This Data?

Sometimes the strongest privacy control is:

Do Not Collect It

26. Data Flow Mapping

A PIA should understand where personal information moves.

Example:

Customer
      ↓
Website
      ↓
API
      ↓
Application
      ↓
Database
      ↓
Analytics
      ↓
Cloud Storage

27. External Data Flow

Data may also move:

Application
      ↓
Payment Provider
      ↓
CRM
      ↓
Marketing Platform
      ↓
Analytics Provider

Each transfer creates additional privacy considerations.

28. Build a Data Flow Map

Create:

07 Privacy Data Flow Map

Document:

Source

Collection Point

Processing System

Storage

Transfer

Vendor

Country

Retention

Deletion

29. Why Data Flow Mapping Matters

Without mapping:

Customer Record

may appear to exist only in:

CRM

but actually exists in:

CRM

Marketing SaaS

Support Platform

Analytics

Data Lake

Backup

Logs

30. System Boundaries

Define:

Where Does
Our Environment End?

and:

Where Does
Third-Party Processing Begin?

31. Data Location

Identify:

Country

Region

Cloud Region

Data Center

Vendor Location

Backup Location

where applicable.

32. Cross-Border Transfers

If information moves between jurisdictions:

Country A
      ↓
Country B

the assessment should evaluate applicable:

Transfer Requirements

Contractual Requirements

Data Residency Requirements

Privacy Requirements

33. Cross-Border Transfer Register

Create:

08 Cross-Border Data Transfer Register

Use:

Data	Source	Destination	Vendor	Basis	Safeguard

34. Transparency

Individuals should generally receive appropriate information about processing.

Assess:

What Are We Telling
the Individual?

35. Privacy Notice

Review whether privacy notices explain relevant items such as:

What Data Is Collected

Why It Is Collected

How It Is Used

Who Receives It

Retention

Individual Rights

Contact Information

as required by the applicable framework.

36. Notice Review

Create:

09 Privacy Notice Review

Use:

Processing	Notice Required	Existing Notice	Gap	Action

37. Consent

Consent may be relevant for some processing activities.

But avoid the misconception:

Privacy
=
Consent Everywhere

Different processing may rely on different legal or organizational requirements.

38. Consent Assessment

Where consent is used, assess whether it is appropriately:

Presented

Recorded

Managed

Withdrawable

Auditable

39. Consent Evidence

Organizations may need evidence showing:

Who Consented?

To What?

When?

Which Version?

Was Consent Withdrawn?

40. Individual Rights

Depending on applicable privacy requirements, individuals may have rights involving:

Access

Correction

Deletion

Restriction

Objection

Portability

Consent Withdrawal

41. Rights Capability Assessment

Ask:

Can the system actually support the privacy rights promised by the organization?

Example:

Customer Requests Deletion
      ↓
Can We Find
All Their Data?

42. Privacy Rights Matrix

Create:

10 Privacy Rights Capability Matrix

Use:

System	Access	Correction	Delete	Export	Restrict

43. Retention Assessment

Every PIA should ask:

How Long
Will the Data
Be Kept?

44. Retention Mapping

Map:

Data Category
      ↓
Retention Schedule
      ↓
System Configuration
      ↓
Deletion

45. Retention Gap

Policy:

3 Years

Application:

Keep Forever

Potential privacy risk:

Over-Retention

46. Deletion Capability

Ask:

Can the Data
Actually Be Deleted?

Consider:

Primary Database

SaaS

Logs

Data Lake

Cache

Backups

Vendor Copies

47. Access Control

Privacy assessments should evaluate who can access personal information.

Personal Data
      ↓
Authorized Roles
      ↓
Least Privilege

48. Excessive Access

Example:

Customer Database
      ↓
All Employees

This may create unnecessary privacy and security risk.

49. Access Matrix

Create:

11 PIA Access Control Matrix

Use:

Data	Role	Access	Need	Approval

50. Authentication

For systems processing sensitive data, assess:

Authentication

MFA

Privileged Access

Session Management

Account Lifecycle

51. Encryption

Assess:

Encryption at Rest

Encryption in Transit

Key Management

Backup Encryption

52. Logging

Privacy-sensitive systems should generally provide appropriate auditability.

Examples:

Access Logs

Administrative Actions

Data Exports

Configuration Changes

Deletion Events

53. Logging Can Create Privacy Risk

Logs themselves may contain:

User IDs

Email Addresses

IP Addresses

Tokens

Request Data

Therefore:

Security Logging

must also consider:

Privacy

54. Masking

Where full data is unnecessary:

Sensitive Value
      ↓
Masked Value

Example:

XXXX XXXX XXXX 1234

55. Pseudonymization

Identifiers may be replaced with:

Pseudonymous Identifier

to reduce direct identifiability.

56. Anonymization

Where appropriate, information may be transformed so that individuals are no longer identifiable under the relevant standard.

Anonymization should not simply be assumed because obvious identifiers were removed.

57. Third-Party Processing

Many modern systems rely on vendors.

Example:

Organization
      ↓
SaaS Vendor
      ↓
Cloud Provider
      ↓
Subprocessor

58. Vendor Privacy Assessment

Create:

12 Vendor Privacy Assessment

Evaluate:

Data Processed

Purpose

Location

Subprocessors

Security

Retention

Deletion

Incident Notification

Contractual Terms

59. Data Processing Agreements

Where required, contractual arrangements may define:

Processing Instructions

Confidentiality

Security

Subprocessors

Incident Notification

Deletion

Return of Data

Audit Rights

60. Subprocessors

Do not stop at:

Primary Vendor

Ask:

Who Else
Processes Our Data?

61. Vendor Termination

The PIA should consider:

What Happens
When the Contract Ends?

Expected lifecycle:

Contract Ends
      ↓
Return Required Data
      ↓
Delete Remaining Data
      ↓
Address Backups
      ↓
Obtain Evidence

62. Cloud Privacy Assessment

Cloud systems may involve:

Shared Responsibility

Data Location

Encryption

Administrative Access

Logging

Backup

Replication

Subprocessors

63. Cloud Region

Example:

Customer Requirement
      ↓
Data Must Remain
in Approved Region

Verify:

Primary Storage

Replication

Backup

Disaster Recovery

Logging

64. SaaS Privacy Assessment

SaaS platforms require questions such as:

Where Is Data Stored?

Who Can Access It?

How Long Is It Retained?

Can It Be Deleted?

Is It Exportable?

Are Subprocessors Used?

Is Customer Data
Used for Other Purposes?

65. Cookies and Tracking

Web applications may use:

Cookies

Pixels

SDKs

Device Fingerprinting

Analytics

Advertising Technologies

These should be included in privacy assessment where applicable.

66. Tracking Inventory

Create:

13 Tracking Technology Register

Use:

Tracker	Purpose	Data	Provider	Duration	Control

67. Employee Monitoring

Employee technologies can create significant privacy considerations.

Examples:

Endpoint Monitoring

Email Monitoring

Location Tracking

CCTV

Productivity Monitoring

Access Monitoring

68. Monitoring Assessment

Ask:

Is Monitoring Necessary?

Is It Proportionate?

Are Employees Informed?

How Long Is Data Retained?

Who Can Access It?

69. Biometrics

Biometric processing may involve:

Face Recognition

Fingerprint

Voice

Iris

Behavioral Biometrics

Because of potential sensitivity, such systems may require enhanced privacy review.

70. Children’s Data

Processing information about children can introduce additional legal and privacy requirements.

The assessment should identify:

Age Group

Collection

Consent Requirements

Profiling

Advertising

Sharing

Retention

as applicable.

71. Location Data

Location information may reveal:

Home

Workplace

Travel

Behavior

Routine

Precise location may therefore create substantial privacy risk.

72. Profiling

Organizations may create profiles using:

Browsing Activity

Purchasing Behavior

Location

Preferences

Demographics

Interactions

Assess:

Purpose

Transparency

Accuracy

Fairness

Individual Impact

73. Automated Decision-Making

Example:

Personal Data
      ↓
Algorithm
      ↓
Decision
      ↓
Impact on Individual

Possible areas:

Hiring

Credit

Insurance

Fraud Detection

Access

Pricing

These activities may require enhanced review depending on applicable requirements.

74. AI Privacy Assessment

AI introduces additional considerations because systems may:

Ingest Personal Data

Generate Personal Data

Infer Attributes

Profile Individuals

Retain Prompts

Use Third-Party Models

Make Recommendations

Automate Decisions

75. Build an AI Privacy Assessment

Create:

14 AI Privacy Assessment

Evaluate:

Training Data

Input Data

Prompt Data

Output Data

Personal Data

Sensitive Data

Retention

Model Provider

Subprocessors

Data Location

Training Usage

Automated Decisions

Human Oversight

76. AI Training Data

Ask:

Where Did
Training Data
Come From?

and:

Are We Authorized
to Use It?

77. AI Prompts

Employees may submit:

Customer Information

Source Code

Contracts

Employee Data

Security Information

to AI platforms.

PIAs should consider this new data flow.

78. AI Output

AI-generated output may:

Expose Personal Information

Infer Sensitive Information

Contain Incorrect Personal Data

Create Profiling Risk

79. Human Oversight

For consequential automated decisions:

AI Recommendation
      ↓
Human Review
      ↓
Decision

may be an important control depending on the use case.

80. Privacy Risk Identification

Once processing is understood, identify:

Privacy Risk

A useful model is:

Processing Activity
      ↓
Privacy Threat
      ↓
Impact on Individual
      ↓
Risk

81. Privacy Risk Examples

Examples include:

Excessive Collection

Unauthorized Access

Unexpected Secondary Use

Over-Retention

Improper Sharing

Cross-Border Transfer

Lack of Transparency

Inability to Delete

Profiling

Re-identification

AI Inference

82. Privacy Risk Register

Create:

15 Privacy Risk Register

Use:

Risk	Data	Likelihood	Impact	Rating	Owner

83. Inherent Privacy Risk

Assess risk:

Before Controls

This is:

Inherent Risk

84. Control Assessment

Then evaluate controls such as:

Minimization

Encryption

Access Control

Masking

Retention

Notice

Consent

Contracts

Monitoring

85. Residual Privacy Risk

After controls:

Inherent Risk
      ↓
Controls
      ↓
Residual Risk

86. Risk Example

Processing:

Precise Location

Inherent risk:

High

Controls:

Opt-In

Minimization

Short Retention

Encryption

Restricted Access

Residual risk:

Medium

depending on the organization’s methodology.

87. Privacy Risk Matrix

Create:

16 Privacy Risk Matrix

Example:

Likelihood	Impact	Rating
Low	Low	Low
Medium	Medium	Medium
High	High	High
Likely	Severe	Critical

88. Risk Treatment

Privacy risks can be:

Avoided

Reduced

Transferred

Accepted

depending on organizational policy and legal requirements.

89. Avoid

Example:

Sensitive Data
Not Required
      ↓
Do Not Collect

90. Reduce

Example:

Precise Location
      ↓
Approximate Region

91. Transfer

Certain contractual and insurance mechanisms may transfer aspects of financial risk, but accountability and regulatory obligations cannot simply be transferred away.

92. Accept

Residual risk may sometimes be formally accepted by an authorized risk owner.

Acceptance should be:

Documented

Justified

Approved

Time-Bound
Where Appropriate

93. Privacy Control Matrix

Create:

17 Privacy Control Matrix

Use:

Risk	Control	Owner	Evidence	Status

94. Remediation Plan

If gaps are identified:

Gap
      ↓
Action
      ↓
Owner
      ↓
Due Date
      ↓
Evidence
      ↓
Validation

95. PIA Action Register

Create:

18 PIA Remediation Register

Use:

Action	Risk	Owner	Due	Status	Evidence

96. Example Finding

Project proposes:

Customer Analytics

and collects:

Exact Location

but only requires:

Country

Finding:

The proposed collection of precise location information exceeds the level of information required for the stated analytics purpose.

97. Correction

Change:

Exact GPS Location

to:

Country

98. Corrective Action

Update:

Requirements

Application

Data Model

Privacy Notice

Data Flow Map

99. Another Finding

SaaS provider retains:

Customer Data
Indefinitely

after account termination.

Risk:

Over-Retention
+
Third-Party Exposure

100. Treatment

Potential controls:

Contractual Retention Requirement

Automated Deletion

Deletion Verification

Vendor Evidence

101. PIA Approval

A PIA should reach a formal outcome.

Possible statuses:

Approved

Approved With Conditions

Remediation Required

Escalated

Rejected

102. Approval Register

Create:

19 PIA Approval Register

Use:

PIA	Risk	Decision	Approver	Conditions	Date

103. Conditional Approval

Example:

Project Approved

subject to:

Encryption Enabled

Retention Reduced

Vendor Contract Updated

Privacy Notice Published

104. High Residual Risk

Where significant residual risk remains:

Project Team
      ↓
Privacy
      ↓
Legal
      ↓
Risk Owner
      ↓
Executive / Governance Escalation

as required by policy and applicable law.

105. Evidence

A strong PIA should contain evidence supporting decisions.

Examples:

Architecture Diagram

Data Flow Diagram

Vendor Assessment

Contract

Privacy Notice

Retention Configuration

Security Architecture

Access Matrix

Risk Assessment

Approval

106. PIA Evidence Repository

Create:

20 PIA Evidence Repository

Suggested structure:

01 Screening

02 Project Description

03 Data Inventory

04 Data Flows

05 Privacy Requirements

06 Security Controls

07 Vendor Assessment

08 Risk Assessment

09 Remediation

10 Approval

11 Testing

107. Change Management

A PIA is not necessarily:

One and Done

Major changes should trigger reassessment.

108. Reassessment Triggers

Examples:

New Data

New Purpose

New Vendor

New Country

New AI Model

New Integration

New Tracking

Major Architecture Change

Security Incident

Regulatory Change

109. PIA Review Workflow

Approved PIA
      ↓
System Changes
      ↓
Material Change?
      │
      ├── No → Document
      │
      └── Yes
             ↓
Reassess

110. PIA Expiration

Organizations may establish:

Periodic Review

for higher-risk processing.

Example:

High-Risk PIA
      ↓
Annual Review

depending on policy.

111. PIA Program Testing

GRC should evaluate whether projects are actually entering the privacy-review process.

112. Test — Project Population

Population:

100 New Projects

PIA screened:

86

Potential finding:

14 Projects
Bypassed Privacy Screening

113. Screening Coverage

Calculate:

86
─── × 100
100

= 86%

114. Test — High-Risk Projects

Identify:

20 High-Risk Projects

Verify:

20 Full PIAs

Expected coverage:

100%

115. Test — Data Minimization

Sample:

25 PIAs

Verify evidence that:

Collected Data
Was Challenged
for Necessity

116. Test — Vendor Review

Sample PIAs involving:

Third-Party SaaS

Verify:

Vendor Assessment

Contract

Subprocessors

Location

Retention

Deletion

117. Test — Remediation

Sample:

30 PIA Findings

Verify:

Owner

Due Date

Completion

Evidence

Validation

118. Test — Approval

Verify projects did not move:

Production

before required:

Privacy Approval

119. PIA Compliance Gap Register

Create:

21 PIA Compliance Gap Register

Use:

Finding	Project	Risk	Severity	Owner	Due

120. Example Control Failure

Policy:

All Systems
Processing Personal Data
Require Privacy Screening

Population:

150 Systems

Screened:

120

Gap:

30 Systems

121. Root Cause Analysis

Why?

Teams Did Not
Submit PIA

Why?

Privacy Review
Was Manual

Why?

Project Workflow
Did Not Require It

Root cause:

Privacy assessment requirements were not integrated into the enterprise project lifecycle.

122. Correction

Assess Existing
30 Systems

123. Corrective Action

Integrate:

Project Intake
      ↓
Privacy Screening
      ↓
Mandatory Gate
      ↓
Deployment Approval

124. Shift-Left Privacy

Mature programs move privacy earlier.

Weak:

Production
      ↓
Privacy Review

Better:

Idea
      ↓
Design
      ↓
Privacy Review
      ↓
Build

125. SDLC Integration

PIA can integrate with:

Project Intake

Architecture Review

Security Review

Procurement

Vendor Onboarding

Cloud Approval

Change Management

AI Governance

126. Procurement Integration

Example:

Business Requests SaaS
      ↓
Procurement
      ↓
Security Review
      ↓
Privacy Screening
      ↓
Vendor Assessment
      ↓
Contract Review
      ↓
Approval

127. Privacy Engineering

Privacy requirements identified by the PIA can become:

Engineering Requirements

Examples:

Delete Data After X

Mask Field Y

Encrypt Database Z

Disable Tracking

Restrict Admin Access

Implement Export Function

128. PIA Dashboard

Track:

Metric	Target
Projects Privacy-Screened	100%
High-Risk Projects With PIA	100%
PIAs Approved Before Production	100%
Overdue PIA Actions	0
High Residual Risks Without Approval	0
Vendors Privacy-Assessed	100%
AI Projects Privacy-Assessed	100%

129. KPI — Screening Coverage

Projects Screened
──────────────── × 100
Applicable Projects

130. KPI — PIA Completion

Required PIAs Completed
────────────────────── × 100
PIAs Required

131. KPI — Remediation

PIA Actions
Closed on Time
────────────── × 100
PIA Actions Due

132. KRI — Production Without PIA

Systems Processing
Personal Data
Deployed Without
Required PIA

133. KRI — High Residual Risk

High Privacy Risks
Without Approved
Risk Treatment

134. KRI — Vendor Risk

Vendors Processing
Sensitive Data
Without Privacy
Assessment

135. KRI — AI Risk

AI Systems
Processing Personal Data
Without Privacy Review

136. Practical Activity — CloudPay Customer Portal

Use fictional organization:

CloudPay

CloudPay plans a new:

Customer Portal

collecting:

Name

Email

Phone

Address

Payment Information

Login Information

Device Information

Perform:

Privacy Screening

Data Inventory

Data Flow

Minimization Review

Retention Review

Security Review

Risk Assessment

137. Practical Activity — Data Minimization

The portal requests:

Date of Birth

but the business says:

We Might
Need It Later

Determine whether this is sufficient justification.

Document:

Purpose

Necessity

Risk

Recommendation

138. Practical Activity — SaaS Vendor

CloudPay wants a marketing platform processing:

Customer Name

Email

Purchase History

Behavior

Assess:

Purpose

Location

Retention

Subprocessors

Deletion

Security

Contract

Cross-Border Transfer

139. Practical Activity — AI Support Assistant

CloudPay deploys:

AI Customer
Support Assistant

The system processes:

Customer Questions

Account Information

Support History

Order Information

Assess:

Model Provider

Prompt Retention

Training Usage

Data Location

Sensitive Data

Output Risk

Human Escalation

Deletion

140. Practical Activity — Employee Monitoring

CloudPay proposes software collecting:

Application Usage

Web Activity

Screenshots

Location

Productivity Scores

Perform a privacy-risk assessment focusing on:

Necessity

Proportionality

Transparency

Minimization

Retention

Access

Employee Impact

Privacy Impact Assessment Operational Checklist

Project Information

• project identified.

• business owner identified.

• system owner identified.

• purpose documented.

• processing activities identified.

Screening

• privacy screening completed.

• personal data identified.

• sensitive data identified.

• high-risk indicators evaluated.

• required assessment level determined.

Data

• data elements inventoried.

• data sources identified.

• classifications assigned.

• data minimization assessed.

• unnecessary collection removed.

Data Flow

• collection points mapped.

• storage locations mapped.

• internal transfers mapped.

• external transfers mapped.

• vendors mapped.

• subprocessors considered.

• backups considered.

Privacy Requirements

• processing purpose documented.

• transparency requirements reviewed.

• consent assessed where applicable.

• individual rights assessed.

• retention mapped.

• deletion capability assessed.

Security

• access controls assessed.

• authentication assessed.

• encryption assessed.

• logging assessed.

• masking considered.

• pseudonymization considered.

Vendors

• vendor privacy review completed.

• data-processing terms reviewed.

• subprocessors identified.

• data location reviewed.

• retention reviewed.

• deletion reviewed.

Cloud

• cloud region identified.

• replication considered.

• backups considered.

• administrative access reviewed.

• shared responsibility understood.

AI

• AI processing identified.

• training data assessed.

• prompt data assessed.

• output risks assessed.

• model provider assessed.

• provider training usage assessed.

• human oversight considered.

Risk

• privacy risks identified.

• inherent risk assessed.

• controls identified.

• residual risk assessed.

• risk owner assigned.

Remediation

• actions documented.

• owners assigned.

• due dates established.

• evidence collected.

• remediation validated.

Approval

• Privacy approval obtained.

• Legal consulted where required.

• high residual risk escalated.

• conditions documented.

• production approval verified.

Monitoring

• reassessment triggers defined.

• material changes monitored.

• PIA actions tracked.

• periodic review performed where appropriate.

141. Common PIA Mistakes

Mistake 1 — PIA After Deployment

Build
      ↓
Deploy
      ↓
Privacy Review

Privacy should be integrated earlier.

Mistake 2 — PIA as a Questionnaire

Completing:

50 Questions

does not automatically mean:

Privacy Risk Managed

Mistake 3 — No Data Flow

Teams know:

What Data

but not:

Where It Goes

Mistake 4 — No Data Minimization

Every requested field is automatically accepted.

Mistake 5 — Ignoring Vendors

Privacy analysis stops at the organization’s application boundary.

Mistake 6 — Ignoring Backups

Deletion may occur in production while data survives elsewhere.

Mistake 7 — No Remediation Tracking

PIA identifies risks but nobody tracks closure.

Mistake 8 — No Reassessment

The system changes significantly while the original PIA remains unchanged.

Mistake 9 — No Technical Validation

Teams state:

Data Deleted
After 30 Days

but nobody verifies the configuration.

Mistake 10 — AI Added Without Reassessment

Existing system:

Customer Support Platform

later gains:

AI Assistant

but privacy assessment is never updated.

142. Weak PIA Program

Questionnaire
      ↓
Privacy Team
      ↓
Approval Email

143. Strong PIA Program

Project Intake
      ↓
Automated Screening
      ↓
Data Inventory
      ↓
Data Flow
      ↓
Privacy Requirements
      ↓
Risk Assessment
      ↓
Engineering Controls
      ↓
Vendor Review
      ↓
Remediation
      ↓
Approval Gate
      ↓
Deployment
      ↓
Continuous Reassessment

144. GRC Analyst Responsibilities

A GRC professional supporting PIAs may:

• maintain PIA procedures.

• manage privacy screening.

• identify high-risk projects.

• coordinate business owners.

• build data inventories.

• review data flows.

• assess data minimization.

• review retention.

• coordinate security reviews.

• assess vendor privacy risk.

• review cloud processing.

• assess AI privacy risks.

• maintain privacy-risk registers.

• track remediation.

• maintain approval evidence.

• test PIA program effectiveness.

• track PIA KPIs and KRIs.

• prepare evidence for internal and external assessments.

GRC connects:

Privacy

Legal

Cybersecurity

Cloud

Engineering

Procurement

Vendor Management

Data Governance

AI Governance

Business Owners

Internal Audit

145. PIA Maturity Model

Level 1 — Reactive

Privacy Review
After Problems

Level 2 — Documented

PIA Template

Manual Screening

Privacy Approval

Level 3 — Governed

PIA Register

Risk Assessment

Vendor Review

Remediation Tracking

Approval Gate

Level 4 — Integrated

SDLC Integration

Procurement Integration

Cloud Integration

AI Governance

Automated Workflow

Level 5 — Continuous Privacy Governance

Continuous Discovery

Automated Screening

Privacy Engineering

Continuous Monitoring

Automated Evidence

146. Privacy Assessment Mindset

For every new project ask:

What Are
We Building?

Why?

What Personal Data
Will We Process?

Do We Need
All of It?

Where Does
It Come From?

Where Does
It Go?

Where Is
It Stored?

Who Can
Access It?

Which Vendors
Receive It?

Which Countries
Receive It?

How Long
Is It Retained?

Can We
Delete It?

Are Individuals
Informed?

Can Their Rights
Be Supported?

Is AI
Involved?

What Could
Go Wrong?

What Controls
Reduce the Risk?

Who Owns
Residual Risk?

Can We Prove
the Controls Work?

That is the practical mindset behind a Privacy Impact Assessment.

Key Takeaways

• PIAs identify and reduce privacy risk before systems and processing activities are deployed.

• Privacy assessment should begin early in the project lifecycle.

• Screening helps determine the appropriate level of privacy review.

• PIA and DPIA requirements may differ depending on the applicable privacy framework.

• Every assessment should clearly document the processing purpose.

• Data minimization is one of the strongest privacy controls.

• Data-flow mapping reveals where personal information actually travels.

• Cloud, SaaS, third parties, backups, and subprocessors must be considered.

• Retention and deletion capabilities should be evaluated during design.

• Security controls form an important part of privacy risk management.

• Privacy risk should be assessed before and after controls.

• High residual risks should follow appropriate escalation and approval processes.

• AI systems require additional assessment of prompts, models, training data, outputs, retention, and automated decisions.

• PIA findings require owners, due dates, evidence, and validation.

• Material system changes should trigger reassessment.

• Mature organizations integrate privacy assessment into SDLC, procurement, cloud governance, and AI governance.

Knowledge Check

Before continuing, make sure you can answer:

1. What is a Privacy Impact Assessment?

2. Why should PIAs happen early?

3. What is Privacy by Design?

4. What is the difference between PIA screening and a full PIA?

5. How can a PIA differ from a DPIA?

6. What events should trigger privacy screening?

7. Why must the processing purpose be documented?

8. What is data minimization?

9. Why is data-flow mapping important?

10. What should be reviewed for cross-border transfers?

11. Why should retention be included in a PIA?

12. Why must deletion capability be assessed?

13. What privacy risks can vendors introduce?

14. Why should subprocessors be identified?

15. What additional risks can AI introduce?

16. What is inherent privacy risk?

17. What is residual privacy risk?

18. How should PIA remediation be managed?

19. What should happen when significant residual risk remains?

20. When should an existing PIA be reassessed?

What’s Next?

➡️ Next: 09 — Data Subject Rights & Requests

In the next lesson, you will move from assessing privacy risk before and during processing to managing the operational requests individuals may make regarding their personal information.

You will examine:

Data Subject Request
      ↓
Request Intake
      ↓
Identity Verification
      ↓
Request Classification
      ↓
Data Discovery
      ↓
Legal / Privacy Review
      ↓
Access / Correction / Deletion
      ↓
Exceptions
      ↓
Third-Party Coordination
      ↓
Response
      ↓
Evidence
      ↓
Metrics & Monitoring

You will also build practical artifacts including a Data Subject Request Procedure, Request Intake Form, Identity Verification Checklist, Data Discovery Checklist, DSAR Register, Deletion Assessment Matrix, Exception Register, Third-Party Request Tracker, Response Evidence Pack, and Privacy Rights Dashboard.