Design Requirements, Processes, & Tools
As presented in the GDPR (General Data Protection Regulation): The Role of Data Management, the DCAM™ Framework provides the Data Management foundation to support compliance with the GDPR. However, the Work Group identified a set of additional focus areas where ongoing collaboration and knowledge share could produce further valuable best practice standards. This post presents a collection of prioritized proposed opportunities for best practice.
In the absence of these best-practice standards, EDM Council recommends that organizations should independently define their approach to each of these focus areas. The list of Best Practice Opportunities is a guide for an organization to ensure its Data Management processes and tools consider an approach to these focus areas.
The EDM Council maintains an ongoing effort to collect best practice executions from member organizations. Members should share their proposed best practice or raise other issues in the comments section at the end of this post.
The table below identifies the Focus Areas, provides a Description of the issue, and lists the GDPR Components to which the issue is aligned. The listing is in ranked order (High, Medium, and Low) per the collective opinion of the Work Group membership.
Focus Areas for Best Practice
| # | Focus Area | Description GDPR Component Alignment |
| High Priority | ||
| 1 | Business Logic | The objective is to define proposed standard business rules or logic that are required to define the scope and parameters of the following components to be considered by an organization. The actual interpretation of the requirements and resulting logic may vary between organizations. ● Transparency and Information Rights ● Purpose Limitation & Data Minimization ● Data Quality and Proportionality ● Legal Basis for Processing Personal Data ● Sensitive Data (Special Categories of Data) ● Controller – Processor Relationship ● International Data Transfers (Cross Border) ● Security of Processing ● Breach Notifications to Data Subjects |
| 2 | Data Elements (DEs) in scope – Additions | The objective is to identify the proposed execution processes data sets. The processes to manage the GDPR component requirements necessitates the creation of new data elements related to the activities in the process (e.g., Data Subject Request Flag, Request Date, Request Completion, Completion Date). Actual execution and data required may vary between organizations. ● Transparency and Information Rights ● Right of Access ● Rectification, Erasure and Restriction of Processing ● Profiling & Automated Individual Decisions ● Data Portability ● Purpose Limitation & Data Minimization ● Data Quality & Proportionality ● Legal Basis for Processing Personal Data ● Sensitive Data (Special Categories of Data) ● Controller – Processor Relationship ● International Data Transfers ● Security of Processing ● Breach Notifications to Data Subjects |
| 3 | Design Guidelines: Data Flow and Lineage | The objective is to define proposed design guidelines for the appropriate rigor of Data Flow or Lineage to execute the GDPR component requirements. The premise is that Data Flow is a lighter rigor subset of the greater rigor included in Data Lineage. The proposal is to align the appropriate required rigor to the GDPR component requirements. ● Transparency and Information Rights ● Rectification, Erasure, and Restriction of Processing ● Profiling & Automated Individual Decisions ● Data Portability ● Purpose Limitation & Data minimization ● Data Quality & Proportionality ● Legal Basis for Processing Personal Data ● Sensitive Data (Special Categories of Data) ● Controller – Processor Relationship ● International Data Transfers ● Security of Processing ● Breach Notifications to Data Subjects |
| 4 | Design Guidelines: Legal Basis for Processing | The objective is to define proposed design guidelines for identifying a standard set of the legal basis for processing. The basis may vary across the range of products of an organization and specific business processes of an organization. ● Legal Basis for Processing Personal Data |
| 5 | Metadata Model Additions | The objective is to identify a proposed standard set of new metadata fields that are needed to execute the GDPR component requirements (e.g., In-Scope for X Flag, Erasure Flag, Automated Decision Flag, Special Categories of Data). ● Transparency and Information Rights ● Rectification, Erasure, and Restriction of Processing ● Profiling & Automated Individual Decisions ● Data Portability ● Purpose Limitation & Data minimization ● Data Quality & Proportionality ● Sensitive Data (Special Categories of Data) ● Controller – Processor Relationship ● International Data Transfers ● Security of Processing ● Breach Notifications to Data Subjects |
| 6 | Policy Implications: Data Retention Policy | The objective is to propose standard language required in the Enterprise Data Management Policy related to achieving the execution of the GDPR related Data Retention policies. ● Rectification, Erasure, and Restriction of Processing ● Purpose Limitation & Data minimization ● Data Quality & Proportionality |
| 7 | Policy Implications: Ecosystem | The objective is to propose standard language required in the Enterprise Data Management Policy to establish accountabilities and collaboration across the in-scope data ecosystem of the organization. ● Transparency and Information Rights ● Rectification, Erasure, and Restriction of Processing ● Profiling & Automated Individual Decisions ● Purpose Limitation & Data minimization ● Data Quality & Proportionality ● Sensitive Data (Special Categories of Data) ● Controller – Processor Relationship ● International Data Transfers ● Security of Processing ● Breach Notifications to Data Subjects |
| Medium Priority | ||
| 8 | Data Elements (DEs) in Scope – Existing | The objective is to identify the possible data set in scope as defined by the specific criteria in the GDPR component requirements. Not all identified data exist or have the same naming in every organization. ● Transparency and Information Rights ● Rectification, Erasure, and Restriction of Processing ● Data Portability |
| 9 | Design Guidelines: 3rd Party Provisioning | The objective is to define proposed design guidelines for the data management processes related to provisioning data to 3rd parties while executing the GDPR component requirements. This objective includes incorporating the actual 3rd party provisioning process into the various products and business processes of the organization. ● Data Portability |
| 10 | Design Guidelines: Data Erasure | The objective is to define proposed technical design guidelines for data erasure (incorporating the invocation of the Right to be Forgotten). Complicating the objective is the apparent tension between minimum records/data retention requirements not defined by GDPR and the Right to be Forgotten in GDPR. How can you do both? The best practice recommendation for this needs to address this tension to successfully meet the criteria. A best practice is to allow for a data subject to reinstate their relationship with an organization. ● Rectification, Erasure, and Restriction of Processing |
| 11 | Design Guidelines: Data Provisioning Format | The objective is to define proposed design guidelines for the standard format for provisioning data as defined in the GDPR component requirements. ● Right of Access ● Data Portability |
| 12 | Education Content Outline | The objective is to propose a curriculum outline for the data management related training required for GDPR compliance. Incorporating this curriculum into an overall GDPR compliance training curriculum maintained by the GDPR accountable control function of the organization. ● Training Program |
| 13 | Policy Implications: Data Management Policy | The objective is to propose standard statements required in the Enterprise Data Management Policy related to GDPR component requirements compliance. The standard statements relate to the policy published by the control function accountable for GDPR compliance. ● Transparency and Information Rights ● Controller – Processor Relationship ● International Data Transfers ● Security of Processing ● Global Requirements |
| Low Priority | ||
| 14 | Design Guidelines: Technical Access Controls | The objective is to define proposed technical design guidelines to take technical and organizational measures to secure the data. A best practice approach is for data to be encrypted, tokenized, anonymized, or pseudonymized at rest, in transit, and memory. Achieving the objective is not possible with policy alone, and it requires a technological solution to manage access to the data. The underlying process determines who is allowed to view the data and for what purposes along with the granting or blocking of data access. ● Security of Processing |
| 15 | Design Guidelines: Human Intervention | The objective is to define proposed design guidelines for the appropriate data management requirements for executing the human intervention in automated decisioning requested by the data subject as defined in the GDPR component requirements. The actual “human intervention process” would be incorporated into the various products and business processes of the organization. ● Profiling & Automated Individual Decisions |
| 16 | Design Guidelines: Master Data | The objective is to define proposed design guidelines for the appropriate data management requirements for including all in-scope data in the related Master Data domain. This objective would only pertain to those organizations that have or are developing related Master Data. ● Transparency and Information Rights |
| 17 | Design Guidelines: Pause Control and Process | The objective is to define proposed design guidelines for the appropriate data management requirements for executing the “pause control process” as defined in the GDPR component requirements. The actual “pause and control process” would be incorporated into the various products and business processes of the organization. ● Rectification, Erasure, and Restriction of Processing |
| 18 | DQ Rules Unique to GDPR | The objective is to define DQ rules that can be applied to in-scope data to measure quality or process compliance (Examples: Is there a data subject restriction applied to this data?). ● Data Quality & Proportionality |
| 19 | Purpose of Processing Standard Categories | The objective is to define a proposed standard set of categories for the Purpose of Processing. The categories may vary across the range of products and specific business processes of an organization. ● Purpose Limitation & Data minimization |
Revision History
| Date | Author | Description |
| May 2018 | Mark McQueen | Initial Publication |
| March 2020 | Mark McQueen | Knowledge Portal Release; Broken into a separate Article from the GDPR: The Role of Data Management |