02 GDPR

The General Data Protection Regulation (GDPR) is one of the most influential privacy laws in the world.

It governs how organizations collect, use, share, retain, secure, and otherwise process personal data relating to individuals in the European Union and European Economic Area, subject to its territorial scope rules.

A practical GDPR governance model looks like:

Applicability
      ↓
Personal Data
      ↓
Processing Purpose
      ↓
Lawful Basis
      ↓
Transparency
      ↓
Data Subject Rights
      ↓
Security & Privacy by Design
      ↓
Processor Governance
      ↓
International Transfers
      ↓
Breach Management
      ↓
Accountability

The central GDPR question is:

Can the organization demonstrate that its processing of personal data is lawful, fair, transparent, proportionate, secure, and accountable throughout the entire data lifecycle?

Learning Objectives

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

Explain what GDPR is.
Understand territorial scope.
Identify personal data under GDPR.
Understand special-category data.
Distinguish controllers and processors.
Understand the GDPR data protection principles.
Identify lawful bases for processing.
Understand consent requirements.
Understand legitimate interests.
Understand transparency obligations.
Explain data subject rights.
Understand Records of Processing Activities.
Understand DPIAs.
Explain privacy by design and by default.
Understand processor contracts.
Understand international data transfers.
Understand personal data breach obligations.
Understand the role of the DPO.
Understand accountability.
Understand enforcement and administrative fines.
Build practical GDPR governance artifacts.

GDPR is:

Regulation (EU) 2016/679

It establishes rules for the protection of natural persons with regard to the processing of personal data and the free movement of such data.

It became applicable on:

25 May 2018

GDPR affects far more than organizations physically located in Europe.

Depending on the circumstances, it may apply to organizations that:

Offer Goods or Services
      ↓
to Individuals in the EU / EEA

or:

Monitor Their Behaviour

even when the organization itself is established elsewhere.

GDPR does not treat every processing activity identically.

Higher-risk processing may require stronger governance.

Example:

Basic Newsletter Signup

usually presents different risk than:

Large-Scale Biometric Profiling

A strong GDPR program follows:

Requirement
      ↓
Processing Activity
      ↓
Control
      ↓
Owner
      ↓
Evidence
      ↓
Monitoring

5. Territorial Scope

Before applying GDPR controls, determine whether GDPR applies to the organization or specific processing activity.

Create:

01 GDPR Applicability Assessment

6. Establishment in the EU / EEA

GDPR generally applies where personal-data processing occurs in the context of activities of an establishment in the EU.

Example:

Company Headquarters:
India

EU Sales Office:
Germany

Processing connected to that EU establishment may fall within GDPR.

7. Offering Goods or Services

An organization outside the EU may fall under GDPR where it offers goods or services to individuals in the EU under relevant conditions.

Indicators can include:

EU-Specific Marketing

EU Currency

EU Delivery

EU Customer Targeting

Localized Services

A website merely being accessible from Europe does not automatically establish applicability by itself.

8. Monitoring Behaviour

GDPR may also apply where an organization monitors behaviour of individuals in the EU.

Examples can include:

Online Tracking

Behavioural Advertising

Profiling

Location Monitoring

Cross-Site Analytics

depending on circumstances.

9. Applicability Assessment

Use:

Question	Response	Evidence
EU/EEA establishment?
EU/EEA individuals targeted?
Behaviour monitored?
Processing activity affected?
GDPR applicable?

GDPR defines personal data broadly.

Examples:

Name

Email

Postal Address

Employee ID

Customer ID

IP Address

Cookie Identifier

Location Data

where they relate to an identified or identifiable natural person.

11. Identifiable Person

An individual may be identifiable:

Directly

or:

Indirectly

through combinations of information.

12. Pseudonymous Data

Pseudonymization replaces direct identifiers with alternate identifiers while keeping re-identification information separate.

Example:

Alice Smith
      ↓
Customer-78342

If the organization can reconnect:

Customer-78342

to Alice, the information generally remains personal data under GDPR.

13. Anonymous Data

Properly anonymized information is treated differently because individuals are no longer identifiable by reasonably likely means.

But:

Removing the Name

does not automatically mean data is anonymous.

14. Special Categories of Personal Data

GDPR provides heightened protection for certain categories.

These include personal data revealing or concerning areas such as:

Racial or Ethnic Origin

Political Opinions

Religious or Philosophical Beliefs

Trade Union Membership

Genetic Data

Biometric Data for Unique Identification

Health Data

Sex Life

Sexual Orientation

15. Special-Category Processing

Processing special-category data generally requires both:

Article 6 Lawful Basis

and:

Applicable Article 9 Condition

