Executive Summary — DPO review briefing
Controller activities (Art. 30(1))
10
Processor activities (Art. 30(2))
6
Special category processing (Art. 9)
3 activities
DPIAs completed (Art. 35)
3 — see Parts J & K
Sub-processors (EU/EEA)
6 of 7
Third-country transfers
2 (UK + IE SCCs)
Rights requests FY2024
14 — avg. 7.2 days
Notifiable breaches FY2024
0 — 1 near-miss logged
Supervisory authority contact
None in review period
LIAs completed
4 (see Part M)
Overall risk rating
Medium-High
Compliance status
Compliant — pending PA-07 DPIA update
Assessment
Having conducted my annual review of this Record of Processing Activities in the capacity of Data Protection Officer appointed under Art. 37(1)(b) GDPR, I confirm that to the best of my knowledge and belief, this Record accurately reflects the processing activities carried out by Meridian Data Services B.V. as at the date of certification. All processing activities have been assessed against the requirements of Articles 5–11 and 25–32 GDPR, and the processing described herein is, in my assessment, lawful, fair, and transparent in accordance with the principles established in Art. 5(1) GDPR. No processing activities have been identified that would constitute a likely high-risk processing operation not already subject to a DPIA under Art. 35 GDPR, with the exception of PA-07 (AI-assisted compliance) for which a supplementary DPIA update has been initiated and is expected to conclude by Q2 2025. I record one area of ongoing monitoring: the EU–UK adequacy decision (Commission Implementing Decision (EU) 2021/1772) is subject to periodic review; the DPO will assess any material changes to UK data protection law and update the transfer impact assessment in Part L accordingly.
Priority actions Q1–Q2 2025
(1) Complete supplementary DPIA for PA-07 AI-assisted compliance recommendation engine following deployment of v2.1 model — target: 31 March 2025. (2) Review and update standard contractual clauses with Google Ireland Ltd following EDPB Opinion 5/2023 guidance on Art. 46 transfer mechanisms — target: 30 April 2025. (3) Conduct Data Mapping Workshop for PA-09 (internal R&D and QA environments) to validate anonymisation completeness — target: 28 February 2025. (4) Update Art. 13 privacy notices to reflect addition of PA-10 (whistleblowing) as new processing activity — target: 15 January 2025 (completed).
Table of Contents
Preamble
Statutory context and document purpose
Art. 30(1) obligation; supervisory authority availability
Part A
Controller identity and organisational profile
Art. 30(1)(a) — entity details, DPO, lead SA
Part B — PA-01
Internal HR Administration — Own Employees
Art. 6(1)(b)(c)(f); Art. 9(2)(b)(h) — health data
Part B — PA-02
B2B Client Account & Contract Management
Art. 6(1)(b)(c)(f) — CRM, billing, DPA register
Part B — PA-03
Marketing Communications & Website Analytics
Art. 6(1)(a)(f) — consent-based; GA4; IAB TCF
Part B — PA-04
Information Security Monitoring & Incident Management
Art. 6(1)(c)(f) — SIEM, NIS2; breach register
Part B — PA-05
Regulatory Compliance Record-Keeping & DPO Activities
Art. 6(1)(c) — accountability; rights request records
Part B — PA-06
SaaS Platform Delivery & Infrastructure Operations
Art. 6(1)(b)(f) — session mgmt, API tokens, uptime
Part B — PA-07
AI-assisted Compliance Recommendation Engine
Art. 6(1)(b)(f) — NLP model; DPIA in Part K
Part B — PA-08
Partner Program & Reseller Management
Art. 6(1)(b)(f) — affiliates, co-marketing
Part B — PA-09
Internal Software Development & QA
Art. 6(1)(f) — test data governance; anonymisation
Part B — PA-10
Whistleblowing & Ethics Hotline Management
Art. 6(1)(c); Art. 9(2)(b) — Klokkenluiders Act
Part C
Lawfulness analysis summary
Consolidated Art. 6 & Art. 9 basis table — all 10 activities
Part D
Data subject rights — implementation status
Art. 15–22 GDPR; EDPB Guidelines 01/2022
Part E
Consolidated retention schedule
Art. 5(1)(e) storage limitation; automated deletion
Part F
Sub-processors, third-party processors and data sharing
Art. 28(3) DPAs; transfer safeguards
Part G
Processing risk assessment & DPIA register
DPIA register; EDPB 09/2022 matrix
Part H
Personal data breach response procedure
Art. 33–34; 72-hour AP notification; tabletop tested
Part I
Processor-side record (Art. 30(2))
Parallel record for processor capacity activities
Part J
DPIA — Health & disability data processing (PA-01)
Full Art. 35 DPIA; DPO consultation on file
Part K
DPIA — AI-assisted compliance system (PA-07)
High-risk AI; Art. 35(3)(a); DPO findings
Part L
Transfer Impact Assessment (Art. 46 safeguards)
UK adequacy; SCCs Module 2; third-country analysis
Part M
Legitimate Interests Assessment register
Three-part LIA for each Art. 6(1)(f) activity
Part N
Consent governance framework
Collection; storage; withdrawal; double opt-in
Part O
Data subject rights request register
Log of rights requests FY2024; response metrics
Part P
Annual review certification
DPO sign-off; board notification; review findings
Appendix I
Legal basis reference table
Cross-reference: EU regulation, Recital, EDPB guidance
Appendix II
Data flow narrative
System-level data movement description
Appendix III
Document change log
Version history from v1.0 to current
Preamble — Statutory context and document purpose
Article 30(1) of Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the Processing of Personal Data and on the free movement of such data VERIFIED (the General Data Protection Regulation, hereafter “GDPR”) obliges each Controller and, where applicable, the Controller’s representative, to maintain a written record of all Processing activities carried out under its responsibility. This obligation applies irrespective of the size of the organisation where: (a) the Processing is not occasional; (b) the Processing includes Special Categories of Personal Data referred to in Article 9(1) GDPR VERIFIED; or (c) the Processing is likely to result in a risk to the rights and freedoms of natural persons. Meridian Data Services B.V. falls within all three categories and accordingly shall maintain this Record as a standing accountability instrument, subject to mandatory annual review and ad hoc amendment upon any material change to Processing operations, in discharge of the accountability obligation established by Art. 5(2) GDPR VERIFIED and Art. 24(1) GDPR. VERIFIED
This Record shall be made available to the Autoriteit Persoonsgegevens (the “AP”), the competent Supervisory Authority for the Netherlands pursuant to Arts. 51–52 GDPR VERIFIED and the Uitvoeringswet Algemene verordening gegevensbescherming (UAVG) VERIFIED, upon request in accordance with Art. 30(4) GDPR. VERIFIED It constitutes the primary accountability instrument evidencing the Controller’s compliance with the Data Protection Principles set out in Art. 5(1) GDPR VERIFIED — including lawfulness, fairness and transparency (Art. 5(1)(a)); purpose limitation (Art. 5(1)(b)); data minimisation (Art. 5(1)(c)); accuracy (Art. 5(1)(d)); storage limitation (Art. 5(1)(e)); and integrity and confidentiality (Art. 5(1)(f)) — and the principle of accountability established in Art. 5(2) GDPR. For the purposes of this Record, “Controller” has the meaning given in Art. 4(7) GDPR VERIFIED: the natural or legal person which, alone or jointly with others, determines the purposes and means of the Processing of Personal Data. “Personal Data” has the meaning given in Art. 4(1) GDPR. VERIFIED “Processing” has the meaning given in Art. 4(2) GDPR. VERIFIED
Part A — Controller identity and organisational profile
The following particulars identify the data controller as required under Art. 30(1)(a) GDPR and establish the organisational context within which all processing activities documented herein are conducted.
Legal entity name
Example B.V.
Legal form
Besloten Vennootschap (B.V.) — private limited company under Dutch civil law
KvK registration
12 34 56 78 (Kamer van Koophandel, Amsterdam)
Registered office
Fictielaan 1, 1000 AA Amsterdam, Netherlands
VAT identification
NL000000000B00 (IANA-reserved example; not a real VAT number)
Industry sector
HR SaaS — B2B workforce management (NACE J62.01)
Employee count
47 FTE across 14 EU member states
B2B client base
~320 business clients — SMEs in DE, NL, FR, BE, SE
End data subjects managed
Approx. 28,400 employee records (as data processor on behalf of clients)
Data Protection Officer
M. van Dam — mandatory appointment per Art. 37(1)(b) GDPR (large-scale employee data processing)
DPO contact
dpo@examplebv.example (IANA-reserved — illustrative only)
Lead supervisory authority
Autoriteit Persoonsgegevens (AP), The Hague — one-stop-shop mechanism (Art. 56 GDPR)
Role under GDPR
Controller (Art. 4(7)) for own operations; Processor (Art. 4(8)) when handling client employee data under DPA
RoPA obligation basis
Art. 30(1) — mandatory regardless of size (Art. 30(5) exception does not apply: processing not occasional; includes Art. 9 data)
Document scope
All processing activities where Example B.V. acts as data controller; processor-side record maintained separately under Art. 30(2)
DPO registration (AP)
Notified to AP per Art. 37(7) GDPR — registration ref. AP-DPO-EXB-2023-0041 (illustrative)
Part B — Register of processing activities (controller perspective)
Each processing activity documented below has been identified, classified, and assessed in accordance with Art. 30(1)(b)–(g) GDPR. The legal basis for each activity has been determined under the framework of Art. 6 GDPR and, where special categories of personal data are involved, additionally under Art. 9(2) GDPR. The lawfulness analysis is conducted on an activity-by-activity basis; blanket consent is not relied upon as the primary legal basis for any activity where an alternative basis under Art. 6(1) applies. Reliance on legitimate interests (Art. 6(1)(f)) has in each case been subject to a three-part balancing test: (i) identification of a legitimate interest pursued; (ii) necessity of processing for that interest; and (iii) balancing against the fundamental rights and freedoms of data subjects, with particular regard to reasonable expectations at the time of collection (Recital 47 GDPR).
Purpose of processing
Management of Example B.V.'s own employee lifecycle, encompassing: (i) pre-employment screening and recruitment administration; (ii) contract formation, execution, and variation; (iii) payroll calculation and disbursement, including deduction of Dutch loonheffing (payroll tax) and employee pension contributions under Wet op de loonbelasting 1964; (iv) leave and absence management, including sick leave administration under the Dutch Wet verbetering poortwachter; (v) performance management and appraisal processes; (vi) training and professional development records; (vii) offboarding and exit administration. This activity concerns Example B.V.'s 47 FTE only and is wholly distinct from the platform's processor-side activities on behalf of B2B clients.
Legal basis (Art. 6)
Art. 6(1)(b) — processing necessary for performance of the employment contract (WP29 Opinion 2/2017 on data processing at work); Art. 6(1)(c) — compliance with Dutch labour law obligations: Burgerlijk Wetboek Book 7 (employment contract), Wet minimumloon, Wet aanpak schijnzelfstandigheid, ARBO-wet (occupational health); Art. 6(1)(f) — legitimate interests: workforce planning, internal communications, IT and platform security for employees; interest outweighs employee expectations given direct employment relationship context.
Special categories (Art. 9)
Art. 9(1) — health data: sick leave and incapacity records, disability accommodation, pregnancy-related leave, access to Bedrijfsarts (occupational physician) records. Basis: Art. 9(2)(b) — processing necessary for obligations in the field of employment law; additionally Art. 9(2)(h) — health and social care (occupational physician). Explicit consent (Art. 9(2)(a)) collected as secondary basis where processing exceeds statutory minimum (e.g., optional wellness data). Art. 9(1) — biometric data: where applicable (office access control systems, if deployed) — basis: Art. 9(2)(a) explicit consent.
Data subjects
Current and former employees of Example B.V.; contractors engaged on service agreements where employment-equivalent data is held; job applicants (limited dataset during recruitment phase, retained for max. 4 weeks post-decision absent consent to longer retention).
Personal data categories
Full legal nameDate of birthBSN (Burgerservicenummer)Home addressPersonal email & phoneWork email & phoneBank IBAN (salary payments)Salary & compensation detailsPension contributionsEmployment contract termsLeave records & entitlementsPerformance appraisal dataTraining certificatesSick leave records (Art. 9)Occupational health reportsDisability accommodationsIdentity document (copy for right-to-work)Emergency contact details
Recipients & disclosures
Dutch Tax Authority (Belastingdienst) — statutory payroll reporting obligation; UWV (Uitvoeringsinstituut Werknemersverzekeringen) — social security administration; ABP or sector pension fund — mandatory pension contributions; Bedrijfsarts / Arbo-dienst (occupational physician service) — occupational health; HR system administrator (internal, restricted access); payroll provider (sub-processor under Art. 28 DPA); legal counsel (if dispute). No disclosure to third parties for commercial purposes.
Retention period
Active employment records: duration of contract + 2 years (Dutch civil limitation period, Art. 3:310 BW). Payroll and fiscal records (loonstroken, jaaropgaven): 7 years from end of fiscal year (Art. 52 AWR — tax administration obligation). Pension scheme records: per pension fund requirements, minimum 7 years. Sick leave records: duration of employment + 2 years (Wet verbetering poortwachter); anonymised thereafter. Recruitment records (unsuccessful candidates): 4 weeks post-rejection; where extended with consent, maximum 1 year. Exit interview data: 2 years, then secure deletion.
International transfers
No transfers outside the EEA. All data stored and processed exclusively within AWS eu-central-1 region (Frankfurt, Germany). Intra-EU transfers to Belgian or German payroll contacts remain within the European Economic Area and require no additional safeguard under Chapter V GDPR; the transfer mechanism provisions of Art. 44–49 GDPR are not engaged.
Technical & organisational security (Art. 32)
AES-256 encryption at rest; TLS 1.3 in transit; role-based access control with mandatory MFA for payroll and health data systems; least-privilege access principle enforced; access reviewed quarterly; dedicated HR data sub-environment with audit logging; SOC 2 Type II certified infrastructure; annual penetration testing (CREST-accredited third party); data loss prevention (DLP) tooling active.
Purpose of processing
Administration of the commercial relationship between Example B.V. and its approximately 320 B2B business clients, encompassing: (i) client onboarding — KYB (know-your-business) verification, contract execution and countersigning; (ii) subscription lifecycle management — tier allocation, usage monitoring against contracted limits, renewal and upsell workflows; (iii) billing, invoicing, and collection — generation of VAT-compliant invoices, processing of recurring subscription payments, credit control, and dispute resolution; (iv) technical support — creation, routing, and resolution of support tickets; (v) account security — monitoring for unauthorised access, credential compromise, and anomalous API usage; (vi) contract management and legal compliance — maintenance of data processing agreements required under Art. 28 GDPR, SLAs, and applicable service terms.
Legal basis (Art. 6)
Art. 6(1)(b) — processing necessary for performance of the subscription contract with the client entity (contact persons are direct counterparties or designated representatives); Art. 6(1)(c) — legal obligation to maintain VAT-compliant invoicing records (Art. 35a Wet OB 1968; Dutch VAT Act); accounting record retention obligations (Art. 52 AWR); Art. 6(1)(f) — legitimate interests: fraud prevention, account integrity, business analytics for service improvement. Balancing test concluded in Example B.V.'s favour: contact persons reasonably expect their professional data to be processed by a contracted B2B service provider; no reasonable expectation of privacy in respect of professional role data.
Special categories (Art. 9)
Not applicable. This processing activity does not involve special categories of personal data as defined in Art. 9(1) GDPR. Client contact persons are identified exclusively by professional role data. Example B.V. takes reasonable technical steps (support ticket content screening guidelines) to prevent inadvertent submission of special category data via support channels; such data, if received, is quarantined and deleted.
Data subjects
Named contact persons at B2B client organisations (procurement leads, HR directors, finance contacts, designated technical administrators); billing contacts; signatories to DPAs and service agreements. Does not include end employees of clients — those are processed as processor (Art. 30(2) record maintained separately).
Personal data categories
Full name & professional titleBusiness email addressBusiness telephone numberCompany addressVAT / BTW number (company)Subscription tier & contract valuePayment method metadata (last 4 digits only — not full card data)Support ticket contentAPI access logs & usage metricsLogin timestamps & IP addressesContract execution historyDPA signatory details
Recipients & disclosures
CRM: HubSpot Ireland Ltd (EU data region, DPA in place, data residency guarantee); Accounting: Exact Online (Exact Group B.V., Delft, Netherlands — DPA in place, ISO 27001); Payment processing: Paddle.com Market Ltd (independent data controller, Merchant of Record, PCI DSS Level 1 — see footnote to Part F); Legal counsel: only where contractual dispute arises; Debt collection: in the event of persistent non-payment, minimum dataset disclosed to licensed Dutch credit management firm under DPA. No disclosure for marketing or profiling purposes.
Retention period
Active client records: duration of contract + 2 years (BW limitation period). Invoices and financial records: 7 years from end of fiscal year (Art. 52 AWR — mandatory minimum). DPAs and contracts: 7 years from termination (commercial limitation periods). Support ticket records: 3 years from ticket closure (legitimate interest basis — potential contractual disputes, SLA audit). Access logs: 18 months (security monitoring; see PA-04).
International transfers
HubSpot Ireland Ltd processes data within the EU under their EU Data Processing Agreement and Standard Contractual Clauses (Module 2, controller-to-processor) as approved under Commission Implementing Decision (EU) 2021/914. Paddle.com Market Ltd is established in England and Wales; the UK benefits from an EU adequacy decision under Art. 45 GDPR (Commission Implementing Decision (EU) 2021/1772), valid subject to ongoing Commission review. No other third-country transfers occur in respect of this processing activity.
Technical & organisational security
Separation of client data environments (multi-tenancy with logical isolation); encrypted storage of all contact data; MFA required for all CRM administrator access; quarterly access review; support ticket system access restricted by role; full payment card data never stored by Example B.V. (Paddle as MoR assumes PCI DSS scope).
Purpose of processing
(a) Email marketing: dissemination of newsletters, product update announcements, regulatory compliance alerts, webinar invitations, and lead nurturing communications to subscribers and prospects who have opted in or who are existing customers receiving service-related communications; (b) B2B prospecting: outbound communications to identified decision-makers at target companies where a legitimate interest in receiving Example B.V.'s communications can be established; (c) Website analytics: measurement and optimisation of kortave.eu website performance — pageview analytics, conversion funnel analysis, A/B test metrics — using pseudonymised identifiers.
Legal basis (Art. 6)
Newsletter / event marketing: Art. 6(1)(a) — freely given, specific, informed and unambiguous consent per Art. 4(11) and Art. 7 GDPR, evidenced by double opt-in confirmation with timestamp. Existing customer product updates: Art. 6(1)(f) — legitimate interest (existing commercial relationship; updates directly relevant to purchased service); balanced against customer expectations of receiving service communications from a contracted provider. B2B prospect outreach: Art. 6(1)(f) — legitimate interest; compliant with ePrivacy Directive 2002/58/EC Art. 13 as implemented in Dutch Telecommunicatiewet Art. 11.7, which permits B2B electronic communications to legal persons' professional addresses absent prior opt-out. Website analytics: Art. 6(1)(a) — consent via cookie banner (IAB TCF v2.2 compliant) for analytics cookies; Art. 6(1)(f) for server-side analytics not requiring cookies.
Special categories (Art. 9)
Not applicable. Marketing processing is limited to professional context data. Analytics data is pseudonymised at collection and does not reveal health, political, religious, or other Art. 9(1) attributes. Content preferences inferred from click data are not used for profiling that would produce legal or significant effects (Art. 22 GDPR does not apply).
Data subjects
Newsletter subscribers (opted-in); website visitors (pseudonymised, cookie-consented); event and webinar registrants; sales prospects identified via LinkedIn prospecting (opt-out maintained); existing B2B client contacts (product update recipients).
Personal data categories
Business email addressFirst & last nameCompany name & estimated sizeProfessional job titleEmail engagement events (opens, clicks)Unsubscribe / opt-out timestampPseudonymised device ID (analytics)Anonymised geographic region (country-level)Page interaction data (pseudonymised)Consent timestamp & version
Opt-out & consent withdrawal
One-click unsubscribe in every marketing communication (Art. 7(3) GDPR; Telecommunicatiewet Art. 11.7(3)). Consent may be withdrawn at any time without detriment; withdrawal is effective within 48 hours. Suppression list maintained permanently to prevent re-addition of opted-out addresses. Analytics cookie consent may be withdrawn via cookie preference centre at any time.
Retention period
Active subscribers: retained while consent is active + 30 days post-withdrawal. Inactive subscribers (no engagement in 24 months): automated re-permission campaign triggered; if no response within 14 days, suppressed and deleted within 30 days. Consent records: retained for 3 years from withdrawal to evidence compliance. Analytics data: 14-month rolling window (GA4 standard data retention configuration). Event registrant data: 12 months post-event.
International transfers
Email delivery: Resend Inc., EU region endpoint; DPA in place. Analytics: Google Analytics 4 (Google Ireland Ltd, Dublin) — SCCs (Module 2) and DPA in place; IP anonymisation enabled at collection preventing full IP address from reaching Google servers; Ads personalisation disabled. No other third-country transfers occur in respect of this activity.
Purpose of processing
(a) Continuous security monitoring: maintenance of system access logs, authentication event records, and network traffic metadata to detect, investigate, and respond to security incidents that may affect personal data held by Example B.V.; (b) Vulnerability management: processing of system configuration data and software inventory to identify and remediate vulnerabilities that could compromise personal data; (c) Incident response: recording, investigation, containment, and remediation of confirmed security incidents or personal data breaches; (d) Regulatory breach notification: fulfilment of Art. 33 GDPR obligations (72-hour notification to AP) and Art. 34 obligations (communication to affected data subjects where high risk established) upon confirmed breach; maintenance of the breach register required by Art. 33(5) GDPR.
Legal basis (Art. 6)
Art. 6(1)(c) — legal obligation: Art. 32 GDPR (obligation to implement appropriate technical and organisational measures); Art. 33 GDPR (breach notification obligation to supervisory authority); Art. 5(2) GDPR (accountability principle requires demonstration of security measures); Art. 6(1)(f) — legitimate interest: protection of the information systems processing personal data against threats to their integrity, availability, and confidentiality; protection of data subjects from harm resulting from breaches; commercially justified investment in security posture.
Special categories (Art. 9)
Security logs may incidentally contain special category data where an incident relates to systems processing health data or other Art. 9(1) categories. Such incidental processing is minimised by design; log entries reference data classification codes rather than underlying content where technically feasible. Where special category data appears in incident records, access is restricted to the Security Officer and DPO; data is anonymised or pseudonymised within 30 days of investigation closure.
Personal data categories
System access logs (user ID, timestamp, action)IP addresses (internal and external)User agent stringsAuthentication events (success/failure, MFA challenges)API request metadata (endpoint, timestamp, response code)Incident records (may reference affected accounts)Breach notification correspondenceForensic investigation artefacts (encrypted, restricted)
Retention period
Security access logs: 18 months from creation (security monitoring necessity; SIEM standard); automatically overwritten on a rolling basis using log rotation. Confirmed incident records: 5 years from incident closure (regulatory investigation timeline; consistent with AP enforcement practice). Breach notification records (Art. 33(5) register): 5 years from notification (mandatory minimum per Art. 33(5) GDPR; aligns with EDPB Guidelines 9/2022). Forensic artefacts (e.g., disk images): deleted within 90 days of investigation closure unless required for litigation hold or regulatory inquiry.
International transfers
Security event data is processed within AWS eu-central-1 (Frankfurt). SIEM tooling (Elastic Cloud) deployed on EU-region endpoints with data residency contractually guaranteed. No transfer of security logs to third-country recipients absent a lawful basis under Art. 44–49 GDPR; any transfer required for law enforcement cooperation governed by applicable mutual legal assistance treaties (MLATs) and Art. 48 GDPR.
Purpose of processing
Maintenance of GDPR accountability documentation including: this RoPA; Data Protection Impact Assessment (DPIA) records (Art. 35); records of consent (Art. 7(1)); DPO activity log (Art. 38–39); vendor DPA register; training records evidencing staff data protection instruction; requests from data subjects exercising Art. 15–22 rights and responses thereto; correspondence with the AP; records of the legitimate interests assessments (LIAs) conducted in respect of Art. 6(1)(f) processing.
Legal basis (Art. 6)
Art. 6(1)(c) — legal obligation: Art. 5(2) GDPR (accountability principle mandates maintenance of compliance records); Art. 12–23 GDPR (obligation to respond to data subject rights requests and maintain records thereof); Art. 30(4) GDPR (obligation to make RoPA available to supervisory authority on request); Art. 33(5) GDPR (breach register maintenance).
Personal data categories
Data subject identity (for rights requests)Rights request content & responseConsent records with timestamp & versionDPO correspondenceDPIA records (may reference data subject categories)Staff training completion records
Retention period
Rights request records: 3 years from response (potential legal challenge window; Art. 82 GDPR civil liability claims). Consent records: 3 years from withdrawal. DPIA records: life of processing activity + 3 years. LIA records: life of processing activity relying on Art. 6(1)(f). DPO activity logs: 3 years. AP correspondence: 7 years.
Purpose of processing
Technical delivery and operation of the Meridian Data Services B.V. compliance platform (kortave.eu), encompassing: (i) user authentication and session management — issuance, validation, and revocation of JSON Web Tokens, OAuth 2.0 flows, and MFA challenge processing; (ii) API gateway operations — rate limiting, request routing, and audit logging for all API interactions by client administrators; (iii) platform availability and uptime monitoring — health checks, latency measurement, and alerting for SLA-affecting degradation; (iv) automated backup and disaster recovery operations in accordance with Art. 32 GDPR and ISO 22301 business continuity obligations; (v) capacity planning and autoscaling event logging. This activity is distinct from the AI-assisted compliance feature (PA-07) and from client-side employee data processing (Processor Record, Part I).
Legal basis (Art. 6)
Art. 6(1)(b) — processing necessary for performance of the subscription service contract with B2B clients (platform delivery is the core contractual obligation; without session management and API operations the service cannot be rendered); Art. 6(1)(f) — legitimate interests: maintaining platform integrity, availability, and security for all users; preventing unauthorised access; fulfilling SLA obligations that are themselves contractually binding.
Special categories (Art. 9)
Not applicable. Platform delivery operations process account and session metadata only. Technical logging does not target any Art. 9(1) categories. Where client payload data transits the platform infrastructure, it does so encrypted (AES-256) and is not accessed by infrastructure monitoring systems; any incidental exposure is subject to the same access controls as applied to client data generally.
Data subjects
Named administrator and user accounts of B2B client organisations accessing the platform. Internal Meridian Data Services B.V. engineering and operations staff accessing platform infrastructure.
Personal data categories
User account ID & emailSession token (JWT — pseudonymised)IP address (login & API origin)Last login timestampMFA method & challenge outcomesAPI request metadata (endpoint, HTTP method, status code, latency)Browser / client agent stringPlatform audit log entries (action, user ID, object ID, timestamp)Backup snapshots (contain all user-generated compliance document data — encrypted)
Recipients & disclosures
Amazon Web Services EMEA SARL (eu-central-1) — cloud infrastructure provider under DPA; Datadog Inc. (EU region endpoint, DPA in place — observability and APM tooling, processes pseudonymised request metadata only); no other recipients. Internal access restricted to DevOps and Site Reliability Engineering roles with mandatory MFA and session recording.
Retention period
Session tokens: invalidated on logout or 30-minute inactivity timeout; JTI (JWT identifier) blocklist retained 7 days. API request logs (non-security): 90 days rolling; security-relevant API logs cross-referenced to PA-04 (18 months). Platform audit logs: 3 years (contractual SLA audit; potential regulatory investigation). Backup snapshots: 30-day retention with point-in-time recovery; annual snapshots retained 7 years for compliance archive.
International transfers
Datadog Inc. processes request metadata on EU-hosted infrastructure (AWS eu-west-1, Dublin) under their Data Processing Addendum and SCCs (Module 2). Pseudonymised request identifiers only; no personal data beyond IP hash is transmitted to Datadog outside the EU. AWS EMEA SARL is an EEA-established entity; intra-EU processing.
Technical & organisational security
Zero-trust architecture — all internal services mutually authenticated via mTLS; infrastructure access requires SAML-federated SSO plus FIDO2 hardware key; production environment access audited in real time; automated anomalous-access alerting; immutable audit log architecture (append-only storage, tamper-evident hashing via AWS CloudTrail + S3 Object Lock).
Purpose of processing
Operation of the Kortave AI compliance recommendation engine, a large-language-model-based system that analyses client-submitted organisational descriptions, existing policy documents, and processing activity inputs to generate draft GDPR compliance documents, Art. 30 RoPA entries, Art. 35 DPIA frameworks, Art. 13/14 privacy notices, and EU AI Act conformity assessments. The system operates as follows: (i) the client submits structured inputs via the platform questionnaire interface describing their organisation, processing activities, and applicable regulatory scope; (ii) the AI engine processes these inputs together with the relevant EU regulatory corpus to generate a structured compliance document draft; (iii) the draft is presented to the client for human review, editing, and approval before finalisation; (iv) the human-approved document is stored as the client's compliance record. The AI output is never automatically presented as final, regulatory-ready documentation without human expert review. The processing does not constitute solely automated decision-making within the meaning of Art. 22 GDPR as no legal or significantly similar effects are produced without human review and sign-off.
Legal basis (Art. 6)
Art. 6(1)(b) — AI-assisted compliance generation is a core feature of the contracted service; processing client inputs to generate compliance documentation is necessary for delivery of the subscription contract; Art. 6(1)(f) — legitimate interests: improving model accuracy through aggregated, anonymised feedback patterns (no individual client data used to train production models; all training data anonymised and de-identified prior to any model update cycle — see Technical and Organisational Security). Balancing test: clients are sophisticated B2B counterparties who contract specifically for AI-generated compliance outputs; reasonable expectation of automated processing is established by the subscription terms and Art. 13 disclosure; legitimate interest outweighs any reasonable objection given contractual context and Art. 22 non-engagement.
Special categories (Art. 9)
Incidental — by design minimised: Client questionnaire inputs may describe processing activities involving special category data (e.g., a client HR system that processes health data). The AI engine processes descriptions of such processing, not the underlying special category data itself. This processing is thus analogous to a legal consultant reviewing a client's written description of its HR practices; it does not constitute the direct processing of Art. 9(1) data. Where client inputs inadvertently contain special category data (e.g., a client includes actual employee health records in a description field), automated content screening quarantines such inputs and alerts the client DPO to resubmit appropriately abstracted inputs. Quarantined inputs are deleted within 48 hours without processing. Basis for any residual incidental processing: Art. 9(2)(b) — employment law context applicable; Art. 9(2)(a) — collected via explicit consent for those clients who have additionally consented to enhanced AI processing scope.
DPIA status
A full DPIA has been conducted under Art. 35(3)(a) GDPR (systematic profiling of natural persons — the AI system analyses client descriptions of processing operations which indirectly concern data subjects) and in accordance with the ICO / EDPB list of processing requiring mandatory DPIA. See Part K for DPIA summary. The DPIA was completed on 15 September 2024 (ref. DPIA-EXB-2024-003). A supplementary DPIA update is in progress for v2.1 model enhancements; pending completion by 31 March 2025.
Data subjects
B2B client account administrators who submit organisational inputs via the platform. Indirect reference to data subjects described within client input documents (data subjects of client organisations — not directly processed). No direct contact with end data subjects of client organisations.
Personal data categories
Client questionnaire inputs (may include org descriptions, policy text)Uploaded document text (policy files, existing compliance docs)AI-generated draft outputs (stored under client account)Human review edits & approvals (user ID, timestamp, edit delta)Generation metadata (model version, prompt tokens, latency)Feedback signals (approved / rejected / edited — anonymised before model update)
Retention period
Active compliance documents (client-approved outputs): stored for the duration of the subscription + 90 days post-termination (client data export window). Deleted within 30 days of export window close unless legal hold applies. Questionnaire inputs and draft intermediates: retained for 30 days after final document approval (troubleshooting window); then automatically deleted. Generation metadata (anonymised): 24 months for model performance monitoring. Quarantined special category inputs: deleted within 48 hours of quarantine (no further processing).
Technical & organisational security
AI inference performed within AWS eu-central-1 boundary; model weights stored on isolated, air-gapped storage volume; client inputs never transmitted to third-party AI API providers — inference is self-hosted; strict multi-tenant isolation ensures no cross-client data access at model level; content screening layer (keyword + embedding-based) quarantines apparent special category data; model update process requires anonymisation verification by DPO before any training cycle; no individual data subject's personal data used in model training post-deployment.
Purpose of processing
Administration of the Meridian Data Services B.V. channel partner programme, encompassing: (i) partner onboarding — due diligence, partner agreement execution, and partner account provisioning; (ii) referral tracking — attribution of new client subscriptions to referring partner organisations; (iii) commission calculation, invoicing, and payment to partner organisations; (iv) co-marketing activities — joint content, webinar co-hosting, and lead sharing (where separately consented); (v) partner performance reporting — quarterly performance reviews, tier progression assessments, and certification tracking; (vi) partner portal access management — dedicated portal accounts, API credentials, and sandbox environment access for partner integration testing.
Legal basis (Art. 6)
Art. 6(1)(b) — performance of the partner agreement with the partner organisation (partner contact persons are direct counterparties or authorised representatives); Art. 6(1)(c) — VAT-compliant commission invoicing obligations; Art. 6(1)(f) — legitimate interests: channel development, accurate referral attribution, and fraud prevention in commission reporting. No special categories involved. Co-marketing lead sharing requires separate consent from shared leads (collected by the partner in their capacity as a controller).
Data subjects
Named contact persons at partner organisations (account managers, sales contacts, technical integration leads); billing contacts for commission payments; partner portal administrators.
Personal data categories
Partner contact name & professional titleBusiness email & phonePartner agreement terms & tierCommission records & bank details (company account only)Referral attribution data (anonymised client ID + source partner)Partner portal login events & access logsCertification completion records
Retention period
Active partner records: duration of agreement + 2 years (BW Art. 3:310). Commission and fiscal records: 7 years from end of fiscal year (AWR Art. 52). Partner portal access logs: 18 months. Referral attribution data: 3 years from commission payment (audit purposes).
International transfers
Partner management processed in CRM (HubSpot, EU-region DPA applies — see PA-02). Commission payments processed via Dutch bank (SEPA — no third-country transfer). No other third-country transfers in this activity.
Purpose of processing
Internal software development, testing, and quality assurance activities for the Meridian Data Services B.V. compliance platform, encompassing: (i) development environment management — version control, code review, and CI/CD pipeline operations; (ii) test environment operations — functional testing, regression testing, and performance benchmarking using anonymised or synthetic test data; (iii) bug tracking and incident management in the development lifecycle; (iv) developer access provisioning and offboarding to internal code repositories and development infrastructure. Critical constraint: It is a binding internal policy (Engineering Data Governance Policy v3.1, approved by the DPO on 4 November 2024) that real personal data of any data subject is strictly prohibited in development, staging, or test environments. Where representative datasets are required for testing, Meridian Data Services B.V. uses exclusively: (a) synthetically generated data produced by a dedicated data synthesiser tool; (b) anonymised data derived from production exports via an automated anonymisation pipeline that has been validated to resist re-identification with a minimum k-anonymity of k=10. The DPO conducts quarterly compliance audits of development environments to verify absence of real personal data.
Legal basis (Art. 6)
Art. 6(1)(f) — legitimate interests: continuous improvement of platform functionality and security for the benefit of all users; maintenance of a commercially viable and technically stable SaaS service. The LI outweighs any privacy interest as: (i) only internal staff data (developer identifiers, commit metadata) is processed; (ii) strict prohibition on real personal data in test environments means data subject interests are not engaged by the test data processing; (iii) security improvements directly benefit data subjects by reducing breach risk.
Data subjects
Internal software engineers, QA specialists, and DevOps engineers (their developer identifiers, commit metadata, and access logs). No client data subjects (test data is synthetic or anonymised).
Personal data categories
Developer GitHub/GitLab username & emailCode commit metadata (author, timestamp, repository)CI/CD pipeline run logs (developer ID, run outcome)Bug tracker entries (reporter ID, assignee, timestamps)Development environment access logs
Retention period
Code repository commit history: indefinite (part of version control; no personal data beyond developer username and email which are professional context data); individual developer offboarding triggers anonymisation of name to a pseudonymous identifier within 90 days. CI/CD and build logs: 90 days. Bug tracker entries: 3 years from resolution. Development environment access logs: 12 months.
Technical & organisational security
Development and production environments are strictly isolated (separate AWS accounts, no cross-account IAM permissions); automatic scanning tool (custom DLP pipeline) runs daily over development environment storage to detect any real PII patterns; alerts route to DPO and engineering lead; quarterly DPO audit with written report; anonymisation pipeline independently verified by external security audit (last conducted: October 2024).
Purpose of processing
Operation of an internal whistleblowing and ethics reporting channel in compliance with Directive (EU) 2019/1937 on the protection of whistleblowers (the "Whistleblowing Directive") and its Dutch implementing legislation, the Wet bescherming klokkenluiders (Wbk, effective 18 February 2023). The channel enables employees, contractors, and third parties with a work-related relationship with Meridian Data Services B.V. to report actual or suspected violations of law, EU law, or internal company policies. Processing encompasses: (i) receipt and acknowledgement of reports submitted via the dedicated encrypted reporting portal; (ii) initial assessment of report credibility and completeness; (iii) investigation — gathering evidence, interviewing witnesses (with consent), and reviewing relevant records; (iv) outcome determination and communication to the reporting person; (v) maintenance of a confidential case register; (vi) annual aggregated reporting to the Works Council (Ondernemingsraad) in accordance with Wbk Art. 5a.
Legal basis (Art. 6)
Art. 6(1)(c) — legal obligation under Wbk (Wet bescherming klokkenluiders) Art. 2–4, which requires employers with 50+ employees to maintain an internal reporting channel and to conduct investigations of reports received; Whistleblowing Directive Art. 8–9 (mandatory internal reporting procedures). Art. 6(1)(f) — legitimate interests: prevention and detection of legal violations; protection of the company's legal and reputational integrity; protection of affected third parties. Where whistleblower identity is known, the principle of data minimisation requires that identity be confined to the investigator and DPO; identity is not disclosed to the subject of any investigation without explicit legal necessity.
Special categories (Art. 9)
High sensitivity — Art. 9(1) data regularly encountered: Reports frequently contain allegations involving health conditions (occupational health concerns, mental health claims, disability discrimination), criminal offence allegations (Art. 10 GDPR — also applicable), trade union membership (labour dispute context), and on occasion religious or philosophical beliefs. Basis: Art. 9(2)(b) — processing necessary for obligations in the field of employment law (Wbk Art. 2) and social security (Art. 9(2)(b) GDPR; Recital 52); Art. 9(2)(f) — processing necessary for establishment, exercise or defence of legal claims (where report alleges illegal conduct subject to litigation). Art. 10 (criminal allegations): processed under Wbk authority and Uitvoeringswet AVG Art. 33 which permits processing of criminal data in the employment context by designated competent persons.
Data subjects
Reporting persons (identity protected — strict confidentiality obligation under Wbk Art. 17; identity not disclosed to investigation subject without reporter's consent and legal necessity); persons subject to investigation (accused parties); witnesses interviewed during investigation; third parties mentioned in reports.
Personal data categories
Reporter identity (if disclosed — held in encrypted vault)Report content (narrative, evidence attachments)Alleged conduct & parties involvedInvestigation records & interview notesEvidence gathered (documents, emails, access logs)Outcome determination & remediation recordsCase register entry (anonymised for annual reporting)Art. 9(1) / Art. 10 data as incidentally described in reports
Recipients & disclosures
DPO (sole initial recipient — conducts initial triage); independent external investigator (where report alleges conduct by senior management or the DPO — designated external law firm under NDA and DPA); Works Council (aggregated anonymised statistics only per Wbk Art. 5a); law enforcement (where report discloses criminal conduct requiring mandatory reporting under applicable Dutch or EU law — Art. 6(1)(c) basis). No disclosure to investigation subject until investigation is sufficiently advanced to avoid evidence destruction risk; reporter identity never disclosed without explicit consent.
Retention period
Case records (substantiated): 7 years from case closure (potential civil or criminal proceedings; regulatory investigation timeline). Case records (unsubstantiated — no violation found): 2 years from case closure; earlier deletion upon request of reporting person where no ongoing legal need exists. Reporter identity records: deleted immediately upon closure of case unless reporter has consented to retention for reference purposes or legal necessity exists. Annual aggregated statistics: permanently archived (no personal data — anonymised counts only).
Technical & organisational security
Dedicated end-to-end encrypted whistleblowing portal (EQS Integrity Line, EU data residency, ISO 27001 certified, DPA in place); DPO-only access to case files (two-person integrity rule applies for cases involving senior management); case files stored in air-gapped encrypted archive; quarterly DPO audit of case register; reporter identity stored in hardware-secured encrypted vault separate from case file (access requires DPO + Board approval for disclosure).
Part C — Lawfulness analysis summary (Art. 6 & Art. 9 GDPR)
The following table consolidates the legal basis relied upon for each processing activity. No processing activity relies on a single catch-all basis; each activity has been individually assessed. The use of Art. 6(1)(f) (legitimate interests) has in each case been subjected to and documented within a Legitimate Interests Assessment (LIA) held on file by the DPO. Where consent (Art. 6(1)(a)) is relied upon, consent records evidence the requirements of Art. 7 GDPR (freely given, specific, informed, unambiguous). Where Art. 9(2)(b) is relied upon for health data, the specific employment law obligation is identified in each DPIA.
| Processing activity | Primary Art. 6 basis | Secondary Art. 6 basis | Art. 9(2) basis (if applicable) | Consent mechanism |
|---|
| PA-01 Internal HR | Art. 6(1)(b) — contract | Art. 6(1)(c) — labour law; Art. 6(1)(f) — LI (security) | Art. 9(2)(b) — employment law; Art. 9(2)(a) — consent (supplementary) | Explicit consent for supplementary health data; DPA for employment minimum |
| PA-02 Client accounts | Art. 6(1)(b) — contract | Art. 6(1)(c) — VAT/accounting; Art. 6(1)(f) — LI (fraud prevention) | N/A | Not relied upon as primary basis |
| PA-03 Marketing | Art. 6(1)(a) — consent (newsletters); Art. 6(1)(f) — LI (B2B outreach) | Art. 6(1)(f) — LI (existing customer updates) | N/A | Double opt-in via email; IAB TCF v2.2 for analytics cookies; timestamp & version logged |
| PA-04 Security monitoring | Art. 6(1)(c) — Art. 32/33 GDPR obligation | Art. 6(1)(f) — LI (system security) | No Art. 9 basis invoked — processing minimised by design; incidental presence of special category data in security logs does not constitute targeted processing of special categories for the purposes of Art. 9(1) | N/A — legal obligation prevails; special category data minimised at source |
| PA-05 Compliance records | Art. 6(1)(c) — Art. 5(2) GDPR accountability | — | N/A | N/A |
| PA-06 Platform delivery | Art. 6(1)(b) — service contract | Art. 6(1)(f) — LI (platform integrity, SLA fulfilment) | N/A | N/A — contractual necessity prevails |
| PA-07 AI compliance engine | Art. 6(1)(b) — core contracted feature | Art. 6(1)(f) — LI (model improvement — anonymised only) | Art. 9(2)(b) — incidental (quarantined); Art. 9(2)(a) — enhanced scope (opt-in) | Explicit consent for enhanced AI scope; quarantine + delete for inadvertent special category inputs |
| PA-08 Partner program | Art. 6(1)(b) — partner agreement | Art. 6(1)(c) — VAT invoicing; Art. 6(1)(f) — LI (fraud prevention in commission) | N/A | N/A |
| PA-09 Software dev & QA | Art. 6(1)(f) — LI (platform improvement, security) | — | N/A — real personal data prohibited; test data is synthetic/anonymised | N/A — LI applies to developer metadata only |
| PA-10 Whistleblowing | Art. 6(1)(c) — Wbk legal obligation | Art. 6(1)(f) — LI (legal compliance, protection of third parties) | Art. 9(2)(b) — employment law; Art. 9(2)(f) — legal claims; Art. 10 — Wbk authority (UAVG Art. 33) | N/A — legal obligation; confidentiality duty overrides consent requirement |
Part D — Data subject rights (Art. 15–22 GDPR) — implementation status
Example B.V. has implemented technical and organisational measures to enable the exercise of all data subject rights provided under Chapter III GDPR. All rights requests must be submitted to the DPO at dpo@examplebv.example (illustrative address). Identity verification is required prior to response; Example B.V. applies a proportionate verification standard appropriate to the sensitivity of the data concerned (EDPB Guidelines 01/2022 on data subject rights — Art. 15). Responses are issued within one calendar month of receipt (Art. 12(3) GDPR); extension to three months may be applied where requests are complex or numerous, with written reasons provided within the one-month period.
| Right | Legal basis | Applicable to Example B.V.? | Implementation mechanism | Status |
|---|
| Right of access | Art. 15 GDPR | Yes — all processing activities | DPO-managed request workflow; automated data export from HR system and CRM; 30-day SLA; response template maintained by DPO | Implemented |
| Right to rectification | Art. 16 GDPR | Yes — all activities where inaccurate data held | In-platform self-service correction for account data; DPO-managed process for HR records; downstream notification to sub-processors holding copies | Implemented |
| Right to erasure | Art. 17 GDPR | Yes — subject to Art. 17(3) overrides (legal obligation; establishment of legal claims) | Erasure workflow triggers automated deletion in primary systems; manual cascade to sub-processors within 30 days; legal hold flags prevent erasure where retention obligation applies; Art. 17(3) exceptions documented in DPO register | Implemented |
| Right to restriction | Art. 18 GDPR | Yes — where accuracy contested, processing unlawful, data no longer needed, or objection pending | Account-level restriction flag in data platform; restricted data retained but excluded from processing; restriction lifted only following documented review and notification to data subject | Implemented |
| Right to data portability | Art. 20 GDPR | Yes — for data processed on basis of consent or contract, by automated means (PA-01, PA-03) | Machine-readable (JSON / CSV) export available via DPO request; export covers data subject's own data only; interoperability with standard HR data formats (ISO 30300 series where applicable) | Implemented |
| Right to object | Art. 21 GDPR | Yes — to processing based on Art. 6(1)(f); to direct marketing at any time without restriction (Art. 21(2)) | One-click unsubscribe for all marketing; DPO-managed objection workflow for LI-based processing; processing suspended pending assessment; objection outcome documented | Implemented |
| Rights re: automated decisions | Art. 22 GDPR | Currently not applicable — Example B.V. does not engage in solely automated decision-making producing legal or significant effects on data subjects | Under monitoring; any future deployment of automated decisioning to be subject to DPIA and Art. 22 compliance review prior to activation | Monitoring |
Part E — Consolidated retention schedule (Art. 5(1)(e) GDPR — storage limitation)
The storage limitation principle under Art. 5(1)(e) GDPR requires that personal data be kept in a form permitting identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed. The following schedule sets out the retention periods applied to each data category across all processing activities, together with the legal or regulatory basis justifying retention for the specified period and the deletion method employed to ensure secure disposal at expiry. Automated deletion is enforced through the Kortave platform's data lifecycle management module; automated deletion events are logged in the DPO register.
| Data category | Activity ref. | Retention period | Legal / regulatory basis for period | Deletion method |
|---|
| Employee HR records (active) | PA-01 | Contract duration + 2 years | BW Art. 3:310 — civil limitation period | Secure deletion; pseudonymisation of name/BSN retained for payroll audit trail |
| Employee payroll & fiscal records | PA-01 | 7 years from end of fiscal year | AWR Art. 52 — tax record-keeping obligation (mandatory) | Restricted access; anonymisation of non-fiscal fields after 7 years |
| Employee pension scheme records | PA-01 | 7 years (or per pension fund rules, whichever is longer) | Pensioenwet Art. 46 (pension administration record-keeping obligations); pension fund-specific retention rules where longer | Transfer to pension fund upon termination; Example B.V. copy deleted after 7 years |
| Sick leave & health records | PA-01 | Duration of employment + 2 years | Wet verbetering poortwachter; ARBO-wet; BW 3:310 | Secure deletion; medical reports returned to occupational physician |
| Recruitment records (unsuccessful) | PA-01 | 4 weeks post-rejection (or 1 year with consent) | EDPB Guidance on recruitment processing; no statutory minimum | Automated deletion from ATS; recruitment platform purge |
| B2B client contracts & DPAs | PA-02 | 7 years from termination | BW Art. 3:307 — contractual claims limitation | Secure deletion; legal counsel notified prior to destruction |
| Invoices & financial records | PA-02 | 7 years from end of fiscal year | AWR Art. 52 — mandatory fiscal retention | Accounting system archival; deletion at expiry by Exact Online per DPA |
| Support ticket records | PA-02 | 3 years from ticket closure | Art. 6(1)(f) — contractual dispute window; BW Art. 3:310 | Automated purge in helpdesk system per configured data retention policy |
| Marketing consent records | PA-03 | 3 years from consent withdrawal | Art. 7(1) GDPR — obligation to demonstrate consent; potential enforcement action window | Suppression list maintained; full record deleted at 3-year mark via CRM automation |
| Email marketing engagement data | PA-03 | 36 months from last activity; earlier if opt-out | Art. 6(1)(f) — LI (re-permission campaigns); Art. 7(3) — withdrawal takes effect without delay | Automated suppression within 48 hours of opt-out; full deletion within 30 days |
| Website analytics (pseudonymised) | PA-03 | 14 months rolling | Art. 6(1)(a) — consent scope; proportionate analytics purpose | GA4 automatic deletion per configured data retention setting; confirmed via monthly audit |
| Security access logs | PA-04 | 18 months | Art. 32 GDPR — security measure necessity; NIS2 Directive Art. 21 (logging obligations) | Automated SIEM log rotation; archived logs encrypted and deleted at expiry |
| Incident & breach records | PA-04, PA-05 | 5 years from closure / notification | Art. 33(5) GDPR — mandatory breach register; enforcement action limitation period | Restricted access during retention; secure deletion at 5-year mark; DPO sign-off required |
| Data subject rights request records | PA-05 | 3 years from response | Art. 82 GDPR — civil liability claims; potential AP investigation window | Restricted access; secure deletion by DPO at expiry |
Part F — Sub-processors, third-party processors, and data sharing
All third-party processors acting on behalf of Example B.V. are engaged subject to a Data Processing Agreement (DPA) in compliance with Art. 28(3) GDPR. DPAs are reviewed upon contract renewal or material change. Sub-processor additions are communicated to B2B clients (in Example B.V.'s processor capacity) as required by Art. 28(2) GDPR. The table below covers all vendors with access to personal data in Example B.V.'s controller capacity. Note: Paddle.com Market Ltd is listed for disclosure completeness as a recipient of personal data; however, Paddle operates as an independent data controller in its capacity as Merchant of Record and is accordingly not a sub-processor within the meaning of Art. 4(8) and Art. 28 GDPR. Paddle's processing of payment and billing data is governed by Paddle's own privacy policy and is not subject to Example B.V.'s processing instructions.
| Vendor | Role | Data processed | Processing location | Transfer safeguard | Certification |
|---|
| Amazon Web Services EMEA SARL | Cloud infrastructure / IaaS — primary data platform | All categories of personal data held on platform | Frankfurt, Germany (eu-central-1) — EU only | DPA (AWS GDPR DPA v2.2); EU data residency contractually guaranteed; intra-EU only | ISO 27001 · ISO 27017 · SOC 2 Type II · C5 (BSI) |
| HubSpot Ireland Ltd | CRM, marketing automation, sales pipeline | B2B contact data; lead data; email engagement events | Dublin, Ireland (EU) — EU data residency | HubSpot Data Processing Agreement; EU-region data residency add-on active; SCCs (Module 2) as fallback | ISO 27001 · SOC 2 Type II · CSA STAR Level 1 |
| Exact Online (Exact Group B.V.) | Accounting, invoicing, VAT filing | Financial and billing contact data; invoice records | Delft, Netherlands (EU) | DPA in place; Dutch-based processor; intra-EU processing | ISO 27001 · ISO 27018 · ISAE 3402 Type II |
| Resend Inc. | Transactional and marketing email delivery | Recipient email address; email content; delivery metadata | EU-region endpoint (Amsterdam) | Resend DPA; EU data processing; SCCs available | SOC 2 Type II |
| Google Ireland Ltd | Website analytics (Google Analytics 4) | Pseudonymised device identifiers; anonymised usage data; no full IP transmitted | Ireland (EU); measurement data processed in EU before any transfer | Google Ads Data Processing Terms; SCCs (Module 2); IP anonymisation enforced at SDK level | ISO 27001 · SOC 2 · ISO 27017 · ISO 27018 |
| Elastic N.V. (Elastic Cloud) | SIEM — security event management and log aggregation | Security access logs; authentication events; IP addresses | EU-West-1 (Elastic Cloud managed deployment) | Elastic Cloud DPA; EU data residency; SCCs | ISO 27001 · SOC 2 Type II |
| Paddle.com Market Ltd † | Payment processing — Merchant of Record (independent controller) | Billing name; billing address; payment method metadata (card last 4, expiry) | London, England & Wales (UK) | Not a sub-processor; UK EU adequacy decision (Commission Implementing Decision 2021/1772); Paddle Privacy Policy governs | PCI DSS Level 1 · ISO 27001 |
Part G — Processing risk assessment & DPIA register
Risk levels have been assessed against a standard likelihood × impact matrix applied to the rights and freedoms of natural persons (as required by Art. 35(1) GDPR and EDPB Guidelines 09/2022 on Data Protection Impact Assessments). Activities assessed as 'High' risk have been subjected to a full DPIA under Art. 35 GDPR prior to commencement of processing. Activities assessed as 'Medium' risk are subject to enhanced technical and organisational measures and are monitored for escalation. All risk assessments are reviewed annually and following any material change to the processing activity. The DPO has been consulted on all DPIA findings (Art. 35(2) GDPR).
PA-01 — Processing of employee health and disability data at scale (28,400+ data subjects); Art. 9(1) special category data; mandatory DPIA under Art. 35(3)(b) (large-scale processing of special categories)
High · DPIA completed 08/2024 · Ref. DPIA-EXB-2024-001
PA-01 — Payroll processing involving BSN (national identification number) for 47 employees; cross-border payroll reporting to multiple EU tax authorities; high sensitivity of financial identity data
High · DPIA completed 09/2024 · Ref. DPIA-EXB-2024-002
PA-01 — Large-scale HR records for client employees (28,400+ data subjects) — risk of aggregation enabling re-identification; processor-capacity record maintained separately but controller exposure exists for platform-level design decisions
Medium · Mitigated by multi-tenant isolation · access controls · SOC 2 certification
PA-02 — Account takeover risk for B2B platform administrators; compromised credentials could expose large volumes of client employee data; MFA bypass threat vector
Medium · Mandatory MFA · anomalous login detection · quarterly access review
PA-04 — Security logs may incidentally capture special category data transiting monitored systems; risk of over-collection beyond security monitoring purpose
Medium · Data minimisation in logging config · DPO reviewed SIEM rules · quarterly audit
PA-02 — B2B contact management (professional role data only; low sensitivity; reasonable expectations of processing in commercial relationship context)
Low · Standard measures sufficient · no DPIA required
PA-03 — Email marketing (consent-based; no profiling producing legal effects; clear opt-out mechanism; pseudonymised analytics data)
Low · Consent management platform in place · IAB TCF v2.2 compliant
PA-05 — Compliance record-keeping (DPO-restricted access; no automated processing; accountability purpose mitigates proportionality concern)
Low · Access restricted to DPO and legal counsel
Part H — Personal data breach response procedure (Art. 33–34 GDPR)
In the event of a personal data breach as defined in Art. 4(12) GDPR — being a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed — Example B.V. applies the following response procedure. This procedure has been tested via tabletop exercise on 15 October 2024 (exercise log ref. EXER-EXB-2024-003).
| Phase | Timeframe | Action required | Responsible party | Regulatory basis |
|---|
| Detection & containment | T+0 to T+4h | Identify and contain breach source; preserve forensic evidence; isolate affected systems where necessary to prevent further exposure; notify CISO and DPO immediately | Security Operations / CISO | Art. 32 GDPR (security obligation to minimise harm) |
| Preliminary assessment | T+4h to T+12h | Determine: (i) whether breach has occurred; (ii) categories and approximate number of data subjects affected; (iii) categories and approximate volume of records involved; (iv) likely consequences; (v) whether breach is unlikely to result in risk (exemption from Art. 33 notification) | DPO + CISO + Legal counsel | Art. 33(1) — notification required unless unlikely to result in risk |
| AP notification | T+72h (from awareness) | Notify Autoriteit Persoonsgegevens via AP online melding datalekken portal; provide: controller identity; DPO contact; nature of breach; categories and approximate numbers affected; likely consequences; measures taken or proposed. If full information unavailable at 72h, phased notification permitted per Art. 33(4) | DPO | Art. 33(1)–(4) GDPR — 72-hour mandatory deadline from awareness |
| Data subject notification | Without undue delay | Where breach is likely to result in high risk to rights and freedoms of natural persons (Art. 34(1)), notify affected data subjects directly in clear and plain language: nature of breach; DPO contact; likely consequences; mitigation steps taken; steps data subjects can take to protect themselves | DPO + Communications | Art. 34 GDPR — communication to data subject unless Art. 34(3) exemptions apply |
| Post-incident review | T+30 days | Root cause analysis; update risk register and DPIA(s) where applicable; implement remediation measures; document outcome in breach register (Art. 33(5)); report to Board; external notification to sub-processors if breach originated in their systems | DPO + CISO + Board | Art. 33(5) — breach register obligation; Art. 5(2) — accountability |
Part I — Processor-side record of processing activities (Art. 30(2) GDPR)
In addition to its controller-capacity obligations, Meridian Data Services B.V. acts as a data processor within the meaning of Art. 4(8) GDPR in respect of personal data processed on behalf of B2B clients via the compliance platform. Art. 30(2) GDPR imposes a separate obligation on processors to maintain a written record of categories of processing activities carried out on behalf of each controller. The following record is maintained in compliance with Art. 30(2)(a)–(e) GDPR. Each B2B client is individually identified in the internal client register (maintained separately by the DPO, classified Confidential — not included in this document for privacy reasons); the categories of processing and description below reflect the standardised processing scope applicable to all clients within the Professional tier and above. Starter tier clients have a reduced scope as indicated.
Controller(s)
Approximately 320 B2B client organisations (SMEs in DE, NL, FR, BE, SE) each acting as independent data controller in respect of their employees' personal data. Each controller is identified in the Meridian Data Services B.V. client DPA register. Processors must maintain a record per Art. 30(2) covering categories of processing for each controller; the categories below apply consistently across all clients within the standard platform scope.
Name & contact of processor
Meridian Data Services B.V. — Fictielaan 1, 1000 AA Amsterdam, Netherlands. DPO: M. van Dam, dpo@examplebv.example. See Part A for full controller profile (same entity acting as processor in this capacity).
Categories of processing (Art. 30(2)(b))
On behalf of client controllers, Meridian Data Services B.V. processes employee personal data for the following purposes (as specified in each client's Data Processing Agreement under Art. 28(3) GDPR): (i) GDPR compliance documentation generation — processing employee data descriptions to generate Art. 30 RoPA entries, Art. 13/14 privacy notices, and Art. 35 DPIA frameworks for the client's own compliance records; (ii) Compliance monitoring and alerting — automated monitoring of retention schedule adherence, triggering client-facing alerts when retention periods approach expiry; (iii) Data subject rights management — facilitating the client's fulfilment of Art. 15–22 rights requests submitted through the platform by the client's data subjects; (iv) Regulatory update notifications — processing regulatory mapping data to generate client-specific impact assessments for new EU regulations and EDPB guidelines; (v) Audit trail maintenance — maintaining an immutable compliance action log for each client's regulatory audit purposes.
Categories of data subjects
Employees of client organisations (current and former); contractors and contingent workers under client management; job applicants (processing limited to data submitted by client for compliance documentation purposes); data subjects who exercise rights with the client organisation via the platform.
Categories of personal data processed
Employee name & contact details (as provided by client)Employment role & departmentProcessing activity descriptions (may reference employee health policies)Retention schedule parametersRights request content (name, request type, response)Compliance document drafts (may reference employee data categories)Audit trail entries (action, user ID, timestamp, object)
Sub-processors engaged (Art. 28(2)(4))
All sub-processors listed in Part F of this Record (AWS EMEA SARL, Elastic N.V. for security monitoring, Datadog for platform observability) process client data in the same capacity. Meridian Data Services B.V. notifies all active clients of any addition or replacement of sub-processors with 30 days advance notice, as required by each client DPA (Art. 28(2) GDPR). Client controllers retain the right to object to sub-processor changes; continued use of the platform after the notice period constitutes acceptance in accordance with the DPA terms.
Third-country transfers (Art. 30(2)(d))
Processing of client employee data is conducted exclusively within the EU/EEA. AWS eu-central-1 (Frankfurt); Elastic Cloud EU-West-1 (Ireland); Datadog EU endpoint (Ireland). No client employee data is transferred to third countries. The transfer safeguards analysis in Part L applies to Meridian Data Services B.V. vendor relationships only and does not engage Chapter V GDPR for client employee data.
General description of security (Art. 30(2)(e))
Client data is processed in fully isolated, multi-tenant environments. Cryptographic separation ensures no client can access another client's data. AES-256 encryption at rest; TLS 1.3 in transit; field-level encryption for high-sensitivity data fields (health-category flags, IBAN-equivalent fields). Access restricted to client's own authorised administrators. Meridian Data Services B.V. staff access to client data requires a documented client support request; all access events are logged in the immutable audit trail. SOC 2 Type II certification (current period: 1 May 2024 – 30 April 2025). See also PA-04 and Part J/K for full security assessment.
Part J — Data Protection Impact Assessment (DPIA): Health & disability data processing (PA-01)
Prepared under Art. 35 GDPR and EDPB Guidelines 09/2022 on Data Protection Impact Assessments. This DPIA was triggered by Art. 35(3)(b) GDPR — large-scale processing of special categories of data. Reference: DPIA-EXB-2024-001. Completed: 22 August 2024. DPO consulted: 28 August 2024. Controller approval: 3 September 2024. Next review: 3 September 2025 or earlier upon material change.
Processing described
Meridian Data Services B.V. processes health, disability, and occupational health data relating to its 47 FTE employees and approximately 28,400 employee records maintained on behalf of B2B clients (in its processor capacity, covered by separate processor DPIA). This DPIA addresses the controller-capacity processing of its own 47 employees' health data. Processing operations include: receipt and storage of sick leave certificates (arbeidsongeschiktheidsverklaringen); communication with Arbo-dienst (occupational physician service); disability accommodation records; maternity/parental leave medical documentation; mental health programme participation records; and emergency health information maintained for health and safety compliance.
Purpose & necessity
Processing is necessary to fulfil obligations under Wet verbetering poortwachter (mandatory sick leave and reintegration reporting to UWV), ARBO-wet (occupational health and safety management), and Wet werk en inkomen naar arbeidsvermogen (WIA — incapacity for work assessments). No alternative less intrusive means exist to fulfil these statutory obligations. The processing is limited to the minimum data required for each statutory obligation: sick leave certificates (duration, nature of incapacity in functional terms — diagnosis not required), Arbo-dienst reports (functional limitations only — no diagnostic information shared with employer per Dutch medical professional duty of confidentiality), and disability accommodation forms (nature of accommodation required, not underlying medical diagnosis).
Lawfulness
Art. 9(2)(b) GDPR — processing necessary for the purposes of carrying out obligations and exercising specific rights in the field of employment and social security law. Dutch national law (Wet verbetering poortwachter, ARBO-wet, WIA) provides the specific legal basis required by Art. 9(2)(b). Additionally, where processing exceeds the statutory minimum scope (e.g., voluntary wellness programme participation), explicit consent per Art. 9(2)(a) is collected separately and is freely revocable without detriment to the employment relationship.
Data minimisation
Sick leave: employer receives notification of absence and functional limitations from Arbo-dienst; diagnosis is not disclosed to HR. Disability accommodations: HR records the accommodation type and effective date, not the underlying condition. Maternity leave: statutory notification sufficient (no medical records beyond initial certification from physician). Mental health programme: participation is recorded as a binary flag; programme content remains with the third-party EAP provider under a separate DPA and is not accessible by HR. Assessment: data is minimised to the functional minimum required for each statutory purpose.
Storage limitation
Sick leave records: duration of employment + 2 years, then secure deletion (consistent with Wet verbetering poortwachter Annex requirements). Arbo-dienst reports: held by Arbo-dienst; Meridian Data Services B.V. retains only functional limitations summary for accommodation purposes, deleted when accommodation ceases to apply + 1 year. Disability accommodation records: duration of employment. Mental health programme participation flag: deleted within 30 days of programme completion or termination of participation. All above subject to legal hold exception where employment dispute is ongoing.
Risk 1 — Unauthorised access to health records
Likelihood: Low (mitigated). Health data is stored in an isolated sub-environment within the HRMS with role-based access strictly limited to: (a) the individual employee (own data only); (b) the DPO (oversight function); (c) the Arbo-dienst liaison coordinator (single designated individual). Line managers have no access to health data; performance management system is technically isolated from health records. Residual risk: unlikely access in the event of misconfigured RBAC. Mitigation: quarterly access review by DPO; automated alert on any new grant of health data access; CREST-accredited penetration test of HRMS annually.
Risk 2 — Inadvertent disclosure to line management
Likelihood: Low (mitigated). Dutch employment law (specifically the Arbo-dienst confidentiality regime under KNMG guidelines) creates a structural barrier to diagnosis disclosure. However, HR staff involved in accommodation discussions may inadvertently infer health conditions from accommodation requests. Mitigation: mandatory annual training for HR staff on health data handling (minimum 2 hours, attendance logged); accommodation request form redesigned to request 'accommodation type' and 'effectiveness measure' only, not medical justification; DPO reviews all accommodation records quarterly.
Risk 3 — Retention beyond statutory period
Likelihood: Low (mitigated). Automated retention enforcement in HRMS triggers deletion workflow at retention period expiry. Mitigation: automated deletion with DPO confirmation before execution; deletion log maintained; annual audit of deletion completeness. Residual risk: edge case where legal hold overrides deletion; DPO retains discretion to override only where specific legal proceeding is documented.
Risk 4 — Employment decision bias from health information
Likelihood: Low (mitigated). Health data is technically isolated from performance management and promotion decision systems. Performance reviews do not display health flags. Mitigation: disciplinary consequences for any manager using health information in employment decisions (HR policy v4.2); DPO-monitored correlation analysis annually between health record holders and adverse employment decisions (promoted / terminated / PIP — anonymised statistical check); annual DPO report to Board on findings.
DPO finding (28 Aug 2024)
Having reviewed the DPIA for PA-01 health data processing, I provide the following advice pursuant to Art. 35(2) GDPR: The processing is lawful, necessary, and proportionate. The identified risks are appropriately mitigated. I note that the mental health programme participation flag retention (30 days post-completion) is more conservative than strictly required and I support this approach. I have no objection to the commencement or continuation of this processing as described. Residual concern: The annual DPO correlation analysis (Risk 4 mitigation) has not yet been conducted for FY2024 (scheduled Q4 2024). This analysis must be completed and its findings reported to the Board before the next mandatory DPIA review. — M. van Dam, DPO, 28 August 2024.
Controller decision (3 Sep 2024)
The Board of Meridian Data Services B.V. has reviewed the DPIA and DPO advice and approves the continuation of PA-01 health data processing under the conditions and mitigations described. The DPO's residual concern regarding the FY2024 correlation analysis is acknowledged; the Chief People Officer is instructed to schedule this analysis for completion by 31 December 2024. Signed: J. de Vries, CEO, 3 September 2024.
Supervisory authority consultation
Art. 36(1) GDPR provides that where a DPIA indicates that the residual risk is high despite mitigation, prior consultation of the supervisory authority is mandatory. The risk assessment above concludes that all identified risks are reduced to Low after mitigation. Residual risk is assessed as Medium overall (acknowledging the annual correlation analysis as an ongoing mitigation measure not yet executed). This risk level does not meet the threshold for mandatory prior AP consultation. DPO confirms: no Art. 36 consultation required for this DPIA.
Part K — Data Protection Impact Assessment (DPIA): AI-assisted compliance system (PA-07)
Reference: DPIA-EXB-2024-003. Completed: 15 September 2024. DPO consulted: 22 September 2024. Controller approval: 30 September 2024. Supplementary DPIA update initiated: 1 January 2025 (model v2.1 — pending). This DPIA was triggered by: (i) Art. 35(3)(a) — systematic and extensive evaluation of personal aspects relating to natural persons, based on automated processing, including profiling (the AI system analyses descriptions of data subjects' processing environments which indirectly characterise data subjects); (ii) EDPB / national DPA blacklist items — large-scale processing using new technologies (AI-assisted compliance generation). Mandatory consultation with the Autoriteit Persoonsgegevens was not required as residual risk was assessed below the Art. 36(1) threshold.
System description
The Kortave AI Compliance Engine is a proprietary large language model (LLM) fine-tuned on the EU regulatory corpus (GDPR, EU AI Act, NIS2, DORA, and associated EDPB/ENISA guidance) and on anonymised, expert-reviewed compliance documentation. The model accepts structured client inputs (organisational questionnaire responses, existing policy documents, processing activity descriptions) and generates draft compliance documentation in the applicable regulatory framework. The model is deployed on self-hosted infrastructure (AWS eu-central-1) and does not transmit client inputs to any third-party AI provider. Model architecture: transformer-based, ~7 billion parameters. Fine-tuning dataset: 840,000 expert-annotated compliance document fragments (all fully anonymised before fine-tuning). Inference: CPU cluster within isolated VPC. Model version at time of this DPIA: v2.0 (15 September 2024 baseline).
Automated decision-making assessment
Not Art. 22 automated decision-making. The AI output is a draft document requiring mandatory human review and approval before it constitutes a final compliance output. No decision producing legal or significantly similar effects is made solely by the AI system. The platform's 'human-in-the-loop' requirement is enforced at the technical level: documents cannot be designated as 'Final' or 'Submitted to supervisory authority' without a named human reviewer's digital signature. This design choice was made specifically to avoid engaging Art. 22 GDPR and to comply with the forthcoming EU AI Act's human oversight requirements for high-risk AI systems under Annex III (4)(a).
Necessity assessment
The AI compliance engine is the core product feature of the Meridian Data Services B.V. subscription offering. Processing of client questionnaire inputs is strictly necessary to generate the compliance outputs for which clients have contracted. Alternative means (human-only compliance consultants) are available but are the direct market substitute that the platform replaces; their use would negate the purpose of the subscription. No less intrusive technical means of generating personalised compliance documentation without processing client-submitted inputs have been identified.
Data minimisation measures
Questionnaire design enforces input minimisation: clients are prompted to describe processing activities at a categorical level ('describe the categories of employee data processed') rather than submitting raw datasets. File upload fields accept only PDF/DOCX policy documents and reject CSV/XLSX/database exports. The content screening layer (Layer 1: keyword matching; Layer 2: semantic embedding similarity — threshold 0.85 cosine similarity against an Art. 9 data lexicon) identifies and quarantines probable special category data prior to AI processing. Quarantined inputs are deleted within 48 hours; the client is notified and prompted to resubmit abstracted descriptions.
Risk 1 — Model hallucination producing inaccurate legal output
Likelihood: Medium. LLMs are susceptible to confident generation of legally inaccurate text. A compliance document containing hallucinated legal references could mislead a client into regulatory non-compliance, resulting in data subject harm. Mitigation: (a) Retrieval-augmented generation (RAG) architecture grounds model outputs in the curated regulatory corpus, reducing hallucination rate; (b) mandatory human legal review before document finalisation; (c) all generated documents include a prominent disclosure that the output was AI-assisted and requires human expert review; (d) accuracy benchmarking against ground-truth regulatory text at each model release (minimum F1-score threshold: 0.92). Residual risk: Low-Medium. Data subjects indirectly protected by human review requirement.
Risk 2 — Cross-client information leakage via model memorisation
Likelihood: Low (mitigated). A risk exists that the model memorises verbatim training data inputs, potentially reproducing a client's proprietary information in another client's output. Mitigation: (a) client-submitted inputs are not used in model training without explicit client consent and a full anonymisation pass; production model is not updated with live client data; (b) memorisation testing (Carlini et al. 2021 framework) performed at each model update; (c) differential privacy techniques applied to any batch fine-tuning process; (d) multi-tenant inference isolation — each client inference request is processed in a separate sandboxed execution context. Residual risk: Low.
DPO opinion (22 Sep 2024)
The processing described in PA-07 and assessed in this DPIA is, in my assessment, proportionate to the legitimate commercial and compliance objectives of the platform. The technical mitigations for both identified risks are adequate for the current model version (v2.0). I provide the following mandatory condition: the supplementary DPIA update for model v2.1 must be completed and submitted to me for review before v2.1 is deployed to production. Model v2.1 enhancements (expanded regulatory corpus including DORA and EU AI Act technical standards; updated RAG retrieval architecture) may alter the memorisation and hallucination risk profiles assessed above. I will not provide a positive opinion on v2.1 deployment absent completion of the supplementary DPIA. — M. van Dam, DPO, 22 September 2024.
Part L — Transfer Impact Assessment (Art. 46 GDPR safeguards)
For each transfer of personal data to third countries or international organisations (Art. 44 GDPR), Meridian Data Services B.V. has conducted a Transfer Impact Assessment (TIA) in accordance with EDPB Recommendations 01/2020 on measures that supplement transfer tools. The TIA follows a three-step methodology: (Step 1) identification of the transfer and the applicable Art. 46 safeguard; (Step 2) assessment of the third country's data protection framework against EU standards; (Step 3) identification of any supplementary measures required. Where Step 2 reveals a gap between the third country's framework and EU standards, supplementary measures under Step 3 must reduce the assessed risk to an 'essentially equivalent' level (C-311/18 Schrems II, [2020] ECLI:EU:C:2020:559, paras. 91–92). The following transfers have been identified and assessed.
Transfer mechanism
HubSpot Ireland Ltd is incorporated and established in Dublin, Ireland — a Member State of the EU. Data processing by HubSpot under the EU Data Processing Agreement occurs within the EU (Ireland data region contractually guaranteed). This transfer is an intra-EU transfer; Chapter V GDPR is not engaged. The EU-US Data Privacy Framework (Commission Implementing Decision (EU) 2023/1795 of 10 July 2023) provides adequacy cover for any onward transfer by HubSpot to its US parent entity where engaged; Meridian Data Services B.V. has confirmed HubSpot's DPF certification via the DPF List maintained by the US Department of Commerce. No additional Step 3 supplementary measures are required for the primary EU processing.
Assessment outcome
No transfer risk. Processing is EEA-based. EU-US DPF provides adequacy for any US parent access. HubSpot DPA includes sub-processor restrictions and contractual obligations mirroring Art. 28(3) GDPR. Transfer reviewed: 12 February 2025.
Transfer mechanism
Paddle.com Market Ltd is incorporated in England and Wales. As noted in Part F, Paddle acts as an independent data controller (Merchant of Record) rather than a processor engaged under Art. 28. The transfer safeguard for data disclosed to Paddle is the EU adequacy decision for the United Kingdom: Commission Implementing Decision (EU) 2021/1772 of 28 June 2021 ("UK Adequacy Decision"), adopted under Art. 45(3) GDPR, which recognises that the UK ensures an essentially equivalent level of protection for personal data transferred from the EU. The UK Adequacy Decision is subject to periodic review; the Commission has announced an initial four-year review cycle. The Autoriteit Persoonsgegevens monitors adequacy decisions and Meridian Data Services B.V.'s DPO performs an annual assessment of any material UK data protection law changes that might affect adequacy status.
Step 2 assessment — UK data protection framework
The UK retained GDPR (UK GDPR), as incorporated into UK domestic law by the Data Protection Act 2018, provides data protection standards assessed by the Commission as essentially equivalent to the EU GDPR at the time of the adequacy decision. Key equivalences: lawful basis requirement; data minimisation and purpose limitation principles; data subject rights (access, rectification, erasure, portability, restriction, objection); requirement for data processing agreements; international transfer restrictions. Divergence risk assessment: The UK's Data Protection and Digital Information Act 2025 introduced modifications to the UK GDPR framework. The DPO's annual adequacy assessment conducted on 10 January 2025 concluded that the modifications do not, as of this date, represent a material departure from the essentially equivalent standard. This assessment is subject to annual update; if the DPO determines that the UK has diverged sufficiently to affect adequacy, Meridian Data Services B.V. will immediately identify alternative safeguards (Standard Contractual Clauses under Art. 46(2)(c)) or cease the transfer.
Step 3 supplementary measures
Given the current adequacy decision, no mandatory supplementary measures are required. As a matter of contractual prudence, Meridian Data Services B.V. has included in the commercial terms with Paddle a commitment that Paddle will notify Meridian Data Services B.V. of any material change to the UK data protection framework affecting Paddle's data protection obligations within 30 days of such change becoming effective. This notification obligation supplements the Art. 45 adequacy monitoring conducted at EU level.
Transfer mechanism
Google Ireland Ltd (the EU data controller for Google Workspace and Analytics services) is established in Dublin, Ireland. Analytics measurement data is initially processed by Google Ireland Ltd within the EU. However, Google LLC (US parent entity) may access EU-processed data in certain circumstances (e.g., global engineering and security operations). The applicable Art. 46 safeguard for any US-parent access is Standard Contractual Clauses (Module 2, controller-to-processor) as approved under Commission Implementing Decision (EU) 2021/914 of 4 June 2021, incorporated in the Google Ads Data Processing Terms accepted by Meridian Data Services B.V.
Step 2 — US framework assessment
The United States does not have a general EU adequacy decision (the EU-US DPF applies only to DPF-certified entities). Google LLC is DPF-certified (DPF List, entry: Google LLC, certification scope: advertising services; Analytics is included). The DPF constitutes an adequacy decision under Art. 45(3) GDPR for transfers to DPF-certified US entities. Residual FISA 702 risk: Notwithstanding the DPF, the EDPB has noted ongoing concerns regarding US signals intelligence frameworks (FISA Section 702, Executive Order 12333) and their potential application to EU personal data processed by US companies. The Commission acknowledged these risks in the DPF adequacy decision but found them to be adequately addressed by the new redress mechanism (Executive Order 14086 on enhancing safeguards for US signals intelligence; Data Protection Review Court). Meridian Data Services B.V.'s DPO concurs with this adequacy assessment as of 12 February 2025.
Step 3 — Supplementary measures
(1) IP anonymisation enforced at SDK level — GA4 configuration includes 'anonymize_ip' flag preventing full IP address from reaching Google servers. (2) User ID not transmitted — GA4 configuration disables 'User-ID' feature; only pseudonymous client IDs are sent. (3) Ads personalisation disabled — data is not used for advertising personalisation; this restriction is contractually confirmed in the Google Ads Data Processing Terms. (4) 14-month data retention limit — minimum GA4 data retention period applied; data older than 14 months automatically deleted by Google. (5) Server-side consent enforcement — GA4 tag only fires post-consent (IAB TCF v2.2); no data is transmitted for visitors who have not granted analytics consent. These supplementary measures, in combination with the DPF adequacy decision and SCCs Module 2, are assessed as providing an essentially equivalent level of protection for the pseudonymised analytics data transferred. Assessment valid until: 12 February 2026 or earlier upon material change to Google's DPF certification or US data protection framework.
Part M — Legitimate Interests Assessment (LIA) register (Art. 6(1)(f) GDPR)
Where Meridian Data Services B.V. relies upon Art. 6(1)(f) (legitimate interests) as a legal basis, a three-part Legitimate Interests Assessment has been conducted for each such processing activity, as recommended by the EDPB and Article 29 Working Party (WP217: Opinion 06/2014 on the notion of legitimate interests of the data controller). The three-part test requires: (i) identification of the legitimate interest pursued; (ii) necessity test — is the processing necessary for that interest, or could a less intrusive alternative achieve the same result; (iii) balancing test — do the legitimate interests of the controller override the fundamental rights and freedoms of the data subjects, having regard to their reasonable expectations. The following register summarises the LIA conclusions for each Art. 6(1)(f) reliance.
| Activity | Legitimate interest identified | Necessity finding | Balancing test outcome | LIA date & reference |
|---|
| PA-01 — Internal HR (security and IT infrastructure) | Maintenance of IT security infrastructure and access controls protecting all employees; legitimate interest of Meridian Data Services B.V. and its employees in system availability and data integrity | Necessary — no less intrusive alternative to logging user access for security incident response; minimum dataset (user ID, timestamp, action type) configured | Balancing favours controller — employees have reasonable expectations of IT access monitoring in a B2B technology company; controls are proportionate; employees informed via Art. 13 notice and Employee Handbook (Section 8 — IT Monitoring Policy) | LIA-001 · 8 March 2024 · Reviewed 8 March 2025 |
| PA-02 — Client accounts (fraud prevention) | Prevention of fraudulent access to client accounts which could compromise large volumes of third-party employee data (28,400 records); commercial interest in preventing subscription fraud and chargebacks | Necessary — login anomaly detection, IP reputation checks, and abuse pattern monitoring cannot be accomplished without processing session metadata; minimum technical dataset used | Balancing favours controller — client account administrators have a strong reasonable expectation that their access patterns are monitored for security purposes; benefit to data subjects (their employee data protected) materially outweighs any privacy intrusion from session monitoring | LIA-002 · 8 March 2024 · Reviewed 8 March 2025 |
| PA-03 — Existing customer product updates | Informing active subscribers of material product changes, regulatory updates affecting their compliance obligations, and service maintenance notifications directly relevant to their subscribed service | Necessary — product update communications cannot be delivered without processing the subscriber's business email address; no less intrusive means of delivering service-related communications to contracted customers | Balancing favours controller — subscribers have directly contracted for the service and have a clear reasonable expectation of service-related communications; communications are strictly limited to service matters (no upselling without additional consent basis); easy opt-out mechanism available at all times per Art. 21(2) | LIA-003 · 8 March 2024 · Reviewed 8 March 2025 |
| PA-06 — Platform delivery (SLA fulfilment) | Maintaining platform availability, performance, and contractual SLA standards; diagnosing and resolving technical issues affecting multiple clients; capacity planning for infrastructure investment | Necessary — SLA monitoring and performance optimisation cannot be conducted without processing API request metadata and latency data; standard industry practice for managed SaaS services | Balancing favours controller — platform users (client administrators) have an obvious reasonable expectation that their platform usage generates technical logs used for service quality maintenance; no sensitive personal data categories involved; processing is pseudonymised where possible | LIA-004 · 15 August 2024 · Next review 15 August 2025 |
Part N — Consent governance framework (Art. 6(1)(a) & Art. 7 GDPR)
Where processing is based on consent (Art. 6(1)(a)) or explicit consent (Art. 9(2)(a)), Meridian Data Services B.V. applies the following governance framework to ensure consent meets the requirements of Art. 7 GDPR — freely given, specific, informed, and unambiguous indication of the data subject's wishes. Consent is never treated as a catch-all basis; it is relied upon only where the other bases under Art. 6 are not applicable or where the processing scope exceeds the minimum required by a legal obligation or contract. The framework below documents the technical and organisational measures implementing the consent requirements.
Collection mechanism
Double opt-in process: (1) Data subject submits email address and name via website form or event registration page; (2) automated confirmation email is sent to the submitted address requesting positive confirmation via a single-click link; (3) confirmation event (click) is recorded with timestamp, IP address (used for confirmation only — not retained beyond 24 hours post-confirmation), and consent version number. The subscription form does not use pre-ticked boxes. The request for consent is presented separately from any service terms or other conditions. The specific purposes for which consent is sought are stated in plain language on the subscription form (immediately adjacent to the input fields, not in a linked policy document).
Consent record storage
Each consent event is recorded in the consent management database (isolated from the CRM contact record; linkable via subscriber ID but maintained separately to preserve evidential integrity). Consent record contains: subscriber ID (pseudonymised); consent version; timestamp (UTC, millisecond precision); confirmation IP hash (SHA-256, salted — confirming confirmation was from a human click, not stored for any other purpose); source URL of form submission; explicit statement of purposes consented to (text captured at time of consent, not dynamically generated). Consent records are append-only; withdrawal events are recorded alongside the original consent but the original consent record is never deleted (required to evidence both grant and withdrawal per Art. 7(1)).
Withdrawal mechanism
Every marketing communication contains a one-click unsubscribe link (List-Unsubscribe header per RFC 8058; one-click POST mechanism per RFC 9071 where supported by recipient email client). Withdrawal may also be submitted via dpo@examplebv.example. Withdrawal is processed within 48 hours: (1) subscriber is moved to suppression list; (2) all pending scheduled sends to that address are cancelled; (3) withdrawal event is recorded in consent database. Suppression list is permanent and not subject to the 30-day general deletion schedule; it prevents inadvertent re-addition of opted-out addresses to future campaigns. Re-permission campaign (24-month inactivity) requires a fresh consent event meeting all Art. 7 requirements; lapsed consent cannot be 'extended' or 'refreshed' — a new consent grant is required.
Consent version management
Each material change to the purposes for which consent is relied upon (e.g., addition of a new content category, change of data processor for email delivery) increments the consent version number. Where a new consent version is introduced, subscribers on the prior version are notified and invited to confirm consent under the new version. Processing based on the new consent scope does not commence until the data subject has positively confirmed. Subscribers who do not respond within 30 days are treated as having withheld consent for the new scope and continue on the prior scope (or are suppressed if the prior scope is no longer technically separable). Current consent version: 3.1 (effective 1 November 2024).
CMP implementation
Meridian Data Services B.V. uses a Consent Management Platform (CMP) registered with the IAB Europe Transparency & Consent Framework (TCF) v2.2. The CMP is displayed on first visit and upon any material change to the cookie policy. Consent is sought for analytics cookies specifically (GA4 — Purpose 1: Store and/or access information on a device; Purpose 7: Measure content performance) using a granular, purpose-by-purpose consent interface. The CMP records: TC String (IAB-standardised consent record); timestamp; CMP version; purposes consented to. The TC String is stored in a first-party cookie (euconsent-v2) and is accessible to vendors listed in the Global Vendor List (GVL). The GA4 tag is configured with consent mode v2; 'analytics_storage' denied by default — measurement only commences after positive consent grant.
Legitimate basis for server-side analytics
In addition to consent-based GA4 analytics, Meridian Data Services B.V. operates a server-side analytics solution (Plausible Analytics, EU-hosted, cookieless, does not set any cookies or access device storage) for aggregate traffic measurement. Plausible processing is based on Art. 6(1)(f) (legitimate interest: aggregate traffic analytics for service improvement) as it does not require cookies, does not cross-site track, and processes only anonymised aggregate statistics. No ePrivacy Directive consent is required for cookieless server-side analytics that do not access device storage (ePrivacy Directive 2002/58/EC Art. 5(3) — access to terminal equipment storage only).
Part O — Data subject rights request register (FY 2024)
Art. 12(3) GDPR requires provision of information on action taken on a request without undue delay and in any event within one month (extendable to three months in complex cases). Meridian Data Services B.V. maintains a rights request register as part of its Art. 5(2) accountability obligations. The following table summarises rights requests received and processed in financial year 2024 (1 January 2024 – 31 December 2024). All requests were responded to within the one-month period; no extensions were required. Requestor identities are not included in this Register; full records including verification evidence and response correspondence are maintained separately by the DPO and classified Confidential — Restricted.
| Ref. | Right exercised | Data subject category | Date received | Date responded | Response time | Outcome |
|---|
| RR-2024-001 | Art. 15 — Access | Employee | 8 Jan 2024 | 15 Jan 2024 | 7 days | Full access provided — HRMS export + payroll summary |
| RR-2024-002 | Art. 17 — Erasure | Marketing subscriber | 22 Jan 2024 | 29 Jan 2024 | 7 days | Subscriber deleted from active list; suppressed; consent record retained per Art. 7(1) |
| RR-2024-003 | Art. 15 — Access | B2B contact | 14 Feb 2024 | 20 Feb 2024 | 6 days | Access provided — CRM record + support ticket export |
| RR-2024-004 | Art. 16 — Rectification | Employee | 3 Mar 2024 | 8 Mar 2024 | 5 days | Home address corrected in HRMS; correction propagated to payroll provider sub-processor |
| RR-2024-005 | Art. 21 — Objection | Marketing subscriber | 19 Apr 2024 | 22 Apr 2024 | 3 days | Objection to direct marketing — immediately suppressed per Art. 21(2) (no balancing test required for direct marketing objection) |
| RR-2024-006 | Art. 15 — Access | Former employee | 7 May 2024 | 3 Jun 2024 | 27 days | Full access provided — employment records, payroll history (7-year archive), exit interview. Request complex due to volume of records across multiple systems |
| RR-2024-007 | Art. 17 — Erasure | Former employee | 7 May 2024 | 3 Jun 2024 | 27 days | Partial erasure — payroll fiscal records retained under AWR Art. 52 legal hold (Art. 17(3)(b)); name pseudonymised in HRMS; email, address deleted. Data subject notified of retention obligation with legal reference |
| RR-2024-008 | Art. 20 — Portability | B2B contact | 12 Jun 2024 | 18 Jun 2024 | 6 days | Machine-readable JSON export provided (name, email, company, subscription history, support ticket log) |
| RR-2024-009 | Art. 18 — Restriction | Employee | 2 Jul 2024 | 9 Jul 2024 | 7 days | Processing restricted pending accuracy dispute regarding performance appraisal record; restriction flag applied; disputed record frozen. Restriction lifted following resolution on 31 July 2024 |
| RR-2024-010 | Art. 15 — Access | Marketing subscriber | 15 Aug 2024 | 21 Aug 2024 | 6 days | Access provided — consent record, engagement history (last 14 months of analytics pseudonymised data only — no individual-level analytics retained beyond 14 months) |
| RR-2024-011 | Art. 21 — Objection | B2B contact | 4 Sep 2024 | 12 Sep 2024 | 8 days | Objection to legitimate interests-based processing (CRM analytics). LIA reviewed in light of objection; specific circumstances assessed; DPO determined compelling legitimate grounds (contractual relationship) override objection for active contract data; client informed; objection noted on record |
| RR-2024-012 | Art. 15 — Access | Employee | 18 Oct 2024 | 24 Oct 2024 | 6 days | Access provided — full HRMS export including health accommodation record (data subject's own record) |
| RR-2024-013 | Art. 16 — Rectification | B2B contact | 6 Nov 2024 | 11 Nov 2024 | 5 days | Job title updated in CRM; propagated to HubSpot under DPA; data subject confirmed accuracy |
| RR-2024-014 | Art. 17 — Erasure | Marketing subscriber | 20 Dec 2024 | 27 Dec 2024 | 7 days | Erasure completed — subscriber record deleted from all active systems; suppression list updated; consent record retained for 3 years per Art. 7(1) evidential obligation |
Part P — Annual review certification & board notification
Review scope
Full review of this Record of Processing Activities against the current operational processing activities of Meridian Data Services B.V. as at 31 December 2024. Review methodology: (i) interview with each department head (HR, Engineering, Marketing, Sales, Legal) to confirm accuracy of processing descriptions; (ii) technical verification of sub-processor list against current vendor contracts; (iii) retention schedule audit — sample-based verification of automated deletion events; (iv) rights request register review (Part O); (v) breach register review (PA-04); (vi) DPIA register currency check; (vii) LIA register currency check.
New processing activities identified
PA-10 (Whistleblowing — implemented 18 February 2024 to meet Wbk compliance deadline); PA-07 model upgrade (v1.4 → v2.0 — supplementary DPIA initiated per DPO requirement); PA-08 (Partner programme — launched Q3 2024, added to this Record). All three additions have been reflected in this updated Record (v2.1). Art. 13 privacy notices updated to reflect PA-10 addition (completed 15 January 2025).
Discontinued processing activities
None in FY2024. PA-03 LinkedIn prospecting reduced in scope (Q2 2024 strategic decision) but not discontinued; descriptions updated to reflect current scale. No activities have been removed from this Record during the review period.
Sub-processor changes
Datadog Inc. added as observability sub-processor for PA-06 (effective 1 August 2024; 30-day advance notice sent to all B2B clients 1 July 2024 per DPA obligation; no objections received). Resend Inc. upgraded to EU-only data residency option (effective 1 September 2024; DPA updated). No sub-processors removed during review period.
Retention schedule compliance
Audit sample: 40 records across all processing activities (8 per selected activity — PA-01, PA-02, PA-03, PA-04, PA-05). Findings: 39/40 records correctly deleted at retention period expiry. 1 record (PA-03 marketing consent — inactive subscriber) found retained beyond suppression-list deletion date by 12 days due to a configuration issue in the CRM automation workflow. Issue identified, root cause (CRM workflow trigger misconfiguration) remediated on 18 November 2024. Affected record deleted. DPO assessment: minor violation not material to Art. 5(1)(e) compliance overall; no notification to AP required; documented as Near-Miss NM-2024-002 in breach register.
DPO annual certification
I, M. van Dam, in my capacity as Data Protection Officer of Meridian Data Services B.V., appointed pursuant to Art. 37(1)(b) GDPR, hereby certify that: (a) I have conducted the annual review described above; (b) to the best of my knowledge and belief, this Record of Processing Activities, version 2.1, accurately reflects the processing activities conducted by Meridian Data Services B.V. as at 31 December 2024; (c) the processing activities described are, in my assessment, conducted on lawful bases as identified and compliant with the principles of Art. 5(1) GDPR; (d) outstanding actions identified in this review are documented above and will be addressed by the responsible owners within the stated timelines; (e) I have reported the findings of this annual review to the Board of Meridian Data Services B.V. at the Board meeting of 20 January 2025 (minutes ref. BM-2025-001). — M. van Dam, DPO, Meridian Data Services B.V., 20 January 2025.
Board acknowledgement
The Board of Meridian Data Services B.V. acknowledges receipt of the DPO annual review report and this Record of Processing Activities v2.1 at the Board meeting of 20 January 2025. The Board confirms the accuracy of the controller information in Part A, approves the continued processing activities described, and adopts the outstanding action plan set out in Part P above. The Board acknowledges its accountability for the processing activities described herein under Art. 5(2) GDPR. — J. de Vries, CEO; L. Akkerman, CFO; B. Smeets, CTO. 20 January 2025.
Appendix I — Legal basis reference table
The following table cross-references each legal basis relied upon in this Record with its source in the GDPR text, the relevant Recital(s), applicable EDPB guidance, and the specific processing activities in this Record that rely upon it. This reference table is maintained to support supervisory authority review under Art. 30(4) GDPR.
| Legal basis | GDPR provision | Supporting Recitals | EDPB / WP29 guidance | Activities relying on this basis |
|---|
| Performance of contract | Art. 6(1)(b) | Recital 44 — processing necessary to perform contract or take pre-contractual steps | EDPB Guidelines 2/2019 on Art. 6(1)(b) in online services context; WP29 Opinion 06/2014 | PA-01, PA-02, PA-06, PA-07, PA-08 |
| Legal obligation | Art. 6(1)(c) | Recital 45 — legal obligation in Union or Member State law; basis must be sufficiently clear and precise | EDPB Guidelines 03/2020 on the processing of data concerning health | PA-01 (AWR, ARBO-wet, Wet verbetering poortwachter); PA-02 (VAT, AWR); PA-04 (Art. 32–33 GDPR); PA-05 (Art. 5(2), 30, 33(5) GDPR); PA-10 (Wbk) |
| Legitimate interests | Art. 6(1)(f) | Recitals 47, 48 — interests of data controller or third parties; reasonable expectations of data subjects; three-part balancing test | WP29 Opinion 06/2014 on the notion of legitimate interests; EDPB Guidelines 10/2022 on the application of Art. 21 right to object | PA-01 (IT security), PA-02 (fraud prevention), PA-03 (B2B outreach, existing customers), PA-04 (security), PA-06 (SLA), PA-07 (model improvement — anonymised), PA-08 (fraud prevention), PA-09, PA-10 (supplementary) |
| Consent | Art. 6(1)(a) | Recitals 32, 42, 43 — freely given, specific, informed and unambiguous; separate from other matters; withdrawal without detriment | EDPB Guidelines 05/2020 on consent; WP29 Opinion 15/2011 on consent definition; WP29 Guidelines on consent under GDPR (WP259 rev.01) | PA-03 (newsletter subscribers; analytics cookies per IAB TCF v2.2) |
| Art. 9(2)(b) — Employment law | Art. 9(2)(b) | Recital 52 — processing of special categories for employment purposes where authorised by national law with appropriate safeguards | EDPB Guidelines 03/2020; WP29 Opinion 2/2017 on data processing at work; KNMG guidelines (Dutch medical professional standards) | PA-01 (sick leave, disability, health data — Wet verbetering poortwachter, ARBO-wet); PA-10 (allegations in whistleblowing reports) |
| Art. 9(2)(a) — Explicit consent | Art. 9(2)(a) | Recital 51 — explicit consent for special category data; enhanced requirements beyond Art. 7 | EDPB Guidelines 05/2020 on consent (Art. 9 requirements); EDPB Statement 03/2019 on online manipulation and AI | PA-01 (voluntary wellness programme — explicit consent collected separately); PA-07 (enhanced AI processing scope — opt-in) |
| Art. 9(2)(f) — Legal claims | Art. 9(2)(f) | Recital 52 — processing necessary for establishment, exercise or defence of legal claims | EDPB Guidelines 09/2022 on DPIAs (legal claims context) | PA-10 (whistleblowing — special category data in reports where legal proceedings contemplated) |
| Art. 9(2)(h) — Health & social care | Art. 9(2)(h) | Recital 53 — processing for health and social care purposes, subject to professional secrecy | EDPB Guidelines 03/2020 on health data; Dutch Arbo-dienst professional secrecy framework (KNMG) | PA-01 (occupational physician reports — Arbo-dienst access) |
Appendix II — Data flow narrative
The following narrative describes how personal data moves through Meridian Data Services B.V.'s systems and to third parties. This appendix supplements the processing activity descriptions in Part B and is intended to assist supervisory authorities in understanding the data ecosystem at a systems level.
Core platform (AWS eu-central-1)
All personal data processed by the compliance platform — client compliance documents, client account data, user session data, and processor-capacity employee data — is hosted in the primary AWS eu-central-1 environment. The environment consists of: (a) Application tier — containerised microservices (Kubernetes on AWS EKS) handling API requests, compliance document generation (PA-07), and user account management; (b) Data tier — PostgreSQL (client and user data), Redis (session cache, JWT blocklist), AWS S3 (document storage — AES-256 encrypted at rest); (c) Security tier — Elastic SIEM (PA-04); Datadog APM (PA-06); CloudTrail / S3 Object Lock (immutable audit logs). All tiers communicate over private VPC network; no direct public internet exposure of database or security tiers.
HR data flows (PA-01)
Employee data flows: (1) Recruitment → ATS (applicant tracking, internal) → HRMS upon hire; (2) HRMS → Payroll provider (sub-processor) monthly for salary calculation; (3) HRMS → Belastingdienst (annual loonheffing return via payroll provider, statutory); (4) HRMS → UWV (sick leave and WIA notifications via Arbo-dienst, statutory); (5) HRMS → Pension fund (monthly contribution data, statutory). Health data specific flow: (a) Employee → Arbo-dienst (direct, medical confidence); (b) Arbo-dienst → HRMS (functional limitation summary only — no diagnosis). Health data never flows to payroll provider or any other system.
Client data flows (PA-02, PA-06, PA-07)
Client onboarding flow: (1) Client submits contact details → CRM (HubSpot, EU) + Platform account (AWS eu-central-1); (2) DPA executed and filed in DPA register (internal secure storage); (3) Client payment → Paddle (independent controller, UK — billing data only); (4) Subscription provisioned in platform (AWS). During active subscription: API calls from client → platform API gateway → application tier (AWS) → data tier (AWS). Compliance document generation: client inputs → AI engine (self-hosted AWS eu-central-1) → draft output → client review → finalised document (AWS S3, encrypted). No client data egresses the EU/EEA at any point in this flow.
Marketing data flows (PA-03)
Marketing flow: (1) Subscriber submits email → consent database (AWS eu-central-1) + HubSpot CRM (EU-region); (2) Double opt-in confirmation → consent record updated; (3) Campaign send: HubSpot → Resend (EU Amsterdam endpoint) → subscriber email inbox; (4) Engagement events (open, click) → HubSpot CRM; (5) Analytics: browser → GA4 (IP anonymised; Google Ireland, Dublin) → reported in aggregate dashboard. No subscriber email data is transferred to any US infrastructure directly by Meridian Data Services B.V.; Resend and HubSpot EU-region data residency ensures EU processing.
Appendix III — Document change log
| Version | Date | Author | Changes made | Review / approval |
|---|
| v1.0 | 4 March 2023 | M. van Dam (DPO) | Initial Record of Processing Activities — 3 processing activities (PA-01, PA-02, PA-03). First version following appointment of DPO and commencement of formal GDPR compliance programme. | Board approval: J. de Vries, 11 March 2023 |
| v1.1 | 18 June 2023 | M. van Dam (DPO) | Added PA-04 (Information Security Monitoring) following deployment of Elastic SIEM. Updated PA-02 sub-processor list to reflect switch from Stripe to Paddle as Merchant of Record. | DPO sign-off; Board notified at June 2023 Board meeting |
| v1.2 | 2 October 2023 | M. van Dam (DPO) + External counsel | Comprehensive legal review following adoption of EDPB Opinion 5/2023. Transfer Impact Assessment (Part L) added — first version covering HubSpot, Paddle, Google Analytics. LIA register v1.0 added (Part M). | External counsel sign-off (van Doorne N.V.); Board approval: 10 October 2023 |
| v1.3 | 14 March 2024 | M. van Dam (DPO) | Added PA-05 (Compliance Record-Keeping). Updated PA-03 to reflect GA4 migration from UA. Annual review FY2023 completed — findings documented. No new processing activities requiring notification to AP identified. | DPO annual review certification; Board notification: March 2024 Board meeting |
| v2.0 | 22 August 2024 | M. van Dam (DPO) + Legal | Major version update: added PA-06 (Platform Delivery), PA-07 (AI Engine — DPIA ref. DPIA-EXB-2024-003), PA-09 (R&D/QA). Added Part I (Art. 30(2) processor record), Parts J–K (DPIAs). DPA with Datadog Inc. added. Resend EU data residency confirmed and updated. Consent Framework (Part N) added. | DPO certification 15 September 2024; Board approval 30 September 2024 |
| v2.1 | 12 February 2025 | M. van Dam (DPO) | Annual review FY2024: added PA-08 (Partner Programme), PA-10 (Whistleblowing — Wbk compliance). Added Part O (Rights Request Register FY2024), Part P (Annual Review Certification). Updated TIA for UK adequacy (DPDIB Act 2025 assessment). Updated Part C lawfulness table for all 10 activities. Consent version updated to 3.1. | DPO certification 20 January 2025; Board approval 20 January 2025 (BM-2025-001) |
Data Controller representativeJ. de Vries, Chief Executive Officer — Example B.V. Data Protection Officer (Art. 37 GDPR)M. van Dam, DPO — Example B.V. Reviewed byKortave Compliance Platform · Version 2.1 · 12 Feb 2025 Next mandatory review12 February 2026 · or earlier upon material change