Introduction

Most organisations approach GDPR as a compliance project. They hire a consultant, draft a privacy policy, conduct a data mapping exercise, and declare themselves compliant. Then they move on.

This approach is fundamentally wrong.

GDPR is not a compliance project with an end date. It is a governance framework that requires permanent, documented systems for managing personal data. The organisations that face enforcement action and substantial fines are not those that lack GDPR knowledge. They are those that lack documented systems demonstrating they have taken the legal obligations seriously.

This article addresses what GDPR systems are, why they differ from one-time compliance efforts, which organisational functions must be involved, and how to build systems that actually reduce risk rather than simply creating documentation.

---

Part 1: Understanding GDPR Systems vs. Compliance Projects

The Difference Between Compliance and Systems

Compliance is a point-in-time assessment: Does our current state meet regulatory requirements as of today?

Systems are ongoing mechanisms: How do we ensure our handling of personal data continues to meet regulatory requirements month after month, year after year, as our business changes?

GDPR is designed around systems, not compliance audits. The regulation repeatedly requires organisations to demonstrate “accountability” and “compliance by design”—not one-time conformance, but permanent, documented processes.

Examples of this distinction:

Regulators view compliance-project organisations as high-risk because they have no systems to ensure ongoing compliance. They view systems-based organisations as lower-risk because they have documented processes.

Why GDPR Systems Matter Now

Three developments have made GDPR systems a regulatory enforcement priority:

1. Escalating Enforcement

EU data protection authorities have moved from issuing warnings to imposing substantial fines. Recent years have seen fines exceeding €90 million. The trend is toward higher fines and more enforcement actions, not fewer.

Notably, many enforcement actions target organisations for failure to demonstrate they have systems in place—not for isolated breaches, but for systemic failures to implement accountability mechanisms.

2. Cross-Border Data Flows

GDPR applies to any organisation processing personal data of EU residents, regardless of where the organisation is located. This means:

• US technology companies must comply with GDPR
• Non-EU businesses transferring data to EU partners must comply with GDPR
• UK organisations post-Brexit must still comply with UK GDPR (substantially identical to EU GDPR)

This expanded scope means more organisations face enforcement risk, not fewer.

3. Regulatory Focus on Accountability Mechanisms

Recent GDPR enforcement actions reveal that regulators prioritise three things:

• Documentation — Do you have documented procedures?
• Consistency — Are procedures actually followed?
• Evidence — Can you demonstrate compliance?

An organisation with imperfect systems but documented procedures faces lower regulatory risk than an organisation with excellent practices but no documentation. The regulation is designed to reward accountability, not perfection.

---

Part 2: The Legal Framework for GDPR Systems

Core GDPR Obligations

GDPR imposes obligations on organisations in seven functional areas. Understanding these areas is essential to building systems.

1. Lawful Basis for Processing

GDPR Article 6 requires that all processing of personal data be based on a lawful basis. There are six lawful bases:

• Consent — The individual has given specific, informed, freely given consent
• Contract — Processing is necessary to perform a contract with the individual
• Legal obligation — Processing is required by law
• Vital interests — Processing is necessary to protect vital interests of the individual or others
• Public task — Processing is necessary for a public task or official function
• Legitimate interests — Processing is necessary for legitimate interests pursued by the organisation, except where overridden by the rights of the individual

This creates a system requirement: every processing activity must be documented with its lawful basis. If you cannot identify the lawful basis, the processing is unlawful.

Systems implication: You must maintain a data processing inventory specifying the lawful basis for each processing activity.

2. Transparency and Privacy Information

GDPR Articles 13 and 14 require that individuals be informed about data processing before or at the time data is collected. The organisation must provide:

• Identity of the controller
• Purpose of processing
• Lawful basis for processing
• Categories of recipients
• Retention period
• Rights available to the individual (access, rectification, erasure, objection, etc.)
• Information about automated decision-making

This creates a system requirement: you must have processes to ensure privacy information is provided to individuals at the correct time and in a comprehensible format.

Systems implication: You must have templates, procedures, and approval processes for privacy notices, and you must document when individuals were provided with this information.

3. Consent Management

Where consent is the lawful basis for processing, GDPR requires that consent be:

• Specific — given for a specified purpose, not blanket consent for all processing
• Informed — the individual understands what they are consenting to
• Freely given — there is no coercion or pressure
• Unambiguous indication — explicit consent (not pre-ticked boxes or inferred from silence)