rather than treating ordinary consent or business need as automatically sufficient.

16. Criminal Conviction Data

Personal data relating to criminal convictions and offences receives separate treatment under GDPR.

Organizations should not treat it as ordinary personal data.

17. Data Subject

A data subject is:

The Natural Person
to Whom Personal Data Relates

Examples:

Customer

Employee

Applicant

Visitor

Contractor

18. Controller

A controller determines:

Purposes
+
Means

of processing.

Example:

CloudShop
      ↓
Decides Why Customer Orders
Are Collected and Processed

CloudShop may be the controller.

19. Processor

A processor processes personal data:

On Behalf of
the Controller

Example:

CloudShop
      ↓
Payroll SaaS Provider

The provider may act as processor for defined activities.

20. Controller vs Processor

Controller	Processor
Determines purpose	Processes for controller
Determines essential means	Follows documented instructions
Responsible for lawful processing	Responsible for processor obligations
Handles transparency	Supports controller obligations

21. Joint Controllers

Sometimes two organizations jointly determine purposes and essential means.

Example:

Organization A
      +
Organization B
      ↓
Jointly Design Shared Processing

This may create:

Joint Controller

responsibilities.

22. Controller-Processor Classification

Do not classify a provider simply because:

They Signed a Contract

Evaluate:

Who Decides Purpose?

Who Decides Essential Means?

Whose Instructions Are Followed?

Article 5 establishes core principles.

A practical model:

Lawfulness, Fairness & Transparency

Purpose Limitation

Data Minimization

Accuracy

Storage Limitation

Integrity & Confidentiality

Accountability

24. Lawfulness, Fairness and Transparency

Processing should be:

Lawful

Fair

Transparent

25. Fairness

Fairness considers whether the processing could:

Unexpectedly Harm

Mislead

Disadvantage

individuals.

26. Transparency

Individuals should understand:

Who Is Processing

What Data

Why

How Long

Who Receives It

What Rights Exist

27. Purpose Limitation

Data should be collected for:

Specified

Explicit

Legitimate

purposes.

28. Purpose Creep

Original:

Customer Email
→ Order Confirmation

later:

Customer Email
→ Third-Party Advertising

This requires additional GDPR analysis.

29. Data Minimization

Processing should be:

Adequate

Relevant

Limited

to what is necessary.

30. Data Minimization Example

Purpose:

Send Product Newsletter

Required:

Email Address

Potentially unnecessary:

Passport Number

Full Home Address

National Identifier

31. Accuracy

Personal data should be:

Accurate

Kept Up to Date
Where Necessary

32. Storage Limitation

Personal data should not be kept in identifiable form longer than necessary for the purposes.

33. Retention Governance

Create:

02 GDPR Retention Schedule

Use:

Data Category	Purpose	Retention	Trigger	Legal Requirement

34. Integrity and Confidentiality

Organizations should implement appropriate technical and organizational measures against:

Unauthorized Processing

Accidental Loss

Destruction

Damage

35. Accountability

The controller is responsible for compliance and should be able to:

Demonstrate Compliance

This is one of GDPR’s most important concepts.

36. Lawful Bases

Article 6 provides lawful bases for processing.

These include:

Consent

Contract

Legal Obligation

Vital Interests

Public Task

Legitimate Interests

37. Build Lawful Basis Register

Create:

03 GDPR Lawful Basis Register

Use:

Processing Activity	Purpose	Lawful Basis	Reason	Owner

Consent may be appropriate where it is:

Freely Given

Specific

Informed

Unambiguous

The organization should be able to prove:

Who Consented

When

What They Were Told

What They Agreed To

40. Withdrawal

Where processing is based on consent:

Give Consent
      ↓
Processing

individuals should generally be able to:

Withdraw Consent

as easily as giving it, subject to applicable rules.

Weak:

Use Service
      =
Agree to All Marketing

This may not satisfy consent standards.

42. Contract

Processing may be necessary for performance of a contract.

Example:

Customer Places Order
      ↓
Shipping Address Processed
      ↓
Deliver Product

43. Legal Obligation

Example:

Tax Law
      ↓
Requires Invoice Records

Processing may be necessary to comply with a legal obligation.

44. Vital Interests

This basis may apply where processing is necessary to protect vital interests, such as certain life-threatening situations.

It is not a general business convenience basis.

45. Public Task

This may apply to tasks carried out in the public interest or official authority under applicable law.

46. Legitimate Interests

Organizations may rely on legitimate interests where applicable when processing is necessary for legitimate interests and those interests are not overridden by individuals’ interests or fundamental rights and freedoms.

47. Legitimate Interests Assessment

A practical:

LIA

may evaluate:

Purpose Test

Necessity Test

Balancing Test

48. Build LIA Register

Create:

04 Legitimate Interests Assessment Register

Use:

Processing	Interest	Necessary?	Individual Impact	Decision

49. Do Not Default Everything to Legitimate Interests

The lawful basis should reflect the actual processing.

Weak:

Business Wants It
      =
Legitimate Interest

is not enough.

50. Lawful Basis Must Be Chosen Before Processing

The organization should not:

Process First
      ↓
Find Legal Basis Later

51. Changing Lawful Basis

Organizations should not casually switch lawful bases after processing begins simply because the original basis becomes inconvenient.

52. Transparency — Articles 13 and 14

GDPR requires organizations to provide information to individuals depending on whether personal data is obtained directly from them or from another source.

53. Privacy Notice Content

A GDPR privacy notice may need to address matters such as:

Controller Identity

Purposes

Lawful Bases

Recipients

Transfers

Retention

Rights

Complaint Rights

Source of Data

Automated Decision-Making

where applicable.

Create:

05 GDPR Privacy Notice Register

Use:

Notice	Audience	Processing	Last Review	Owner

55. Layered Notices

For complex processing, organizations may use:

Short Notice
      ↓
Detailed Privacy Notice

to improve usability.

56. Privacy Notice Must Match Reality

Weak:

Notice:
We Never Share Data

Actual:

CRM

Analytics

Cloud Provider

Marketing Platform

This creates a transparency gap.

57. Data Subject Rights

GDPR provides several rights to individuals.

Common rights include:

Access

Rectification

Erasure

Restriction

Data Portability

Objection

Rights Related to Automated Decision-Making

58. Right of Access

Individuals may request confirmation about processing and access to applicable personal data and information.

59. Subject Access Request

DSAR

or subject access request may trigger:

Identity Verification
      ↓
System Search
      ↓
Data Review
      ↓
Exemptions / Third-Party Review
      ↓
Response

60. Right to Rectification

Individuals may request correction of inaccurate data.

61. Right to Erasure

Often called:

Right to Be Forgotten

but this right is not absolute.

Deletion may not apply where data must be retained for certain lawful reasons.

62. Right to Restriction

In certain situations, individuals may request that processing be limited while the data remains retained.

63. Right to Data Portability

Where applicable, certain personal data may need to be provided:

Structured

Commonly Used

Machine-Readable

and potentially transmitted to another controller.

64. Right to Object

Individuals may object to certain processing.

Direct marketing is especially important.

65. Direct Marketing Objection

Where an individual objects to direct marketing under GDPR:

Direct Marketing Processing
      ↓
Must Stop

for that purpose.

66. Automated Decision-Making

GDPR provides protections relating to certain decisions based solely on automated processing that produce legal or similarly significant effects.

67. Automated Decision Example

AI Credit Model
      ↓
Automatically Rejects Loan

may require additional legal and governance review depending on circumstances.

68. Build Data Subject Rights Matrix

Create:

06 GDPR Data Subject Rights Matrix

Use:

Right	Applies When	Workflow	Owner	SLA

69. Rights Request Register

Create:

07 GDPR Rights Request Register

Use:

Request	Right	Received	Due	Completed	Status

GDPR generally requires responses to applicable data-subject requests:

Without Undue Delay

and in principle within:

One Month

subject to permitted extensions and conditions.

71. Identity Verification

Do not disclose personal data to someone simply because they know:

Name

Email Address

Use proportionate identity verification.

72. Excessive Verification

Do not collect unnecessary sensitive information simply to verify identity.

Privacy principles still apply.

73. Records of Processing Activities

GDPR Article 30 requires certain controllers and processors to maintain records of processing activities.

RoPA

is one of the most important GDPR governance artifacts.

74. Build RoPA

Create:

08 GDPR Record of Processing Activities

Use:

Process	Subjects	Data	Purpose	Recipients	Retention	Transfers

75. RoPA Example

Process:

Employee Payroll

Data subjects:

Employees

Data:

Name

Bank Account

Tax ID

Salary

Purpose:

Payroll Administration

76. RoPA Should Be Operational

Weak:

Spreadsheet Updated
Once Three Years Ago

Strong:

New Project
      ↓
Privacy Review
      ↓
RoPA Updated

77. Data Protection Impact Assessment

DPIA

is required under GDPR where processing is likely to result in a high risk to individuals’ rights and freedoms, subject to applicable rules.

78. DPIA Triggers

Examples may include:

Systematic and Extensive Profiling

Large-Scale Special-Category Data

Systematic Monitoring of Public Areas

Other High-Risk Processing

