Applying GDPR to SaaS - Data Protection by Design

General Data Protection Regulation (GDPR) puts on the table a lot of new issues to be taken under consideration and handled by all parties involved in the SaaS market; both SaaS buyers and vendors. In this post, I’d like to focus on the vendor side and discuss a little bit more the issue of Privacy by Design. 

SaaS product designers perceive this issue as the general design of the SaaS product in a way that several mechanisms are in place in order to restrict or allow data access and handling by whoever is eligible from the client’s side. Of course, the question of “who” should be answered by clients, when they define their internal processes and map them to SaaS functions. They will define roles and responsibilities, which will result in a mosaic or map of data access rights and user rights. The SaaS platform must be in a position to address this design, preferably through already implemented mechanisms that have been included in the initial design and/or have been long tested in practice. Of course, not-covered requirements may exist and they will need additional development (apart from parametrization) to be met, but in an ideal world they should be minimum in number and minimal in system impact.

Below, I cite a list of basic features that a SaaS platform should have in order to be on the right side of the Privacy by Design “river bank”.

1) Extensive User rights management: Apart from the obvious user rights table where the system administrator defines which user has access to which system features, these rights management should go deeper in the details. If a user has access to a specific function, can he or she utilize the full potential of the system’s information capabilities. If, for example, a typical user has access to issue sales invoices, then is he/she able to also review the customer’s full data sheet? A tax ID field may not be necessary to issue a Credit Invoice, so is this field accessible to the user issuing that Credit Invoice?

2) Role-based access: The system should be able to allow access to “more” or “less” of the data subject’s sensitive or personal data. There may be cases where two users must have access to a data entity (say, the customers’ contracts in a contract management application). But if these users belong to different departments, it is certain that the data that they will need to see are different. The application should be able to “adjust” what is shown to each one, by defining different access levels, by User Role. While a payments officer needs to be able to see the bank account of the data subject, only a higher-level Accounting Manager should be able to edit that field. At the same time, a credit officer should not have any access to this piece of information… This can be a complex map to draw, which, conceptually, could look something like this:

	Data field 1	Data field 2	…	Data field n
Role 1	EDIT	HIDE	…	DISPLAY ONLY
Role 2	EDIT	DISPLAY ONLY	…	EDIT
…	…	…	…	…
Role m	HIDE	EDIT	…	HIDE

3) Row-level access rights: Imagine that data inside a database are organized in spreadsheet-like tables which have rows and columns. What we have discussed in point (2) above generally revolves around the access of users/roles in columns of the Data Subject personal and sensitive data. But what about rows? Can we accept that, if a user has access to the customer file, then he/she has access to all “rows” of that “spreadsheet”? In general, systems and organizations respond with “yes”. But this may not suffice anymore. For example, if a Data Subject decides to activate the “right to restriction” then its personal data should no more be accessible by all or most users in the system. There are many ways to handle this request but generally speaking it is all about restricting the access to a “row” of the “spreadsheet”. This is not a common feature in most applications but it is one that would be particularly useful for the purposes of GDPR. Imagine a mechanism through which you could define that a specific “record” (=row) can be accessed only by users A and B and nobody else in your organization. In many cases that would require some kind of “customization” on behalf of the SaaS vendor, but “Privacy by Design” may imply that this should, from now on, be a built-in feature.

There are many other examples of additional security/restriction requirements that I can think of. But the basic idea is that from now on, just building functionality and granting access per user is not enough. Data Privacy by Design must become an integral part of the application design process and in the next months or years SaaS buyers may see the design inefficiencies of several immature, so to speak, SaaS products emerge. 

On the other hand, we should not remain with the notion that this whole thing leaves only some burden on the designer’s shoulders! SaaS buyers should do their own analysis & market research and add a “line” in their system requirements, having to do with the data protection design features that they need. And to do that, they must have documented their requirements, first.