This creates a system requirement: you must have consent management systems that capture, document, and can retrieve individual consents.

Systems implication: You must have technical systems (or documented manual processes) for recording who consented to what, when, and for how long. You must be able to retrieve this record upon request.

4. Data Subject Rights

GDPR grants individuals (called “data subjects”) seven key rights:

• Right of access — to receive a copy of their personal data held by the organisation
• Right to rectification — to correct inaccurate data
• Right to erasure (“right to be forgotten”) — to have data deleted under specified circumstances
• Right to restrict processing — to limit how data can be used
• Right to data portability — to receive data in a structured format and transfer it to another organisation
• Right to object — to object to processing on grounds of legitimate interests or for direct marketing
• Rights related to automated decision-making — to object to decisions based solely on automated processing

This creates a system requirement: you must have documented procedures for responding to data subject requests within the statutory timeframe (typically 30 days, extendable to 90 days).

Systems implication: You must have procedures for receiving requests, identifying relevant data, gathering data from all systems holding it, reviewing for exemptions, and providing the response within legal timeframes. For many organisations, this requires manual processes or technical tools.

5. Data Protection by Design and Default

GDPR Article 25 requires that organisations implement “technical and organisational measures” to embed privacy and security into systems and processes from the outset. This includes:

• Data minimisation — collect only data necessary for the purpose
• Purpose limitation — use data only for the stated purpose
• Retention management — delete data when no longer needed
• Privacy by default — privacy-protective settings are enabled by default
• Encryption and security — appropriate technical measures to protect data

This creates a system requirement: you must have processes ensuring that privacy and security considerations are built into systems and processes before they are deployed, not added afterward.

Systems implication: You must require privacy impact assessments before implementing systems that process personal data, and you must have procedures for embedding data protection into system design.

6. Data Protection Impact Assessment (DPIA)

GDPR Article 35 requires a Data Protection Impact Assessment for processing that is “likely to result in a high risk” to individuals. High-risk processing includes:

• Large-scale processing of personal data
• Processing of sensitive data (racial or ethnic origin, political opinions, religious beliefs, trade union membership, genetic data, biometric data, health data, sex life data)
• Systematic monitoring or profiling
• Automated decision-making with significant effects
• Use of new technology
• Matching data from multiple sources
• Combinations of the above

A DPIA must:

• Describe the processing and its purposes
• Assess necessity and proportionality
• Identify risks to individuals’ rights and freedoms
• Identify mitigation measures
• Consult with the data protection authority if high risks cannot be mitigated

This creates a system requirement: you must have a procedure for identifying when DPIAs are required and conducting them before implementing high-risk processing.

Systems implication: You must have a criteria checklist for assessing whether processing is high-risk, DPIA templates, and procedures for documenting and maintaining DPIAs.

7. Breach Detection and Notification

GDPR Article 33 requires notification of personal data breaches to the data protection authority “without undue delay and, where feasible, not later than 72 hours after becoming aware of a breach.”

GDPR Article 34 requires notification to affected individuals if the breach is likely to result in high risk to their rights and freedoms.

A breach includes:

• Confidentiality breach — unauthorised or accidental disclosure of personal data
• Integrity breach — unauthorised or accidental alteration of personal data
• Availability breach — loss of access to personal data through unauthorised or accidental destruction

This creates a system requirement: you must have procedures for detecting breaches, assessing risk, notifying regulators and individuals within statutory timeframes, and investigating and mitigating breaches.

Systems implication: You must have monitoring systems detecting unauthorised access, procedures for risk assessment and notification, and incident response procedures.

---

Part 3: Core Components of GDPR Systems

Building compliant GDPR systems requires documented systems across seven functional areas.

1. Data Processing Inventory and Documentation

Purpose: Maintain a documented record of all processing activities, their lawful basis, and their compliance status.

System components:

• Data processing inventory — a comprehensive list of all processing activities, including:
  • What personal data is collected
  • From whom it is collected
  • For what purpose
  • On what lawful basis
  • Who has access to it
  • How long it is retained
  • Who it is shared with
  • Where it is stored (location, system)
• Controller and processor documentation — identification of who controls the data and who processes it on behalf of the controller
• Data flow mapping — documentation of how personal data moves through the organisation and to external parties
• System inventory — documentation of all systems holding personal data, their security controls, and their technical characteristics

