GRC Portfolio — Write-up #02

GDPR Data Flow Audit
& ROPA Gap Analysis

Mapping personal data flows across a fictional SaaS organisation, assessing compliance of Records of Processing Activities under GDPR Article 30, and identifying four gap categories with structured remediation guidance.

Author
Xavier Richert

Date
March 2026

Environment
Simulated — fictional dataset

Frameworks
GDPR Art. 30 · Art. 32 · ISO 27701

Tools
Python · Pandas · draw.io

Executive Summary

A simulated data flow audit was conducted for Verada Health Tech (fictional SaaS organisation processing patient-adjacent data). Analysis of five core processing activities revealed that two lacked a documented lawful basis, one transferred personal data to a third-country processor without adequate safeguards, and none had retention periods formally defined in the ROPA. Risk is rated High for the third-country transfer and Medium for the remaining gaps. Four structured recommendations are provided with GDPR article references and ISO 27701 mapping.

Scenario & Methodology

Organisation: Verada Health Tech (fictional) — a B2B SaaS company providing workflow tools to physiotherapy clinics across the EU. The platform collects appointment data, practitioner notes, and basic patient identifiers on behalf of clinic customers, who act as data controllers. Verada is a data processor under GDPR Article 4(8).

The audit objective was to reconstruct the organisation's data flows from first principles, verify them against the existing ROPA (which had not been updated since 2022), identify gaps, and produce an updated gap register with remediation priorities.

Methodology followed a three-stage approach used in real DPO engagements: (1) data flow discovery via system inventory and interview simulation, (2) ROPA comparison against documented flows, (3) gap classification and framework mapping.

Why this matters for Xavier's profile ROPA auditing is one of the most common entry-level GRC tasks in organisations subject to GDPR. It requires both technical understanding of how data moves through systems and regulatory knowledge of what must be documented. Xavier's data pipeline background gives him a rare ability to reconstruct data flows from system architecture rather than relying solely on self-reported inventories.

Data Flow Map — Verada Health Tech

The following diagram reconstructs personal data flows across Verada's platform architecture. Five processing activities were identified. Third-party processors are highlighted where data leaves the EU/EEA.

ROPA Assessment — Five Processing Activities

GDPR Article 30 requires processors to maintain a Record of Processing Activities documenting, at minimum: the name and contact details of the processor, categories of processing, transfers to third countries, and where possible retention periods. The existing Verada ROPA was assessed against each required element.

Processing activity	Lawful basis	Retention	3rd country	DPA clause	Status
Appointment scheduling Name, DOB, contact	Art. 6(1)(b)	Missing	No	Present	Partial
Email notifications Email address, appt ref	Art. 6(1)(b)	Missing	USA (SendGrid)	SCCs signed	Partial
Usage analytics User ID, click events	Undocumented	Missing	USA (Mixpanel)	No SCCs	Non-compliant
Support tickets Name, issue description	Assumed Art. 6(1)(f)	Missing	EU (Zendesk)	SCCs signed	Partial
Staff access logs Employee ID, timestamps	Art. 6(1)(c)	Missing	No	N/A	Partial

Python — ROPA Completeness Audit Script

The following script was used to load the ROPA as a structured dataset, calculate a completeness score per processing activity, and flag records below the compliance threshold. This approach demonstrates how data engineering skills apply directly to GRC evidence work.

Python — ROPA completeness scoring (Pandas)

import pandas as pd
import json

# Required ROPA fields under GDPR Art. 30(2)
REQUIRED_FIELDS = [
    'processing_activity', 'data_categories',
    'lawful_basis',       'retention_period',
    'third_country',       'transfer_safeguard',
    'dpa_clause_ref',      'processor_contact'
]

df = pd.read_csv('ropa_verada_2022.csv')

# Score completeness: 1 pt per non-null, non-empty field
def completeness(row):
    filled = sum(
        1 for f in REQUIRED_FIELDS
        if pd.notna(row.get(f)) and str(row.get(f)).strip() != ''
    )
    return round(filled / len(REQUIRED_FIELDS) * 100, 1)

df['score'] = df.apply(completeness, axis=1)

# Flag high-risk gaps: missing safeguard on 3rd country transfer
df['critical_gap'] = (
    (df['third_country'].notna()) &
    (df['transfer_safeguard'].isnull() | (df['transfer_safeguard'] == ''))
)

gaps = df[df['score'] < 75][['processing_activity', 'score', 'critical_gap']]
print(gaps.to_string(index=False))

##  processing_activity          score  critical_gap
##  Usage analytics               37.5          True   ← HIGH RISK
##  Support tickets               62.5         False
##  Appointment scheduling        75.0         False
##  Email notifications           75.0         False

## FLAG: Usage analytics — 3rd country transfer (Mixpanel/USA)
## with no Standard Contractual Clauses on file. GDPR Art. 46 breach.
## Immediate action required.

Gap Register

GAP-01 — Third-country transfer without SCCs (Mixpanel) CRITICAL

Usage analytics data (User IDs, behavioural events) is transferred to Mixpanel servers in the United States without Standard Contractual Clauses, Binding Corporate Rules, or any other Art. 46 safeguard. This constitutes an unlawful transfer. Mixpanel processes data that may be linkable to natural persons via User ID.

GDPR Art. 44, 46 · EDPB Recommendations 01/2020 · ISO 27701 §8.5.5

GAP-02 — No lawful basis documented for analytics processing HIGH

