Search every question across sub-FAQs

Keep evidence at processing-activity level. A useful role file shows the purpose, essential means, party responsibilities, instructions, contract or arrangement, relevant records of processing, and the trigger for reassessing the label.

Article 30 records support this work because controllers must record processing activities under their responsibility, while processors must record categories of processing carried out on behalf of each controller. RoPA entries should therefore preserve the controller, processor, joint-controller, and subprocessor distinctions instead of collapsing every party into a vendor list.

A DPIA is mandatory when the planned processing is likely to result in a high risk to individuals. Article 35 says the controller must assess the impact before the processing starts, especially where new technologies are used and the nature, scope, context, and purposes of the operation make the risk high.

Article 35(3) gives three cases where a DPIA is required in particular: systematic and extensive automated evaluation, including profiling, that produces legal or similarly significant effects; large-scale processing of special-category data or criminal-offence data; and large-scale systematic monitoring of a publicly accessible area.

Start with the three Article 35(3) cases, then test the broader high-risk criteria described in DPIA guidance: evaluation or scoring, automated decisions with legal or similar significant effects, systematic monitoring, sensitive or criminal-offence data, large scale, matched or combined datasets, vulnerable people, innovative technology, cross-border transfers outside the EU, and processing that prevents people from exercising a right or using a service or contract.

The DPC guidance reports the WP29 rule of thumb: the more criteria a processing operation meets, the more likely it is to require a DPIA; operations meeting at least two criteria will require a DPIA, and a controller that decides otherwise should thoroughly document why the processing is not likely to be high risk.

Article 35(4) requires each supervisory authority to establish and publish a list of processing operations that are subject to the DPIA requirement, and Article 35(5) allows a supervisory authority to publish a list of operations for which no DPIA is required. Use those lists as a jurisdiction-specific check only where the relevant list is actually available and applicable to the processing operation.

Do not treat a general guidance page, sector label, vendor statement, or non-applicable national list as an exemption. If a no-DPIA list is used, the decision should explain why the processing falls strictly within the listed procedure and continues to meet the relevant requirements.

If the threshold is met, Article 35(7) requires the DPIA to contain at least four elements: a systematic description of the envisaged processing and purposes, an assessment of necessity and proportionality, an assessment of risks to data subjects' rights and freedoms, and the measures envisaged to address those risks and demonstrate GDPR compliance.

CNIL's PIA methodology maps those elements into practical records: context and processing description; fundamental-principles analysis covering purpose, lawfulness, minimization, storage, information, rights, processors, and transfers; privacy-risk analysis; and formal validation involving DPO advice and, where appropriate, views of data subjects or their representatives.

Do not start the Article 33 clock from every raw security alert. The EDPB says a controller becomes aware when it has a reasonable degree of certainty that a security incident has occurred and has led to personal data being compromised.

That short investigation period is not a pause button. The controller is expected to investigate promptly, establish whether personal data was breached, contain the incident, assess risk to individuals, and notify the supervisory authority if Article 33 is triggered.

A processor that becomes aware of a personal data breach affecting personal data processed for a controller must notify the controller without undue delay. The processor does not decide the Article 33 risk threshold for the controller before escalating.

Once the processor informs the controller, the controller uses that notice to run the Article 33 assessment and, if required, notify the supervisory authority. The controller keeps legal responsibility for notification even if a processor is authorised to submit a notice on its behalf.

The GDPR allows notification information to be provided in phases when it is not possible to provide all information at the same time. The first notice should say what is known, what is not yet known, and that more information will follow without undue further delay.

If the supervisory-authority notification is not made within 72 hours after awareness, Article 33 requires reasons for the delay. Those reasons should be specific to the breach, such as why facts could not be established sooner or why a bundled notification was used for closely related breaches.

Article 33(5) requires the controller to document personal data breaches, including the facts, effects, and remedial action. The record must allow a supervisory authority to verify compliance with Article 33.

Keep records for both notifiable and non-notifiable breaches. If the controller decides not to notify, the record should explain why the breach was unlikely to result in risk to individuals; if data subjects are not told, the record should support the Article 34 high-risk decision or applicable Article 34 condition.