GDPR Art. 22: how did you document 'meaningful information' for automated decisions?

The documentation burden for Art. 22 is often underestimated because the regulation's language around "meaningful information" is deliberately vague — which is both a feature and a problem. What we ended up producing for our DPO was a three-layer documentation package: 1. **System-level**: Data flow diagrams showing exactly where automated decisions happen, what input data feeds the model, what the output is used for, and where the human override point sits. This is the easy part. 2. **Model-level**: This is where it gets hard. You need to document: (a) the logic of the decision-making process — which for neural networks means you're documenting the architecture, training objectives, and feature importance at a level a non-technical reviewer can understand; (b) the significance and envisaged consequences — essentially a risk assessment of what happens when the model is wrong. We used SHAP values for feature importance and built a "plain language" summary that maps model outputs to real-world consequences (e.g., "score < 0.3 → application rejected → user must reapply in 30 days"). 3. **Process-level**: The "meaningful human intervention" documentation. This is the part most teams get wrong. The EDPB guidelines say the human reviewer must have actual authority to override the decision, not just rubber-stamp it. We documented: who reviews, what information they see (not the raw model output — a summarized risk score with the top 3 factors), what their training requirements are, and the escalation path if they disagree. The biggest gap we found: most teams document the model but not the override process. Auditors care about both equally. If a human can override but doesn't know why the model decided X, that's not meaningful intervention — it's theater.

From a practitioner's perspective, the most valuable thing you can do early is establish a 'compliance baseline' — a living document that maps your current state against each applicable framework. We found that most organizations start with compliance gaps they don't know they have. A structured baseline assessment reveals: (1) controls you think you have but don't, (2) controls you have but aren't documented, and (3) controls that exist but don't match the framework's language. Fixing #3 alone gets you 60% of the way to certification in most cases.

We ran into the NIS2 classification problem last month. Our workaround: we built a 5-point scoring rubric that maps directly to the 'significant impact' criteria in Art. 21(2). Score each incident on: (1) service downtime in hours, (2) number of affected users, (3) financial impact, (4) data breach scope, (5) criticality of affected infrastructure. If the weighted score exceeds threshold X, it automatically enters the 24h reporting pipeline. The 3-hour debate you describe is exactly the problem NIS2 was designed to prevent — you need pre-baked criteria so the SOC doesn't need legal counsel at 2am to classify an incident.