GDPR Compliance Program: From Gap Assessment to DPC Certification in 19 Steps
A practical guide for DPOs and privacy consultants on using Rakenne's GDPR Compliance Program workspace template to build a complete EU GDPR compliance programme — with dual-track support for EU-wide and Ireland DPC approaches, and tool-assisted validation at every step.
The EU General Data Protection Regulation has 99 articles, 173 recitals, and a growing body of EDPB guidelines, CJEU case law, and national supervisory authority guidance. Organizations processing EU personal data need to demonstrate compliance across every dimension — lawful basis, transparency, data subject rights, security, breach notification, international transfers, and processor management. The documentation burden is enormous, and a single inconsistency between your ROPA and your privacy notices, or between your legal basis register and your consent forms, can unravel the entire programme under supervisory authority scrutiny.
Rakenne’s GDPR Compliance Program workspace template provides 19 specialized skills covering the full GDPR lifecycle. Unlike single-framework templates, GDPR compliance has two natural entry points: an EU-wide gap assessment across 14 GDPR domains, or alignment with the Ireland Data Protection Commission’s Self-Assessment Checklist. The workspace supports both tracks — and lets you combine them for comprehensive coverage.
This guide walks through all 6 phases, shows real dialog excerpts from a live session, and explains what makes validated compliance documentation materially better than generic AI drafting.
Why plain LLMs fall short for GDPR
A plain LLM can draft privacy policies and DPIA reports. Where it struggles is regulatory-grade validation:
| Concern | Plain LLM | Rakenne with GDPR skills |
|---|---|---|
| Legal basis determination | May conflate legitimate interest with consent | Validates that each processing activity has a documented legal basis with Art. 6(1) citation and supporting analysis |
| ROPA completeness | May omit required Art. 30 fields | Checks all mandatory fields: purposes, data categories, recipients, transfers, retention periods, security measures |
| DPIA screening | May miss high-risk processing triggers | Validates against Art. 35(3) criteria and EDPB’s 9 screening criteria from Guidelines on DPIA (wp248rev.01) |
| Consent validity | May produce consent forms that fail EDPB tests | Checks against EDPB Guidelines 05/2020: freely given, specific, informed, unambiguous, withdrawable |
| Cross-document consistency | ROPA may list “consent” while privacy notice says “legitimate interest” | Cross-references legal basis register, consent forms, privacy notices, and ROPA for consistency |
| Supervisory authority alignment | Generic advice, not authority-specific | DPC skills align to the published Self-Assessment Checklist; UK skills follow ICO-specific DPIA guidance |
The difference is structural: each skill gives the agent a defined workflow, GDPR-specific references (articles, recitals, EDPB guidelines, CJEU case law), and built-in validation tools to verify its own output. This is what turns a draft into a supervisory-authority-ready artifact.
The dual-track approach
Unlike ISO frameworks with a single certification path, GDPR compliance has two natural entry points:
Track 1: EU-Wide GDPR — Start with the gdpr-gap-assessment skill for a structured maturity assessment across 14 GDPR domains (lawfulness, transparency, data subject rights, security, breach notification, DPIAs, international transfers, processor management, and more). This produces a prioritised remediation roadmap that drives the rest of the programme. Best for organisations with EU-wide operations or multiple supervisory authorities.
Track 2: Ireland DPC Self-Assessment — Start with the dpc-gdpr-readiness skill to align with the DPC’s published Self-Assessment Checklist covering 8 compliance areas. This track is tailored for organisations whose Lead Supervisory Authority is the Ireland DPC — particularly relevant for US tech companies with EU headquarters in Ireland.
You can combine both tracks. The gap assessment provides the strategic overview; the DPC checklist provides the tactical, authority-specific alignment.
The 6-phase compliance lifecycle
The workspace template installs 19 skills that map to 6 phases:
| Phase | Skills | What gets validated |
|---|---|---|
| Assessment & Foundation | Gap Assessment, DPC Readiness, Privacy by Design | Domain maturity scores, DPC checklist alignment, Art. 25 principles coverage |
| Legal Basis & Transparency | Personal Data, Consent Forms, Legitimate Interest Assessment, Transparency | Legal basis per processing activity, EDPB consent validity, three-part LIA, Art. 13/14 notice completeness |
| Core Documentation | ROPA & DPIA, Controller Obligations | Art. 30 field completeness, Art. 35 screening criteria, Art. 28 processor agreements |
| Rights & Security | Data Subject Rights, Data Security, Breach Preparedness, Breach Notification | SAR response procedures, Art. 32 security measures, 72-hour notification workflow |
| Data Lifecycle | Accuracy & Retention, International Transfers | Retention schedules, transfer inventory, SCC/TIA documentation |
| Vendor Management | Vendor & Processor Audit | Art. 28(3)(a–h) verification, sub-processor chain audit |
Optional skills: DPC Certification, Lead SSA (cross-border), UK GDPR DPIA.
Each skill reads the deliverables produced by earlier phases — the gap assessment findings prioritise which phases to focus on, the legal basis register feeds consent forms and privacy notices, the ROPA feeds DPIAs and controller obligations, and the security programme feeds breach procedures.
Phase 1: Assessment & Foundation
Step 1: Gap Assessment — 14 domains, one prioritised roadmap
The GDPR Gap Assessment skill performs a structured maturity assessment across 14 GDPR domains, scoring each from 0 (non-existent) to 5 (optimised). The findings register captures specific gaps, and the remediation roadmap prioritises them by risk and regulatory exposure.
You: DataBridge Analytics is a 180-person data analytics company headquartered in Dublin, with offices in Berlin and São Paulo. We process behavioural analytics data for 200+ enterprise clients across the EU. Our Lead Supervisory Authority is the Ireland DPC. We use AWS (eu-west-1) for infrastructure, Snowflake for data warehousing, and Segment for data collection. Our DPO is Sarah Brennan.
Agent: I’ll conduct the gap assessment across all 14 GDPR domains. Let me start by evaluating your current state against each domain.
I’ve completed the assessment. Here are the maturity scores:
Domain Score Key Finding Lawfulness & Legal Basis 2/5 Legal basis documented for primary processing but not for secondary analytics uses Consent Management 1/5 No centralised consent management; consent forms don’t meet EDPB 05/2020 requirements Transparency 3/5 Privacy policy exists but Art. 14 notices for indirect collection are missing Data Subject Rights 2/5 SAR process exists but no automated workflows; erasure and portability procedures undocumented ROPA & Accountability 1/5 No formal Art. 30 ROPA; processing activities tracked informally in spreadsheets DPIA Programme 0/5 No DPIA screening criteria or completed DPIAs despite high-risk behavioural profiling Data Security 3/5 Good technical controls but Art. 32 documentation incomplete Breach Notification 2/5 Incident response plan exists but 72-hour DPC notification procedure not formalised Running validation… PASS — All 14 domains assessed with scored maturity, specific findings, and evidence references.
Critical gap: Your behavioural analytics processing likely triggers Art. 35(3)(a) — systematic and extensive profiling with significant effects. A DPIA is legally required, and its absence is the highest-risk finding.
I’ve produced the findings register (23 findings) and a 4-wave remediation roadmap prioritised by regulatory risk.
The validator checks that every domain has a numeric score, at least one specific finding, and that the remediation roadmap addresses findings in risk order — not alphabetical. It also cross-references Art. 35(3) screening criteria against the organisation’s described processing activities to flag legally required DPIAs that haven’t been completed.
Step 2: Privacy by Design — the Art. 25 assessment
You: Assess our Snowflake data pipeline against Privacy by Design principles. We collect clickstream data via Segment, process it in Snowflake, and serve analytics dashboards to clients.
Agent: I’ve assessed the data pipeline against the 7 foundational principles and Hoepman’s 8 design strategies. Let me validate.
Principles coverage: PASS — All 7 principles assessed: Proactive not Reactive (2/5), Privacy as Default (1/5), Privacy Embedded in Design (2/5), Full Functionality (3/5), End-to-End Security (3/5), Visibility & Transparency (2/5), Respect for User Privacy (2/5).
Key recommendation: Your Segment integration collects all clickstream events by default and filters later. Art. 25(2) requires data protection by default — you should collect only what’s necessary for the stated purpose and apply purpose-specific filters at the collection layer, not the analytics layer.
I’ve produced the Privacy by Design assessment with specific remediation actions mapped to each principle.
Phase 2: Legal Basis & Transparency
Step 3: Personal Data / Legal Basis — grounding every processing activity
The Personal Data skill establishes a legal basis register: for every processing activity, document which Art. 6(1) ground applies, whether special category data (Art. 9) is involved, and any additional conditions.
You: Document the legal basis for our 8 main processing activities: client analytics, marketing emails, employee HR data, payroll, website cookies, client onboarding, fraud detection, and product improvement research.
Agent: I’ve drafted the legal basis register. Let me validate each entry.
Legal basis validation:
- Client analytics: Legitimate interest (Art. 6(1)(f)) — requires a Legitimate Interest Assessment ✓
- Marketing emails: Consent (Art. 6(1)(a)) — requires EDPB-compliant consent mechanism ✓
- Employee HR: Contract performance (Art. 6(1)(b)) + Legal obligation (Art. 6(1)(c)) for statutory requirements ✓
- Fraud detection: Legitimate interest (Art. 6(1)(f)) — WARNING: if this involves automated decision-making with legal effects, Art. 22 applies and you need explicit consent or a legal basis under Art. 22(2)
Cross-reference check: PASS — All 8 processing activities are consistent with the gap assessment’s data mapping. No orphaned activities.
Step 4: Consent Forms — EDPB 05/2020 validated
You: Create consent forms for marketing emails and website analytics cookies. We need granular cookie consent with separate toggles for analytics, marketing, and functional cookies.
Agent: I’ve drafted both consent mechanisms. Let me validate against EDPB Guidelines 05/2020.
Consent validity check:
- Freely given: PASS — consent is not bundled with service access; users can decline without losing functionality
- Specific: PASS — separate consent for each purpose (marketing emails, analytics cookies, marketing cookies)
- Informed: PASS — each consent form identifies the controller, purposes, data categories, recipients, and rights
- Unambiguous: PASS — affirmative action required (checkbox, not pre-ticked); no ambiguous language
- Withdrawable: PASS — withdrawal mechanism described and as easy as giving consent
Special category check: N/A — no Art. 9 data involved in these processing activities.
I’ve produced consent form templates with implementation notes for your frontend team.
Marketing Email Consent Form
DataBridge Analytics would like to send you updates about our products, services, and industry insights.
What we’ll send: Product updates, feature announcements, and data analytics industry content. Approximately 2–4 emails per month.
What we collect: Your email address and engagement data (opens, clicks) to improve our communications.
Your rights: You can withdraw consent at any time by clicking “Unsubscribe” in any email or contacting privacy@databridge.eu . Withdrawal does not affect the lawfulness of processing before withdrawal.
☐ I consent to receiving marketing emails from DataBridge Analytics.
This consent is voluntary. You can use our services without subscribing to marketing emails.
Step 5: Legitimate Interest Assessment — the three-part test
You: Conduct an LIA for our client analytics processing. We aggregate clickstream data to provide clients with user behaviour insights.
Agent: I’ve conducted the three-part Legitimate Interest Assessment per EDPB Opinion 06/2014 and updated Opinion 08/2024. Let me validate.
Part 1 — Purpose test: PASS. The interest is legitimate (providing contracted analytics services), specific (behavioural analytics for named clients), and real (core business activity, not speculative).
Part 2 — Necessity test: PASS. The processing is necessary to achieve the purpose. Less intrusive alternatives were considered: anonymised analytics (insufficient — clients need cohort-level behavioural patterns that require pseudonymised data), sampling (insufficient — statistical significance requires full dataset).
Part 3 — Balancing test: WARNING. The balancing test needs strengthening. Data subjects are website visitors who may not reasonably expect their clickstream data to be processed for third-party analytics. Mitigating measures recommended:
- Prominent Art. 14 privacy notice on client websites informing visitors of analytics processing
- Pseudonymisation applied at the collection layer (Segment) before data reaches Snowflake
- Opt-out mechanism via the client’s cookie consent tool
With these safeguards, the balancing test is satisfied — the legitimate interest is not overridden by data subject rights. I’ve documented the CJEU Meta Platforms (C-252/21) balancing criteria.
Step 6: Transparency — Art. 13/14 privacy notices
You: Create privacy notices for: (1) our website visitors (Art. 13 — direct collection), and (2) data subjects whose data we receive indirectly through our clients’ websites (Art. 14 — indirect collection).
Agent: I’ve drafted both privacy notices. Let me validate completeness.
Art. 13 notice (direct collection): PASS — All 11 required elements present: controller identity, DPO contact, purposes, legal basis, recipients, transfers, retention, rights, right to complain, automated decision-making, and source (N/A for direct).
Art. 14 notice (indirect collection): PASS — All 12 required elements present, including the additional Art. 14(2)(f) requirement to state the source of personal data and whether it came from publicly accessible sources. Source identified as: “Personal data is collected through our clients’ websites via tracking technologies deployed under their own privacy notices.”
Layered notice structure: I’ve produced a short-form notice (first layer) and a comprehensive notice (second layer) per the Article 29 Working Party’s transparency guidelines.
Phase 3: Core Documentation
Step 7: ROPA & DPIA — the compliance backbone
The ROPA & DPIA Author skill produces the two most critical GDPR artifacts: the Art. 30 Records of Processing Activities and Art. 35 Data Protection Impact Assessments.
You: Build the ROPA for all 8 processing activities from our legal basis register, then conduct a DPIA for the client analytics processing.
Agent: I’ve built the Art. 30 ROPA. Let me validate field completeness.
ROPA validation: PASS — All 8 processing activities have the mandatory Art. 30(1) fields: controller name, DPO contact, purposes, data subject categories, personal data categories, recipients, third-country transfers, retention periods, and security measures description.
Cross-reference check: PASS — Legal basis for each activity matches the legal basis register. No discrepancies between ROPA purposes and transparency notice descriptions.
Now conducting the DPIA for client analytics…
DPIA screening: The client analytics processing triggers 3 of the EDPB’s 9 screening criteria:
- Systematic monitoring (criterion 3) — continuous tracking of website visitor behaviour
- Large scale processing (criterion 5) — 200+ enterprise clients, millions of data subjects
- Combining datasets (criterion 7) — cross-domain clickstream aggregation
Meeting 2+ criteria makes a DPIA mandatory per EDPB Guidelines. I’ve completed the full DPIA with risk assessment and mitigation measures.
DPIA validation: PASS — Systematic description of processing, necessity and proportionality assessment, risk assessment to rights and freedoms, and risk mitigation measures all documented.
Step 8: Controller Obligations
You: Document our controller obligations. We use 4 processors: AWS (infrastructure), Snowflake (data warehouse), Segment (data collection), and SendGrid (email).
Agent: I’ve documented the accountability framework. Let me validate.
Art. 28 processor agreements: PASS — All 4 processors have documented agreements covering the Art. 28(3) mandatory clauses: (a) documented instructions, (b) confidentiality, (c) security, (d) sub-processor approval, (e) data subject rights assistance, (f) deletion/return, (g) audit rights, and (h) DPA notification.
DPO appointment: PASS — Sarah Brennan appointed as DPO under Art. 37(1)(b) — core activities consist of large-scale regular and systematic monitoring of data subjects. DPO contact details published and communicated to the DPC.
DPIA trigger procedures: PASS — Screening criteria documented, review threshold defined (any new processing activity or significant change to existing activities), and escalation to DPO for assessment.
Phase 4: Rights & Security
Step 9: Data Subject Rights — procedures for all 8 rights
You: Create procedures for handling data subject requests. We receive about 15 SARs per month from end users whose data appears in our analytics.
Agent: I’ve documented procedures for all 8 data subject rights. Let me validate.
Rights coverage: PASS — All rights documented:
- Access (Art. 15) — SAR intake, identity verification, 30-day response, extension procedures
- Rectification (Art. 16) — correction workflow, notification to recipients
- Erasure (Art. 17) — deletion criteria, exceptions (legal obligations, public interest), propagation to processors
- Restriction (Art. 18) — flagging mechanism in Snowflake, conditions for lifting restriction
- Portability (Art. 20) — machine-readable export format (JSON/CSV), direct transmission procedures
- Objection (Art. 21) — legitimate interest balancing test re-evaluation, direct marketing opt-out
- Automated decision-making (Art. 22) — human review procedures for profiling outputs
- Withdrawal of consent (Art. 7(3)) — withdrawal mechanism, cessation of processing, no impact on prior lawfulness
Response time tracking: Each procedure includes the statutory deadline (30 days, extendable to 90 days for complex requests), escalation triggers, and the DPO review threshold.
Volume recommendation: At 15 SARs/month, I recommend implementing an automated SAR intake portal rather than manual email processing. The procedure documents both the current manual workflow and a recommended automated workflow.
Steps 10–12: Security, breach preparedness, and DPC notification
Data Security (
dpc-gdpr-data-security) — produces Art. 32 security programme documentation: technical measures (encryption at rest and in transit, access controls, pseudonymisation), organisational measures (security training, incident procedures, vendor security assessments), and risk assessment. The validation checks that every security measure maps to a specific risk identified in the DPIA.Breach Preparedness (
dpc-gdpr-data-breaches) — produces the incident response plan, breach severity assessment matrix, and breach register template. The validation checks that the 72-hour notification timeline is realistic given the organisation’s detection and assessment capabilities.Breach Notification (
dpc-gdpr-breach) — produces DPC-specific breach notification templates and the post-breach review procedure. The Art. 33/34 notification templates include all mandatory fields: nature of breach, categories and approximate number of data subjects affected, DPO contact, likely consequences, and measures taken or proposed.
Agent: After completing all 3 security and breach skills, breach readiness is at 85%. The 15% gap is in detection capability — your current monitoring doesn’t cover all data exfiltration vectors. Specifically:
- Snowflake query audit logs are enabled but not integrated with your SIEM
- No DLP controls on the Segment data pipeline
I’ve flagged these in the security programme as priority remediation items and noted them in the DPIA risk mitigation section for cross-reference.
Phase 5: Data Lifecycle & Transfers
Step 13: Accuracy & Retention
You: Create our data retention policy. Client analytics data should be retained for 2 years, employee data for 7 years after departure (statutory requirement), and marketing consent records indefinitely as proof of consent.
Agent: I’ve drafted the retention policy. Let me validate.
Retention schedule validation: PASS — All 8 processing activities have defined retention periods with legal justification:
- Client analytics: 2 years from collection — justified by legitimate interest balancing (data utility diminishes beyond this period)
- Employee HR: 7 years post-departure — justified by statutory employment law retention requirements
- Consent records: retained for the duration of the processing relationship + 3 years — WARNING: “indefinite” retention fails the minimisation principle. I’ve adjusted to relationship duration + 3 years (statute of limitations for regulatory action), with periodic review.
Secure destruction procedures: PASS — Documented for each data store: Snowflake (time-travel disabled after retention period, then permanent deletion), AWS S3 (lifecycle policy with MFA-protected deletion), email (automated purge via retention labels).
Step 14: International Transfers
You: Document our international transfers. Snowflake and AWS are US-based (but data stays in eu-west-1). Segment processes data in the US. We also have the São Paulo office accessing analytics dashboards.
Agent: I’ve built the transfer inventory. Let me validate each transfer mechanism.
Transfer assessment:
- AWS (eu-west-1): No transfer — data at rest and in transit within EU. However, AWS support access from the US constitutes a transfer. Covered by AWS’s SCCs (controller-to-processor, Module 2).
- Snowflake (eu-west-1): Same assessment as AWS — data in EU, but US-based support access covered by Snowflake’s SCCs.
- Segment (US processing): Art. 46(2)(c) SCCs required. Transfer Impact Assessment needed — US surveillance law risk assessment per Schrems II (C-311/18).
- São Paulo office: Brazil has an EU adequacy decision (as of 2025). No supplementary measures required.
TIA for Segment: I’ve drafted the Transfer Impact Assessment covering US surveillance laws (FISA 702, EO 12333), the effectiveness of SCCs as a transfer mechanism, and supplementary measures (encryption in transit, data minimisation before transfer, contractual commitments regarding government access requests).
Phase 6: Vendor Management
Step 15: Vendor & Processor Audit
You: Audit our 4 processors against Art. 28(3) requirements. Prioritise Segment since it involves US data transfers.
Agent: I’ve completed the Art. 28(3)(a–h) verification for all 4 processors. Let me validate.
Segment (HIGH priority — US transfer):
- (a) Documented instructions: PASS — DPA Section 3 specifies processing only per controller instructions
- (b) Confidentiality: PASS — employee NDAs and annual training documented
- (c) Security: WARNING — SOC 2 Type II report available but last audit was 14 months ago. Request updated report.
- (d) Sub-processor approval: PASS — current sub-processor list published, 30-day notification of changes
- (e) Data subject rights: PASS — SAR assistance procedures in DPA Annex B
- (f) Deletion/return: WARNING — DPA allows 90-day deletion window, which exceeds your 30-day retention trigger. Negotiate reduction to 30 days.
- (g) Audit rights: PASS — right to audit documented, SOC 2 accepted as proxy
- (h) DPA notification: PASS — obligation to notify of any government access request
Sub-processor chain: Segment uses 3 sub-processors. All have SCCs. I’ve documented the chain in the vendor audit report with transfer mechanisms for each.
Optional: DPC Certification, Lead SSA, UK GDPR
Three additional skills cover specialised scenarios:
DPC Certification (
dpc-gdpr-certification) — For organisations pursuing a DPC-approved certification scheme under Art. 42. Assesses readiness against certification body requirements (INAB-accredited bodies in Ireland) and produces the certification maintenance plan.Lead SSA / Cross-Border (
dpc-lead-ssa-ropa) — For US multinationals with EU operations. Documents the main establishment justification (why Ireland is your lead authority), the One-Stop-Shop mechanism, and produces a Lead Supervisory Authority ROPA.UK GDPR DPIA (
uk-gdpr-dpia) — For organisations also subject to the UK GDPR post-Brexit. Covers ICO-specific DPIA screening criteria, UK GDPR divergences from EU GDPR, and UK transfer mechanisms (International Data Transfer Agreement, UK Addendum to EU SCCs).
The dashboard: tracking progress across all 6 phases
As each skill completes, the agent updates the project dashboard. The dashboard provides a single view of compliance programme progress:
Key metrics tracked:
- GDPR Compliance Readiness — weighted percentage across 6 areas: Assessment & Foundation (15%), Legal Basis & Transparency (20%), Core Documentation (20%), Rights & Security (20%), Data Lifecycle (15%), Vendor Management (10%)
- Compliance Track — EU-Wide / DPC Ireland / Both
- Current Phase — which phase is active
- Gap Maturity Scores — heatmap of 14-domain maturity ratings (0–5)
- Legal Basis Coverage — percentage of processing activities with documented legal basis
- Processing Activities Documented — ROPA entries
- DPIAs Completed — count of completed impact assessments
- Data Subject Rights Procedures — table showing status per right
- Breach Readiness — percentage based on security and breach preparedness skills
- DPC Checklist Completion — percentage for DPC-track users
- Transfers Documented — count of documented international transfers
- Processors Audited — count of completed processor audits
The dashboard gives DPOs and privacy consultants a real-time view of where the programme stands and what still needs attention — without digging through individual artifacts.
How the documents connect
GDPR compliance programmes fall apart when documents contradict each other — a privacy notice claiming “consent” while the ROPA shows “legitimate interest”, or a DPIA listing risks that the security programme doesn’t address. The GDPR workspace enforces cross-document consistency:
- Gap Assessment identifies maturity gaps and prioritises the remediation roadmap
- Legal Basis Register grounds every processing activity in a specific Art. 6(1) ground
- Consent Forms and LIAs provide the supporting analysis for consent and legitimate interest bases
- Privacy Notices reference the exact purposes and legal bases from the register
- ROPA documents each processing activity with the same legal basis, purposes, and data categories
- DPIAs screen processing activities from the ROPA against Art. 35(3) criteria
- Controller Obligations ensure processor agreements cover every processor in the ROPA
- Security Programme addresses risks identified in DPIAs
- Breach Procedures operationalise the security programme’s incident response
- Retention Policy aligns with ROPA retention periods
- Transfer Documentation covers every third-country transfer in the ROPA
- Vendor Audits verify every processor in the controller obligations register
When the agent produces a DPIA, it loads the ROPA and legal basis register to ensure consistency. When it writes a privacy notice, it cross-references the legal basis register. When it audits a processor, it checks the controller obligations for the contract terms. This traceability chain means a supervisory authority can follow any thread from top to bottom and find consistent documentation.
Effort comparison: with and without tool assistance
Based on typical GDPR compliance programme effort for a mid-sized data controller:
| Activity | % of effort | Tool-assisted acceleration |
|---|---|---|
| Gap assessment & programme scoping | 10% | Structured 14-domain assessment with maturity scoring prevents ad hoc gap identification |
| Legal basis determination & analysis | 15% | Cross-referencing between processing activities, legal bases, and supporting analyses (consent, LIA) catches inconsistencies |
| ROPA & DPIA authoring | 20% | Art. 30 field completeness validation and Art. 35(3) screening criteria prevent omissions that trigger supervisory authority criticism |
| Privacy notices & transparency | 10% | Art. 13/14 completeness checks ensure all mandatory elements are present; cross-referencing with legal basis register prevents misstatements |
| Data subject rights procedures | 10% | All 8 rights covered with statutory deadlines, escalation procedures, and volume-based workflow recommendations |
| Security & breach documentation | 15% | Risk-to-control mapping between DPIAs and security measures ensures no identified risk goes unaddressed |
| International transfers | 10% | Transfer mechanism validation (adequacy, SCCs, TIA) with post-Schrems II supplementary measures assessment |
| Processor management & audit | 10% | Art. 28(3)(a–h) systematic verification prevents the common mistake of accepting processor DPAs without checking compliance |
The heaviest documentation activity (ROPA & DPIA authoring, 20% of effort) is exactly where the cross-document validation adds the most value — not by replacing DPO judgment on processing purposes and risk levels, but by catching the mechanical consistency issues (mismatched legal bases, missing ROPA fields, unscreened high-risk processing) that consume review cycles and create supervisory authority exposure.
Getting started
- Create a new project in Rakenne and select the GDPR Compliance Program workspace template
- All 19 skills are automatically installed
- Choose your compliance track — EU-Wide, DPC Ireland, or Both
- Start with the Gap Assessment (Track 1) or DPC Readiness (Track 2) to establish the foundation
- Follow the 6-phase sequence: Assessment → Legal Basis → Documentation → Rights & Security → Data Lifecycle → Vendor Management
- Use the dashboard to track progress across all 6 compliance phases
Each skill is independent but builds on deliverables from earlier phases. You can run them in any order, but the recommended sequence ensures each skill has the context it needs from prior work — and that the documentation chain will hold up under supervisory authority scrutiny.
Summary
The GDPR Compliance Program workspace template turns the EU’s most complex data protection regulation into a structured, validated compliance programme. The 19 skills cover the full lifecycle from gap assessment through vendor audit, and the built-in validation enforces the same checks a senior privacy consultant would apply — consistently, automatically, and traceably.
What sets this apart from generic AI drafting is the dual-track approach (EU-wide vs. DPC-specific), the cross-document consistency checks (legal basis register ↔ consent forms ↔ privacy notices ↔ ROPA ↔ DPIAs), and the regulatory-grade validation (EDPB guidelines, CJEU case law, Art. 35(3) screening criteria). The result is a compliance programme where every privacy notice, processor agreement, and impact assessment can be traced back to a specific legal basis and a specific processing activity — exactly what a supervisory authority expects to see.
Try it yourself
Open a workspace with the skills described in this article and start drafting in minutes.
Get Started Free — No Sign-Up