depending on the context and supervisory guidance.

79. DPIA Workflow

New Processing
      ↓
Privacy Screening
      ↓
High Risk?
      │
      ├── No → Standard Review
      │
      └── Yes
             ↓
DPIA
             ↓
Risk Mitigation
             ↓
Approval

80. Build DPIA Register

Create:

09 GDPR DPIA Register

Use:

Project	Processing	Risk	DPIA Required	Status	Owner

81. DPIA Content

A DPIA typically considers:

Processing Description

Purpose

Necessity

Proportionality

Risks to Individuals

Mitigating Controls

82. Residual High Risk

If high residual risk remains after planned mitigation, consultation with the supervisory authority may be required in relevant circumstances.

83. Privacy by Design

GDPR Article 25 requires:

Data Protection
by Design and by Default

84. Privacy by Design Example

New mobile application requests:

Contacts

Precise Location

Microphone

Photos

Before implementation ask:

Which Permissions
Are Actually Necessary?

85. Privacy by Default

Default settings should generally process only personal data necessary for the specific purpose.

86. Build Privacy Design Checklist

Create:

10 GDPR Privacy by Design Checklist

Include:

Purpose defined.
lawful basis identified.
minimization applied.
retention defined.
access restricted.
encryption considered.
transparency addressed.
rights supported.
vendor processing reviewed.
DPIA screening completed.

87. Security of Processing

GDPR Article 32 requires appropriate technical and organizational measures based on risk.

Potential measures include:

Encryption

Pseudonymization

Resilience

Availability

Recovery

Regular Testing

depending on the risk.

88. Security Should Be Risk-Based

Weak:

All Personal Data
Uses Same Controls

Stronger:

Risk
      ↓
Sensitivity
      ↓
Threat
      ↓
Appropriate Controls

89. Security Controls

Common examples:

MFA

Least Privilege

Encryption

Logging

Backups

Security Testing

Incident Response

DLP

90. Processor Governance

Controllers should not simply send personal data to any vendor.

There should be:

Processor Due Diligence

Contract

Security Requirements

Subprocessor Governance

Ongoing Monitoring

91. Article 28 Contracts

Controller-processor contracts should address applicable GDPR requirements.

Common areas include:

Documented Instructions

Confidentiality

Security

Subprocessors

Data Subject Rights Support

Breach Support

Deletion / Return

Audit Information

92. Build Processor Register

Create:

11 GDPR Processor Register

Use:

Processor	Service	Data	Location	DPA	Owner

93. Processor Due Diligence

Evaluate:

Security

Privacy

Data Location

Subprocessors

Incident History

Certifications

Contractual Terms

94. Subprocessor Governance

A processor may use:

Subprocessors

The controller should understand applicable notification, authorization, and contractual obligations.

95. International Data Transfers

GDPR places restrictions on transfers of personal data to certain countries outside the EEA where applicable.

96. Transfer Example

EU Employee
      ↓
HR SaaS
      ↓
Data Center in USA

This may constitute an international transfer requiring an appropriate transfer mechanism.

97. Transfer Mechanisms

Depending on circumstances, mechanisms may include:

Adequacy Decision

Standard Contractual Clauses

Binding Corporate Rules

Specific Derogations

among other lawful mechanisms.

98. Standard Contractual Clauses

SCCs are contractual mechanisms adopted by the European Commission for certain international transfers.

99. Transfer Impact Assessment

Organizations may need to assess whether the transfer mechanism provides effective protection in the destination context.

Create:

12 GDPR International Transfer Register

Use:

Transfer	Origin	Destination	Mechanism	Assessment	Owner

These concepts are related but not identical.

Data Residency

asks:

Where Is Data Stored?

GDPR transfer analysis asks:

Is Personal Data
Being Transferred or Made Available
Across Relevant Jurisdictions?

101. Personal Data Breach

GDPR defines a personal data breach broadly around security breaches leading to accidental or unlawful:

Destruction

Loss

Alteration

Unauthorized Disclosure

Unauthorized Access

to personal data.

102. Breach Examples

Examples:

Stolen Laptop

Misconfigured Cloud Storage

Wrong Email Recipient

Ransomware

Unauthorized Database Access

103. Breach Does Not Require Exfiltration

Example:

Ransomware Encrypts
Personal Data

Even without confirmed theft, this can still be a personal data breach because availability may be affected.

104. Breach Response Workflow

Incident
      ↓
Containment
      ↓
Personal Data Involved?
      ↓
Risk Assessment
      ↓
Regulatory Notification Decision
      ↓
Individual Notification Decision
      ↓
Documentation
      ↓
Remediation

105. Supervisory Authority Notification

