TEMPLATE FOR DATA PROTECTION IMPACT ASSESSMENT REPORT (DPIA) FOR PUBLIC SECTOR
This template is aimed at helping data controllers to comply with the provisions of the General Data Protection Regulation when it is necessary to carry out an Impact Assessment for Data Protection, within the framework of personal data risk management.
The report must be prepared by data controller bearing in mind that this is a working tool for people with different profiles, including people who are not used to data protection terminology, or, on the other hand, who do not master technical aspects of the processing. Therefore, the report must be adapted according to the audience to which it is addressed, so that there may be different versions of the report depending on the different profiles of the recipients. Then, the language used, must be clear and explanatory, without losing the precision of the analysis carried out.
The language used when the report is intended for managers who, based on it, must approve, and apply the DPIA and, consequently, make decisions related to the processing of personal data described in the DPIA will be of special relevance.
This model contains the minimum chapters and sections that must appear in the documentation of a DPIA. Depending on its complexity, the DPIA documentation may be contained in a single text or in several.
The DPIA is a process within the framework of risk management for the rights and freedoms of citizens. 
On this basis, and within the framework of risk management, the controller should proceed in accordance with the recommendations set out in the Practical Guide for Risk Management and Impact Assessment in the Processing of Personal Data Subject to the GDPR (hereinafter the GUIDE).
In this way, the DPIA must necessarily go far beyond the mere completion of this report.
In no case should the objectives of a DPIA be understood exclusively in terms of compliance but in terms of risk management for the protection of the rights and freedoms of natural persons.
On the other hand, in the event that it is necessary to consult the AEPD in relation to the DPIA (GDPR Art. 36.1 and Recital 94), the data controller must bear in mind the checklist (hereinafter "the List") published by the supervisory authority.
NOTE: These tables are intended to provide a description of each section of the document. They do not replace the above-mentioned Guides and should be removed from the final report.
April 2022 release

I.	EXECUTIVE SUMMARY
This section should indicate the objectives pursued with the DPIA reflecting, in a condensed way, the most significant aspects of the chapters that are developed throughout the document. 
This summary will contain the name of the processing activity, the version of the document, the identification of the controller, the accountable unit for the organization, data management units involved in any of the processing phases, processors and sub-processors and planned data transfers.
In turn, it will include a brief description of the processing, its purpose, the main categories of data, significant processing operations and its planned implementation, as well as the conclusions of the analysis of necessity, suitability, and proportionality of the processing and of the legal bases that legitimize the processing of personal data.
Finally, it will include a brief description of the context of the DPIA and the formal risk management process, including a brief reference to the methodology used, the extent and limits of the DPIA, the most significant identified privacy risks, the management solutions and techniques planned, a synthesis of the cost-in-privacy analysis in relation to the benefit to data subjects and the conclusions derived from it. of the residual risk and the need to carry out or not to carry out a prior consultation with the AEPD.

II.	INDICE

I.	EXECUTIVE SUMMARY
II.	INDICE
III.	BASIC DATA
A.	GDPR controller identification
B.	Name and description of the processing
C.	Expected starting date of the processing
D.	Date of the end of the processing and expiration conditions
IV.	DPIA METHODOLOGY
A.	Persons involved in the implementation of the DPIA
B.	Guides, tools, methodologies, and standards used in the evaluation
C.	Extension and limits of the DPIA: Identify what has been left out of the evaluation
D.	Approval of the process of the DPIA report
V.	ANALYSIS ON THE LAWFULNESS OF THE PROCESSING
VI.	DEDESCRIPTION OF THE PROCESSING
A.	High level analysis of the processing
B.	Structured analysis of the processing
C.	Data lifecycle description
D.	Inventory of assets
E.	Cases of use
VII.	IDENTIFICATION AND ANALYSIS OF RISK FACTORS
A.	Identification of risk factors
B.	Analysis of risk factors
C.	Analysis of personal data breach scenarios
D.	Intrinsic risk assessment
VIII.	ANALYSIS OF DPIA OBLIGATION AND DPIA NEED
A.	Inclusion of the processing in the list of the types of data processing that do not require DPIA
B.	Applicability of the exception provided in Article 35.10 of GDPR
C.	Analysis of the inclusion of the processing in cases of mandatory DPIA processing
IX.	CONTROLES PARA LA REDUCCIÓN DEL RIESGO
A.	Measures on the concept and design of the processing
B.	Governance measures and data protection policies
C.	Data protection measures by design
D.	Security measures and management of personal data breaches
E.	Risk reassessment
F.	Risk management action plan
X.	ANALYSIS OF THE NECESSITY AND PROPORTIONALITY OF THE PROCESSING
A.	Suitability judgement
B.	Judgment of necessity
C.	Proportionality judgment in the strict sense
XI.	NEED FOR PRIOR CONSULTATION
XII.	CONCLUSIONS AND RECOMMENDATIONS
XIII.	MEMORANDUM OF THE DATA PROTECCION OFFICER
A.	DPO point of view
B.	Conclusions and recommendations of the DPO to the controller
XIV.	REFERENCIAS
XV.	ANEXOS

