Concept card

GDPR Accountability Principle

As of 2026-07-23

Edited by Cédric-Olivier Mâry, sole editor and publication director — 27 years in the SAP ecosystem. How these pages are produced, and where automation is used.

What is GDPR Accountability Principle?

Under Article 5(2), the absence of documented proof IS the compliance failure — regardless of whether any actual harm occurred.

What it is

The GDPR Accountability Principle (Article 5(2)) is the obligation that distinguishes GDPR from prior data-protection regimes: the controller must not only comply, they must DEMONSTRATE compliance through documented evidence. For SAP analytics consultants who process client personal data, accountability obligations cascade through their work — and the absence of documentation is itself a compliance failure, regardless of whether actual harm occurred.

The four documentation pillars. (1) Records of Processing Activities (ROPA, Article 30) — every consultant operating as a processor must maintain a register of processing activities for each client, including categories of data, processing purposes, retention, transfers, security measures. (2) DPIA (Data Protection Impact Assessment, Article 35) — required when processing is "high risk" (large-scale personal data, sensitive categories, automated decision-making, monitoring). SAP analytics work on customer-segmentation models or HR analytics typically triggers DPIA requirement. (3) Records of Data Subject Requests — when client receives a data-subject-rights request (access, rectification, erasure), processor must support response within statutory timelines. Documentation proves cooperation. (4) Breach Register — every personal-data breach (even those not reaching notification threshold) logged with date, scope, mitigation, lessons learned.

Why it matters

Most CNIL audits find documentation gaps, not actual data misuse — the paperwork itself is the exposure, not the underlying practice.
SAP analytics work on customer-segmentation or HR-analytics models typically triggers the DPIA requirement under Article 35's 'high risk' threshold.
The controller/processor line blurs when a consultant makes independent decisions on data structure — drifting toward joint controllership without anyone noticing.

Key points

Art. 5(2): demonstrate compliance via documented evidence.
Four pillars: ROPA · DPIA · DSR records · breach register.
ROPA per-client, quarterly updates.
DPIA when > 10k subjects OR sensitive categories.
Sub-threshold breaches still logged internally.
CNIL 2024-2026: B2B service providers priority.
Investment: €800 template + ~4h/quarter/client.
Status drift to joint controllership = accountability trap.
GDPR Accountability Principle is mastered only when it changes a named buyer decision.
Start with the semantic contract and control model before demonstrating the tool.

Terms used on this page

Accountability Principle: GDPR Art. 5(2) requirement to DEMONSTRATE compliance, not just achieve it.
ROPA (Records of Processing Activities): Art. 30 register documenting processing activities per controller relationship.
DPIA (Data Protection Impact Assessment): Art. 35 risk assessment for high-risk processing (large-scale, sensitive categories, automated).
DSR (Data Subject Request): Subject's right to access/rectify/erase. Processor supports controller's response.
Breach Register: Internal log of all personal-data breaches, including sub-72h-notification events.
Status drift: Processor unintentionally crossing into joint controllership via independent decisions on data structure.
Self-audit: Annual Q4 review of ROPA + DPIA + breach register + DSR cooperation evidence.
TIA (Transfer Impact Assessment): Schrems-II-mandated case-by-case documentation for non-EEA personal-data transfers.

Sources

Full card available to members. What the full card adds: the full decision framework · the SAP vs Snowflake / Databricks / Fabric comparison · the common pitfalls and their fix · the cheat sheet · the architecture schemas · the code blocks.

Open in the app →