Skip to main content
Privacy Track
Category: Impact Assessments & Documentation

Systematic Description of Processing

Also known as: Systematic description of envisaged processing operations, Description of the processing (DPIA)
Simply put

A systematic description of processing is a structured, comprehensive account of how an organisation intends to handle personal data as part of a Data Protection Impact Assessment. It typically explains what data is involved, how it will be collected, used, stored, shared and deleted, where the data comes from, and why the processing is carried out. It is meant to give a clear, complete picture of the planned activity so that its privacy risks can be assessed.

Formal definition

Under Article 35 GDPR, a Data Protection Impact Assessment must contain, as a minimum, a systematic description of the envisaged processing operations and the purposes of the processing. In practice, and consistent with regulator guidance (for example the ICO), this description generally covers the nature of the processing (how personal data is collected, used, stored and deleted), the sources of the data, any data sharing, and the purposes pursued. The description forms the factual foundation of the DPIA against which necessity, proportionality and risks to individuals are subsequently assessed; it should not be conflated with the necessity/proportionality assessment or the risk-mitigation measures, which are distinct DPIA components. The precise expected content beyond the statutory minimum can vary with regulator guidance and member state practice, so practitioners should verify requirements against the current official text and applicable supervisory authority guidance. Note this term is specific to the DPIA context and is unrelated to 'systematic processing' as used in cognitive psychology.

Why it matters

The systematic description of processing is the factual foundation on which an entire Data Protection Impact Assessment rests. Under Article 35 GDPR, a DPIA must contain, as a minimum, a systematic description of the envisaged processing operations and the purposes of the processing. If this description is incomplete or inaccurate, for example, if it omits data sharing arrangements or fails to identify where data originates, the necessity, proportionality and risk assessments that follow are built on a flawed picture, and any mitigation measures may address the wrong risks. Getting the description right is therefore a precondition for a defensible DPIA.

The description also serves an accountability and evidential function. Regulator guidance, such as that published by the ICO, expects the description to cover the nature of the processing (how personal data is collected, used, stored and deleted), the sources of the data, any data sharing, and the purposes pursued. A clear, complete account allows supervisory authorities, data protection officers and internal reviewers to understand at a glance what is planned and to test whether the processing is justified. It also helps demonstrate that the organisation genuinely engaged with the activity before deploying it, rather than treating the DPIA as a formality.

Because the description is where scope is fixed, it is easy to conflate it with other DPIA components. It should not be treated as the necessity and proportionality analysis, nor as the set of risk-mitigation measures, these are distinct parts of the assessment. Keeping the description separate and comprehensive reduces the chance that a risk is overlooked simply because the underlying processing was never fully mapped. The precise content expected beyond the statutory minimum can vary with regulator guidance and member state practice, so practitioners should verify requirements against the current official text and applicable supervisory authority guidance.

Who it's relevant to

Data Protection Officers
DPOs frequently review or advise on DPIAs and rely on the systematic description as the basis for judging whether necessity, proportionality and risk have been properly addressed. An incomplete description makes meaningful oversight difficult, so DPOs typically press for a full account of the data lifecycle, sources, sharing and purposes.
Privacy and Compliance Leads
Those responsible for building and maintaining DPIA processes need to ensure the description captures at least the statutory minimum under Article 35 and reflects applicable supervisory authority guidance. They should keep the description distinct from the necessity/proportionality and risk-mitigation components, and verify current requirements against the official text and relevant regulator resources.
Engineers and Product Teams
Because the description maps how personal data is collected, used, stored, shared and deleted, engineers and product owners are often the source of the technical detail it depends on. Their accurate input on data flows, sources and third-party sharing is essential to producing a description that reflects the system as actually built.
Privacy Lawyers and Advisers
Legal advisers assessing DPIA adequacy or advising on high-risk processing use the systematic description to test whether the assessment has a sound factual foundation. They should be alert to gaps, to the boundary between the description and other DPIA elements, and to the fact that expected content beyond the statutory minimum can vary with regulator guidance and member state practice.

Inside Systematic Description of Processing

Nature of the processing
A narrative account of what the processing involves, typically covering how personal data is collected, used, stored, and otherwise handled. This forms the descriptive foundation of the exercise and is generally the first element expected in a systematic description under Article 35 of the GDPR.
Scope of the processing
An articulation of the boundaries of the processing, including the categories and volume of personal data, the number of data subjects affected, the geographical reach, and the duration or retention period. The scope helps frame the extent of potential impact and is subject to assessment against the specific operation.
Context of the processing
The broader circumstances surrounding the processing, such as the relationship with data subjects, their reasonable expectations, the nature of the controller-data subject relationship, and any relevant technological or societal factors. Context can influence risk and is generally weighed alongside nature and scope.
Purposes of the processing
A clear statement of why the processing is carried out, including any legitimate interest pursued by the controller where relevant. Purposes should be specified and, in most cases, connect to the applicable legal basis under Article 6 (and an additional condition under Article 9 where special category data is involved).
Data flows and lifecycle
A description of how personal data moves through the operation, from collection to erasure, often supported by data flow mapping. This typically identifies sources, recipients, and any transfers, though the applicable transfer mechanisms and safeguards should be assessed separately and verified against current rules.
Assets, systems, and parties involved
Identification of the systems, applications, and infrastructure processing the data, along with the roles of parties involved (for example controller, processor, or joint controllers). Distinguishing these roles precisely is important because it affects allocation of obligations.