III.	BASIC DATA
A.	GDPR controller identification 
Identification of GDPR controller entity, and identification of joint controllers, as well as the rest of the actors and involved in the processing with the unequivocal definition of their obligations and tasks.
Brief description of the structure of the organization, functions, and competencies. policies, rules, and standards adopted, maturity objectives of the organization and in general the culture of the organization.
Point out some of the characteristics of the organization, such as, for example, the number of people involved in the processing, their profiles, roles, and the possible segregation of functions throughout the entire life cycle of the processing. Identification of all the processes of the organization that may be related or affected by the processing in relation to the map of processes of the organization.
Identification of a contact point (POC) in the controller entity (if possible DPD) as well as each of the managers or POC of each of the management units or functional units involved in the processing, with express indication of the identity and date of notification of the DPO to the control authority in compliance with the obligations established in Chapter III of the LOPDGDD.
Details of the DPO's involvement in the DPIA in terms of advice, supervision, and enforcement.
Identification of the management unit or units in charge of the management of the processing within the controller organization.
B.	Name and description of the processing
Internal name given to the processing, name should be the same than the one intended to be included in the Register of Processing Activities, in the inventory of processing activities (LOPDGDD Art. 31.2), and an internal identification of the version of the processing with indication of the history of changes and modifications made to the processing, if any, for each of its stages.
Brief description of the processing, including the information set out in article 31 of the LOPDGDD (GDPR Art. 30) in relation to the record of processing activities and the inventory of the processing activity.
Do not misunderstand a processing with a file or one of the operations or techniques used in the whole processing. The processing is defined by its ultimate purpose (see Section III.A of the GUIDE)
C.	Expected starting date of the processing
Where the processing has been initiated prior to the DPIA and/or prior consultation and prior consultation is considered necessary, an objectively reasoned justification shall be included as to the reasons why the DPIA or prior consultation was not initially necessary and the reasons why they were subsequently deemed necessary, in accordance with section X.C of the GUIDE. If the origin of the obligation to carry out a DPIA is a regulatory change, the rule that motivates it must be indicated.
D.	Date of the end of the processing and expiration conditions
The date on which the processing is expected to end and/or the conditions of expiration of the processing will be included.
IV.	DPIA METHODOLOGY
A.	Persons involved in the implementation of the DPIA
In a brief way, description of the working group that has made this report and is involved in the management of risks for the rights and freedoms, details of their roles, tasks, responsibilities, etc. In this section, a RACI matrix may be used.
If the views of data subjects or their representatives have been sought in the process of identifying and assessing the risks to the rights and freedoms, it should be included to describe their involvement in the DPIA process in line with Chapter XV of the GUIDE. 
B.	Guides, tools, methodologies, and standards used in the evaluation
Guidelines, standards, and other reference materials used in the implementation of the DPIA shall be detailed. In particular, it will be detailed its adequacy to the provisions of Instruction 1/2021 in relation to Prior Consultations (hereinafter the Instruction).
C.	Extension and limits of the DPIA: Identify what has been left out of the evaluation 
If the DPIA extension was limited, the reasons for such limitation must be specified in relation to the purposes and scope of the processing, including those aspects that would be outside its analysis and the possible associated risks for the rights and freedoms of individuals, including the way in which they could be addressed and the identification of those responsible for such risks.
D.	Approval of the process of the DPIA report 
Identification of the person who coordinates the team willing to carry out the DPIA.
Internal approval process.
Date, time of adoption of the report.
Version or revision of the realization of the DPIA report.
History of changes and modifications, in general, any element that can demonstrate the follow-up carried out by the person in charge of the DPIA. 

