EA case study - Impact from GDPR

One of the major differences between todays EA and Enterprise Architecture work done a few years ago is the impact of GDPR and other privacy regulations. The other major change is the impact of VUCA, and this is the reason I added both privacy and VUCA to Architecture Principles.

Business events

We have two Business Events in our Architecture Scope that relates to GDPR, and they are both are prioritised.

  • Request for personal information, e.g. GDPR (Customer support)

  • Security incident with impact on personal data (IT)

We start with the first Business Event as we have not yet reached the IT-solutions in the EA case study.

The question us now how our process should look like, when an individual ask which information we have about them, for which purpose and on which grounds we have collected them.

First of all, we have to understand where we have personal information or not, and if it’s sensitive. Second, for which purpose we have this personal information and third, ground to use it.

If we look at our Capabilities in our company, then each of them have a purpose. So this why I start with them and look if they manage personal identifiable information and the PII is sensitive.

Capabilities

We have identified 16 Capabilities in our company and they cover the needs of the company on a high-level.

Capabilities and privacy.png

Without any formal information modelling done in this stage, but with the experience from running a company. I would say that some of the capabilities use personal identifiable information and other use sensitive personal identifiable information. We then assume that we have a few capabilities that shouldn’t use personal identifiable information at all. (This need to be verified).

  • Marketing & communication (personal identifiable information)

  • Sales (personal identifiable information)

  • Customer care (personal identifiable information)

  • Invoicing (personal identifiable information)

  • Production (sensitive personal identifiable information)

  • Distribution (sensitive personal identifiable information)

  • HR (sensitive personal identifiable information)

  • Finance (sensitive personal identifiable information)

  • Supply chain (personal identifiable information)

  • Legal (sensitive personal identifiable information)

  • Facility & workplace (personal identifiable information)

  • IT (sensitive personal identifiable information)

  • Management (personal identifiable information)

  • Business development (none)

  • Product development (none)

  • Platform development (none)

In order to answer the question from an individual about what kind of personal identifiable information we have about them, we need to know the different types of information objects managed by the company. I.e, we need to do a proper information model that covers the whole company.

We also need to identify the ground for collecting this information for each of the capabilities and the included business services.

This helps us to set the foundation for the first prioritized event, Request for personal information, e.g. GDPR (Customer support).

Architecture principles and frameworks

But GDPR is more than consent to use personal identifiable information. This is why we have the Architecture Principle that’s Privacy by Design based of Ann Cavoukian’s work.

We need an additional framework, like the one Claudio started to described yesterday, to address privacy concerns as we have a number of capabilities with sensitive personal identifiable information and this is for the next article.