01 Privacy Fundamentals

Privacy has become a core component of modern Governance, Risk & Compliance (GRC).

Organizations collect and process enormous amounts of information about:

Customers

Employees

Applicants

Contractors

Partners

Website Visitors

Students

Patients

Consumers

This information can create significant business value.

It can also create significant risk.

A privacy program therefore asks:

What personal data does the organization collect, why does it need it, how is it used, who can access it, where does it go, how long is it retained, and what protections exist throughout its lifecycle?

A practical privacy lifecycle looks like:

Personal Data
      ↓
Collection
      ↓
Purpose
      ↓
Lawful Processing
      ↓
Use
      ↓
Sharing
      ↓
Protection
      ↓
Retention
      ↓
Individual Rights
      ↓
Deletion / Disposal
      ↓
Accountability

Privacy is not simply:

Keeping Information Secret

It is about governing how information about individuals is collected and used throughout its lifecycle.

Learning Objectives

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

• Explain privacy and data protection.

• Distinguish privacy from information security.

• Define personal data.

• Identify sensitive and special-category information.

• Understand data subjects.

• Understand controllers and processors.

• Explain common privacy principles.

• Understand lawful processing.

• Understand consent.

• Explain transparency requirements.

• Apply purpose limitation.

• Apply data minimization.

• Understand data accuracy.

• Understand retention and storage limitation.

• Understand confidentiality and security.

• Explain privacy accountability.

• Understand privacy by design and by default.

• Understand data subject rights.

• Understand privacy notices.

• Understand cross-border data processing.

• Identify privacy risks.

• Understand privacy governance.

• Identify common enterprise privacy artifacts.

1. What Is Privacy?

Privacy concerns an individual’s ability to understand and influence how information about them is:

Collected

Used

Shared

Stored

Retained

Deleted

A simple privacy question is:

What is the organization doing with information about people?

2. What Is Data Protection?

Data protection concerns the controls used to govern and safeguard personal data.

Examples include:

Policies

Access Controls

Encryption

Retention Rules

Privacy Notices

Contracts

Deletion Processes

Incident Response

Privacy and data protection overlap heavily.

3. Privacy vs Security

These concepts are related but not identical.

Security asks:

Is the information protected from unauthorized access or modification?

Privacy asks:

Should we collect and use this information in this way in the first place?

4. Security Without Privacy

Consider:

Customer Database
      ↓
Strong Encryption
      ↓
Strong MFA
      ↓
Secure Infrastructure

Technically:

Highly Secure

But suppose the organization collected:

Customer Location

Contacts

Browsing History

without a valid reason or proper transparency.

The system may be secure but still create:

Privacy Risk

5. Privacy Without Security

Likewise, an organization may have:

Privacy Policy

Consent Notice

Retention Policy

but weak security.

If attackers steal the data:

Privacy Program
      ↓
Still Fails

Strong programs need:

Privacy Governance
+
Security

6. What Is Personal Data?

Personal data is broadly information relating to an identified or identifiable individual.

Examples may include:

Name

Email Address

Phone Number

Home Address

Employee ID

Customer ID

IP Address

Device Identifier

Location Information

The exact legal definition varies by jurisdiction.

7. Direct Identification

Some information identifies a person directly.

Examples:

Full Name

Government Identifier

Personal Email

Phone Number

8. Indirect Identification

Information may also identify someone when combined with other information.

Example:

Job Title
+
Office Location
+
Age
+
Department

may make one employee identifiable.

9. Online Identifiers

Modern privacy programs should consider:

IP Addresses

Cookie IDs

Advertising IDs

Device IDs

Account Identifiers

depending on applicable law and context.

10. Sensitive Personal Data

Certain information creates higher privacy risk.

Examples may include:

Health Data

Biometric Data

Financial Data

Precise Location

Government Identifiers

Different privacy laws use different categories and terminology.

11. Special Categories

Under some legal frameworks, heightened protections may apply to information relating to areas such as:

Health

Biometrics

Genetics

Political Views

Religion

Sexual Orientation

Exact categories depend on applicable law.

12. Why Classification Matters

Compare:

Corporate Newsletter Preference

with:

Medical Diagnosis

Both may involve personal information.

But risk is very different.

Therefore privacy programs classify data based on:

Sensitivity

Legal Requirement

Business Impact

Potential Harm