V.	ANALYSIS ON THE LAWFULNESS OF THE PROCESSING
This chapter is dedicated to the identification and legal basis for the processing of data, based on the provisions of article 6 of the GDPR and articles 6 to 8 of the LOPDGDD.
The analysis of the legal bases will be carried out in relation for each of the purposes of the processing, including secondary or subsequent purposes. 
If special categories of data are processed (Article 9 GDPR and Article 9 LOPDGDD) the reasons that led to the lifting of the prohibition on processing special categories of data must be properly justified. If the lifting of the prohibition is carried out by consent, the conditions of that consent will have been analyzed.
In any case, it should be borne in mind that the absence of a legal basis legitimizing the processing or the existence of doubts about such legal basis cannot be replaced by the adoption of guarantees derived from risk management for the rights and freedoms of citizens since the fulfillment of duties and principles, including that of "legality, loyalty and transparency" (GDPR Art. 5.1.a) are mandatory obligations.
To complete this section, it is recommended to consult the Regulatory Compliance List published by the AEPD on its website.
VI.	DEDESCRIPTION OF THE PROCESSING  
A correct management of the risk for rights and freedoms requires knowing the details of the processing, which implies the necessary systematic description of it.
The granularity that must be achieved in the description of the processing must be enough to make it possible to carry out such management. In this regard, the following levels of detail are recommended:
• High-level study of processing.
• Structured analysis of the processing, or decomposition of the processing into phases to carry out the individual study of them.
• Data lifecycle analysis.
Finally, from the structured analysis of the processing it will be possible to obtain the Inventory of assets associated with a processing according to different use cases to which the design of the same must respond. 
In any case, the description of the processing must include:
• The type of agreement, provision or legal act between joint controllers involved or third parties (GDPR Art.4.10) involved in the processing, as well as the legal act that links them with the processing and that legitimizes their participation in it and if such link specifies and defines accountability measures and guarantees that must be implemented by processors and sub-processors.
• The existence of legal guarantees to ensure consultation of the person in charge by managers before addressing the hiring of sub-processors.
• The measures foreseen to guarantee and demonstrate the fulfillment of the duty of information to data subjects.
• The procedures put in place to guarantee the rights of data subjects.
• Planned data transfers.
• Planned international data transfers, including the identification of that third country or international organization and, where appropriate, the necessary guarantees provided.
• The codes of conduct, seals, trademarks, and certifications applicable in each case.
• Any other information that is relevant. 
A.	High level analysis of the processing
If the description of the processing is made through a high-level study of it, this section should include all relevant aspects of the processing analysis in a joint manner. 
At least, the high-level study of the processing must include the information indicated in section V.A of the GUIDE in relation to the nature, purposes, scope, and context of the processing.
In particular, and not only, possible relationships with other data processing of the organization and elements that could be shared, for example, phases of other data processing that are common to the processing under analysis, as well as the context of the proposed system/s for the implementation of the processing and details of the technologies used. 
B.	Structured analysis of the processing
If the description of the processing requires a greater degree of detail, it may be done by means of a structured analysis of the processing. This section will include the information of the study at a high level of the processing and will identify the different processing operations that are carried out in addition to the detail of the relationship between them considering the nature, purposes, scope and context of the processing. The degree of description of each operation will agree with the level of impact of the risk that each phase might have.
More detail on how to approach structured analysis can be found in section V.B of the GUIDE.
C.	Data lifecycle description
Finally, if a higher level of detail is required to carry out the systematic description of the processing, it is advisable to carry out a global analysis of the life cycle of the data which will be based on the high-level analysis and the structured analysis of it. 
Life cycle analysis involves studying, for a set or category of data, the different stages of its life, from its collection or generation to its destruction. The data lifecycle description is a complementary analysis to the high-level analysis and structured analysis of the processing.
In section V.C of the GUIDE you can find more detailed information about it.
Likewise, a description of data transfers and its recipients will be provided, in relation to the purposes, the life cycle of the processing, the life cycle of the data and the processing operations in addition to the functional description in which said assignments are carried out for each of the recipients. The transfers of data will be linked to the legal bases that legitimize them.
D.	Inventory of assets
Based on the result of the structured analysis or the description of the life cycle of the data in the processing, it will be possible to obtain the list of all the assets necessary to address the initiation of the processing and an adequate management of the risks to the rights and freedoms of natural persons.
Assets shall be included, organized, and kept up to date, in what is called the processing asset inventory.  Assets are defined as any good or resource that may be necessary to implement and maintain a processing operation at any stage of its life cycle, from its conception and design to the withdrawal of the processing.
The level of detail to be included in the asset inventory should be necessary to identify and manage risks efficiently and, at the same time, to be able to demonstrate such management.
The inventory of assets must be determined from the structured analysis of the processing, or through any other procedure determined by the entity, of equal or greater effectiveness.
Failure to have an adequate inventory of assets updated may involve inappropriate decision-making regarding the processing and, in the case of carrying out a prior consultation, the Supervisory Authority may conclude that the information provided is incomplete, incorrect and, therefore, inaccurate, without prejudice of other principles such as transparency.
Section V.D of the GUIDE describes the information needed to document the assets of the processing.
E.	Cases of use
Considering the complexity of the processing, there may be different cases of use in order to respond to different processes of an organization.
In the description of the processing, in its different levels of detail, it must be identified to which use case it refers and mark its differences. It is possible that the cases of use are motivated based on rules or laws in which the controller acts within the scope of its competences, in this case it must be indicated for each case of use, the law or norm to which said case responds.
In addition, the default privacy measures and their implementation for each use case should be identified and documented.
The identification cases of use, with examples, has been dealt with in the Default Data Protection Guide. And the List of Default Data Protection Measures is also available online. 

