GDPR Quickstart

Practical 60-day plan to get from sign-up to GDPR-ready in Matproof — covering Article 30 ROPA, Article 32 security measures, breach notification, DPIAs, and data-subject rights.

GDPR Quickstart

This is the operational companion to /frameworks/gdpr. GDPR has been in force since 2018 — this guide is for organizations either implementing GDPR for the first time or porting an existing programme into Matproof.

Who this is for

• Any organization that processes personal data of EU/EEA residents — controllers and processors
• DPOs, privacy leads, compliance officers responsible for the GDPR programme
• Engineering and security leads who need to demonstrate technical/organizational measures (Article 32)

GDPR is largely a documentation regime — most of the obligations are about being able to show you’ve thought about each area. Matproof’s job is to make the documentation produce itself from your existing operations rather than being maintained as a parallel set of spreadsheets.

Before you start

Have ready	Why
A list of personal-data categories you process (employees, customers, prospects, suppliers, special categories)	Drives the ROPA structure
List of all processors (cloud, SaaS, payroll, marketing tools)	Article 28 DPA register
Existing Privacy Notice / Privacy Policy	You’ll port it; Matproof generates a starting draft
DPO designation (if required under Article 37)	Named accountable owner
Knowledge of any cross-border transfers (US-based processors, group companies in third countries)	Article 44–49 transfer safeguards

Phase 1 — Week 1: Foundation

Complete Onboarding first. Then:

1. Settings → Frameworks — confirm GDPR is active (~25 controls)
2. People → Invite team: at minimum the DPO (or the person responsible for privacy if no formal DPO is required), plus a senior engineering or IT lead
3. If you have customers across multiple EU member states with different supervisory authorities, document this in Settings → Organization — Matproof references your lead supervisory authority on report templates

Phase 2 — Week 2: Article 30 Records of Processing Activities (ROPA)

Article 30 is the single biggest GDPR documentation deliverable. Most supervisory authorities ask for the ROPA as the first thing in any inspection.

For each processing activity (e.g. “employee onboarding,” “customer support tickets,” “marketing email campaigns,” “prospect database”), document:

1. Purpose of processing
2. Categories of data subjects (employees, customers, prospects, etc.)
3. Categories of personal data processed (contact info, employment data, financial data, special categories)
4. Recipients — internal teams, processors, third countries
5. Retention periods for each category
6. Technical and organizational security measures in place (cross-link to relevant Matproof controls)
7. For transfers outside EU/EEA: the transfer mechanism (SCCs, adequacy decision, BCR)

In Matproof:

• Open Privacy → Records of Processing Activities (or via the GDPR framework view)
• Create one ROPA entry per processing activity — Matproof’s template prompts for each Article 30 field
• Cross-link to the relevant controls and policies so the security-measures section auto-populates

For most organizations, 8–15 ROPA entries cover everything. SaaS companies typically have around 12.

Phase 3 — Week 2–3: Article 28 — Processor DPAs

Every processor that handles personal data on your behalf needs a signed DPA under Article 28(3). Matproof’s Vendor Risk module has a dedicated Article 28 register view.

1. Vendor Risk → Vendors → Import your processor list (cloud providers, SaaS, payroll, marketing automation, support tools)
2. For each, mark processes_personal_data: yes and complete the Article 28 fields:
   • Categories of personal data the processor handles
   • Purpose of processing
   • Sub-processor list (collected via the GDPR Article 28 Data Processor Assessment questionnaire)
   • Transfer mechanism if non-EU
   • DPA file (uploaded; if not yet signed, mark as pending)
3. For any processor without a signed DPA, send the questionnaire + a request for their DPA template — track to closure
4. Schedule annual reassessment for every processor in the register

Output: an Article 28 register exportable as PDF or Excel for your DPO or supervisory authority.

Phase 4 — Week 3–4: Article 32 — Security Measures

Article 32 requires “appropriate technical and organizational measures” — proportionate to the risk. Matproof’s auto-generated policies cover the policy side; the controls and integrations cover the evidence side.

Concrete deliverables:

1. Publish the Information Security Policy (auto-generated, customize, publish)
2. Publish the Data Protection Policy (auto-generated, customize, publish)
3. Connect cloud integrations (AWS / Azure / GCP) — populate evidence on encryption-at-rest, audit-log enablement, access controls
4. Connect identity integrations (Entra ID / Google Workspace) — MFA evidence, access-review evidence
5. Roll out the Device Agent — endpoint encryption, screen-lock, antivirus, vulnerable-app evidence

The above produces enough evidence to populate ~80% of Article 32 controls automatically.

Phase 5 — Week 4–5: Article 33–34 — Breach Notification

Article 33: notify the supervisory authority within 72 hours of becoming aware of a personal-data breach (unless the breach is unlikely to result in a risk to data subjects’ rights and freedoms).

Article 34: notify affected data subjects without undue delay if the breach is likely to result in a high risk.

In Matproof, the Incidents module handles both:

1. Incidents → Settings — confirm your supervisory authority is correct (e.g. BfDI for German federal organizations, BayLDA for Bavaria, CNIL for France)
2. Test the flow with a tabletop:
   • Create a synthetic personal-data-breach incident
   • Step through the breach-notification classifier (does it meet the Article 33 threshold? Article 34?)
   • Generate the supervisory-authority notification template
   • If Article 34 applies, generate the data-subject communication
3. Document detection sources in the Incident Response Policy — what tools surface a potential breach (Aikido findings, device agent CVEs, employee reports)

Phase 6 — Week 5–6: Article 35 — DPIAs

Article 35 requires a Data Protection Impact Assessment (DPIA) for processing “likely to result in a high risk to the rights and freedoms of natural persons” — typical triggers are large-scale processing of special-category data, systematic monitoring, automated decision-making with significant effect.

In Matproof:

1. Privacy → DPIAs → New DPIA — for each high-risk processing activity, run the guided DPIA workflow
2. The workflow walks through Article 35(7) requirements: systematic description of processing, necessity/proportionality assessment, risk assessment, measures envisaged
3. If the DPIA shows residual high risk, Article 36 requires prior consultation with your supervisory authority before the processing starts. Matproof generates the prior-consultation request template

For SaaS organizations using AI features, an EU AI Act–DPIA combined assessment is now expected — see /quickstarts/dora cross-references and the EU AI Act framework for the AI module.

Phase 7 — Week 6–8: Data-Subject Rights

Articles 15–22 give data subjects rights: access, rectification, erasure (“right to be forgotten”), restriction, portability, objection, automated-decision-making safeguards.

You must respond to most requests within one month (extendable by two months if complex).

1. Privacy → Data Subject Requests — configure intake (an email alias like [e-mail] that creates a ticket in Matproof, plus a public web form on your site that posts to Matproof’s API)
2. Document the workflow for each right type — who fulfils, how identity is verified, what’s exported, how the response is communicated
3. Test it — submit a synthetic access request and walk it end-to-end. The result is your evidence of an operational DSR programme

Audit-readiness checklist

Use this for an audit by your supervisory authority or as part of a vendor-due-diligence response:

• Art. 30: ROPA complete and current; covers every processing activity; reviewed in last 12 months
• Art. 32: Information Security Policy and Data Protection Policy published; technical measures evidenced via integrations
• Art. 28: DPA register complete; every processor has a signed DPA on file
• Art. 33: Breach-notification flow tested via tabletop in last 12 months; on-call team trained on 72h timeline
• Art. 34: Data-subject notification template ready; criteria for triggering Article 34 documented
• Art. 35: DPIAs completed for every high-risk processing activity
• Art. 36: Prior-consultation process documented (even if not yet triggered)
• Art. 37: DPO appointed if required; DPO contact details in privacy notice
• Art. 13–14: Privacy notice published; reflects current ROPA
• Art. 15–22: Data-subject-rights workflow tested end-to-end; response time ≤ 1 month
• Art. 44–49: Cross-border transfer mechanism documented for every non-EU processor
• Art. 5(2): Records of compliance with the principles (accountability) are maintainable from Matproof’s exports

Common gotchas

• The ROPA isn’t optional even for smaller organizations. The Article 30(5) exemption for under-250-employee orgs is narrower than people think (it doesn’t apply when processing is regular, occasional, or includes special-category data — which covers basically every business).
• Most processors aren’t equally critical. Don’t try to send a 200-question DPA assessment to every SaaS vendor — use Matproof’s vendor classification and risk-based the depth of assessment.
• The 72-hour clock starts on awareness, not investigation. If your detection produces possible-breach signals at 6pm Friday, the 72-hour clock runs through Monday morning — out-of-hours coverage matters.
• DPIA ≠ DPA. DPIAs (Article 35) are your internal risk assessment for processing activities. DPAs (Article 28) are contracts with processors. Different docs, different obligations.
• Right to be forgotten has limits — Article 17(3) lists exceptions (legal claims, public-interest archiving, etc.). Don’t promise unconditional erasure; document your exceptions in the DSR workflow.

GDPR framework

Conceptual overview — what GDPR requires

Vendor Risk

Article 28 DPA register

Incidents

Article 33 breach-notification flow

Roles & Permissions

Configuring the DPO role