Many companies are already preparing for General Data Protection Regulation (GDPR), and have started activities to be compliant when the regulation becomes effective on May 25, 2018. Some are just starting, gathering information, based on which necessary actions can be planned.
A typical organization may have several business areas, processses, and systems where an assessment is necessary. Service and software vendors are providing materials and announcements of compliance. Building a coherent view of the status and readiness of the whole organization and an IT system portfolio may be challenging given the approaching deadline.
Enterprise Architecture and GDPR
If your organization is already using Enterprise Architecture (EA) framework and tools to manage and model the development of the operations and IT system portfolio, there is a possibility of synergy to be gained. There are numerous recommendations and guidelines available for steps to take while getting ready for GDPR. These can be mapped to architecture viewpoints, gathered using suitable EA elements, relations, and attributes to collect and highlight relevant issues. This enables estimating and prioritizing the efforts needed.
Collected information can be used to report and analyze situation across the architecture. This capability is very important for the integrated system and process landscape, since even if individual vendors provide GDPR assessment for their software, the combination of interconnected architecture is unique for the enterprise. Only paying attention, and performing Data Protection Impact Assessment (DPIA), to obvious customer facing systems and HR applications will not suffice. The decision of the DPIA necessity needs to be based on verified facts, and recorded for future reference, since companies are required to document their compliance.
Steps to take
Materials produced about GDPR by European Commission include set of Guidelines written by Article 29 Working Party. These guidelines are advisory in nature, and include criteria for an acceptable DPIA. By using this criteria, existing EA information of the company can be enriched to include information necessary to analyze the operations and IT system landscape of the company.
Steps should be taken iteratively, and where needed, more detailed analysis can be performed. It is also recommended that review dates are recorded as part of the analysis, since especially for high risk processing and systems the DPIA should be repeated periodically.
1. What personal data is processed?
Conceptual data models can be used to identify types of persons and personal data. Logical data models can be used to identify high risk data and detailed info needed for identifying the need for DPIA.
2. Which business services, processes handle the data?
Business models, process maps and integration diagrams are used to identify services and processes handling personal data. How are they gathering the data, processing it, and what are the integrations to other processes.
3. Which applications are handling and storing the data?
Processes and activities are linked to applications, layered architecture of them identifies the systems which should be analyzed for data cleaning, minimizing, or pseudonymization.
4. Who can access the data?
Process flows contain the roles involved in processing of data, and activities using applications for processing. Administrator access to IT systems should be considered also.
5. What data transfers are used?
Process integrations and application integrations reveal where data is transferred. Only required data should be transferred. Possibilities for removal, pseudonymization should be concidered. Integrations to external 3rd parties must be included in the analysis.
6. How applications and IT systems are protected?
Technology architecture EA information should include info about encryption of data in rest and data in transit, firewalls and other security measures in place.
Including GDPR related information as part of EA model enables two things:
✔ Operations and architecture of the company can be developed while simultaneously keeping track of GDPR requirements, instead of making a separate effort of gaining compliance.
✔ GDPR and DPIA compliance status can be periodically checked by analyzing the architecture information, with less manual data gathering and documentation update.