Where a breach is likely to result in a risk to individuals’ rights and freedoms, GDPR generally requires notification to the competent supervisory authority:

Without Undue Delay

and, where feasible:

Within 72 Hours

after becoming aware of it.

106. 72 Hours Is Not Investigation Completion

Organizations should not wait until every forensic detail is known before considering notification obligations.

107. Data Subject Notification

Where a personal-data breach is likely to result in a:

High Risk

to individuals’ rights and freedoms, notification to affected individuals may also be required, subject to applicable exceptions.

108. Build Breach Assessment Register

Create:

13 GDPR Breach Assessment Register

Use:

Incident	Data	Subjects	Risk	Authority Notification	Individual Notification

109. Breach Risk Factors

Consider:

Type of Data

Sensitivity

Volume

Identifiability

Number of People

Potential Harm

Encryption

Containment

110. Breach Documentation

Even where notification is not required, GDPR requires controllers to document personal-data breaches sufficiently to enable supervisory authorities to verify compliance.

111. Processor Breach Notification

A processor should notify the controller:

Without Undue Delay

after becoming aware of a personal data breach, under applicable GDPR obligations.

112. Data Protection Officer

DPO

may be required in certain circumstances.

113. Typical DPO Triggers

Examples include where core activities involve:

Regular and Systematic Monitoring
on a Large Scale

or:

Large-Scale Processing
of Special-Category Data

as well as certain public-authority situations.

114. DPO Independence

The DPO should perform responsibilities with appropriate independence.

The organization should avoid:

Conflict of Interest

between DPO duties and other roles.

115. DPO Responsibilities

May include:

Informing and Advising

Monitoring Compliance

Advising on DPIAs

Cooperating with Supervisory Authorities

Create:

14 GDPR Governance & Accountability Register

Use:

Governance Area	Owner	Evidence	Review Cycle

117. Representative in the EU

Certain organizations outside the EU subject to GDPR may need to designate an EU representative, subject to the Regulation’s conditions and exceptions.

118. Supervisory Authorities

Independent data protection authorities oversee GDPR enforcement in EU/EEA jurisdictions.

Organizations should understand which authority may act as:

Lead Supervisory Authority

where applicable.

119. One-Stop-Shop Mechanism

Organizations with cross-border processing in the EU may interact with a lead supervisory authority under relevant GDPR rules.

120. Accountability Artifacts

A mature GDPR program may maintain:

RoPA

Lawful Basis Register

DPIAs

LIAs

Privacy Notices

Processor Register

Transfer Register

Rights Register

Breach Register

Retention Schedule

Training Evidence

A GRC analyst may test areas such as:

RoPA Completeness

Lawful Basis

Privacy Notices

DSAR Responses

Retention

DPIAs

Processor Contracts

International Transfers

Breach Handling

122. Test — RoPA Completeness

Business application inventory:

100 Applications

RoPA-related processing identified:

Potential:

16 Activities
Require Investigation

123. Test — DSAR

Population:

75 Data Subject Requests

Sample:

Verify:

Identity Verification

Response Date

Response Completeness

Extensions

Evidence

124. Test — Privacy Notice

Actual processing:

Website Analytics

Advertising

CRM

AI Recommendation

Notice describes only:

Order Processing

Result:

Transparency Gap

125. Test — DPIA

New project:

Employee Facial Recognition

DPIA:

Not Completed

Potential:

High-Risk Processing Governance Gap

126. Test — Processor Agreement

Population:

25 Critical Processors

Result:

22 Signed GDPR DPAs

3 Missing

Potential:

Processor Governance Gap

127. Test — International Transfers

Cloud provider processes EU customer data in:

USA

Evidence:

No Transfer Mechanism Documented

Potential:

Transfer Compliance Gap

128. Test — Retention

Policy:

Customer Support Records
2 Years

Actual:

7-Year Records Present

Potential:

Storage Limitation Gap

Create:

15 GDPR Compliance Gap Register

Use:

Gap	GDPR Area	Risk	Severity	Owner

130. Root Cause Example — Missing DPIA

Problem:

High-Risk AI Project
No DPIA

Why?

Privacy Team
Was Not Engaged

Why?

Project Intake
Has No Privacy Trigger

Root cause:

Enterprise project governance does not include automated privacy screening for high-risk processing.

131. Correction

Perform DPIA

132. Corrective Action

Add Privacy Screening
to Project Intake

133. Root Cause Example — Expired Retention

Problem:

Old Customer Data
Still Stored

Why?

Retention Policy
Not Automated

Root cause:

Retention requirements are documented but not technically integrated into the data lifecycle.

134. Corrective Action