VII.	IDENTIFICATION AND ANALYSIS OF RISK FACTORS 
The identification and analysis of risk factors for the rights and freedoms of natural persons is the prior step to the assessment of the level of risk inherent in the processing.
In the context of accountability, the identification and analysis of risk factors shall always be documented and justified so that the controller can demonstrate that the decisions taken at any given time in relation to risk management have been the most appropriate measures based on the information available.
In order to support the performance of this task, the AEPD makes available to controllers and processors of the processing the GDPR Risk Assessment tool that aims to help managers and processors to identify the risk factors for the rights and freedoms of data subjects in their personal data processing,  making a first assessment of the intrinsic risk, helping to determine if there is an obligation to carry out a DPIA, while it can also serve in the process of managing the residual risk of the processing.
In no case GDPR Risk Assessment represents all the risk factors of the entire possible set of processing but a basis and methodology for the identification of the possible inherent risk factors of the processing. In short, it is not a closed list of risk factors. It is therefore up to the controller to identify all the possible risk factors that could affect the processing of personal data that is intended to be carried out in each case.
In general, it should be borne in mind that a processing carried out by an Administration will be, due to its context and nature, a large-scale processing in terms indicated in document WP243 of the EDPB. That is, it will be understood that most of Public Administration processing, involve, from the outset, an inherent risk factor besides other risk factors that the controller must identify.  
A.	Identification of risk factors
During risk management and analysis phases, in addition to risks included in GDPR, the LOPDGDD, sectorial regulations, lists, guides and guidelines approved by the data protection authorities, where a set of risk factors are identified; specific risk factors that derive from the intended processing of personal data must also be identified and evaluated according to their nature,  scope or the purposes pursued, without forgetting, either, those others that derive from the present context (internal and external to the organization) and future of the processing.
Sections VI.C and VI.E of the GUIDE, provide lists of risk factors identified in the regulations are developed in more detail.
B.	Analysis of risk factors
For each identified risk factor, the controller must determine its inherent impact, that is, the potential results from not considering the measures and guarantees for rights and freedoms. The impact will depend on the damage that may be caused to the data subjects in particular and to society as a whole, within the scope of their rights and freedoms, in the short, medium and long term. 
In turn, it will also be necessary to determine the probability that the identified risk will materialize.
Although the analysis can be done according to any recognized methodology, section VI.B of the GUIDE gives a series of indications of how this analysis of the risk factors can be carried out to comply with the requirements of the Instruction.
C.	Analysis of personal data breach scenarios
In practice, risk level assessment process cannot be carried out without taking into account the possible consequences of personal data breaches on data subjects in order to establish criteria for consistency in the risk assessment, preventing the initial risk assessment from differing in relation to the consequences on data subjects resulting from the loss of confidentiality, integrity, availability of data, reversal of anonymization/pseudonymization, use of data for non-compatible purposes, breach of warranties, etc.
Therefore, in the identification and analysis of risk factors is necessary to determine the damages that may arise from the materialization of personal data breaches in their different dimensions.
Detailed guidance for the analysis of these damages in the event of personal data breaches is included in section VI.D of the GUIDE.
D.	Intrinsic risk assessment
It is necessary to carry out an analysis of the total intrinsic risk of the processing, in accordance with Article 35.7.c of the GDPR, taking into account the elements identified from the result of the assessment of the level of risk for each of the risk factors identified in the processing.
The interdependence of different risk factors could increase the risk level of processing above the worst case of each risk factor taken individually.  When there are different risk factors, it is necessary to interpret how these factors, considered independently, could interact with each other to increase the level of risk of the processing (cumulative risk factor), by analyzing their combined dependencies and effects or the mutual interactions that exist between them.
Chapter VII of the GUIDE provides more detailed guidance for this assessment.