Why it matters: GDPR Article 30 requires that controllers and processors maintain a “record of processing activities.” This is the foundation of accountability. Regulators’ first request in an investigation is typically: “Show us your processing inventory.”

Implementation: Most organisations maintain this inventory in a spreadsheet or RACI matrix. Larger organisations may use dedicated data governance software.

Review frequency: At minimum annually, but should be updated whenever processing changes (new systems implemented, data uses modified, new vendors engaged).

2. Privacy Notice and Transparency System

Purpose: Ensure individuals receive required privacy information at the correct time and in an understandable format.

System components:

• Privacy notice templates — standardised language appropriate to different processing contexts (online collection, offline collection, third-party data, etc.)
• Approval procedures — process for reviewing and approving privacy notices to ensure they contain all required information
• Delivery procedures — documented process for ensuring privacy notices are delivered to individuals at the point of data collection
• Accessibility procedures — process for ensuring privacy notices are accessible (multiple languages, accessible formats for people with disabilities)
• Version control — documentation of privacy notice versions and when they changed

Why it matters: Transparency is a foundational GDPR principle. Individuals must understand how their data will be used. Lack of clear privacy information is one of the most frequent grounds for regulatory enforcement.

Implementation: Maintain privacy notice templates. Establish approval procedures through legal or compliance function. Embed privacy notices in forms, websites, and data collection processes.

Review frequency: Annually minimum, but should be updated whenever:

• Processing purposes change
• New recipients receive data
• New technology or processing methods are implemented
• Retention periods change

3. Consent Management System

Purpose: For processing based on consent, capture, document, and manage individual consents.

System components:

• Consent capture mechanisms — technical or manual processes for individuals to provide explicit consent
• Consent recording — database or system recording:
  • Who consented
  • When they consented
  • What they consented to (specific purpose)
  • Whether consent was explicit or pre-ticked
  • IP address and timestamp of consent
• Consent withdrawal procedures — process allowing individuals to withdraw consent at any time
• Consent verification — ability to retrieve individual consent records upon request
• Granular consent — ability to capture separate consents for separate purposes rather than blanket consent

Why it matters: Consent without documentation is not consent under GDPR. Regulators specifically investigate consent management systems. Organisations without documented consent often face enforcement action.

Implementation: For simple consent (e.g., newsletter signup), standard form platforms (Mailchimp, HubSpot) provide adequate consent capture. For complex consent (multiple purposes, sensitive data), consider dedicated consent management platforms.

Red flags indicating inadequate systems:

• Pre-ticked opt-in boxes
• Combined consent for multiple purposes without granular options
• No record of when individuals consented
• No mechanism to withdraw consent

4. Data Subject Rights Management System

Purpose: Respond to data subject requests (access, rectification, erasure, etc.) within the statutory 30-day timeframe.

System components:

• Request reception procedures — process for receiving data subject requests through email, webforms, or other channels
• Request tracking — system for recording:
  • When request was received
  • What type of request (access, erasure, portability, etc.)
  • Status of response
  • When response was provided
• Data gathering procedures — process for identifying and collecting all personal data held by the organisation about an individual across all systems
• Review procedures — process for:
  • Reviewing data for accuracy and appropriateness
  • Identifying exemptions or restrictions on disclosure
  • Preparing data for release
• Response procedures — process for providing data to the individual in the correct format (usually PDF or portable format for access requests)
• Metrics and reporting — tracking of requests received, response times, and exemptions applied

Why it matters: Data subject requests are mandatory. Failure to respond within 30 days (or 90 days if complex) is a regulatory violation and grounds for enforcement.

Data subject access requests are also frequently the first indicator of a regulatory investigation. A data protection authority may submit an access request to test whether the organisation actually has procedures in place.

Implementation: Many organisations handle access requests manually. For organisations receiving numerous requests, consider dedicated tools (OneTrust, TrustArc, BigID) that can search across systems and compile responses.

Common failures:

• No documented procedure for receiving requests
• No tracking of request status or response deadlines
• Inability to gather data from all systems
• Responses provided late
• Responses incomplete or in inappropriate format

5. Data Protection Impact Assessment (DPIA) System

Purpose: Conduct structured risk assessments before implementing high-risk processing.

System components:

• DPIA trigger criteria — documented criteria for determining when processing is “high-risk” and requires assessment
• DPIA templates and guidance — standardised documentation format and guidance for conducting DPIAs
• DPIA process — documented procedure for:
  • Describing the processing activity
  • Assessing necessity and proportionality
  • Identifying risks to individuals
  • Documenting risk mitigations
  • Recording DPIA approval