Automated Retention

Deletion Workflow

Exception Monitoring

Track:

Metric	Target
Processing Activities in RoPA	100%
Activities With Lawful Basis	100%
High-Risk Processing With DPIA	100%
Rights Requests Within SLA	100%
Critical Processors With DPA	100%
International Transfers With Mechanism	100%
Overdue Retention Actions	0

Percentage of GDPR rights requests
completed within applicable timeframe

High-risk processing
operating without required DPIA

Target:

Critical processors
without appropriate
Article 28 terms

International personal-data transfers
without documented transfer mechanism

Reportable breaches
not escalated within required timeline

141. Enforcement

Supervisory authorities have significant investigative and corrective powers.

Potential measures can include:

Warnings

Reprimands

Orders

Processing Restrictions

Administrative Fines

142. Administrative Fines

GDPR provides two main maximum fine tiers.

Certain infringements may result in maximum administrative fines of up to:

€10 Million
or
2% of Total Worldwide
Annual Turnover

whichever is higher under the applicable provision.

More serious categories may reach:

€20 Million
or
4% of Total Worldwide
Annual Turnover

whichever is higher under the applicable provision.

Actual enforcement depends on the circumstances and factors set out in GDPR.

143. Fines Are Not the Only Risk

Organizations may also face:

Operational Restrictions

Litigation

Contractual Impact

Reputation Damage

Loss of Customer Trust

Use fictional organization:

CloudShop India

Conditions:

Headquarters:
India

Customers:
Germany, France, India

EU Shipping:
Available

EU Advertising:
Active

Behavioural Tracking:
Enabled

Determine:

Does GDPR Potentially Apply?

Why?

Which Processing?

145. Practical Activity — Lawful Basis

Activities:

Deliver Customer Order

Email Marketing

Employee Payroll

Fraud Detection

Emergency Medical Response

Identify the potential lawful basis for each and document the reasoning.

146. Practical Activity — RoPA

Build entries for:

Customer Orders

Marketing

Recruitment

Employee Payroll

Customer Support

Website Analytics

147. Practical Activity — DSAR

Customer requests:

Provide All Personal Data
You Hold About Me

Build:

Identity Verification
      ↓
System Discovery
      ↓
Search
      ↓
Third-Party Review
      ↓
Legal Review
      ↓
Response

148. Practical Activity — Deletion Request

Former customer requests:

Delete Everything

Records include:

Marketing Profile

Closed Account

Tax Invoices

Fraud Investigation Record

Determine:

What Can Be Deleted?

What May Need Retention?

What Must Be Explained?

149. Practical Activity — DPIA

CloudShop introduces:

AI Fraud Detection

using:

Purchase History

Location

Device Fingerprinting

Behavioural Profiles

Perform initial DPIA screening.

150. Practical Activity — Processor Review

New CRM provider processes:

Customer Name

Email

Order History

Support Notes

Review:

Article 28 Terms

Subprocessors

Security

Data Location

International Transfer

Deletion

151. Practical Activity — International Transfer

EU customer data moves:

France
      ↓
CloudShop
      ↓
India
      ↓
US SaaS Provider

Map:

Transfer

Role

Mechanism

Risk

Documentation

152. Practical Activity — Breach

Scenario:

Misconfigured Cloud Bucket
      ↓
20,000 EU Customer Records
Publicly Accessible
for 12 Hours

Data includes:

Name

Email

Address

Order History

Determine:

Containment

Risk Assessment

72-Hour Consideration

Individual Notification

Documentation

153. Practical Activity — Privacy Notice

Actual processing:

Order Processing

Analytics

Personalized Advertising

Fraud Detection

AI Recommendations

Existing notice mentions:

Order Processing Only

Identify the transparency gaps.

Applicability

EU/EEA establishment assessed.
targeting assessed.
monitoring assessed.
processing scope documented.

Personal Data

personal data inventoried.
special-category data identified.
criminal-conviction data considered.
pseudonymous data understood.

Roles

controllers identified.
processors identified.
joint controllers assessed.
subprocessors identified.

Principles

purpose defined.
minimization applied.
accuracy maintained.
retention defined.
security controls implemented.
accountability evidence maintained.

Lawful Basis

Article 6 basis documented.
Article 9 condition documented where applicable.
consent evidence maintained where used.
legitimate-interest assessments completed where appropriate.

Transparency

Article 13/14 notices maintained.
notices match actual processing.
retention disclosed where required.
transfer information addressed.

Rights

request channels established.
identity verification defined.
deadlines monitored.
access supported.
correction supported.
deletion supported.
objection supported.
portability supported where applicable.

RoPA

