GDPR – Why?
The GDPR - the General Data Protection Regulation - is a European Union law that lays down ‘rules relating to the protection of natural persons with regard to the processing of personal data and rules on the free movement of personal data’ [3], in order to protect the fundamental rights and freedoms of its citizens and residents.
Of course, the GDPR does not prohibit the use of personal data, but it sets limits and demands respect for the person behind the data. The regulation requires appropriate handling of data by design and by default from the outset of developing solutions. It should be part and parcel of the mindset delivering gainful and trusted solutions.
GDPR requires that only the really necessary personal data be used, for specific purposes, in a transparent way (full disclosure to the data subject, clear legal grounds, etc.) and in an appropriately secure way (privacy by design and by default, cybersecurity, etc.). The GDPR also assigns responsibilities to the different actors involved (data controller, data processor) and the conditions under which personal data can be exchanged with third parties.
Adopted in 2016 and in force since 2018, implementing the GDPR has been seen as quite a challenge. However, there are many benefits, also beyond Europe: if a system or solution is GDPR compliant, it is likely to already be (largely) compliant with other privacy laws (or can be brought into compliance quite easily), facilitating world wide handling of personal data.
To put this in terms similar to those in the IREB's ‘CPRE Foundation Level Handbook': consider the GDPR as a ‘context’ for the system you're designing. As Principle 4 states, ‘Systems cannot be understood in isolation’. When formulating requirements, you need to consider the needs for GDPR compliance in addition to the functional, system and quality requirements!
GDPR – How?
Implementing the GDPR is a complex exercise that touches on much more than just one or two data records, with some serious efforts and investments involved… Its multifarious aspects affect many parts of an organisation and its information solutions. As a comprehensive, and often rather expensive exercise, make sure that GDPR efforts benefit much more than simply the use of personal data.
Typically, GDPR compliance starts with a ‘hunt’ for personal data. What personal data is kept and used by the organisation, where, used by whom, for what purpose, under what conditions (when, for how long), possibly also outside the organisation... Usually, the first question is: what is personal data? One piece of advice: the GDPR provides some guidance [4], but ultimately, ‘personal data’ should not be defined too narrowly. In fact, it also includes data that, in combination with other data, can indirectly identify a specific person. A second step is the creation of a data register [5] containing information on which personal data are used for which applications and processes (do not forget to keep updating this register!).
Let’s put this in the form of an example, say an e-commerce. When a customer orders a product, some personal data is required to fulfil the contract [6] as for instance address (delivery), contact information (communication about fulfilment), payment information, and perhaps even age related information (e.g. for the sale of alcohol). This information may only be used for order fulfilment, and not for additional purposes, as e.g. marketing, unless consented to by the customer. Furthermore, the e-commerce must clearly (that is in understandable language) and transparently inform the customer (the data subject) about the personal data/privacy policy of the company, including how and where to contact the company in case of conflict. The company can only request the information that’s really needed to fulfil the order (data minimisation), and can only use and keep it as long as it is necessary (or legally required).
Obviously, when designing the order fulfilment solution, all necessary requirements must be included to enable the process functionally, but also to provide resources for informing the customer, and e.g. comply with privacy-related requests from the customer.
GDPR - How (2)
Considering the effort and expense, a GDPR compliancy exercise should preferably be a starting point for a more general data 'refresh'. Look at the enterprise architecture from a data perspective. Do you define all kinds of business elements (customers, partners, even production elements) as data objects (and how)? Do you classify your data in a structured way that helps both day-to-day operations and strategic decisions? These are fundamental steps for any kind of compliance!
Furthermore, do you have a method for data categorisation? Some data is more important and sensitive than others, and personal data is not the only category that needs protection. What about financial data, intellectual property, manufacturing data, etc.?
Assign categories to all types of data (public, internal, proprietary, sensitive, etc.), as well as associated risk levels (low, moderate, high). Use all of this to formulate requirements for the necessary procedures and resources (e.g. role/function based ID & access management). And any other security measures required (network segmentation, cyber security).
Key take away
Securing personal data may require significant investment. Make this investment work for all important data!
In fact, this data-centric exercise should extend beyond the boundaries of an organisation. When personal data of ‘data subjects who are in the Union’ [7] is exchanged by the data controller (the entity that determines the purposes and means of the processing of personal data) with external processors, recipients and third parties, these parties must provide at least the same level of protection of personal data, whether these parties operate inside or outside Europe. This includes the exchange of personal data within supply chains linking organisations. (See figure)
Role of Business Analysts and Requirement Engineers
In a sense, both business analysts and requirement engineers are the last ones to have a general overview of the whole of a solution, both regarding the processes (inside and outside the organisation) and the specific means.
While the business owner focuses on functionality (i.e. the job that needs to be done), it's up to the business analyst to also provide all the processes and procedures throughout the solution chain that are necessary for compliance, and to do so throughout the solution's lifecycle. For example, if personal data is being used, there will come a time when that use stops. Then there must be a procedure for archiving and/or deleting this data (either specific to a solution or through the application of a data policy). The same applies to exception handling, anomaly escalation, resilience, etc. Procedures must also be in place to support the rights of data subjects (information on the use of data, correction of errors, etc.). Furthermore, the GDPR has requirements not only in case of data loss, but also in case of unavailability of data, loss of integrity, etc.
As the business analyst formulates the needs from a functional point of view, it is up to the requirements engineer to formulate the specific requirements to implement these needs in a working system, which is itself part of a larger information infrastructure. If the business analyst foresees the need for an ID and access management system, it must also be provided for by system elements, including all the necessary elements for monitoring, logging, etc. It is the requirements engineer who ensures that the necessary elements are specified, by design, by default.
Indeed, browsing through the ‘CPRE Foundation Level Handbook’, time and again it states why and how the requirements engineer needs to pay attention to the GDPR. Personal data protection certainly is a desire of the stakeholder, and ‘requirement engineering’ minimises the risk of delivering a system that does not meet his or her desires (Def. 1.2). It minimises the risk of missing to fulfil needs as GDPR compliance, avoiding expensive remediation (1.2 Why). GDPR has an impact where requirements are formulated regarding socio-technical systems (organisational aspects), systems, domain requirements, business requirements (1.3 Where). Requirements are a crucial means to an end, that is GDPR compliance!
Common Effort
In practice, GDPR compliance and a fundamentally more privacy aware mindset is a collaborative effort! From development efforts to profound change management, it is a long term exercise, challenged by fast changing information technologies, and new societal demands. So the requirements engineer can’t be expect to do all of this on his own… Indeed, Principle 3 clearly states that ‘system development, including requirements engineering, is a multi-person endeavour.’
Fortunately, we see that nowadays development is increasingly handled by multidisciplinary teams. Interesting examples are the ‘secdevops’-teams combining the expertises of developers, production teams and security specialists, usually assisted by stakeholders as e.g. endusers. Obviously, the interaction between these teams and experts earlier in the design phase will become stronger, particularly in more dynamic development methods (agile…).
As a result, a GDPR exercise in particular will incentivise requirements engineers to extend their collaborative relations with in-house or external experts in the domain of privacy, personal data protection and related subjects as security and system resilience. Prime sources of advice are the company Data Protection Officer (if this function is required by GDPR in your organisation) or the person responsible for privacy policies and their implementation (as your organisation should have one).
Finally, GDPR compliance and privacy awareness should not be considered as prohibitive burden, but as an opportunity to increase the protection of all valuable data in an organisation, and to increase business by offering more trustworthy services to customers and partners, worldwide.
Assistance with writing this article
Guy Kindermans wrote this article in collaboration with Christiane Vandepitte, who is an experienced business analyst and software designer.
Guy Kindermans and Christiane Vandepitte are currently giving presentations on the EU digital strategy and the laws that come with it, e.g., the EU General Data Protection Regulation, the EU Artificial Intelligence Act and the EU NIS2 directive.
References
- [1] Multiple language versions of the GDPR: eur-lex.europa.eu/eli/reg/2016/679/oj English version: eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679
- [2] Rustad, Michael L. and Koenig, Thomas H.: Towards a Global Data Privacy Standard (September 11, 2018). Florida Law Review, Volume 71, Forthcoming, Suffolk University Law School Research Paper No. 18-16, Available at SSRN: ssrn.com/abstract=3239930 - see final paragraph of the conclusion. (An interesting article in its own right, discussing the origin of the GDPR and comparing it with existing privacy law at that time. Obviously, the privacy law scene has since evolved, but the GDPR still leads by example.)
- [3] GDPR Article 1.1
- [4] GDPR Article 4 (1)
- [5] GDPR Art 30
- [6] GDPR Art 6 (b)
- [7] GDPR Art 3.2
Guy Kindermans, with over 30 years at Belgian IT magazine Data News, has covered a broad spectrum of IT topics, from microchips to enterprise applications, including software development environments. Focused on information security and privacy, he speaks on these issues for organizations such as IIBA, as well as national and local organizations.