VIII.	ANALYSIS OF DPIA OBLIGATION AND DPIA NEED
A.	Inclusion of the processing in the list of the types of data processing that do not require DPIA
If the processing is on the list of exempt processing established within the framework of Article 35.5 of the GDPR, it is not mandatory to carry out the DPIA, and the report would end here, unless the controller has taken the decision to carry out the impact assessment, then the reasons should be motivated below (see sections XI and XII of the GUIDE).
This list, approved by the European Data Protection Board, can be consulted here and its nature is merely indicative.
B.	Applicability of the exception provided in Article 35.10 of GDPR
If the processing has its legal basis under Union law or under law of a Member State that applies to the controller (GDPR Art. 6.1.c and 6.1.e) and such law regulates the specific processing operation or set of processing operations and a data protection impact assessment has already been carried out as part of a general impact assessment in the context of the adoption of such a legal basis, the obligation to carry out the DPIA shall not apply. This derogation shall not apply if a rule provides that it is necessary to carry out the DPIA, in any event.
This report, in addition to the possible conclusions that would have been reached during the implementation of the DPIA in the context of the adoption of a certain legal basis, shall demonstrate that the processing is duly in line with the provisions of the DPIA carried out in the development of the applicable legal basis and, in the same way, this report will be completed with the conclusions that had previously been obtained.
C.	Analysis of the inclusion of the processing in cases of mandatory DPIA processing
This section will determine if there is an obligation to carry out the DPIA. This shall consider, in particular, whether the processing:
1.	Is included in the list of cases listed in Article 35.3 of the GDPR.
2.	Is under the conditions detailed in the list, approved by the European Data Protection Board, of mandatory processing (article 35.4 of the GDPR) that can be consulted here taking into account that it is an indicative list of mandatory DPIA processing.
3.	There are the assumptions of greater risk of the cases listed in article 28.2 of the LOPDGDD.
It is recommended to make use of the GDPR Risk Assessment tool  for the analysis of the risk factors inherent in the processing that arises in the DPIA.
Regardless of all, data controller could assume the need to carry out the DPIA, in which case, the possible reasons that in the opinion of the controller would make the DPIA necessary must be indicated (data protection policies, quality requirements, etc.). 
IX.	RISK REDUCTION CONTROLS
The purpose of this section is to establish management measures, organizational measures, definition of processing, procedures and technical measures that allow managing each of the risk elements identified in section VII "Analysis of the obligation to carry out a DPIA: risk assessment"
More detailed information is available in Chapter VIII of the GUIDE.
A.	Measures on the concept and design of the processing
These measures will act in the very same definition of the nature, scope, context, or purposes of the processing, that is, the essence of the processing as it is conceived and designed. 
On the original description of the processing, the decomposition of it into phases or sub-processes must be optimized, to be able to apply risk reduction measures with greater granularity.
In this way, it is also convenient to identify possible unnecessary phases, isolate those with the highest level of risk from the rest of the phases, determine specific measures to manage the phases of greatest risk and determine those that do not require access to personal data.
Among the possible measures or guarantees that could be adopted would be those included in section VIII.A of the GUIDE. Also, for further guidance on this section it is advisable to consult the Default Data Protection Guide published by AEPD.
B.	Governance measures and data protection policies
This section will indicate the governance measures and data protection policies of the entity (accountability) aimed at implementing a personal data governance system that allows demonstrating compliance with:
-Principles
-Rights
-Guarantees to manage risk.
In particular:
- Measures that allow to have control over what data is accessed, by whom, from whom, when, with what legitimacy and purpose, the processing that have been carried out on them, etc.
- Measures to ensure that rights management systems are properly implemented.
- Measures to preserve the traceability of the data communicated to third parties.
- Appointment of DPD.
- Measures to notify data subjects of security incidents that affect their rights and freedoms.
- Human intervention by the controller in the processing that involve automated individual decisions.
- etc.
In section VIII.B of the GUIDE you can consult a much more exhaustive list of examples of possible governance measures and data protection policies.
C.	Data protection measures by design
The applicable Privacy by Design and Default measures will depend on the type of processing. In addition, specific measures will be applied in the different phases of the processing, therefore, the application of these measures is related to the previous section of Optimization of the processing.
To resolve this section, it is advisable to consult, in particular,  the Privacy from Design Guide published by the AEPD, and in general, the guides and notes published on the AEPD website in the Innovation and Technology section.
A list, for generic and non-exhaustive processing, is derived from the provisions of article 25 of the GDPR, and are measures that include minimization, concealment, separation, abstraction, information, control, compliance, and demonstration, which can be found summarized in section VIII.C of the GUIDE.
D.	Security measures and management of personal data breaches 
This section details the analysis of the requirements necessary to minimize risks to the rights and freedoms over security domains: confidentiality, availability, integrity, authenticity and traceability and how the integration of these requirements is carried out with the rest of the security requirements (for business continuity, fraud control, etc.) of the organization. 
In addition, the management of the entity will be specifically included in the event of personal data breaches.
It may be appropriate to attach to this report the declaration of applicability of the ENS signed by the security officer and the controller which will reflect the mandatory advice of the DPO in terms of risks to the rights and freedoms of the data subjects.
Detailed guidance on the applicable security measures for the protection of rights and freedoms can be found in section VIII.D of the GUIDE.
E.	Risk reassessment
Risk management is an ongoing process. In this sense, the application of a measure to avoid or mitigate a risk may, in turn, cause the appearance of new risks or unintended consequences for data subjects. In this way, a re-identification and risk assessment should be carried out after the implementation of the measures.
Residual risk shall be quantified in accordance with the organization’s risk management policy.
Chapter IX of the GUIDE contains guidance on this necessary re-evaluation in the impact assessment.