13. Data Subject

A data subject is the person to whom personal data relates.

Examples:

Customer

Employee

Applicant

Website Visitor

Student

Patient

14. Business Example

CloudShop stores:

Alice Smith

alice@example.com

Shipping Address

Purchase History

Alice is:

The Data Subject

15. Controller

A controller generally determines the purposes and means of processing personal data under frameworks using this terminology.

Example:

CloudShop

decides:

Which Customer Data to Collect

Why It Is Collected

How It Will Be Used

CloudShop may therefore operate as a controller for that processing.

16. Processor

A processor generally processes personal data on behalf of a controller.

Example:

CloudShop
      ↓
Cloud CRM Provider

The CRM provider processes customer information on CloudShop’s behalf.

17. Controller-Processor Relationship

A common model:

Data Subject
      ↓
Controller
      ↓
Processor
      ↓
Subprocessor

18. Subprocessor

A processor may engage another organization.

Example:

CloudShop
      ↓
CRM Provider
      ↓
Cloud Hosting Provider

The cloud hosting provider may be a:

Subprocessor

depending on the legal relationship.

19. Why Roles Matter

Responsibilities may differ for:

Controller

Processor

Subprocessor

These distinctions affect areas such as:

Contracts

Transparency

Security

Incident Notification

Data Subject Requests

20. What Is Processing?

Processing is generally interpreted broadly.

Examples:

Collecting

Recording

Organizing

Storing

Viewing

Using

Sharing

Modifying

Deleting

Therefore:

Simply Storing Personal Data

is typically a form of processing.

21. Personal Data Lifecycle

A useful enterprise model:

Collect
      ↓
Use
      ↓
Store
      ↓
Share
      ↓
Archive
      ↓
Delete

Privacy controls should exist at every stage.

22. Privacy Principles

While specific laws differ, many modern privacy frameworks share common principles.

A practical enterprise model includes:

Lawfulness

Transparency

Purpose Limitation

Data Minimization

Accuracy

Storage Limitation

Security

Accountability

23. Principle 1 — Lawfulness

Organizations should have a legitimate and legally permitted basis for processing personal data.

The exact lawful bases depend on the applicable privacy law.

24. Processing Should Have a Reason

Weak:

We Collect It
Because We Might Need It

Strong:

Defined Business Purpose
      +
Applicable Legal Basis

25. Lawful Processing Examples

Depending on jurisdiction, processing may be supported by concepts such as:

Consent

Contract

Legal Obligation

Legitimate Interests

Public Interest

Vital Interests

Not every privacy framework uses the same terminology.

26. Lawful Basis Register

Organizations may maintain:

01 Lawful Processing Register

Use:

Processing Activity	Purpose	Personal Data	Legal Basis	Owner

27. Principle 2 — Transparency

Individuals should understand:

What Data Is Collected

Why

How It Is Used

Who Receives It

How Long It Is Kept

What Rights They Have

28. Privacy Notice

Transparency is often delivered through:

Privacy Notice

or:

Privacy Statement

29. Weak Privacy Notice

We may use your information for business purposes.

This provides very little meaningful information.

30. Stronger Transparency

A better notice explains:

Data Categories

Purposes

Sharing

Retention

Rights

Contact Details

31. Principle 3 — Purpose Limitation

Personal data should be collected for:

Defined Purposes

and not casually reused for unrelated purposes.

32. Purpose Limitation Example

Customer provides:

Phone Number

for:

Delivery Notification

Later marketing asks:

Can We Use It
for Promotional Calls?

That new purpose requires privacy analysis.

33. Purpose Register

Create:

02 Processing Purpose Register

Use:

Data	Original Purpose	New Purpose	Compatible?	Review

34. Principle 4 — Data Minimization

Collect only information reasonably necessary for the defined purpose.

Weak:

Newsletter Signup

Name

Email

Date of Birth

Passport Number

Home Address

Strong:

Newsletter Signup

Email

if that is all the business actually needs.

35. Why Minimization Matters

Less data means:

Less Privacy Risk

Less Breach Impact

Less Storage

Less Compliance Burden

36. Data Minimization Question

For every data element ask:

Why do we need this?

If nobody can provide a strong answer:

Do Not Collect It

or reassess its necessity.

37. Principle 5 — Accuracy

Organizations should take reasonable steps to keep personal data:

Accurate

Relevant

Up to Date

where required for its purpose.

38. Accuracy Risk

Suppose an employee’s outdated address causes:

Tax Documents

to be mailed to:

Wrong Person

Incorrect data can itself create privacy risk.

39. Accuracy Controls

Examples:

Self-Service Updates

Validation

Periodic Review

Correction Requests

40. Principle 6 — Storage Limitation

Organizations should not retain personal data indefinitely without a valid reason.

Weak:

Keep Everything Forever

Stronger:

Purpose
      ↓
Retention Period
      ↓
Deletion / Archive

41. Retention Example

Applicant data:

Collected
      ↓
Recruitment
      ↓
Candidate Not Selected

Question:

How Long Should
the Data Remain?

The answer should be governed by:

Legal Requirements

Business Need

Privacy Risk

42. Retention Schedule

Create:

03 Personal Data Retention Schedule

Use:

Data Category	Purpose	Retention	Trigger	Disposal

43. Principle 7 — Security

Personal data should be protected against risks such as:

Unauthorized Access

Loss

Disclosure

Modification

Destruction

44. Security Controls

Examples:

Encryption

MFA

Access Control

Logging

Backups

Data Loss Prevention

Network Security

45. Confidentiality

Only authorized parties should access personal information.

Example:

Employee Salary Data
      ↓
HR + Authorized Management

not:

All Employees

46. Integrity

Personal information should not be improperly altered.

Example:

Bank Account Details

require strong protection against unauthorized changes.

47. Availability

Privacy also requires appropriate availability.

Example:

A person requests:

Copy of Their Data

but the organization cannot locate it.

Poor data governance may prevent fulfillment.

48. Principle 8 — Accountability

The organization should be able to demonstrate that privacy obligations are actually being managed.

Accountability means:

We Say We Protect Privacy

becomes:

We Can Prove
How Privacy Is Governed

49. Accountability Evidence

Examples:

Privacy Policies

Processing Inventory

PIAs / DPIAs

Training

Contracts

Retention Records

Rights Request Records

Incident Records

Audit Evidence

50. Privacy Accountability Model

Requirement
      ↓
Policy
      ↓
Control
      ↓
Owner
      ↓
Evidence
      ↓
Monitoring

51. Consent

Consent is one possible legal mechanism for processing under certain privacy laws.

Valid consent generally should not be treated as:

A Checkbox That Solves Everything

52. Consent Characteristics

Depending on the applicable law, effective consent may need to be:

Informed

Specific

Freely Given

Unambiguous

Withdrawable

53. Bundled Consent

Weak:

Create Account
+
Receive Marketing
+
Share With Partners
=
One Required Checkbox

This may create privacy concerns.

54. Granular Consent

Stronger design:

Account Processing
→ Required for Service

Marketing Email
→ Separate Choice

Partner Marketing
→ Separate Choice

where consent is the applicable mechanism.

55. Consent Withdrawal

If processing depends on consent:

Give Consent
      ↓
Use Data

the organization may also need a mechanism to:

Withdraw Consent

where applicable.

56. Consent Register

Create:

04 Consent Management Register

Use:

Individual	Purpose	Consent Date	Source	Withdrawn

57. Privacy Notice vs Consent

These are different concepts.

Privacy notice:

Provides Information

Consent:

May Provide Authorization
for Specific Processing

where applicable.

58. Data Subject Rights

Modern privacy frameworks often give individuals rights relating to their personal data.

Common examples include:

Access

Correction

Deletion

Restriction

Objection

Portability

Consent Withdrawal

Exact rights vary by jurisdiction.

59. Right of Access

An individual may ask:

What personal data do you hold about me?

The organization should be able to:

Locate

Review

Validate

Provide

the relevant information under applicable requirements.

60. Right to Correction

Example:

Customer Address
Incorrect

The individual requests:

Correction

61. Right to Deletion

Depending on applicable law and circumstances, individuals may request deletion.

But deletion is not always absolute.

Data may sometimes need to remain because of:

Legal Obligation

Fraud Prevention

Contractual Requirement

Litigation Hold

62. Data Subject Request Workflow

A practical workflow:

Request
      ↓
Identity Verification
      ↓
Request Classification
      ↓
System Search
      ↓
Legal Review if Needed
      ↓
Fulfillment
      ↓
