Advisory Note

Maturity Level Matrix for GDPR Readiness

KuppingerCole Maturity Level Matrix for the degree of readiness for implementing EU GDPR (General Data Protection Regulation) requirements. Foundation for assessing the current status and identifying specific measures in your GDPR compliance projects and programs.

Matthias Reinwarth

mr@kuppingercole.com

1 KuppingerCole Maturity Level Matrix – How to use this document

The EU GDPR (General Data Protection Pro) has significant impact on how organizations can collect, store and process PII (Personally Identifiable Information. It applies to all organizations that do business with EU resident people, regardless of where these organizations reside and whether they have a subsidiary in the EU. That also applies to services that are free of charge, such as many search engines or social networks. Many organizations have initiated and implemented programs to work towards compliant systems and processes during the past few years.

1.1 Why GDPR readiness and compliance programs need regular reviews

IT systems and business processes evolve to support new use cases, business requirements, and deployment models. During these change processes it is important that compliance with all applicable regulations and especially with the GDPR is continuously ensured and all necessary evidence is collected. Unlike other regulations, there is no regular inspection of compliance with the requirements. Rather, individuals (including customers, employees or other relevant data subjects) and the competent supervisory authorities are able to make enquiries if alleged or actual omissions or offences are to be investigated. However, as yet there is no proof of GDPR compliance as a regular and permanent seal of quality.

However, assessing the quality and maturity of the controls, systems and processes implemented by an organization is essential. Given the level of agility required from business and market requirements this assessment needs to be executed on a regular basis. Continuous improvements are essential to achieve an adequate level of compliance in all key areas of the GDPR.

KuppingerCole strongly recommends regular reviews of the current state of IT projects and programs. This includes the review for maturity in the areas of compliance with regulatory or industry-specific regulations or frameworks. To support such reviews, KuppingerCole provides Maturity Level Matrixes that are specifically targeted to distinct areas of the IT market, in this case, GDPR readiness. The following sections elucidate the KuppingerCole Maturity Level Matrix for GDPR readiness.

1.2 How to use the KuppingerCole Maturity Level Matrix

The KuppingerCole Maturity Level Matrixes are tools for analyzing the current state of IT programs and projects. They provide information about levels, descriptive characteristics of these levels, and information about the technologies involved at the various levels. Overall, they follow the established concept also found in the CMM (Capability Maturity Model), a methodology originally designed to develop and refine an organization's software development process.

Initiatives to measure GDPR readiness and readiness not only enable an organization to understand and realize the potential benefits of investing in improving data protection but also provides guided direction on prioritizing projects in the development roadmap.

KuppingerCole recommends assessing your GDPR program on a five-point maturity scale formulated on the Carnegie Mellon Maturity Index. Below is a brief overview of the Maturity Index as applied to GDPR readiness. The below-mentioned criteria are not intended to be comprehensive or complete at every level, but are provided to exemplify the degree of maturity achieved at each level.

It has to be noted that this maturity level approach goes beyond the requirements of actual GDPR compliance but also looks at an adequate level of efficiency, business benefit and automation.

Level 1 is ad-hoc and reactive. Organizations in Level 1 have met fundamental data protection requirements in an ad hoc manner to date and, for example, responded to requests about stored personal data manually on a case by case basis. Some parts of the organization are aware of requirements of GDPR, but these have not yet been fully communicated or understood across the organization.

  • Data classification occurs in an ad hoc manner partially covering PII. There is no complete inventory of the PII the organization holds, nor is there a complete record of the reasons why this data was collected and what consent was given where this is relevant.
  • There are few defined workflows, and little or no user self-management of identities, thereby making it difficult for data subjects to update their data. Obtaining consent from users is problematic, and consent audit trails are non-existent.
  • There is no formal process for managing data subject access requests, data correction or erasure. There is no consistent way of ensuring that these requests are from the actual data subject.
  • The lifecycle of PII data held is managed in an ad hoc manner.
  • It is not yet known where DPIAs will be needed and the approach to these will be ad hoc.
  • GDPR requirements have not yet led to organizational changes for example a DPO has not yet been appointed.
  • Contracts with partners and suppliers holding or processing PII are only reviewed on an ad hoc basis to take account of GDPR requirements.
  • Technical measures for achieving security and privacy have yet to be reviewed against GDPR. As a result, the risk of data breaches has not been adequately assessed.
  • The process for the development or acquisition of systems that collect or process PII is ad hoc and privacy by design is not a documented requirement.
  • There is no formal process for ensuring that PII obtained from third parties has the required consent to its use, that it is accurate, and the minimum needed.
  • The processes for detecting and reporting data breaches are ad hoc and are not regularly tested. Hence the risk of non-compliance in the event of a breach is high.

Organizations at level 1 are not well prepared to comply with GDPR requirements. However, the organization has some measures in place, albeit rather ad hoc, and needs to take steps to determine and close gaps in technology, products, processes, and organizational structure. At this level an organization would find it difficult to provide evidence of compliance.

At Level 2 the organization has a partially documented and repeatable approach towards GDPR compliance. PII for all relevant data subjects is fragmented and stored in separate user repositories, but efforts are made to understand and document those repositories and their business justification.

  • Data classification processes including those covering PII are documented and applied in some cases.
  • The process to find and classify all PII is documented and has started. A catalogue of all systems storing, processing and transferring PII is being implemented. This includes the reasons why the data is collected and records of consent.
  • The lifecycle of PII collected and processed is documented and there is a documented process covering its deletion.
  • System consolidation and data minimization has started. A process for identifying, collecting and consolidating all data related to a single data subject is documented.
  • The above includes cloud services (IaaS, PaaS, SaaS), managed services and outsourced systems as well as on premises services.
  • There is a documented process for reviewing contracts with partners and suppliers holding or processing PII. These are being reviewed in the light of GDPR requirements.
  • There is a documented process for ensuring that PII obtained from third parties has the required consent to its use, that it is accurate, and the minimum needed.
  • The need to appoint a DPO is understood and a person has been identified, appointed and is active in this role.
  • The need to execute DPIAs is known and the process for identifying where these will be needed is being documented and communicated to relevant stakeholders.
  • There is a documented process for communication with all data subjects to achieve a solid foundation for consent management and to enable their exercise of subject access rights. This process implements a consistent way of ensuring that these requests are from the actual data subject.
  • Documented and repeatable security controls are implemented to protect confidentiality, integrity, and availability of personal data.
  • The process for the development or acquisition of systems that collect or process PII is defined and consideration of privacy by design is a documented requirement.
  • Data leakage prevention is implemented for PII overall and for all technologies and processes deployed.
  • There is a documented process for detecting and reporting data breaches, but this is only infrequently tested.

Organizations at this stage of maturity have taken the first steps towards a repeatable process for GDPR compliance, but have only partially achieved this goal. Organizations at this level would be able to provide some evidence of compliance for how some PII is collected and processed.

Level 3 - This level is characterized by an overall defined business process supported by some technologies, products, processes, and organizational structure. However, many of the relevant processes continue to rely heavily on manual labor and are not sufficiently efficient. These processes collect the evidence that would be needed to justify compliance with GDPR.

  • There is a standard business process for classifying and cataloguing PII together with the reasons why this data is collected, how consent was obtained where this is relevant and how long the data should be held. This catalogue is being reviewed to ensure all PII aspects are covered.
  • There are defined business processes for obtaining and managing consent, and responding to data subject requests. This process implements a robust way of ensuring that these requests are from the actual data subject.
  • There is a business process to ensure that the lifecycle of PII collected and processed is managed and that it is deleted at the appropriate point in time.
  • PII is protected through appropriate technologies such as access control, encryption, pseudonymizing / tokenizing and anonymization. Security and privacy controls are in place to ensure the confidentiality, integrity, and availability of PII.
  • The business process for agreeing contracts between data owners and data processors has been updated to ensure that individual responsibilities regarding GDPR compliance are included. Existing contracts are actively being reviewed and updated where relevant.
  • There is a business process for ensuring that PII obtained from third parties has the required consent to its use and that it is accurate, and the minimum needed, and this is enforced through contractual terms.
  • The collection, storage and processing of PII is at all times based on legitimate grounds, e.g. legitimate interest or consent.
  • There is a business process that defines how the need for DPIAs is assessed and how these are to be executed where needed. The results from this process are leveraged for a continuous improvement process of GDPR compliance.
  • Processes and technology are in place to track the consent lifecycle for each data subject and purpose down to data field level. Access controls are linked to given consent. Information on given consent can be provided and modified upon request.
  • There is a business requirement that the process for the development or acquisition of systems that collect or process PII uses privacy by design.
  • There are manual processes that enable data subjects to execute their extended rights, including transparency, insight, correction, export, freezing or removal of stored data.
  • There is adequate evidence that PII is not leveraged for automated profiling or decision-making processes without human intervention. This includes defined processes for data subjects to challenge made decisions.
  • There are business processes, supported by appropriate technologies, in place to detect data breaches and to ensure the timely notification of all relevant parties.
  • Data transfer to 3rd parties is monitored, documented and well justified.
  • Business processes ensure that international data transfers are based on legitimate grounds with sufficient documentation and evidence being available.

Organizations which have made compliance with GDPR a business objective are expected to be found at this level. At this level and organization would be able to provide evidence of compliance with GDPR albeit with some manual effort.

Level 4 is characterized by a higher level of automation and efficiency. In effect the processes defined for Level 3 are automated where practical or supported by workflows and other relevant tools.

  • There are automated business processes that support the justification for the collection of PII together with reason, consent, sensitivity and retention. These processes include any statutory notification of regulators. Systems that collect PII cannot be deployed without undergoing this process.
  • There are automated processes and technology that scan storage and network traffic to detect and control both authorized and unauthorized PII.
  • The business processes for obtaining and managing consent, and responding to data subject requests are automated. For example, data subjects are provided with a secure user portal, to request, inspect, adjust and remove PII. There are automated strong controls to ensure that only the data subject can access this data.
  • There is an automated process to ensure that the lifecycle of PII collected and processed is properly managed and that it is deleted at the appropriate point in time.
  • There are highly automated processes for breach prevention, detection and response. Pre-prepares responses are available, automatic identification of which data subjects to notify, while maintaining protection against any violation of privacy.
  • Processes and technology are in place to track the consent lifecycle for each data subject and purpose down to data field level. Insight into given consent is provided within an online portal and can be instantly modified with changes being effective immediately. There are automated strong controls to ensure that only the data subject can access this data.
  • The right to be forgotten is executed automatically in all connected systems. Where there are technological constraints that prevent this for example for data in logs, backups and analytics, there are supplementary mitigating controls to prevent this data from subsequently being restored or used.
  • There are automated processes that ensure existing security and privacy measures are tested regularly.
  • Dashboards and reports give continuous and ad-hoc insight into the current state of privacy, security and GDPR-related performance indicators.

Organizations in constantly changing market segments depend on a high extent of automation in order to be able to act as a successful market participant, to be able to use PII in accordance with the regulations and at the same time to guarantee and document an adequate degree of GDPR compliance.

Level 5 is the optimal level. It builds upon the processes and technologies described in Level 4:

  • There is complete and continuous insight, documentation and controls over collection, storage and processing of personal data, with automated and timely on- and off-boarding of applications and processes.
  • Applications, infrastructures and processes are designed and implemented according to the principles of Privacy by Design and Privacy by Default, making sure that new applications (COTS and home-grown) support compliance with GDPR requirements.
  • Adaptive and intelligent technologies support in preventing and detecting security and privacy issues, response and containment are automated and continuously improving.
  • Well-defined technological interfaces and APIs implement access control based on consent management and prevent storage and processing PII without legitimate grounds.
  • There is continuous improvement of processes and technologies.

Organizations in industries with strong regulatory requirements might be the first to achieve this level but achieving this needs to be the objective for any organization storing and processing PII.

1.3 Key Support Attributes

In addition to the CMM model there are six additional Key Support Attributes, listed in the table below, that pertain specifically to GDPR readiness.

Insight & Documentation Process Definition Organizational Measures Technical Measures Contractual Measures Consent Management
Complete and continuous analysis and documentation of fair and lawful collection, storage and processing of personal data. GDPR's data protection principles are embedded in all business processes. The company’s organization is adapted to GDPR requirements, e. g. a DPO is appointed and GDPR responsibilities are assigned. Secure storage and processing of PII (e. g. encryption, anonymization, tokenization, access control, backup & recovery), privacy by design and default. Written agreements between data owners and data processors (including CSPs) that clearly and fully define responsibilities and duties aligned with GDPR. Processes and technology are in place to track the consent lifecycle for each data subject and purpose potentially at the data field level. Access controls must be linked to this consent.
Symbols representing attribute levels
Figure 2: Symbols representing attribute levels

The maturity of the above six supporting attributes as described in the table above.

1.4 Using the Matrix and Supporting Attributes

The following situations can be taken as examples for triggering a maturity level analysis:

  • A CRO of a customer-facing organization (financial services, online shop, citizen portal) wants to have and communicate appropriate insight into GDPR compliance as part of determining the risk posture of the overall organization.
  • The overall maturity can be improved by proactively identifying potential gaps and their mitigation.
  • he CISO obtains the KuppingerCole GDPR Readiness Maturity Level Matrix and, with the help of his or her subordinates, completes the matrix, which helps to provide an overall picture to the CRO.
  • Another possible example would be related to modernizing the management of customer identity data:
  • For improvement of marketing efficiency and expected benefits in compliance, a customer-facing organization plans to invest into a state-of-the-art CIAM (Customer Identity and Access Management System).
  • As part of the preparation of the development of the CIAM system, existing systems and processes are analyzed in order to determine requirements for the new system, as requested by the CEO.
  • Business and IT jointly obtain the KuppingerCole GDPR Readiness Maturity Level Matrix, and collaboratively complete the matrix, which helps justify the expenditure in the eyes of the CEO, while improving the overall risk posture.

The recommended approach:

Start by baselining existing systems and processes. Assess them against the six key supporting attributes listed in the table in section 1.2. Measuring current system and process capabilities to these six attributes allow an organization to more accurately understand their overall maturity and risk posture.

Organizations that need to adhere to the requirements of the EU GDPR do not necessarily need to aim for the highest level of maturity. However, they need to demonstrate an adequate level of compliance to their Data Protection Authority when requested to do so. The Matrix can provide a gap analysis, and can assist in defining roadmaps for the future investments in GDPR compliance.

KuppingerCole provides additional Advisory Services to help clients benchmark their current maturity level regarding GDPR readiness, define the target architecture, identify the gaps between as-is and desired states, and develop tailored roadmaps to achieve that target.

Continue reading...
Read the full report and get access to KuppingerCole Research for 4 weeks.
Start Your Free Trial
Already a subscriber? Click here to login.