Protecting Consumer & Employee Data In The Cloud

Cybersecurity has quickly emerged from a technical task to a problem that keeps executives up at night.

Why is that? Consumers expect to interact with businesses through a multitude of channels. Organizations do not only need to offer more and more online services, but also want to collect behavioral data about how users navigate, what are their shopping preferences etc. To do so comprehensively, organizations depend on vendors to provide the necessary technology.

Given the usual push for functionality while security is an afterthought, it is only a matter of time until vulnerabilities of such an ecosystem are exposed and exploited. May this be inadvertently caused by employees or vendors, may this be intentionally pursued by bad guys outside.

Remote working has only exacerbated the risk as employees now work in environments that – from a security perspective – are even less under control of the organization. Employees working from home may copy data about consumers or fellow employees to their computer or to their personal cloud (which may not be secured at all) or fall prey to a phishing email that they deem to be authentic and inadvertently disclose their credentials.

This been said, I want to emphasize that Cybersecurity is not a mere technical issue, but requires a culture where the organization, its employees as well as its suppliers collaborate in lock-step and follow the same charter of data protection.

Furthermore, I’d like to point out that whenever we talk security, we need to accept that higher security comes with a price, and perfect security is not possible. So it becomes critical for any organization to define its risk appetite and its level of risk tolerance. Therefore, data protection issues in general and cybersecurity issues in particular can only be tackled in a risk-based approach.

If you like to hear more about this approach, please join the upcoming non-technical webinar “Quantifying And Managing Cloud Risk For Consumer & Employee Data” on December 9, 2020 at 11 am EST. Being one of the panelists, I will take on a compliance perspective for protecting personal information in the Cloud. You are welcome to register here.

A Privacy Regulation Applying in the USA and Canada (and Everywhere)

Although the General Data Protection Regulation (GDPR)* was passed more than three years ago and entered force more than one year ago, there is still confusion and misconception about the regulation’s sphere of impact.

In a new series of posts, I will share some advice** drawn from experience in projects that I have conducted since the inception of the regulation, but also include updated guidelines that the European Data Protection Board (EDPB) recently published*** regarding the regulation’s territorial scope (Art.3 GDPR). To avoid amendments and editorial notes to my original post under this subject, I offer below a complete rewrite.

Although I encourage everyone to read the provisions of the GDPR as well as the above mentioned EDPB guidelines (which illustrate typical cases by example), here are the major takeaways regarding the GDPR's territorial scope:

• GDPR is a regulation to protect personal data of individuals ("data subjects") who are physically present – and may it only be temporarily - in the EEA (European Economic Area – which includes all EU member states plus Iceland, Liechtenstein and Norway). Data subjects’ protection rights are not dependent on their citizenship or residency.
• All organizations worldwide whose activities "intentionally, rather than inadvertently or incidentally, target" individuals being in the EEA are obligated to comply with the GDPR.
• Organizations established in the EEA have additional obligations: They must comply with GDPR regardless of where in the world data subjects are located.

The following matrix shows under which conditions GDPR applies:

However, in a world of international trade and high mobility of individuals, organizations can obviously not control the data subjects’ whereabouts while a business transaction takes place or thereafter. (Even data subjects’ IP addresses captured during electronic communications do not prove presence in or absence from a certain territory since individuals can legitimately – and will increasingly – hide their real geographical location by employing Virtual Private Networks.) Therefore, I recommend that organizations as of row B conduct all their activities related to processing personal data in a GDPR-compliant manner.

From a practical perspective, the above matrix can then be simplified as follows:

In conclusion, any organization offering products or services worldwide must presume, by default, that GDPR applies to them. On the complementary, non-EEA businesses whose commercial target area is outside of the EEA will be exempt from GDPR compliance.

 

* Published at https://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1528874672298&uri=CELEX%3A32016R0679
** Legal disclaimer: This blog post is not intended to be legal advice, but to raise awareness that it is recommended to consult a lawyer.
*** Published at https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_guidelines_3_2018_territorial_scope_after_public_consultation_en.pdf