processing inventory complete.
owners assigned.
purposes documented.
recipients documented.
transfers documented.
retention documented.

DPIA

privacy screening exists.
high-risk processing identified.
DPIAs completed.
residual risks tracked.

Privacy by Design

privacy included in project lifecycle.
minimization reviewed.
privacy defaults implemented.
technical controls documented.

Processors

processor register maintained.
due diligence completed.
Article 28 terms maintained.
subprocessors governed.
deletion / return addressed.

Transfers

international transfers inventoried.
transfer mechanisms documented.
transfer assessments completed where required.
data locations monitored.

Security

security risks assessed.
access restricted.
encryption considered.
testing performed.
incidents monitored.

Breaches

breach workflow established.
72-hour escalation supported.
notification decisions documented.
breach register maintained.
processor notification obligations understood.

Governance

DPO requirement assessed.
EU representative requirement assessed.
training completed.
audit / control testing performed.
remediation tracked.

Territorial scope can extend beyond the EU.

Mistake 2 — Name Removed Means Anonymous

Individuals may still be identifiable.

Consent is only one lawful basis.

Mistake 4 — Lawful Basis Chosen After Processing Starts

Lawfulness is not retrospective paperwork.

Mistake 5 — Privacy Notice Is Generic

It does not reflect actual processing.

Mistake 6 — RoPA Is Treated as Annual Spreadsheet Work

Changes are not captured.

Mistake 7 — All Deletion Requests Are Automatically Approved

Legal and regulatory retention obligations are ignored.

Mistake 8 — DPIA Performed After Launch

High-risk processing is already operating.

Processor obligations, contracts, transfers, and roles remain relevant.

Mistake 10 — 72 Hours Means 72 Hours to Complete Investigation

Breach notification decisions must begin much earlier.

Privacy Notice
      ↓
DPA Template
      ↓
Wait for Complaint

Applicability
      ↓
Processing Inventory
      ↓
Lawful Basis
      ↓
Transparency
      ↓
Rights Management
      ↓
DPIA
      ↓
Privacy by Design
      ↓
Processor Governance
      ↓
Transfer Governance
      ↓
Security
      ↓
Breach Response
      ↓
Continuous Accountability

157. GRC Analyst Responsibilities

A GRC professional supporting GDPR may:

Perform GDPR applicability assessments.
maintain lawful-basis registers.
maintain RoPA.
coordinate DPIA screening.
maintain DPIA registers.
review privacy notices.
coordinate data-subject rights processes.
monitor rights-request deadlines.
review processor agreements.
maintain processor inventories.
maintain international transfer registers.
coordinate transfer risk assessments.
support breach assessments.
maintain breach documentation.
coordinate remediation.
maintain privacy evidence.
prepare GDPR dashboards.
support DPO, Legal, Internal Audit, and supervisory-authority requests.

GRC connects:

DPO / Privacy

Legal

Security

HR

Marketing

Product

Engineering

Procurement

Risk

Third Parties

Internal Audit

Level 1 — Reactive

Privacy Notice

Basic DSAR Process

Incident Response

Level 2 — Documented

RoPA

Lawful Bases

Processor Contracts

Retention

Level 3 — Governed

DPIA

Transfer Governance

Control Testing

Dashboards

Level 4 — Integrated

Privacy by Design

Automated Rights Workflows

Vendor Integration

Automated Retention

Continuous Data Discovery

Dynamic RoPA

Automated DPIA Triggers

Continuous Transfer Monitoring

Real-Time Privacy Risk

For every processing activity ask:

Does GDPR apply?

What personal data is involved?

Are special categories involved?

Who is the controller?

Who is the processor?

What is the purpose?

What is the lawful basis?

Is processing fair?

Have individuals been informed?

Are we collecting only what we need?

How long will we keep it?

Who receives it?

Does it leave the EEA?

What transfer mechanism applies?

Can individuals exercise their rights?

Does the project require a DPIA?

How is the data secured?

What happens if there is a breach?

Can we demonstrate all of this?

For every new vendor ask:

What GDPR role
does the vendor perform?

For every new project ask:

Could this create
high risk to individuals?

For every privacy claim ask:

What evidence proves it?

That is the practical mindset behind GDPR accountability.

Key Takeaways