Common questions

Answers to the questions practitioners most commonly ask about Systematic Description of Processing.

Is the systematic description of processing the same thing as the whole Data Protection Impact Assessment?
No. The systematic description is one component within a DPIA under Article 35, not the assessment in its entirety. Article 35(7) typically frames the DPIA as including at least a systematic description of the envisaged processing operations and purposes, an assessment of necessity and proportionality, an assessment of the risks to the rights and freedoms of data subjects, and the measures envisaged to address those risks. The systematic description generally provides the factual foundation on which the later analytical steps build, but it does not by itself satisfy the DPIA obligation. You should verify the specific requirements against the current official text of Article 35.
Does producing a systematic description mean the processing is documented in the same way as the record of processing activities under Article 30?
Not necessarily. These are distinct instruments serving different purposes and they should not be conflated. The record of processing activities under Article 30 is a standing inventory maintained by a controller or processor, while the systematic description sits within a DPIA and is typically more detailed and specific to the particular high-risk processing being assessed. Information from an Article 30 record may inform or feed into the systematic description, but the two obligations arise under different articles and have different content expectations. Confirm the precise content of each against the current Regulation text.
What level of detail should a systematic description generally include?
In most cases a systematic description aims to capture the nature, scope, context, and purposes of the processing in enough detail that a reader can understand what data flows occur and why. Practitioners typically document elements such as the categories of personal data and data subjects involved, the purposes and, where relevant, the legal basis relied on, the data flows and processing operations, recipients or categories of recipients, any transfers, retention periods, and the assets or systems used. The appropriate depth is context and risk dependent, and you should tailor it to the specific processing rather than applying a fixed template.
Who should be involved in preparing the systematic description?
Preparation is generally a collaborative exercise. The controller holds responsibility for the DPIA, but input is typically drawn from those who understand the processing in practice, such as business or product owners, engineering or IT teams who understand the data flows and systems, and where designated, the data protection officer, whose advice should be sought. Depending on the arrangement, processors may need to assist. Roles should be allocated according to who holds the relevant knowledge, and the involvement of specific functions can vary by organisation.
How should the systematic description be kept up to date over the life of the processing?
A systematic description generally reflects the processing as envisaged at a point in time, so it can become inaccurate as systems, data flows, purposes, or recipients change. It is common practice to treat it as a living part of the DPIA and to review it when there is a material change to the processing, and to re-examine the assessment where the risk profile may have shifted. The appropriate review cadence is context dependent, and you should align it with your broader DPIA and change-management processes rather than assuming a single fixed interval.
How does the systematic description relate to the later risk assessment steps in the DPIA?
The systematic description typically functions as the factual basis for the subsequent analytical steps, namely the assessment of necessity and proportionality and the assessment of risks to the rights and freedoms of data subjects. Because those later steps generally depend on an accurate understanding of what the processing involves, gaps or inaccuracies in the description can undermine the reliability of the risk analysis that follows. Practitioners often ensure the description is complete before, or iteratively alongside, the risk assessment, though the precise sequencing can vary in practice.

Common misconceptions

The systematic description is the whole Data Protection Impact Assessment.
The systematic description is generally understood as one component of a DPIA under Article 35, not the entire assessment. A DPIA typically also includes an assessment of necessity and proportionality, an evaluation of risks to data subjects, and the measures envisaged to address those risks. The description sets the factual basis on which those later steps depend.
A systematic description only needs to list data categories.
Listing data categories is only part of the scope element. A systematic description is generally expected to also address the nature, context, and purposes of the processing, along with data flows and the parties involved, so that the operation can be properly understood and assessed.
Describing the processing automatically demonstrates lawfulness.
Producing a systematic description does not by itself establish that processing is lawful or compliant. Compliance is context and risk dependent; the description supports subsequent analysis, including identifying the correct legal basis and assessing necessity, proportionality, and risk. It is a starting point rather than a conclusion.

Best practices

Document the nature, scope, context, and purposes of the processing as distinct elements so that no dimension of the operation is overlooked when the description feeds into later DPIA steps.
Use data flow mapping to trace personal data across its lifecycle, from collection through to erasure, and record sources, recipients, and any onward disclosures.
Clearly identify the roles of each party involved, distinguishing controller, processor, and joint controller relationships, since this affects how obligations are allocated.
Record the intended legal basis under Article 6 for each purpose, and flag where special category data is involved so that an additional Article 9 condition is considered.
Keep the description current by reviewing and updating it when the processing, systems, data flows, or purposes change materially.
Treat the systematic description as the factual foundation for the necessity, proportionality, and risk assessment stages, and cross-reference it against the current official GDPR text and applicable regulator guidance.