How The GDPR Can Propel An Organization's Informational Infrastructure

I concluded a previous post "GDPR - More Than Just Another Regulation" stating that the GDPR (General Data Protection Regulation) forces organizations to prioritize a long-due overhaul of their informational infrastructure. 

In my understanding, a contemporary informational infrastructure is a system of people, processes and tools (software, hardware) that covers the five business disciplines represented in the image below whereas each level builds on the lower one(s).

Due to my observations, a vast number of organizations find themselves in the status where upper management hopes to advance level 4 and 5 to get the edge over the competition while business departments still struggle with the quality of level 3 due to a lack of foundation in level 1 and 2.

How does that relate to an organization's capability to comply with the GDPR? 

The sole purpose of the GDPR is the protection of an individual's rights as the owner of their personal data. However, since personal data are at the core of almost any business and even any business transaction, the GDPR's provisions imply a certain informational infrastructure. 

For example, GDPR grants any individual being in the EU ("data subject") a far-reaching control over their personal data records throughout the complete data life cycle with an organization, i.e. control over Create, Read, Update and Delete of their personal data (as long as it does not restrict the legitimate rights, liberties or legal obligations of other parties). 

• Create: The creation of records requires the data subject's explicit consent or is necessary to perform a contract with the data subject [Art. 6 et al.]. 
• Read: The data subject has the right at any time to know the total scope of captured and stored metadata and values related to their personal data [Art. 15 et al.] and to exclude usage of their data from certain purposes [Art. 21 et al.]. On the complementary, the organization has the obligation to restrict the access to personal data on a need-to-know basis.
• Update: The data subject has the right to rectify [Art. 16] and/or to restrict processing of their personal data [Art. 18].
• Delete: The data subject has the right "to be forgotten", i.e. their personal data to be deleted upon demand [Art. 17].

Although the provisions of the GDPR do not explicitly mention any infrastructural measures as of level 1 and 2, it is obvious that the organization can only comply with the rights of the data subject (and fulfill its own respective obligations), if the whereabouts of the data subject's personal data are completely transparent at any time, i.e. if the organization employs

• a data model of the personal data (that shows all the references and physical storages of personal data throughout the organization) [prerequisite for rectification and deletion] 
• a map that shows all the information flows of personal data (data flow diagram, process model) through the organization [prerequisite for information about the usage purposes and potential objection] 
• a functioning Master Data Management system that maintains "golden" records of personal data (or at least keeps possibly multiple records in sync) [prerequisite for rectification and deletion] 
• a functioning Data Governance system [prerequisite to comply with the GDPR in general] 

Organizations should welcome the GDPR as they will profit from these measures far beyond the purpose of complying with this regulation...

Note: This post has been updated from an earlier version written before the GDPR entered force.  

Personal Data - a Universal Definition Applying in the USA and Canada (and Everywhere)

In my previous post A Privacy Regulation Applying in the USA and Canada (and Elsewhere), I alluded to the worldwide impact of the General Data Protection Regulation (GDPR)*. In this post, I like to clarify** the GDPR’s definitional scope of personal data.

The GDPR considers data to be personal if they relate to an identified or identifiable natural person (“data subject”). Although the term “identifiable” tends to consume all the attention here, actually the term “relate” carries more weight as it widens the definition in a way that it resonates with common sense.

So while e.g. a Social Security Number, International Bank Account Number (IBAN) or passport number uniquely identify an individual and are therefore unquestionably personal data, the GDPR includes as well non-identifying attributes such as weight (at a given point in time), height or eye color to be personal data if they can be assigned to an identifiable individual.

But the term “relate” even pertains to more than a natural person’s attributes. A prominent example is a civic address register which certainly is public and does in no way constitute personal data in and by itself. However, if a register entry, e.g. “123 Main Street, Newcastle, Fantasyland”, relates to an individual “Jane Doe” whereas the relationship is “is residential address of”, that entry, by common sense and GDPR, becomes part of Jane Doe’s personal data.