Response
      ↓
Evidence

63. Data Subject Request Register

Create:

05 Data Subject Rights Register

Use:

Request	Right	Received	Due	Status	Owner

64. Identity Verification

Before releasing personal data:

Verify Requester Identity

Otherwise:

Privacy Request
      ↓
Could Become
Privacy Breach

65. Example

Attacker submits:

Give Me All Data
for alice@example.com

The organization should not simply email the information.

66. Privacy by Design

Privacy should be considered when systems are:

Designed

Built

Purchased

Changed

not added after deployment.

67. Weak Model

Build Application
      ↓
Launch
      ↓
Privacy Team Reviews Later

68. Strong Model

Business Idea
      ↓
Data Requirements
      ↓
Privacy Review
      ↓
Architecture
      ↓
Development
      ↓
Launch

69. Privacy by Default

Default configurations should favor the minimum personal-data use necessary for the intended service.

Example:

Weak default:

Location Tracking:
ON

even when not needed.

Stronger:

Location Tracking:
OFF

until legitimately enabled.

70. Privacy Impact Assessment

Organizations may use:

Privacy Impact Assessment

or:

PIA

to identify privacy risks before implementation.

71. Higher-Risk Processing

Certain frameworks may require more formal assessments for high-risk processing, such as:

Large-Scale Sensitive Data

Systematic Monitoring

Biometrics

Profiling

New High-Risk Technology

72. PIA Questions

Ask:

What Data?

Whose Data?

Why?

How Much?

Where?

Who Receives It?

How Long?

What Could Go Wrong?

What Controls Exist?

73. Processing Inventory

A foundational privacy artifact is:

Record of Processing Activities

or similar processing inventory.

Create:

06 Personal Data Processing Inventory

Use:

Process	Data Subjects	Data	Purpose	Systems	Providers

74. Example Processing Activity

Process:
Employee Payroll

Data subjects:

Employees

Data:

Name

Address

Bank Details

Tax Information

Purpose:

Salary Payment

75. Data Inventory vs Processing Inventory

Data inventory asks:

What Data Exists?

Processing inventory asks:

Why and How
Is the Data Used?

Both are useful.

76. Data Flow Mapping

Privacy teams should understand:

Source
      ↓
System
      ↓
Internal Team
      ↓
Vendor
      ↓
Storage
      ↓
Deletion

77. Example Customer Flow

Customer
      ↓
Website
      ↓
CRM
      ↓
Marketing Platform
      ↓
Cloud Hosting

Every transfer should have a business and privacy rationale.

78. Third-Party Privacy Risk

Organizations often share personal data with:

Cloud Providers

CRM Platforms

Payroll Providers

Analytics Providers

Marketing Platforms

79. Vendor Questions

Ask:

What Personal Data?

Why Is It Shared?

Where Is It Processed?

How Long Is It Retained?

Who Are the Subprocessors?

How Is It Protected?

80. Data Processing Agreement

Controller-processor arrangements may require contractual privacy protections.

A:

Data Processing Agreement

or:

DPA

may define responsibilities.

81. Contract Areas

Common clauses address:

Processing Instructions

Security

Confidentiality

Subprocessors

Incident Notification

Deletion

Audit Rights

depending on applicable law.

82. Cross-Border Processing

Personal data may move between jurisdictions.

Example:

Customer in EU
      ↓
Application in India
      ↓
Cloud Storage in USA

This creates:

Cross-Border Data Transfer

83. Why Cross-Border Transfers Matter

Different jurisdictions may impose requirements relating to:

Transfer Mechanisms

Localization

Contracts

Government Access

Risk Assessments

84. Cross-Border Register

Create:

07 Cross-Border Data Transfer Register

Use:

Data	Origin	Destination	Provider	Transfer Mechanism

85. Data Localization

Some jurisdictions may require certain information to:

Remain Within a Country

or impose additional conditions on transfer.

Privacy teams should understand applicable requirements rather than assume all data can move globally.

86. Data Retention

Every important personal-data category should ideally have:

Retention Rule

Trigger

Deletion Method

87. Retention Trigger

Examples:

Account Closure

Employee Termination

Contract End

Transaction Date

Application Completion

88. Deletion

Deletion should address copies across:

Production

Backups

Archives

SaaS Platforms

Data Lakes

according to technical and legal requirements.

