How the EU’s GDPR (General Data Protection Regulation) impacts your business
Blog: KWKeirstead's Blog
GDPR
(General Data Protection Regulation EU 2016/679) took effect one week ago (May 25, 2018).
The Regulation and two related Directives EU 2016/680 and EU 2016/681 deal with the processing of personal data relating to natural persons who are citizens of one of the 28-member States or persons residing in one or more of the 28-member States.
The first thing to note is that if you are a corporation whose headquarters is outside of the EU and if you host any personal data relating to EU citizens/residents, you are also subject to EU Regulation 2016/679.
Article 4 of EU 679 defines “processing” to include “collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction”.
The only way to understand the far-reaching impact of the legislation is to read the legal texts – there is one overarching Regulation and two Directives (680 & 681) but each member state (28 of them) has the right to publish its own versions of EU 2016 670/680/681.
If you do the math, you get 3 legal texts x 28 states x 150 explanatory texts/articles, for a possible total of 12,600 notes/articles.
If you have operations in more than one EU state, your policy/procedure re personal data relating to natural persons may require adjustments.
Know and Understand the legislation
A graphic free-form-search knowledgebase where you can simultaneous view all texts/articles for a search phrase facilitates the task.
You can view the texts/articles this way, i.e. no knowledge base.
or this way . . ., with a knowledge base
The problem with organizations running transaction-based software applications is that current systems are not likely to meet GDPR minimal requirements. There will be disclosures, fines will be imposed.
If you do a risk assessment OR bring in a consultant to carry out a risk assessment, the opinion is likely to be that in the event of disclosure you could receive a fine equal to 4% of your total world revenue. (i.e. Article 83).
A search at my EU 679/680/681 knowledgebase for “fine” highlights all “hits” down to the individual text/clause, allowing you quick/easy access to, in this case, Article 83.
GDPR sets the bar to a new, higher level in the area of natural persons data protection.
Be aware that “rule sets”, typically pervasive in transaction processing software, have great difficulty protecting personal “documents” (i.e. images, audio recordings, video recordings, documents, and memo field recordings, etc.).
For this reason, only share “documents” via a data exchanger that handles data sharing at transaction application process instance steps, using PCPs (process control points) that require manual intervention/clearance with other than across-the-board user permissioning.
Here are three (3) high-level recommendations re the design and configuration of transaction processing software systems to handle data relating to natural persons.
1. Restrict sharing of data relating to natural persons.
Only share data relating to natural persons on a need-to-know basis – the more data you share, the greater the risk of deliberate or inadvertent data breaches.
2. Importance of having formal data repositories.
Your core transaction processing software systems need to feature consolidating Case Histories that post system-generated date/timestamps, a user “signatures”, along with data, as it was, on the form versions that were in service at the time (who, what, where, when) at any process step you commit. Simple “logs” where you see accesses, without precise tracking on what was accessed, when, by whom, from where, are not good enough.
Postings to data histories must be automated, as opposed to selective and must include visits to all forms that host personal data, even if no data is recorded on these forms.
When a user leaves a process step form that has been visited and edited, the software suite must immediately lock down the new History posting.
Following this, no changes must be allowed to the new posting (or to any previous postings), except that authorized users can look up a form that is in the History, clone the form with its data, proceed to carry out edits on the form copy and then save the form template and data as a new session in the History.
3. Strictly control access to stored personal data
All access to personal data for purposes of viewing or data sharing should be via “official” interfaces only (i.e. direct log in, portal access, data exchanger).
a) Data being directly entered into the system by logged-in ordinary users should be controlled by user name and password, with permissions down to the form level i.e. a newly-added user should have no access to any record in the system. Access to the records that contain data relating to natural persons should be granted by “role”. Some records (i.e. ‘VIP’ records) should be blocked from access/viewing for other than specific designated users. VIP records should be excluded from searches, from directory listings and from Reports that list data across records.
b) Casual and external users should only be able to access data relating to persons via a portal login using a user name and password, preferably using dual factor authentication.
One possible configuration for portals is to use a portal-facing IIS server that pushes out a user-specific “menu of services” itemizing authorized service requests. The content of the “menu of services” should be “role-based”. (i.e. the only people who get to see the data for a database record are those actively involved in processing that data). Clicking on a portal user menu line-item invokes a database engine at the portal-facing server. The database engine alone logs into the back-end server, retrieves requested forms /data and posts the form(s) and data to the user in-tray at the portal.
c) Batch data streams from/to local or remote 3rd party systems and applications should only post to a standalone data exchanger that accommodates a mapping of need-to-know data elements per subscriber (typically a local or remote system). Parsers and formatters are the responsibility of subscribers and publishers and data streams must be encrypted for data transport. The data exchanger should accommodate rule sets that operate on incoming data (point of origin checks, range checks, boilerplate pick list lookup verification) and tag problematic incoming data for manual clearance.
Bottom line, if your current transaction processing systems/apps do not restrict sharing on a strict need-to-know basis, if your data repositories to not build/maintain formal Histories or if you they allow access to natural person’s data via other than official interfaces, you need to replace, re-engineer or adapt your systems/apps.
Many corporations view such undertakings as requiring a huge amount of capital/time/disruption,
They fail to realize that task execution/tracking (the major source of natural person data) can be carried out under a Case platform that can link to existing systems/apps via a generic data exchanger, giving the corporation improved control over workflow/workload, with the option of later adapting/re-engineering/replacing legacy systems/apps.
Here is a list of caveats in respect of data sharing of data relating to natural persons.
- Avoid e-mail systems (too easy to inadvertently reference the wrong addressee, proliferation of storage of personal data).
- Avoid cloud document-sharing facilities (better to have everything relating to a dbms record “at” the dbms record).
- Avoid use of APIs or RPA apps that build transaction logs, complete with personal data (i.e. determine where these apps are, who has access to them, what the retention strategy of each app is?) – your Case Histories are your permanent record of each transaction.
kwkeirstead
https://kwkeirstead.wordpress.com
Leave a Comment
You must be logged in to post a comment.