GDPR can apply to organizations outside Europe depending on territorial scope.
Personal data includes direct and indirect identifiers.
Pseudonymized data generally remains personal data where re-identification is possible.
Special-category data receives heightened protection.
Controllers and processors have different GDPR responsibilities.
Core principles include lawfulness, fairness, transparency, purpose limitation, minimization, accuracy, storage limitation, security, and accountability.
Article 6 provides multiple lawful bases; consent is only one.
Special-category processing generally requires an additional Article 9 condition.
Privacy notices must accurately describe actual processing.
GDPR provides extensive rights to data subjects.
RoPA is a foundational accountability artifact.
DPIAs help assess high-risk processing before deployment.
Privacy by design and default should be integrated into product and system development.
Processor arrangements require appropriate governance and contractual controls.
International transfers require appropriate legal mechanisms where applicable.
GDPR breach management includes the well-known 72-hour supervisory-authority notification requirement where the statutory threshold applies.
DPO requirements depend on organizational and processing circumstances.
Accountability requires evidence that privacy controls actually operate.
GRC operationalizes GDPR through inventories, registers, evidence, testing, remediation, and monitoring.

Knowledge Check

Before continuing, make sure you can answer:

What is GDPR?
Can GDPR apply to organizations outside the EU?
What is personal data?
What is pseudonymization?
What is special-category data?
What is a controller?
What is a processor?
What are the Article 5 principles?
What are the six Article 6 lawful bases?
Why is consent not appropriate for every processing activity?
What is a legitimate interests assessment?
What rights do GDPR data subjects have?
What is a RoPA?
What is a DPIA?
What does privacy by design mean?
What does Article 28 address?
What are SCCs?
What is an international transfer?
When does the 72-hour breach-notification rule become relevant?
What role does GRC play in GDPR compliance?

What’s Next?

➡️ Next: 03 — DPDP Act (India)

In the next lesson, you will move from the European GDPR framework into India’s Digital Personal Data Protection Act, 2023 and its operational data-protection model.

You will examine:

Applicability
      ↓
Digital Personal Data
      ↓
Data Principal
      ↓
Data Fiduciary
      ↓
Consent & Notice
      ↓
Legitimate Uses
      ↓
Data Principal Rights
      ↓
Data Fiduciary Obligations
      ↓
Significant Data Fiduciaries
      ↓
Data Processors
      ↓
Cross-Border Processing
      ↓
Personal Data Breaches
      ↓
Grievance Management
      ↓
Accountability

You will also build practical artifacts including a DPDP Applicability Assessment, Data Processing Inventory, Consent & Notice Register, Data Principal Rights Register, Data Fiduciary Obligation Matrix, Processor Register, Breach Register, Grievance Register, Significant Data Fiduciary Readiness Checklist, and DPDP Compliance Dashboard.

02 GDPR

Learning Objectives

1. What Is GDPR?

2. Why GDPR Matters

3. GDPR Is Risk-Based

4. GDPR Accountability Model

5. Territorial Scope

6. Establishment in the EU / EEA

7. Offering Goods or Services

8. Monitoring Behaviour

9. Applicability Assessment

10. Personal Data Under GDPR

11. Identifiable Person

12. Pseudonymous Data

13. Anonymous Data

14. Special Categories of Personal Data

15. Special-Category Processing

16. Criminal Conviction Data

17. Data Subject

18. Controller

19. Processor

20. Controller vs Processor

21. Joint Controllers

22. Controller-Processor Classification

23. GDPR Data Protection Principles

24. Lawfulness, Fairness and Transparency

25. Fairness

26. Transparency

27. Purpose Limitation

28. Purpose Creep

29. Data Minimization

30. Data Minimization Example

31. Accuracy

32. Storage Limitation

33. Retention Governance

34. Integrity and Confidentiality

35. Accountability

36. Lawful Bases

37. Build Lawful Basis Register

38. Consent

39. Consent Should Be Demonstrable

40. Withdrawal

41. Consent Mistake

42. Contract

43. Legal Obligation

44. Vital Interests

45. Public Task

46. Legitimate Interests

47. Legitimate Interests Assessment

48. Build LIA Register

49. Do Not Default Everything to Legitimate Interests

50. Lawful Basis Must Be Chosen Before Processing

51. Changing Lawful Basis

52. Transparency — Articles 13 and 14

53. Privacy Notice Content

54. Build GDPR Notice Register

55. Layered Notices

56. Privacy Notice Must Match Reality

57. Data Subject Rights

58. Right of Access

59. Subject Access Request

60. Right to Rectification

61. Right to Erasure

62. Right to Restriction

63. Right to Data Portability

64. Right to Object

65. Direct Marketing Objection

66. Automated Decision-Making

67. Automated Decision Example

68. Build Data Subject Rights Matrix

69. Rights Request Register

70. GDPR Response Time

71. Identity Verification

72. Excessive Verification

73. Records of Processing Activities

74. Build RoPA

75. RoPA Example

76. RoPA Should Be Operational

77. Data Protection Impact Assessment

78. DPIA Triggers