89. Data Disposal

Secure disposal may include:

Secure Deletion

Cryptographic Erasure

Media Destruction

depending on the technology.

90. Privacy Incident

A privacy incident may include:

Unauthorized Disclosure

Wrong Recipient

Lost Laptop

Misconfigured Storage

Unauthorized Internal Access

Accidental Publication

91. Privacy Breach vs Cyberattack

Not every privacy breach involves hackers.

Example:

Employee Emails Payroll Spreadsheet
to Wrong Recipient

This may still constitute:

Personal Data Breach

under applicable law.

92. Privacy Incident Workflow

Incident Identified
      ↓
Contain
      ↓
Determine Data
      ↓
Determine Individuals
      ↓
Assess Risk
      ↓
Legal / Regulatory Review
      ↓
Notification Decision
      ↓
Remediation

93. Privacy Breach Register

Create:

08 Privacy Incident & Breach Register

Use:

Incident	Data	Individuals	Risk	Notification	Status

94. Privacy Risk

Privacy risk focuses heavily on potential harm to individuals.

Examples:

Identity Theft

Financial Loss

Discrimination

Embarrassment

Loss of Confidentiality

Unauthorized Profiling

95. Cyber Risk vs Privacy Risk

Cybersecurity may ask:

What Is the Impact
to the Organization?

Privacy also asks:

What Is the Impact
to the Individual?

96. Privacy Risk Assessment

Evaluate:

Type of Data

Volume

Sensitivity

Individuals

Purpose

Access

Third Parties

Retention

Security

97. Privacy Risk Matrix

Create:

09 Privacy Risk Register

Use:

Risk	Processing	Likelihood	Impact	Controls	Owner

98. Example Privacy Risk

Processing:

Employee Biometric Attendance

Risk:

Biometric Template Exposure

Impact:

High

because biometric identifiers cannot be changed like passwords.

99. Employee Privacy

Privacy programs must cover:

Employees

not only customers.

Employee information may include:

Salary

Performance

Health Records

Background Screening

Location

Monitoring Data

100. Monitoring Employees

Technologies such as:

EDR

Email Monitoring

DLP

CCTV

Location Tracking

may serve legitimate security purposes but can also create privacy considerations.

101. Privacy and Security Monitoring Balance

Organizations should consider:

Security Need

Proportionality

Transparency

Data Minimization

Retention

102. Children’s Data

Processing information relating to children may trigger additional protections under applicable privacy laws.

This should receive:

Higher Privacy Scrutiny

103. Artificial Intelligence and Privacy

AI systems can introduce privacy risks through:

Training Data

Prompt Data

Profiling

Automated Decisions

Data Inference

Model Retention

104. AI Example

Employee enters:

Customer Passport

Medical Information

Contract Details

into a public AI service.

Potential concerns:

Unauthorized Disclosure

Unapproved Processing

Cross-Border Transfer

Retention

Third-Party Risk

105. AI Privacy Governance

Organizations should define:

Approved AI Platforms

Permitted Data

Restricted Data

Retention Rules

Vendor Controls

106. Cookies and Tracking

Websites may use:

Essential Cookies

Analytics Cookies

Advertising Cookies

Preference Cookies

Depending on jurisdiction, consent and transparency obligations may differ.

107. Cookie Inventory

Create:

10 Website Tracking Inventory

Use:

Tracker	Purpose	Provider	Data	Consent Requirement

108. Shadow Data

Privacy teams should watch for personal information stored outside approved systems.

Examples:

Excel Files

Email

Shared Drives

Chat

Developer Logs

Personal Devices

109. Data Discovery

Privacy governance benefits from knowing:

Where Personal Data Actually Exists

not only where policies say it exists.

110. Data Classification

Privacy should integrate with enterprise classification.

Example:

Public

Internal

Confidential

Restricted

Sensitive personal information may receive:

Restricted

classification.

111. Privacy Policy

An enterprise privacy policy should define:

Purpose

Principles

Roles

Processing Rules

Rights

Security

Third Parties

Retention

Incident Management

112. Build Privacy Governance Artifact Set

A mature program may maintain:

Privacy Policy

Processing Inventory

Data Flow Maps

Privacy Notices

Consent Register

Rights Register

Retention Schedule

PIA Register

Incident Register

Third-Party Register

113. Privacy Governance Roles