F.	Risk management action plan
This section will detail the necessary actions to carry out the adequate risk management for the rights and freedoms of individuals, reflecting the set of actions necessary for the review and updating of the measures that would have been identified in the DPIA.
The action plan can be defined by the data protection policies (GDPR Art. 24) that the controller deems necessary, including in them, the clauses of expiration of the processing. 
It must detail the objectives, tasks, calendar, the necessary resources, those responsible, as well as the interaction with other processing of the organization.
In particular, the privacy measures by design and by default that would have been defined in the DPIA must be reflected so that data protection is integral to the product/service, not an added layer.

X.	ANALYSIS OF THE NECESSITY AND PROPORTIONALITY OF THE PROCESSING
One of the requirements of article 35 of the GDPR in relation to the DPIA is the one that appears in section 35.7.b of the GDPR, the obligation to carry out "an evaluation of the necessity and proportionality of the processing operations in terms of their purpose". The analysis of necessity and proportionality of the processing should not be confused with the analysis of the obligation or the need to carry out the DPIA.
The word "evaluate" implies the performance of an objective analysis that supports a conclusion, so it is not reduced to a simple statement.
This principle of proportionality, taken to the evaluation of the necessity and proportionality of the processing, translates into a weighting according to three criteria:
-	Suitability judgment: It is necessary to determine if the processing is suitable for the purpose it pursues. The processing responds to certain shortcomings, demands, obligations or objective opportunities and can achieve the proposed objectives with sufficient efficiency.
-	Judgment of necessity: It is necessary to determine whether the purpose pursued cannot be achieved in another less harmful or invasive way, that is, there is no alternative processing that is equally effective for the achievement of the purpose pursued.
-	Proportionality judgment in the strict sense: The seriousness of the risk for the rights and freedoms of the processing and its interference in privacy must be appropriate to the objective pursued and proportionate to the urgency and gravity of it. It is necessary to weigh the benefit that the processing, from the point of view of data protection, provides to the Company while maintaining a balance with the impact it represents on other fundamental rights. However, even if it may partially assign, in no case, the absolute denial of the right to data protection can be assumed and emptied of its essential content.
This evaluation must end with a decision whether to carry out the processing or, where appropriate, modify it so that it complies with the three required judgments. In no case is it recommended to continue with the DPIA when the processing does not reach the assessment of necessity and / or proportionality.
Non-compliance with these requirements cannot be addressed or justified by alternative forms of compliance, such as legal bases or technical and organizational measures.
Chapter XIII of the GUIDE contains detailed information on how to conduct these assessments.
For the implementation of the DPIA in the context of a regulatory development that could provide a legal basis in the context of Union law or in the law of a Member State that could be applicable to a particular controller on the basis of Articles 6.1.c and 6.1.e, in relation to the analysis of the necessity and proportionality of such regulatory development,  the Guides of the European Data Protection Supervisor for the assessment of necessity and proportionality can be consulted.
A.	Suitability judgement
The threshold of effectiveness of the processing shall be defined. It will be established objectively or qualitatively and based on evidence, determining what is the threshold of effectiveness that should be reached to meet the purposes of the processing.
The effectiveness of the processing proposal will be evaluated. The effectiveness of the processing, as it has been proposed, will be assessed in an objective, qualitative and evidence-based way, verifying if it responds to the needs raised and extent.
B.	Judgment of necessity
The relevance of the purposes of the processing will be determined. It will be assessed that the purposes of the processing are of sufficient importance to be addressed with a high-risk processing.
The adequacy of the processing operations will be verified, that is, that each of them is aimed at fulfilling the purposes of the processing in an objectively and demonstrable way.
The current configuration of the processing will be justified. It will be evaluated that there is no other processing, already in progress or that could be raised, that might resolve the declared purposes without involving a high risk, even if it is necessary to introduce some modification to fulfill the purposes pursued.
The limitation clauses provided for the processing will be indicated both by their nature, as well as by their scope, their context, and their purposes.
C.	Proportionality judgment in the strict sense
It must be identified the degree of impact of the processing on the rights and freedoms. It is required to express, in detail, the limitations or intrusions to the rights and freedoms that the processing may entail for data subjects. This evaluation is a previous task that has already had to be carried out in the determination of the factors and levels of risk previously analyzed, exposing at this point of the evaluation its conclusions.
Compensatory measures shall be identified and described. Details of the controls established in the processing design are required to reduce this impact.
The benefits of the processing will also be identified. The advantages and benefits that the processing, objectively and with evidence, has for data subjects, considered individually and collectively, must be determined. In other words, social benefit must also be considered.
The existence of identity in the quality of the information will be confirmed. It must be evaluated whether there is symmetry in the information analyzed for the weighting judgment, that is, if the level of analysis in relation to the impact is equal to the level reached based on the information provided regarding the advantages. 
A HBB (Harm-Benefit Balance) analysis will be performed. An assessment is required on whether the benefits to data subjects and society, previously determined, outweigh, and justify the impact on the rights and freedoms identified in the first point of this proportionality judgment in the strict sense.
XI.	NEED FOR PRIOR CONSULTATION
Based on the results obtained, it will be described whether it is necessary to carry out prior consultation with AEPD.
If the residual risk is low, the possible prior consultation referred to in article 36 will not take place, if there are risks for which the controller could not have taken measures, then due request for prior consultation referred to in article 36 of the GDPR must be made in accordance with the requirements indicated in the Instruction. This section will detail the risks for which controller has not been able to adopt measures and which justify the need to carry out the request for prior consultation.
If a prior consultation on the same processing has been submitted in advance, it is necessary to details of all the modifications introduced in the nature, context, scope, purposes, risks and guarantees in the processing that could make the DPIA and prior consultation necessary. 
If there are prior consultations made to a Supervisory Authority in advance, an express reference to the response or responses of the Supervisory Authority or Authorities shall be included. 
The documentation included in prior consultation must guarantee that the information provided is complete and accurate (Art. 36.3 GDPR), the prior consultation will be signed by the controller of the processing and sent by the consultation channel of the AEPD as required by the Instruction. 
Further guidance can be found in Chapter XVI of the GUIDE.