• Escalation procedures — process for escalating high-risk processing to legal/compliance for review
• Authority consultation procedure — process for consulting the data protection authority if high risks cannot be adequately mitigated
• DPIA register — documented list of all DPIAs conducted

Why it matters: DPIA requirements are one of the most frequently overlooked GDPR obligations. Organisations routinely implement high-risk processing (new systems, data profiling, automated decision-making) without conducting DPIAs.

Regulators specifically investigate whether organisations have conducted required DPIAs. Failure to conduct a DPIA for high-risk processing is an independent violation, even if the processing itself complies with GDPR.

Implementation: Establish DPIA governance with:

• Clear trigger criteria (use a checklist)
• Templates for common scenarios (employee monitoring, customer profiling, vendor risk assessment)
• Approval process involving legal/compliance
• Documentation and filing system

Common failures:

• No criteria for determining when DPIA is required
• DPIAs conducted only after processing is implemented
• DPIAs that lack substantive risk analysis
• DPIAs not reviewed or approved
• No escalation of high-risk findings

6. Vendor Risk Management and Data Processor System

Purpose: Ensure that vendors and data processors handling personal data comply with GDPR.

System components:

• Processor assessment procedures — process for evaluating whether vendors are compliant processors before engaging them
• Data Processing Agreements (DPA) — contracts with processors specifying:
  • Scope of processing
  • Security obligations
  • Incident notification
  • Sub-processor requirements
  • Audit and inspection rights
  • Deletion of data upon termination
• Sub-processor management — process for identifying sub-processors (vendors used by processors) and obtaining authorisation before they process data
• Vendor audit and monitoring — process for periodically assessing vendor compliance
• Incident notification procedures — process requiring vendors to notify of breaches or security incidents
• Termination procedures — process requiring secure deletion of data when vendor relationships end
• Vendor register — documented list of all processors and sub-processors

Why it matters: Many data breaches involve vendor compromise or unauthorised access through vendor systems. GDPR holds organisations responsible for vendor compliance.

Additionally, many organisations claim GDPR compliance but have never assessed their vendors. Regulators investigate vendor management as part of enforcement.

Implementation:

• Implement vendor assessment questionnaire covering security, compliance, incident response
• Use DPA templates (standard templates are available from regulators)
• Maintain vendor register and DPA documentation
• Conduct periodic vendor audits or self-assessments
• Include contractual provisions requiring vendor incident notification

Common failures:

• No formal assessment of processor security
• No written Data Processing Agreements with processors
• Sub-processors used without authorisation
• No notification requirement for processor breaches
• No procedures for requiring data deletion when relationships end

7. Breach Detection and Response System

Purpose: Detect personal data breaches, assess regulatory notification requirements, and respond within statutory timeframes.

System components:

• Breach detection mechanisms — technical and procedural measures for identifying breaches:
  • Access logs and monitoring of systems handling personal data
  • Employee reporting procedures (whistleblower channels)
  • Vendor incident notification
  • Security event monitoring and alerting
• Breach documentation — record of:
  • When breach was discovered
  • How it was discovered
  • What data was affected
  • How many individuals affected
  • How the breach occurred
  • What measures were taken to contain it
• Risk assessment procedure — process for determining:
  • Whether the breach involves personal data
  • Whether it creates risk to individuals’ rights and freedoms
  • Whether it requires notification to regulators and/or individuals
• Regulatory notification procedure — process for:
  • Notifying the data protection authority within 72 hours
  • Providing required information (nature of breach, approximate number affected, likely consequences, measures taken)
  • Maintaining notification records
• Individual notification procedure — process for:
  • Notifying affected individuals if high-risk breach
  • Providing notice in plain language
  • Advising of individuals’ rights
  • Maintaining notification records
• Investigation and mitigation — process for:
  • Conducting forensic investigation
  • Preserving evidence
  • Identifying root cause
  • Implementing measures to prevent recurrence
• Breach register — documented record of all breaches

Why it matters: Breach response is where compliance theory meets real-world regulatory scrutiny. Regulators focus on:

• Whether organisations actually detect breaches
• Whether they notify within 72 hours
• Whether notifications contain required information
• Whether organisations conduct adequate investigations

Breach response systems reveal more about an organisation’s actual compliance maturity than any other system.

Implementation:

• Deploy monitoring systems for systems handling restricted data
• Establish clear escalation procedures and incident response team
• Document breach assessment criteria (when notification is required)
• Maintain templates for regulatory and individual notifications
• Conduct breach drills to test response procedures
• Maintain breach register documentation

Common failures:

• No monitoring of systems holding personal data
• Breaches discovered by third parties rather than by the organisation
• Delays in reporting to regulators (beyond 72 hours)
• Notifications lacking required information
• No investigation of root cause
• No measures implemented to prevent recurrence

8. Training and Awareness System

Purpose: Ensure employees understand GDPR obligations and comply with procedures.

System components:

• Mandatory training for all employees covering:
  • What GDPR is
  • What personal data is
  • Employees’ obligations
  • Basic data security practices
  • Procedures for data subject requests
• Role-specific training for employees with data responsibilities:
  • Data processors understanding processing activities
  • HR staff understanding data subject rights
  • IT staff understanding technical security obligations
  • Managers understanding data governance responsibilities
• Training frequency — initial training for new employees, refresher training annually
• Testing and certification — verification that employees understand obligations (quizzes, assessments)
• Documentation — records of who received training and when
• Incident response training — specific training for incident response team on breach response procedures

Why it matters: GDPR compliance depends on employee behavior. Many breaches and violations result from employee error or negligence. Training reduces risk by:

• Increasing awareness of data security obligations
• Reducing phishing and social engineering attacks
• Ensuring consistent handling of data subject requests
• Creating culture of data protection

Implementation:

• Develop or purchase GDPR training materials
• Require mandatory training for all employees
• Provide role-specific training for data-handling roles
• Maintain training records
• Conduct periodic refresher training

---

Part 4: Building and Implementing GDPR Systems

Assessment and Planning Phase

Before implementing systems, conduct a comprehensive assessment:

1. Regulatory scope assessment

• Which jurisdictions’ data protection laws apply to your organisation?
• Are you subject to EU GDPR, UK GDPR, other national laws?
• Do you operate in California (CCPA), Brazil (LGPD), or other jurisdictions with data protection laws?

2. Data processing assessment

• What personal data does your organisation process?
• Where does it come from?
• How is it used?
• Who has access to it?
• Where is it stored?
• Is it transferred internationally?

3. Compliance gap analysis

• Which GDPR obligations are currently met?
• Which obligations are partially met or not met?
• What systems and processes are missing?
• What is the risk of current gaps?

4. Prioritization

• Which gaps create the highest regulatory risk?
• Which gaps create the highest operational impact?
• What is the implementation timeline and resource requirement?

Implementation Approach

Effective GDPR system implementation follows this sequence:

Phase 1: Foundation (Months 1-3)

Establish baseline systems:

• Data processing inventory
• Privacy notices for main processing activities
• Data subject rights procedures
• Breach detection and notification procedures

Phase 2: Risk Management (Months 3-6)

Implement risk-focused systems:

• DPIA procedure and conduct DPIAs for high-risk processing
• Vendor risk management and Data Processing Agreements
• Data Protection by Design procedures

Phase 3: Maturity (Months 6-12)

Enhance systems:

• Consent management systems (if consent-based processing)
• Advanced monitoring and breach detection
• Training and awareness program
• Audit and monitoring procedures

Phase 4: Continuous Improvement (Ongoing)

• Regular review and update of systems (at least annually)
• Measurement of compliance metrics
• Response to regulatory guidance
• Incorporation of new technologies or business processes

Governance and Accountability

Effective GDPR systems require clear governance:

Accountability structure:

• Data Protection Officer or Lead — identified executive responsible for GDPR compliance
• Data Protection Committee — cross-functional team (legal, IT, operations, HR) meeting regularly to oversee GDPR implementation and governance
• Process owners — individuals responsible for each GDPR system (data inventory, privacy notices, DPA, breach response, etc.)

Approval and ownership:

• GDPR systems and policies should be approved by senior management or the board
• Board or audit committee should receive regular reporting on GDPR compliance status
• Compliance metrics should be tracked and reported

Documentation:

All GDPR systems should be documented in a GDPR governance manual or policy framework specifying:

• Who is responsible for each system
• What the procedure is
• When it is executed
• How compliance is monitored
• How the system is reviewed and updated

---

Part 5: Common GDPR System Gaps

Gap 1: No Documented Processing Inventory