The usage analytics processing activity has no lawful basis recorded in the ROPA. Legitimate interest (Art. 6(1)(f)) could be applicable but has not been assessed via a Legitimate Interest Assessment (LIA). Without a LIA on file, the basis cannot be defended in a supervisory authority inquiry.

GDPR Art. 6(1)(f) · Art. 30 · EDPB Guidelines 01/2019 on LIA

GAP-03 — Retention periods absent across all five activities MEDIUM

No retention period is defined for any of the five processing activities in the ROPA. GDPR Art. 5(1)(e) requires data to be kept "no longer than necessary." Without defined retention periods, automated deletion workflows cannot be implemented and the organisation cannot demonstrate compliance with storage limitation.

GDPR Art. 5(1)(e) · Art. 30(1)(f) · ISO 27701 §7.4.7

GAP-04 — ROPA last updated 2022 — reflects outdated architecture MEDIUM

The existing ROPA reflects Verada's architecture as of 2022. Zendesk was added as a sub-processor in Q3 2023 and Mixpanel in Q1 2024. Neither appears in the 2022 document. The ROPA is a living document and must be updated when processing activities change. Absence of a maintenance cadence is itself a compliance gap.

GDPR Art. 30 · Recital 82 · ISO 27701 §5.2.1

Framework Mapping

GAP-01Unlawful transfer

GDPR Art. 44 & 46 — Transfers to third countries require an adequacy decision or appropriate safeguard. The EU-US Data Privacy Framework covers some processors but Mixpanel must be verified against the current DPF list. If not listed, SCCs must be executed and a Transfer Impact Assessment (TIA) completed before any further data transfer.

GAP-02Missing lawful basis

GDPR Art. 6(1)(f) — Legitimate interest requires a three-part test: the interest must be legitimate, necessary, and not overridden by data subjects' interests. A documented LIA is required. ISO 27701 §7.2.2 requires that processing purposes be defined and documented prior to processing commencing.

GAP-03No retention periods

GDPR Art. 5(1)(e) storage limitation — Each processing activity requires a defined maximum retention period tied to the purpose. ISO 27701 §7.4.7 maps directly. Retention periods feed into deletion schedules and must be communicated to data subjects in the privacy notice.

GAP-04Stale ROPA

GDPR Art. 30 & Recital 82 — The ROPA must reflect current processing. ISO 27701 §5.2.1 requires a process for keeping privacy-related documentation current. A minimum annual review cadence with triggered updates on any change to processing activities should be established as policy.

Recommendations

R1
Suspend Mixpanel transfer and execute SCCs or verify DPF listing Immediately suspend transfer of personal data to Mixpanel pending legal review. Verify whether Mixpanel appears on the EU-US Data Privacy Framework list. If not, execute EU Standard Contractual Clauses (Module 4 — Controller to Processor) and complete a Transfer Impact Assessment before resuming. If pseudonymisation can render the data non-personal before transfer, document the assessment.
Priority: ImmediateOwner: DPO + Legal
R2
Complete a Legitimate Interest Assessment for analytics processing Conduct and document a three-part LIA for the usage analytics processing activity. If legitimate interest is confirmed, update the ROPA and privacy notice accordingly. If not, consider alternative bases or redesign the analytics to use aggregated non-personal data only, removing the GDPR obligation entirely.
Priority: 14 daysOwner: DPO
R3
Define and document retention periods for all five activities For each processing activity, define a maximum retention period based on the purpose and any applicable statutory requirements (e.g. healthcare records legislation in each operating jurisdiction). Map retention periods to automated deletion workflows in the database layer. Update the ROPA and privacy notice to reflect periods. Xavier's data pipeline experience is directly applicable here — defining deletion jobs in the ETL layer is a technical implementation of this policy requirement.
Priority: 30 daysOwner: DPO + Engineering
R4
Establish a ROPA maintenance procedure with annual review cadence Create a documented ROPA maintenance policy: minimum annual full review, triggered update on any new processing activity, sub-processor addition, or change to data categories. Assign ownership to the DPO. Add ROPA review as a standing item on the annual compliance calendar. Version-control the ROPA document with a changelog — the 2022 gap would have been detected immediately if a 2023 version had been required.
Priority: 30 daysOwner: DPO

GRC Reflection

The most significant finding in this audit — the Mixpanel transfer without SCCs — was not visible in the ROPA at all. It was discovered by reconstructing the data flow from the system architecture and then checking each third-party integration against the documented record. This is where a background in data engineering changes the quality of a GDPR audit: rather than relying entirely on self-reported processing inventories, an auditor who understands how data pipelines actually work can identify what the inventory is missing.

The gap between what an organisation believes it does with data and what it actually does with data is where most regulatory risk lives. The ROPA audit is the mechanism for closing that gap — but only if the person conducting it knows what to look for at the pipeline level, not just the policy level.

Skills demonstrated in this write-up

GDPR Art. 30 — ROPA audit Art. 44/46 — third-country transfers Lawful basis assessment ISO 27701 mapping Data flow reconstruction Python · Pandas — compliance scoring Gap register documentation Transfer Impact Assessment framing Retention period policy Sub-processor management

GDPR Data Flow Audit& ROPA Gap Analysis

Scenario & Methodology

Data Flow Map — Verada Health Tech

ROPA Assessment — Five Processing Activities

Python — ROPA Completeness Audit Script

Gap Register

Framework Mapping

Recommendations

GRC Reflection

GDPR Data Flow Audit
& ROPA Gap Analysis