XII.	CONCLUSIONS AND RECOMMENDATIONS
The working team carrying out the DPIA will reflect, in a condensed form, the result of the risk management for rights and freedoms, the general guidelines for the implementation of the processing, it will also be determined that the risk is low enough and the following actions, in particular if the Prior Consultation to the AEPD is appropriate in accordance with Article 36 of the GDPR.
In short, the decision of the team that has made the DPIA must be indicated to the controller, including the points of view of its members.
XIII.	MEMORANDUM OF THE DATA PROTECCION OFFICER
A.	DPO point of view
This section will include, in a condensed form, the point of view of the DPO in relation to the processing that is intended to be carried out, demonstrating its adequate participation in the DPIA process and the supervision of its application (GDPR Art.39.1.e). 
In general, the DPO must pronounce himself in relation to the possible risks to the rights and freedoms of natural persons, that is, with respect to the potential negative consequences that the processing could entail for data subjects (GDPR Art.39.2).
B.	Conclusions and recommendations of the DPO to the controller
In an equally condensed or summarized manner, this section must include the conclusions and recommendations that, in his advisory work, the DPO makes to the controller or the processor of the personal data processing.
XIV.	REFERENCIAS
All documents that have been used by the working group in the implementation of the DPIA shall be detailed. 
It is not a question of supplementing this section with a list of documents that could have been used, but of reflecting, throughout the DPIA, reference documents (opinions, judgments, legal reports, guides, normative references, etc.) on which the DPIA bases its conclusions, compiling in this section an exhaustive list of the documents mentioned throughout the report. 

XV.	ANEXOS
Any reference to working documents that have been included in the DPIA that justify the decisions of the controller in relation to the processing and that, in addition, are part of the documents with which the controller can demonstrate compliance (assessment of the residual risk to rights and freedoms, contractual clauses, declarations, descriptions, reports, standards, guides or documents in general, inventory of assets, applicable security measures, etc.).

In................ on ...... of................ 202x

	
Signature on behalf of the controller: 
Mr./Mrs.:
Charge:
Email: 
Telephone:

Signature of the Data Protection Officer (if applicable):
Mr./Mrs.:
Email: 
Telephone: