Skip to main content

​
Getting Started with GDPR

The General Data Protection Regulation (GDPR) has applied since May 25, 2018. It governs how organizations collect, process, store, and delete personal data of data subjects in the EU — regardless of where the organization itself is based. Non-compliance exposes organizations to fines of up to €20M or 4% of global annual turnover. Matproof’s GDPR framework maps accountability and governance controls to your policies, vendor assessments, and evidence library. It is designed to complement your GDPR documentation (RoPA, DPIAs) rather than replace dedicated privacy management tools.
Activate GDPR under Settings → Frameworks → GDPR. Your control set focuses on organizational and technical measures under Article 32, accountability documentation, and vendor (processor) management.

​
Who Must Comply?

GDPR applies to you if:
  • You are established in the EU (regardless of where you process data)
  • You are outside the EU but offer goods or services to data subjects in the EU
  • You are outside the EU but monitor the behaviour of data subjects in the EU (e.g., analytics, tracking)
There is no minimum size threshold. A one-person business processing EU customer data must comply.

​
Key GDPR Roles

RoleDefinitionYour Obligation
Data ControllerDetermines the purpose and means of processingPrimary accountability — must have lawful basis, honor data subject rights, maintain RoPA
Data ProcessorProcesses data on behalf of a controllerMust follow controller instructions, sign DPA, implement Article 32 measures
Sub-processorProcessor used by another processorController must approve sub-processors; DPA chain must flow down
Most SaaS companies are both: a controller for their own employee data, and a processor for their customers’ data.

​
Core GDPR Requirements at a Glance

ArticleRequirementMatproof Module
Art. 5Data minimisation, purpose limitation, accuracyPolicies
Art. 13-14Privacy notices for data subjectsPolicies
Art. 24Responsibility of the controllerControls
Art. 25Data protection by design and by defaultControls
Art. 28Data Processing Agreements with processorsVendor Risk
Art. 30Records of Processing Activities (RoPA)Controls, Policies
Art. 32Technical and organisational measures (TOMs)Controls, Evidence
Art. 33Breach notification to supervisory authority (72 hours) — only if the breach is likely to result in a risk to individuals’ rights and freedomsIncidents
Art. 34Communication to data subjects when high riskIncidents
Art. 35Data Protection Impact Assessments (DPIAs)Controls
Art. 37Data Protection Officer (DPO) appointment where requiredPeople, Settings
1
Step 1 — Map your data flows
2
You cannot protect data you haven’t mapped. Before anything else:
3
  • Identify every system where you store or process personal data
  • For each system, document: what data, whose data, legal basis for processing, retention period, who has access
  • Identify all third-party processors you share data with (cloud providers, SaaS tools, analytics platforms)
    • 4
    This becomes the basis for your Records of Processing Activities (RoPA) — required under Article 30 for all organizations unless they have fewer than 250 employees AND their processing is occasional, does not pose risks to data subjects, and does not involve special category or criminal offence data. In practice, this exemption rarely applies — most organizations processing customer or employee data regularly must maintain a RoPA regardless of size.
    5
    Document your data flows in the Context Hub (Settings → Context Hub) so Matproof’s AI can generate relevant policies.
    6
    Step 2 — Establish lawful bases
    7
    Every processing activity needs a lawful basis. The six lawful bases under Article 6:
    8
    BasisWhen to useConsentSubject has freely given, specific, informed, unambiguous consentContractProcessing necessary to perform a contract with the subjectLegal obligationProcessing required by lawVital interestsNecessary to protect someone’s lifePublic taskNecessary for a task in the public interestLegitimate interestsNecessary for your (or a third party’s) legitimate interests, unless overridden by subject’s rights
    9
    Document the lawful basis for each processing activity in your RoPA. This is what supervisory authorities ask for first.
    10
    Step 3 — Generate GDPR policies
    11
    Go to Policies → Generate and generate the GDPR policy set:
    12
  • Privacy Policy (external — for data subjects)
  • Data Retention and Deletion Policy
  • Data Subject Rights Procedure
  • Personal Data Breach Response Policy
  • Data Protection by Design Policy
  • Acceptable Use Policy (for employees handling personal data)
    • 13
    Assign a DPO or privacy lead as owner of each policy.
    14
    Step 4 — Implement Article 32 technical measures
    15
    Article 32 requires “appropriate technical and organisational measures” — but does not specify exactly what. In practice, supervisory authorities look for:
    16
    MeasureEvidence in MatproofEncryption at rest and in transitTechnical documentation, configuration exportsAccess controls and least privilegeAccess logs, IAM policy exports, access reviewsPseudonymisation where possibleArchitecture diagrams, code review evidenceRegular testing (penetration tests, audits)Pen test reports, audit recordsBusiness continuity and recoveryBCP document, DR test results
    17
    Work through the Article 32 controls in Controls → GDPR and attach evidence for each.
    18
    Step 5 — Manage processors and DPAs
    19
    Article 28 requires a written Data Processing Agreement (DPA) with every third party that processes personal data on your behalf.
    20
  • Go to Vendor Risk and add all processors (cloud providers, SaaS tools, analytics, email platforms)
  • For each processor, upload or link their DPA
  • Review the DPA to confirm it includes all Article 28(3) requirements
  • For critical processors, send a vendor risk assessment to verify their security posture
    • 21
    If you use sub-processors (your processor uses another company to process data), you must inform controllers and obtain approval. Document sub-processor chains in Vendor Risk.
    22
    Step 6 — Configure breach notification workflow
    23
    GDPR Article 33 requires notifying your supervisory authority within 72 hours of becoming aware of a personal data breach.
    24
  • Go to Incidents → Settings
  • Configure GDPR breach classification criteria (what qualifies as a personal data breach)
  • Set up escalation so the DPO is notified immediately
  • Document the supervisory authority contact details (your lead DPA in the EU)
    • 25
    The 72-hour clock starts when your organization becomes aware — not when you confirm the full scope.
    26
    Step 7 — Data subject rights process
    27
    GDPR grants data subjects: right of access (DSAR), right to rectification, right to erasure, right to portability, right to restrict processing, right to object, and right not to be subject to solely automated decision-making (Article 22).
    28
    Document your response procedures and assign owners:
    29
  • Access request response within 1 month (extendable by up to 2 further months for complex or numerous requests — data subject must be informed of the extension within the first month)
  • Erasure (“right to be forgotten”) workflow including downstream processor deletion
  • Portability export format and process
    • 30
    Step 8 — DPIAs for high-risk processing
    31
    Article 35 requires a Data Protection Impact Assessment (DPIA) before starting any processing that is “likely to result in a high risk” to individuals. This includes:
    32
  • Large-scale processing of sensitive data
  • Systematic monitoring of individuals
  • Automated decision-making with significant effects
    • 33
    Document DPIAs as evidence in the relevant controls. Supervisory authorities require DPIAs to be completed before processing begins.

    ​
    Breach Notification Quick Reference

    StepTimelineAction
    Breach detectedT+0Contain breach, assess scope, notify DPO
    Within 72 hoursT+72hNotify lead supervisory authority (even if incomplete)
    High risk to individualsASAPNotify affected data subjects directly
    DocumentationOngoingLog in breach register regardless of notification obligation
    Not all breaches require supervisory authority notification. If the breach is unlikely to result in a risk to individuals’ rights and freedoms, notification is not required — but you must still document the breach in your internal breach register (Article 33(5)).

    ​
    Common Mistakes

    Consent is one of the hardest lawful bases to maintain (it must be freely given, withdrawable, and documented). For B2B SaaS processing customer data, legitimate interests or contract is usually more appropriate for most processing activities.

    ​
    2. DPAs treated as a checkbox

    Many organizations collect DPAs from processors but never review them. Article 28 requires DPAs to include specific provisions — collect them and verify the content.

    ​
    3. Ignoring employee data

    GDPR applies to employee personal data too. Recruitment data, payroll, performance records, and monitoring activities all require a lawful basis and retention policy.

    ​
    Next Steps

    • Incidents — 72-hour breach notification workflow
    • Vendor Risk — DPA tracking and processor risk assessments
    • People Module — employee data handling and access management
    • Policy Management — privacy policy generation and acknowledgement tracking