The problem: Many organisations have not documented what personal data they process, where it is stored, or how it is used. This is the most fundamental GDPR requirement and its absence is indefensible in regulatory proceedings.

Why it happens: Creating a processing inventory requires effort across departments (IT identifies systems, business teams identify uses, HR identifies employee data, etc.). Many organisations defer this work indefinitely.

Risk: An organisation without a processing inventory cannot demonstrate GDPR compliance for any processing activity. This creates regulatory liability for every data processing activity.

Solution: Implement a structured approach:

1. Issue questionnaire to department heads asking what personal data they process
2. Conduct system audit to identify all systems storing personal data
3. Consolidate responses into processing inventory
4. Conduct spot-check validation with sample of responses
5. Establish update procedures for ongoing maintenance

Gap 2: Inadequate Privacy Notices

The problem: Privacy notices are often incomplete, written in impenetrable legal language, or not provided to individuals at the point of collection. Many organisations claim to comply with GDPR but have never updated privacy notices from previous versions.

Why it happens: Privacy notice drafting is often delegated to legal counsel who prioritise legal completeness over clarity. Updates are deferred because they are time-consuming.

Risk: Lack of clear privacy information violates GDPR Articles 13-14. Regulators specifically investigate privacy notices as part of compliance audits.

Solution:

1. Audit current privacy notices against GDPR requirements
2. Identify required information elements (controller identity, purpose, lawful basis, recipients, rights, retention, etc.)
3. Rewrite in plain language accessible to individuals
4. Implement version control and approval procedures
5. Establish regular review schedule (at least annually)
6. Test comprehensibility with sample users

Gap 3: No Consent Management System

The problem: Organisations using consent as a lawful basis often have no documented process for capturing consent. They may have pre-ticked boxes, blanket consent for multiple purposes, or no record of when individuals consented.

Why it happens: Consent capture is often treated as a technical implementation detail assigned to web developers or marketing. Legal requirements for consent capture are not enforced during implementation.

Risk: Consent without documentation is not consent under GDPR. Processing based on undocumented consent is unlawful. This is a frequent basis for regulatory enforcement.

Solution:

1. Audit current consent mechanisms for GDPR compliance
2. Identify instances of pre-ticked boxes or combined consent
3. Implement granular consent for separate purposes
4. Ensure explicit opt-in (not inferred from silence)
5. Document consent capture and recording procedures
6. Implement consent withdrawal mechanisms
7. Conduct regular audits of consent compliance

Gap 4: No Data Subject Rights Procedures

The problem: Organisations often have no documented procedure for handling data subject access requests. When requests arrive, response is ad hoc and often slow. Many organisations cannot gather data from all systems holding personal data about an individual.

Why it happens: Data subject requests are infrequent for many organisations, so procedures are not prioritised. When requests do arrive, responsibility is unclear about who handles them.

Risk: Failure to respond to access requests within 30 days is a direct GDPR violation. Incomplete responses (missing data from one system) also violate the right of access.

Solution:

1. Designate clear responsibility for handling data subject requests
2. Establish request reception procedures (email, webform, etc.)
3. Map all systems holding personal data about individuals
4. Develop data gathering procedures for each system
5. Establish review procedures (accuracy, exemptions, format)
6. Implement response procedures and tracking system
7. Establish 30-day response deadline with escalation procedures
8. Maintain documentation of all requests and responses

Gap 5: DPIAs Not Conducted for High-Risk Processing

The problem: Many organisations implement new systems or processing activities without conducting required Data Protection Impact Assessments. DPIAs are often seen as an administrative burden rather than a risk management process.

Why it happens: DPIA requirements are not widely understood. Project teams implementing systems focus on technical requirements, not GDPR compliance. Legal/compliance teams are not consulted during implementation planning.

Risk: Failure to conduct a DPIA for high-risk processing is an independent GDPR violation. Processing implemented without DPIA often contains risks that could have been identified and mitigated prospectively.

Solution:

1. Establish clear DPIA trigger criteria
2. Integrate DPIA into project governance (require DPIA for new systems, significant data processing changes)
3. Develop DPIA templates and guidance
4. Train project managers on DPIA requirements
5. Implement escalation procedure for high-risk findings
6. Maintain DPIA register with evidence of completion
7. Conduct periodic audits to identify high-risk processing that missed DPIA

Gap 6: Weak or No Vendor Risk Management

