Who is concerned?
The GDPR applies to any organisation that processes personal data of people in the EU — regardless of where the organisation itself is established.
- Controllers — you decide why and how personal data is processed.
- Processors — you process personal data on a controller's instructions (SaaS vendors, hosting providers, analytics platforms).
- Non-EU organisations offering goods or services to people in the EU, or monitoring their behaviour.
If you build software that touches customer data, employee data or telemetry that can identify a person, the GDPR is in scope — and it stacks with CRA, NIS2 and the AI Act rather than replacing them.
What it requires (high-level)
RICE tracks 15 atomic obligations for the GDPR, each anchored to a specific article and paragraph:
- Security of processing (Art. 32(1)) — appropriate technical and organisational measures, proportionate to risk.
- Integrity and confidentiality (Art. 5(1)(f)) — a founding principle, not an optional control.
- Data protection by design and by default (Art. 25(1) and 25(2)) — two distinct obligations, often treated as one.
- Processor due diligence (Art. 28(1)) and written processing agreement (Art. 28(3)), including the duty to assist the controller (Art. 28(3)(f)).
- Breach notification to the supervisory authority (Art. 33(1)) and documentation of the breach (Art. 33(3)).
- Breach communication to data subjects (Art. 34(1)) when the risk to their rights is high.
- Data protection impact assessment (Art. 35(1)), with the minimum content it must contain (Art. 35(7)).
- Records of processing activities (Art. 30(1)).
- Transfers to third countries (Art. 44) — adequacy, safeguards or derogation.
- Designation of a data protection officer (Art. 37(1)) where the conditions are met.
Why it overlaps with your other obligations
The GDPR is where NexCyber's cross-regulation engine earns its keep. The same technical control frequently answers to several regulations at once:
- Incident reporting — GDPR Art. 33 (72 hours to the supervisory authority) sits alongside NIS2 reporting deadlines and CRA vulnerability reporting. Different deadlines, different recipients, one detection capability.
- Security of processing — GDPR Art. 32 overlaps substantially with NIS2 risk-management measures and CRA essential requirements.
- DPIA — GDPR Art. 35 and the AI Act's fundamental rights impact assessment cover adjacent ground for AI systems processing personal data.
RICE maps these once and shows you which evidence serves more than one obligation, instead of asking you to produce it twice.
Exposure
Two tiers of administrative fines apply. The upper tier — which covers the obligations above — is capped at €20 million or 4% of total worldwide annual turnover, whichever is higher (Art. 83(5)). Supervisory authorities weigh the nature, gravity and duration of the infringement, whether it was negligent or intentional, and the measures taken to mitigate harm.
How RICE handles the GDPR
- Applicability is determined deterministically — the rule engine evaluates your profile (personal data processing, establishment in the EU, monitoring of data subjects) against
backend/rules/gdpr/applicability.json. No language model decides whether the GDPR applies to you. - Each of the 15 obligations carries its legal anchor down to the paragraph and, where relevant, the point —
GDPR/Art.33/P1,GDPR/Art.28/P3/L.f. Every statement in a RICE report can be traced to the text it comes from. - Shared controls are surfaced, not duplicated — where a control also answers to NIS2 or the CRA, the cross-regulation view says so.
Note on scope. The GDPR is a data protection regulation, and NexCyber addresses it from the angle of technical and organisational security measures — the obligations listed above. It does not cover the full breadth of data protection law: lawful basis, consent mechanics, data subject rights handling and retention policy remain your privacy counsel's domain, not a compliance engine's.