Size matters when doing EA and implementing IT-solutions, but GDPR doesn’t take the size of the organization into account.

Nevertheless, we have to be good enough for company of this size, i.e a small start-up. To say we can’t afford to follow the law is a really bad excuse.

DPO

We doesn’t see the need for a designated DPO as the company is small and we don’t process large amounts of personal information. Now and in a near future will we probably have less than 250 employees, less than 5000 data subjects and not a huge amount of sensitive personal.

Don’t take this as a legal advise for your own organisation.

Personal registry

However, we need one personal registry as we manage personal data.

The other question is what this register should contain?

One common register with all personal information?
One common register with all individuals as names and an id, but all details in separate registers?
No common register, only a register where to find personal information.

In IAF, this is modeled in Logical Scenarios and Architecture Principles gives the guidelines of which scenario to select.

How we reach the conclusion that the third option, no central register, is preferred option right now is to be shown in a later article.

Privacy by design

We have an Architecture Principle that states we have Privacy by Design as a guideline for new projects.

Responsibility

We don’t yet have a strongly defined operation model for the company yet as it’s to small.

We have two major options as today for responsibility, either a functional organization based on capabilities or a valuestream organisation based on Business Domains.

As we start-up the business, most of our work is based on a functional organisation and the different skills of involved staff.

Thus is why we decide that ownership for Privacy belongs to the process owner for each of the 16 capabilities.

Ownership

We need to update the existing privacy policy based on the framework and our mapping of capabilities.

We then need to define additional business events and associated processes and solutions and update our list where previously mentioned events are in bold.

Request for information (Right for access)
Request to change personal information (right to rectification)
Delete personal information for one person (Right to be forgotten)
Transfer personal information for one person (Data portability)
Questions via Customer support (right to object)
Security incident with impact on personal data

Each process owner have to describe the type of personal information used in their process and the central repository need to be updated to reflect this on a regular basis.

Evidence

We need to setup a dedicated Privacy mailbox for internal and external use and verify the process for above business events.

Same appoach for security incidents. We need to set up a Security mailbox for internal and external use and verify the security incident process.

Baseline

So far, only the most rudimentary parts of GDPR according to KPI’s are met today. This why we plan to implement the other parts in the near future, and add this to the list of projects.

http://www.artmann.co.uk/quality/legal/gdpr

How the management should evaluate the risks will be described by Claudio in a few days time.

Disruptive architecture

DPO