The problem: Many organisations have not assessed whether their vendors comply with GDPR. They have not executed Data Processing Agreements with vendors. They do not require vendors to notify of breaches.

Why it happens: Vendor assessment is seen as an extra burden on vendor selection. Procurement teams prioritise cost and functionality, not compliance. Legal teams are not consistently involved in vendor management.

Risk: Organisations are liable for vendor compliance with GDPR. A vendor breach or non-compliance can create regulatory liability for the organisation, not just the vendor.

Solution:

1. Audit current vendors for processing of personal data
2. Develop vendor assessment questionnaire
3. Conduct assessment of existing vendors
4. Implement Data Processing Agreement template
5. Require DPAs before new vendors process personal data
6. Map sub-processors and obtain authorisation before use
7. Establish vendor audit procedures (annual or periodic)
8. Require incident notification provisions
9. Establish procedures for data deletion when relationships end
10. Maintain vendor register with DPA documentation

Gap 7: Insufficient Breach Detection and Monitoring

The problem: Many organisations have no systematic breach detection. They rely on external parties (customers, security researchers, news reports) to discover breaches. When breaches are discovered, response is often slow and incomplete.

Why it happens: Breach detection requires investment in monitoring systems. Many organisations lack resources or technical capability to implement monitoring. Breach response procedures may not be defined until a breach occurs.

Risk: Organisations that do not detect their own breaches have no ability to comply with the 72-hour notification requirement. Regulators view reactive breach discovery as evidence of inadequate compliance systems.

Solution:

1. Deploy monitoring systems for systems holding restricted personal data
2. Establish access logging and alerting
3. Define breach response team and assign responsibilities
4. Establish breach assessment criteria and notification decision tree
5. Create breach notification templates
6. Establish escalation procedures and communication protocols
7. Implement forensic investigation procedures
8. Maintain breach register documentation
9. Conduct breach response drills regularly

---

Part 6: GDPR Systems and Regulatory Enforcement

What Regulators Look For

Regulatory investigations typically focus on whether organisations have implemented and followed documented systems. Regulators assess:

1. Documentation

• Do you have documented procedures for each GDPR obligation?
• When were procedures adopted?
• Who approved them?

2. Consistency

• Are procedures actually followed?
• When procedures were not followed, was that exceptional or routine?
• What controls ensure procedures are followed?

3. Evidence

• Can you produce evidence of compliance (training records, DPIAs, Data Processing Agreements, breach registers, access request responses)?
• Are records maintained and retrievable?

4. Governance

• Who is responsible for GDPR compliance?
• Is there oversight and accountability?
• Has compliance performance been reported to leadership?

5. Effectiveness

• Have the systems actually reduced risk and violations?
• Are there metrics showing system performance?

Organisations with documented systems that are actually followed, with evidence of compliance maintained, face substantially lower enforcement risk than organisations with better practices but no documentation.

Common Enforcement Actions

Recent GDPR enforcement actions reveal regulatory patterns:

Failure to maintain processing inventory — €50 million fine for organisation unable to produce documented processing inventory during investigation

Inadequate Data Processing Agreements — €20 million fine for processing through vendors without documented processor agreements

Failure to conduct DPIAs — €30 million fine for implementing high-risk processing without conducting required impact assessments

Inadequate breach response — €40 million fine for failure to detect and report breach within 72 hours

Inadequate consent — €90 million fine for processing based on pre-ticked consent boxes and combined consent for multiple purposes

Weak vendor management — €27 million fine for vendor breach resulting from inadequate processor due diligence

The pattern is consistent: organisations face enforcement for having inadequate systems, not for isolated violations.

---

Part 7: GDPR Systems as Competitive Advantage

Organisations often view GDPR compliance as regulatory burden. This perspective misses a significant business opportunity.

Effective GDPR systems create several competitive advantages:

1. Customer Confidence
Customers increasingly require evidence of data protection compliance before engaging vendors. Organisations with documented GDPR systems can credibly demonstrate compliance, creating competitive advantage in customer acquisition.

2. Data Quality and Governance
The process of building GDPR systems (data mapping, inventory, retention procedures) inherently improves data quality and governance. This creates operational benefits beyond compliance: better decision-making, lower storage costs, reduced data sprawl.

3. Risk Reduction
Documented systems reduce regulatory enforcement risk and liability from data breaches. This reduces insurance costs and increases attractiveness to investors.

