Ads 468x60px

perjantai 3. maaliskuuta 2017

GDPR compliance is inevitable – some thoughts on how to handle it and benefit from it

Today’s blog post bends the old boundaries a bit and is a result of a collaboration between KPMG Finland and Software AG. Writers have extensive expertise in Enterprise Architecture, Security Architecture and Privacy Architecture.

As many of you already know, the new regulation regarding data protection (General Data Protection Regulation, GDPR) will be effective all across the European Union starting from May 2018. The regulation will have an impact to all organizations operating within the EU, and to organizations outside the EU that are providing services within EU.

Currently ongoing transition period gives organizations time to evaluate and adapt to the new regulation. Our recent experiences from the field show that many organizations are worried how to meet upcoming requirements. While a majority of companies have realized that additional investments are needed to comply with the regulation, quite many of them do not know how to approach upcoming changes.

Some major obstacles would be removed once organizations could answer questions such as “in which business process do we collect, process or delete personal data?” or “where do we store our data, for how long and what for?” Answering these kind of questions has been in the heart of Enterprise Architecture Management (EAM) since the beginning, using the old metaphor of city maps to classify an enterprise landscape, e.g. what are the supporting business functions, applications and data usage.

The details of the GDPR may be new to many, but Enterprise Architects have been modeling business and IT transformations for decades

Let’s take an illustrative example from the financial services sector and an organization that offers housing loans through personal banking unit and insurances through separate unit. All of these products require the collecting, processing and storing of personal data. Both of these are different contexts and the GDPR does not automatically allow service provider to utilize that data across units, unless an explicit consent from the data subject or some other legal ground for the processing exists. Due the regulation and business-related demands, service provider needs to consider at least these point of views:
  • In what context the personal data is captured and processed?
  • Who is a processor and who is a controller?
  • Who has access to this information and on what basis?
  • On what basis personal data is used and long it is stored?
The service provider needs to understand the dependencies between things such as sales channels, business processes, IT systems and the data that is processed by the different business units to able comply with regulation and to effectively carry out development initiatives.

Let’s then add to the complexity, as the financial services provider can have hundreds of products in their portfolio and even several of underlying IT systems. One can start imaging the complexity of the landscape where personal data is processed. In addition to comply with GDPR requirements, there are a high chances that some architectural elements are not fulfilling their business needs well enough, or even worse, there are overlapping solutions increasing complexity for nothing. Regardless of the industry, similar issues are prevailing.

Potential challenges with “the right to be forgotten”

Complying with “the right to be forgotten” will be challenging both technically and operationally. There are a lot of hype around the connected society (e.g. Internet of Things, IoT) and the enormous potential around smart buildings, smart cars, and interactive wearables etc. Possibilities are nearly endless within the interconnect world. However, IoT is built on an ecosystem consisting independent organizations, various partnerships, technologies and customers. That ecosystem in itself is definitely a challenging task to handle. In the wake of a stricter data protection regulation, it is certainly not getting any easier. For an example “the right to be forgotten” and the case of a so called smart car. Who do you turn to if you want to be forgotten? One option could be the car dealer, as they have a customer service function and that is where you have had a dialogue about the car. But, is it really the car dealer who is responsible for gathering the vehicle’s data? The other option could be to turn to the manufacturer. But does the manufacturer have capabilities to provide such an information and do they actually possess the data?

Once again it will be crucial to answer the common EAM questions such as “in which IT system do we process person data” and “where is that technology deployed”. So, while you now are more or less forced to analyze, describe and model your processes from GDPR perspective, why don’t you do it from the efficiency perspective as well, since you sure now have the funding for it now.

The benefits within Business and IT transformation

Before saying that EAM is the solution to overcome the hurdles in the GDPR roadmap we need to understand the environment in which businesses operates these days, especially from the digitalization perspective. Along with the mandatory compliance work, there are significant possibilities to utilize findings for other business development activities to speed up digitalization or other business transformation initiatives. In another hand, the digitalization initiatives demand a higher rate of change, a dedicated customer experience management and GRC practices that acknowledges digitalization.

The typical Enterprise Architecture function will have hard time relying on the old document-based modeling of the truth with snapshots of a given moment in time. Based on the experiences from various projects, documentation tends to be outdated after time passes. In another words, we need to re-think best practices to keep answering these questions and keeping the models (and whole portfolio) up to date. 

EAM should be responsible for integrating the various stakeholders of digitalization. It needs to set up a structured way for collaboration rather than the traditional approach where stakeholders work are isolated from each other. The integrated approach will allow you to understand not only the snapshots of your architecture but also the change perspective (ongoing and planned), business perspectives (financial and structural) and IT perspectives (externally and internally facing). Moreover, this will engage all necessary stakeholders, such as legal, finance and of course the business representatives.

Looking back at the points above, the concept of Enterprise Architecture Management cannot be sheered as a nice-to-have gimmick, but rather way of survival.

Peter Björklund, Business Architect, Software AG
Tuomo Kuusinen, Enterprise Architect, KPMG
Kristian Backman, Security and Privacy Architect, KPMG

Ei kommentteja:

Lähetä kommentti