Potential participants include:

Privacy Officer

DPO Where Applicable

GRC

Legal

Security

HR

Marketing

Product

Procurement

114. Data Protection Officer

Some legal frameworks require or recognize a:

Data Protection Officer

or:

DPO

under specified circumstances.

Responsibilities may include:

Advisory

Monitoring

Training

Regulatory Interaction

Privacy Governance

115. Privacy Owner

Every major processing activity should have a:

Business Owner

Privacy is not only the responsibility of:

Legal

or:

Privacy Team

116. Privacy Governance Model

Board / Executive Oversight
      ↓
Privacy / Legal
      ↓
GRC
      ↓
Business Owners
      ↓
Technology Teams
      ↓
Operational Controls

117. Privacy Training

Employees should understand:

Personal Data

Sensitive Data

Approved Sharing

Privacy Incidents

Data Subject Requests

Retention

118. Developer Privacy Training

Developers should understand:

Data Minimization

Privacy by Design

Secure Logging

Retention

Testing Data

119. Marketing Privacy Training

Marketing should understand:

Consent

Tracking

Purpose

Preference Management

Third-Party Sharing

120. Privacy Control Testing

A GRC analyst may test:

Privacy Notice

Consent Records

DSAR Requests

Retention

Vendor DPAs

PIAs

Deletion

121. Example — Data Subject Request Test

Population:

120 Requests

Sample:

20

Verify:

Identity Validation

Completion Date

Response

Evidence

122. Example — Retention Test

Policy:

Rejected Candidate Data:
12 Months

Actual:

Candidate Records:
5 Years Old

Result:

Retention Control Gap

123. Example — Vendor Test

Policy:

DPA Required
Before Personal Data Sharing

Sample:

15 Vendors

Result:

13 Have DPA

2 Missing

Potential:

Third-Party Privacy Gap

124. Example — PIA Test

Policy:

High-Risk Processing
Requires PIA

New biometric system:

No PIA

Potential:

Privacy Governance Gap

125. Privacy Evidence

Evidence may include:

Privacy Notices

Consent Logs

Processing Records

PIAs

Rights Requests

Retention Reports

Vendor Agreements

Incident Records

Training Records

126. Build Privacy Evidence Register

Create:

11 Privacy Evidence Register

Use:

Control	Evidence	Source	Owner	Frequency

127. Privacy Metrics

A mature privacy program tracks operational performance.

Examples:

Rights Requests

Overdue Requests

Open PIAs

Retention Exceptions

Privacy Incidents

Vendor Privacy Reviews

128. Privacy Dashboard

Track:

Metric	Target
Processing Activities With Owner	100%
High-Risk Projects With PIA	100%
Rights Requests Within SLA	100%
Retention Exceptions Past Due	0
Critical Privacy Incidents Open	0
Critical Vendors With DPA	100%

129. Privacy KPI

Example:

Percentage of
data subject requests
completed within
required timeframe

130. Privacy KRI

Example:

High-Risk Processing Activities
Without Completed Privacy Assessment

Target:

0

131. Retention KRI

Example:

Personal Data Stores
Beyond Approved Retention

132. Third-Party KRI

Example:

Critical Vendors
Processing Personal Data
Without Appropriate Contractual Controls

133. Incident KRI

Example:

High-Severity Privacy Incidents
Open Beyond Response SLA

134. Practical Activity — Identify Personal Data

Use fictional:

CloudShop

Classify:

Customer Name

Shipping Address

IP Address

Order History

Payment Token

Employee Salary

Employee Health Record

Device ID

Determine:

Personal Data?

Sensitive?

Business Purpose?

135. Practical Activity — Build Processing Inventory

Create activities for:

Customer Orders

Marketing

Employee Payroll

Recruitment

Customer Support

Website Analytics

For each document:

Data Subjects

Data

Purpose

System

Vendor

136. Practical Activity — Data Minimization

Marketing signup currently collects:

Name

Email

Phone

Date of Birth

Home Address

Business purpose:

Weekly Email Newsletter

Identify which fields may be unnecessary.

137. Practical Activity — Purpose Limitation

Customer phone number collected for:

Delivery Updates

Marketing wants to use it for:

Promotional Calling

Identify:

New Purpose

Privacy Review Needed

Transparency / Legal Basis Impact

138. Practical Activity — Retention

Records:

Rejected Applicant:
6 Years

Inactive Customer:
10 Years

Former Employee:
12 Years

Determine which require review against:

Retention Schedule

Legal Requirement

Business Need

139. Practical Activity — Privacy Incident

Scenario:

HR Spreadsheet
with 500 Employee Salary Records
      ↓
Sent to Wrong External Recipient

Identify:

Personal Data

Sensitivity

Affected Individuals

Containment

Risk

Notification Assessment

140. Practical Activity — Vendor Privacy Review

New SaaS provider receives:

Employee Name

Email

Job Title

Performance Data

Determine:

Purpose

Role

Security Review

DPA

Retention

Location

Subprocessors

141. Practical Activity — Data Subject Request

Customer requests:

Give me all personal data
you hold about me

Design the workflow:

Verify Identity
      ↓
Search Systems
      ↓
Review Results
      ↓
Legal Exceptions
      ↓
Respond
      ↓
Record Completion

142. Practical Activity — New AI Tool

Marketing wants to upload:

Customer Purchase History

Email Addresses

Support Transcripts

into an external AI platform.

Perform a basic privacy review considering:

Purpose

Necessity

Vendor

Retention

Training Use

Data Location

Security

Legal Basis

Privacy Fundamentals Checklist

Data

• Personal data identified.

• sensitive data identified.

• data subjects identified.

• processing purposes documented.

Lawfulness

• processing purpose defined.

• legal basis assessed where applicable.

• consent documented where relied upon.

• consent withdrawal supported where required.

Transparency

• privacy notices exist.

• notices describe processing.

• notices remain current.

Minimization

• only required data collected.

• unnecessary fields challenged.

• duplicate data reduced.

Accuracy

• correction processes exist.

• outdated information reviewed.

Retention

• retention periods defined.

• retention triggers documented.

• deletion implemented.

• exceptions tracked.

Rights

• request channels defined.

• identity verification implemented.

• requests tracked.

• deadlines monitored.

Third Parties

• processors identified.

• subprocessors understood.

• contracts reviewed.

• data locations understood.

• security assessed.

Security

• access restricted.

• sensitive data protected.

• logging appropriate.

• incidents monitored.

Privacy by Design

• privacy reviews embedded in projects.

• high-risk processing assessed.

• privacy defaults considered.

Governance

• privacy policy exists.

• processing inventory maintained.

• owners assigned.

• training completed.

• evidence retained.

143. Common Privacy Mistakes

Mistake 1 — Privacy Equals Cybersecurity

Secure processing can still be inappropriate processing.

Mistake 2 — Only Customer Data Is Considered

Employee and applicant data are ignored.

Mistake 3 — Everything Uses Consent

Other lawful mechanisms may apply depending on jurisdiction and context.

Mistake 4 — Data Collected “Just in Case”

Purpose limitation and minimization are ignored.

Mistake 5 — Data Kept Forever

Storage limitation is not operationalized.

Mistake 6 — Privacy Notice Never Updated

Actual processing changes while documentation stays static.

Mistake 7 — SaaS Vendors Ignored

Personal data leaves the organization without governance.

Mistake 8 — Rights Requests Are Manual and Untracked

Deadlines and evidence are missed.

Mistake 9 — Privacy Review Happens After Launch

Privacy risks become expensive to fix.

Mistake 10 — AI Tools Bypass Privacy Governance

Sensitive information reaches unapproved third parties.

144. Weak Privacy Program

Privacy Policy
      ↓
Published Online
      ↓
No Operational Process

145. Strong Privacy Program

Personal Data Discovery
      ↓
Processing Inventory
      ↓
Purpose & Legal Basis
      ↓
Privacy Notice
      ↓
Minimization
      ↓
Security
      ↓
Retention
      ↓
Rights Management
      ↓
Third-Party Governance
      ↓
Privacy Risk Assessment
      ↓
Monitoring
      ↓
Continuous Improvement

146. GRC Analyst Responsibilities

A GRC professional supporting privacy may:

• Maintain the privacy policy.

• maintain processing inventories.

• coordinate privacy risk assessments.

• maintain PIA/DPIA registers.

• support data-flow mapping.

• review retention schedules.

• coordinate data subject requests.

• monitor rights-request SLAs.

• maintain privacy evidence.

• review third-party privacy assurance.

• maintain cross-border transfer records.

• track consent processes.

• support privacy incident assessments.

• test privacy controls.

• track remediation.

• prepare privacy dashboards.

• support regulatory or audit requests.

GRC connects:

Privacy

Legal

Security

HR

Marketing

Product

Engineering

Procurement

Third Parties

Internal Audit

147. Privacy Maturity Model

Level 1 — Reactive

Privacy Policy

Incident Response

Level 2 — Documented

Processing Inventory

Retention

Privacy Notices

Rights Procedures

Level 3 — Governed

PIAs

Vendor Privacy Reviews

Control Testing

Metrics

Level 4 — Integrated

Privacy by Design

Automated Rights Workflows

Data Discovery

Retention Automation

Level 5 — Continuous Privacy Assurance

Continuous Data Discovery

Dynamic Processing Inventory

Automated Risk Detection

Continuous Privacy Control Validation

148. Privacy Fundamentals Mindset

For every personal-data processing activity ask:

What data are we collecting?

Whose data is it?

Why do we need it?

Do we actually need every field?

What permits us to process it?

Have we told the individual?

Who can access it?

Which systems store it?

Which third parties receive it?

Where is it processed?

How long do we keep it?

How is it deleted?

What rights can the individual exercise?

What happens if the data is exposed?

Has the processing changed?

Can we prove all of this?

For every new project ask:

Could this create
new privacy risk?

For every new data field ask:

Why do we need it?

For every old data set ask:

Why are we
still keeping it?

These questions form the foundation of practical enterprise privacy governance.

Key Takeaways

• Privacy governs how information about individuals is collected, used, shared, retained, and deleted.

• Privacy and cybersecurity overlap but are not the same.

• Personal data can identify individuals directly or indirectly.

• Certain personal-data categories require heightened protection.

• Data subjects are the individuals to whom personal data relates.

• Controllers determine processing purposes and means; processors process data on their behalf under frameworks using those concepts.

• Common privacy principles include lawfulness, transparency, purpose limitation, minimization, accuracy, retention limitation, security, and accountability.

• Consent is only one potential legal mechanism and must be governed appropriately where used.

• Privacy notices support transparency.

• Data subject rights require operational workflows, not just policy statements.

• Privacy by design integrates privacy review before systems and processes launch.

• Processing inventories and data-flow maps are foundational privacy artifacts.

• Third-party processing and cross-border transfers require governance.

• Retention rules should define when personal data should be deleted.

• Privacy incidents may occur without cyberattacks.

• Privacy risk considers harm to individuals as well as organizational impact.

• AI, analytics, monitoring, and tracking technologies introduce new privacy considerations.

• GRC helps operationalize privacy through controls, evidence, risk assessment, testing, and continuous governance.

Knowledge Check

Before continuing, make sure you can answer:

1. What is privacy?

2. How is privacy different from cybersecurity?

3. What is personal data?

4. What is sensitive personal information?

5. Who is a data subject?

6. What is a controller?

7. What is a processor?

8. What is processing?

9. What is purpose limitation?

10. What is data minimization?

11. Why is data accuracy important?

12. What is storage limitation?

13. What does accountability mean in privacy?

14. What is consent?

15. What is a privacy notice?

16. What are data subject rights?

17. What is privacy by design?

18. What is a PIA?

19. Why are third parties important in privacy?

20. What role does GRC play in privacy governance?

What’s Next?

➡️ Next: 02 — GDPR

In the next lesson, you will move from general privacy principles into one of the world’s most influential privacy frameworks: the European Union General Data Protection Regulation (GDPR).

You will learn how GDPR organizes privacy requirements around:

Territorial Scope
      ↓
Personal Data
      ↓
Controller & Processor
      ↓
Lawful Basis
      ↓
Data Protection Principles
      ↓
Data Subject Rights
      ↓
Records of Processing
      ↓
DPIA
      ↓
Privacy by Design
      ↓
Processors & Contracts
      ↓
International Transfers
      ↓
Personal Data Breaches
      ↓
Accountability

You will also build practical artifacts including a GDPR Applicability Assessment, Lawful Basis Register, Record of Processing Activities (RoPA), Data Subject Rights Matrix, DPIA Register, Processor Register, International Transfer Register, Breach Assessment Register, and GDPR Compliance Dashboard.