You will find a more complete approach in my post GDPR & Personal Data - Context is Key and (Foreign) Key is Context underscoring that data modeling is a mandatory discipline in any medium or large organization being in need to get their head around personal data.

* Official publication of GDPR at https://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1528874672298&uri=CELEX%3A32016R0679

** Legal disclaimer: This blog post is not intended to be legal advice, but to raise awareness that it is recommended to consult a lawyer.

GDPR - Repeated Misconceptions

The original article at this address has been replaced by a more comprehensive post here.

GDPR & Personal Data - Context is Key and (Foreign) Key is Context

A logical data model is one of the important milestones on the road to GDPR (General Data Protection Regulation) compliance. Being the blueprint of an organization's semantic data and the relationships among them, the logical data model serves as the virtual hub between the existing physical data stores and the future implementation of a GDPR-compliant data architecture.

The logical data model even offers a GDPR-related bonus, as it teaches that being 'personal' (or non-'personal') is not an absolute characteristic of data, but depends on the context in which these data are made available.

To illustrate the latter, let's look at an example of a logical data model which presumably represents the business of a B2C online retailer. This model may have been obtained as the result of the process described in my previous post "GDPR - How to Discover and Document Personal Data" or through any other modeling approach.

Click to enlarge

Which of these tables contain records with personal data?  As per the definition of 'personal data' imposed by the GDPR ('personal data' means any information relating to an identified or identifiable natural person), the answer is: All of them! 

Why? Because all tables are 'related' to the table 'person', i.e. there is a path from each table to 'person' (and vice versa).

This does not mean that all records of all tables shown here contain personal data, but those records that can be reached through a chain of foreign-key-value to primary-key-value links (or vice versa) from a 'person id' or to a 'person id'.

In other words, the existence of relationships (foreign keys) provides the context that categorizes records of data as 'personal' or 'non-personal'. For example, if we isolate the table 'address', its content simply constitutes a list of addresses which may exist in public reference databases such as Google Maps and therefore cannot be considered to contain personal data. But in the context shown in the above model, those records of the table 'address' that are identified by the value of the foreign key 'residential address id' in table 'person' (or by values of the foreign keys 'delivery address id' and 'billing address id' in table 'order') become personal data.

Still, the necessity and degree to protect personal data may vary from table to table and from column to column. The sensitivity of personal data must be evaluated, and the risk of processing personal data with respect to the rights and freedoms of natural persons must be assessed. Sensitivity and processing risk for each personal data element in isolation, but more importantly for their combination and in context will influence the physical design of data stores including measures of encrypting, pseudonymizing and anonymizing personal data to achieve GDPR compliance. But that will be subject to another post...

GDPR - How to Discover and Document Personal Data

One of the first steps for organizations on the journey to GDPR compliance is to find out what 'personal data' (i.e. any information relating to an identified or identifiable natural person) are stored where. For many organizations, this can be a tedious, cumbersome process, since very often the complete 'list' of all metadata describing personal data is not at hand right from the start. Making matters more complex, personal data's metadata (like any metadata) may be found under a variety of synonyms in different data stores. 

To streamline the process for data discovery as much as possible, I suggest a sequence of 5 steps which may need to be repeated several times. With each pass, additional personal data and/or their locations may be discovered based on the names of columns / fields added in a previous iteration. The process can be stopped once a consolidated, structurally sound logical data model has been obtained. 

Click to enlarge

The steps include:

1. Create an inventory of all data stores. Record their name, purpose and  physical location (device type, country!). Important: Include locations where potential 'processors' (contractors) store business data on behalf of the 'controlling' organization! 
2. Select (subset of) data stores that are already known to contain personal data. (In a first iteration, start searching data stores using typical metadata of personal data! In later iterations, search data stores using additional metadata of personal data based on the logical data model previously created (see step 5).) 
3. Capture / reverse engineer the physical model of the selected data stores.
4. For each selected data store, identify metadata (field names) of personal data and of objects relating to personal data. Assign business meaning to those fields by linking them to semantic items from your business data dictionary. (If you do not have a business data dictionary, create one in parallel by using existing documentation and involving subject matter experts!) 
5. Create / enrich (partial) logical data model using the business data dictionary.

Although this is only the beginning of the journey, professional data (and process) modeling tools are obviously necessary on the road to GDPR compliance. (Note: All red arrows in the above image do not only indicate step sequence, but ought to also represent links among the related artifacts in the modeling tools' metadata repository.) Having already a business data dictionary in place and/or logical and physical data models tool-documented will greatly facilitate the process.

Stay tuned and read part 2 "GDPR & Personal Data - Context is Key and (Foreign) Key is Context" where I will demonstrate how context is important to determine whether data are to be considered personal or not with respect to the GDPR.

Need For Compliance With GDPR Is Beyond Any Organization's Control

The original article at this address has been replaced by a more comprehensive post here.

GDPR Necessitates a Professional Data Modeling Tool

In his recent article Data governance initiatives get more reliant on data lineage info, David Loshin pointed out that "data lineage management offers a compelling scenario for improving the data governance process". Loshin distinguishes two aspects to Data Lineage, one structural and the other related to data flows which I characterize as follows:

• Structural Data Lineage - mapping and tracking semantic data objects (and their synonyms) throughout the organization from elements of conceptual and logical schemas to their physical occurrences in databases
• Dynamic Data Lineage - mapping and tracking the flow of semantic data objects (and their synonyms) from their sources, through the processes and data stores of the organization to downstream consumers.

In my post How The GDPR Can Propel An Organization's Informational Infrastructure I mentioned that recording Data Lineage is implicitly required by multiple regulations, most prominently the General Data Protection Regulation (GDPR).

Let's bring this to life using an example scenario of the not so distant future:

Thomas, an EU resident, is client of the online retailer xyzAnywhere Corp. which communicates with Thomas usually by email, but occasionally chooses to send him promotional letters by post mail. Thomas receives some of xyzAnywhere's promotional mail at his current residential address (as shown in his online profile), but also still some of their letters via mail forwarder as they are sent to his previous home. Thomas exercises his right granted by the GDPR to request a copy of the entire personal data that xyzAnywhere Corp. holds about him.

Upon receipt of that copy, Thomas realizes that the information provided to him does not include his previous residential address at all.

Regardless of how the communication between the customer and the organization may continue and leaving aside whether and how regulatory authorities will consider the case and penalize the organization, we can conclude that the organization failed to comply with GDPR (Art. 15), as it did not make the complete set of the customer's "personal data undergoing processing" available.

How could the organization have avoided to fail?

By employing a professional data modeling tool that especially

• Features the creation of a business data dictionary where all semantic data objects can be uniquely named and well-defined for the entire organization
• Supports to map and trace all synonym occurrences that may exist throughout the organization related to a data dictionary entry
• Serves to represent a model of Master Entities and their physical distribution.

The data modeling tool SILVERRUN fully supports the above criteria and helps you to build a solid foundation for Data Model Management, Master Data Management and Data Governance.
 
Below please see how SILVERRUN reports Structural Data Lineage which would have helped in the above example scenario to identify all database columns that constitute synonyms e.g. of the data dictionary item "person last-name" and thus define the data model needed to systematically extract all personal data related to a particular customer.
 

Click to enlarge

To be clear:  Links between a data dictionary item (glossary entry) and its synonyms can only be created by "brainware", not by software (alone) since the semantics behind any data object has to be understood first. However, with human guidance, SILVERRUN can integrate the puzzle pieces that may be available through reverse engineering of databases, importing spreadsheets, reusing existing models and accessing other sources of documentation. 

Once integrated, the resulting data model constitutes the solid ground to build a future-proof Master Data Management system and to flexibly respond to regulatory requirements as e.g. stipulated by the GDPR.

[In the spirit of full disclosure: I represent Grandite, the supplier of the SILVERRUN tools for data and process modeling.]

GDPR - More Than Just Another Regulation

It has become all too common that business initiatives targeting infrastructural improvements such as Enterprise Architecture & Business Modeling, Data Governance & Master Data Management, Privacy & Data Protection are put on the back-burner or are totally suppressed in favor of endeavors that promise monetary benefits in the short term.

Accordingly, few organizations are really prepared for a timely response to requirements imposed by law or by industry-specific regulatory authorities. Considering the usually moderate fines for non-compliance and potentially little other consequences, delayed reaction and acceptance of the risk to eventually be hit by the proverbial stick have become an element of business calculation.

When conceiving the General Data Protection Regulation (GDPR), the European Union (EU) obviously anticipated that a non-negligible number of organizations would be reluctant to comply rather than making reasonable efforts. EU lawmakers have therefore replaced the penalty stick with a sledgehammer right out of the gate (May 2018). In plain English, the EU's powerful message says: 

"If you, the organizations of the world, process personal data of our people, you have to respect the provisions of the GDPR, otherwise we will hold you accountable with fines of up to EUR 20 million, while in return we apply the same rules to our organizations when it comes to processing personal data of your people."

Not emphasizing nations or ideologies, but simply putting people first, is not only a strong political statement, but a directive that will change the way how business will be done in the foreseeable future. It is a contemporary way of saying "the customer is king" while forcing organizations to prioritize the long-due overhaul of their informational infrastructure. 

Too bad that we need lawmakers to remind us of what should have been common sense in the first place.

Pondering on Data and CDO (Chief Data Officer)

A successful approach to organizing a business is to avoid overhead, i.e. to decentralize responsibilities as much as possible and to centralize as little as necessary. Having this in mind, I closed an earlier post "Close encounters with the 3rd resource" postulating that business departments take their ownership and responsibility to govern Data as assets.

Since governing the other two main resources, Finance and Human Resources, as assets were established early on and practices are not widely disputed, it should be deemed worthwhile to explore how Finance and Human Resources are fostered in a balanced approach between centralization and decentralization:

In medium or large enterprises, Finance and Human Resources are typically represented by central organizational units, headed by the CFO (Chief Financial Officer) and the CHRO (Chief Human Resources Officer), respectively, each of them directly reporting to the CEO. In their respective realm, Finance and Human Resources a.o.

• Develop corporate target scenarios and related strategies
• Ensure that the organization follows legal and regulatory obligations
• Advise business departments regarding strategic and legal aspects
• Perform tasks that are not assigned to the department level, but to the corporate level (e.g. declare taxes, report to regulatory authorities, compose the balance sheet, negotiate with the workers' union)
• Provide standard templates / procedures that operational departments can / must apply (e.g. standardize expense reports)

Any item of the above list is abstractly applicable to the resource Data, therefore, I suggest that medium and large enterprises implement a central unit headed by a CDO (Chief Data Officer) who directly reports to the CEO. 

More precisely, the Chief Data Office(r)'s tasks ought to include e.g.

• Develop a High-Level Enterprise Information Management Map (also see my post here)
• Ensure that the organization follows worldwide-applicable regulations such as the GDPR (General Data Protection Regulation) and industry-specific regulations such as HIPAA, Solvency II, Basel III etc.
• Derive measures that respond to international, national and corporate requirements of Data Governance and advise business areas accordingly
• Develop a detailed data model for the intersection of business areas (Master Data)
• Conceive standard interfaces for Master Data Management and related hubs
• Build a corporate Business Data Dictionary

Taking this approach, the enterprise will fulfill a crucial prerequisite to govern Data as an asset of the organization.