4. Operational Efficiency
Documented procedures for breach response, data subject requests, and vendor management reduce time and cost of managing these activities. Clear procedures also reduce errors and rework.

5. Employee Confidence
Employees are more productive and engaged when they understand data protection obligations and see leadership commitment to privacy. GDPR systems send a signal that data protection is a priority.

6. Vendor Management
Effective vendor management systems (assessment, DPAs, monitoring) create better vendor relationships and reduce vendor-related risk.

---

Part 8: GDPR Systems and Sector-Specific Considerations

Technology and SaaS Companies

SaaS and technology companies face particular GDPR challenges:

• Large-scale data processing — SaaS companies often process personal data of millions of individuals
• International data transfers — SaaS companies typically operate globally, creating data transfer complexities
• Sub-processor requirements — SaaS companies often use cloud infrastructure and other sub-processors
• High-risk processing — many SaaS services involve profiling, analytics, automated decision-making

Priorities for tech companies:

• Robust vendor risk management (especially cloud providers)
• Documented sub-processor management
• Clear processor-controller responsibilities
• International data transfer compliance mechanisms
• Strong breach detection systems

Financial Services

Financial services firms face strict GDPR requirements due to the sensitivity of financial data:

• Customer data protection — customer financial information is highly sensitive
• Regulatory overlap — financial services are subject to both GDPR and sector-specific regulations (banking regulations, insurance directives)
• Contract-based processing — financial services often process data based on contract (client data for account management)
• Fraud prevention — financial institutions process data for fraud detection and prevention

Priorities for financial services:

• Strong access controls for sensitive data
• Robust breach detection and response
• Data subject rights procedures (financial data requires special handling)
• Processing inventory aligned with banking regulations
• Vendor compliance (especially payment processors and data providers)

Healthcare

Healthcare organisations face healthcare-specific data protection requirements in addition to GDPR:

• Sensitive health data — health data is explicitly protected under GDPR
• Patient rights — healthcare regulations provide patient access and privacy rights
• Business continuity — healthcare systems must remain available even during incidents
• Sector-specific regulations — many jurisdictions have healthcare-specific data protection requirements

Priorities for healthcare:

• Data Protection Impact Assessments for all patient systems
• Robust consent management (much healthcare processing is consent-based)
• Strong breach detection and response (patient privacy breaches are particularly sensitive)
• Access controls for sensitive health data
• Patient rights procedures (patients have strong rights over health data)

HR and Employment

HR and employment data is particularly sensitive, triggering enhanced protections:

• Employee privacy expectations — employees expect strong protection of their personal data
• Workplace monitoring — monitoring of employee activity requires careful GDPR compliance
• Sensitive data — employment records often contain sensitive data (health, diversity, disciplinary)
• International assignments — multinational companies must manage employee data across jurisdictions

Priorities for HR:

• Clear lawful basis for HR data processing
• Consent management for non-employment processing (internal communications, non-work related data)
• DPIA for monitoring, profiling, or automated decision-making
• Vendor compliance for HR systems and vendors
• Employee training on data protection rights and obligations

---

Conclusion

GDPR compliance is not a project with a completion date. It is a governance framework requiring documented, maintained systems across seven functional areas: data processing inventory, privacy notices, consent management, data subject rights, DPIAs, vendor management, and breach response.

Organisations with mature GDPR systems—documented, implemented, monitored, and regularly reviewed—face substantially lower regulatory enforcement risk and create competitive advantage through customer confidence and operational efficiency.

The organisations most exposed to GDPR enforcement are not those with imperfect systems, but those that have not implemented documented systems at all. Regulators and courts do not require perfection; they require accountability. Documented systems demonstrate accountability.

The cost of building and maintaining GDPR systems is modest relative to the cost of regulatory enforcement actions, which routinely exceed millions in fines, legal fees, and reputational harm. Building systems proactively is substantially more cost-effective than defending against regulatory enforcement.

---

LES & Partners provides advisory services in GDPR compliance, data protection systems design, and implementation. If your organisation requires assessment of current GDPR compliance or development of documented data protection systems aligned to regulatory requirements, we are available for consultation.

Practice areas:

• GDPR compliance assessment and system design
• Data Protection Impact Assessments
• Privacy notice and consent management
• Vendor risk management and Data Processing Agreements
• Breach response procedures and incident management
• International data transfer compliance
• Sector-specific compliance (SaaS, financial services, healthcare)

Contact us: info@les-partners.com