Understanding and becoming GDPR compliant – part 2

The General Data Protection Regulations (GDPR) will soon be upon us. See part 1. So how can we build a public facing infrastructure to move to GDPR compliance? What kind of GDPR focused applications can we expect to appear on the market and what are they likely to look like?

Applications to support GDPR

  • Cloud based, as organisations should avoid any new on premise infrastructure.
  • Software as a service (SaaS) on either a monthly subscription – depending on functionality, or on a consumption model (number of API calls).
  • Leverage cloud platform as a service technology (PaaS), so as to be highly available, with low cost and dynamically scaleable.
  • Integrate directly or indirectly with on-premise infrastructure through messaging, publicly available but secured APIs, or through on premise gateways.
  • Single tenant option- so that an larger organisations can purchase or lease their own cloud instance or copy of the application – deploying into either their own cloud tenant, or a managed third party tenant.
  • Multi-tenant managed service. Multiple smaller organisations can register in a single shared cloud instance of the application, with logical or physical partition of the data.
  • Avoid storing any kind of PII, but acting as a conduit or hub for PII
  • Ability for organisation to enter and publish publicly searchable GDPR information.
  • May provide a searchable DPO catalogue.
  • Distinct separate sign-in for different roles – DC, DPO, DS, SA
  • Avoid any kind of self hosted identity provision, instead leveraging external identity providers – such as social media- Facebook, Google etc or Azure B2C.

General Public -DS SignIn:

  • Provide the ability to register using social media accounts (Google, Microsoft, Amazon, Twitter, LinkedIn)
  • Search for organisations that may hold PII
  • Perform data request, data grant consent, or data revoke consent.

Organisation -DC SignIn:

  • Provide the ability to register using social media accounts (Google, Microsoft, Amazon, Twitter, LinkedIn)
  • Publish required information such as: Data Protection Officer, privacy notices, describe where data is held, and why and for how long etc.
  • Respond to general public requests with one month
  • Informing the Service Authority or the public of breaches with 72 hours
  • Track breaches
  • Integrate with on premise systems to provide an end to end experience.

Data Protection Officer -DPO SignIn:

  • Provide the ability to register using social media accounts (Google, Microsoft, Amazon, Twitter, LinkedIn)
  • Monitor the compliance of the DC

Vendor SignIn

  • Monitor the application

Possible SaaS Architecture

  1. Data Subject logs in to Azure hosted Web App, browses to find Company and makes a request.
  2. Web App forwards request to Azure Logic App workflow.
  3. Logic App stores the request for history and emails DC
  4. If request is to view the PII, then either the Logic App logs the request or, obtains PII from the DC either through an on-premise gateway or by calling an DC API that is accessible to Azure.
  5. PII is returned in an email which contains an encrypted expiring version of the PII. The encryption passphrase is sent in a separate mobile phone txt.
  6. DS uses pass-phrase to de-crypt the PII using SaaS application.
  7. If request is to grant consent then request is stored
  8. If request is to revoke consent, then instead of returning the PII, it is deleted.

Note: this is a very simplified direct access model. The DC may require a two step workflow that stores requests that DC will act on when ready.

For an example click here. Thanks for reading!!

Leave a Reply

Your email address will not be published. Required fields are marked *