Blog

BLOG

The Security, Privacy and Confidentiality safeguards you should look out for in a Marketing SaaS offering

PUBLISHED ON 12 JANUARY, 2016

Security, privacy and confidentiality are three key terms that invariably arise during the early stages of a SaaS (Software as a Service) selection process in the Marketing Technology space.

These very different concepts may at times, however, get lost in translation (or confused with one another) once requirements start flowing through a chain of internal stakeholders. That is, of course, until the answers provided by a given cloud-based marketing software provider reach the two key departments in charge of giving it the green light: “legal” (guaranteeing regulatory and contractual compliance) and “IT/security” (ensuring that internal systems cannot be breached and confidential or personal data does not become available to outsiders).

It is at that point, most likely too late, that everyone realizes we are simultaneously playing on three separate dimensions or compliance frameworks: regulatory, contractual and self-regulatory.

Since these compliance frameworks are not directly correlated with the three principal sets of requirements (Security, Privacy and Confidentiality) we must meet, it becomes essential to address the most likely permutations of requirements and compliance frameworks at a very early stage.

Very specifically, I am referring to the following scenarios:

Let’s go into the specifics, addressing each set of requirements separately.

Understandably, compliance with a certain set of Information Security standards has become the primary requirement in SaaS procurement processes or RFPs. After all, how can we claim to protect personal or confidential data if we cannot show substantial diligence in the avoidance of a security breach or critical data management flaw?

Of all existing standards, ISO/IEC 27001:2013 reigns supreme with worldwide acceptance amongst enterprise IT and Information Security departments. ISO/IEC 27001 basically entails multiple sets of audited control mechanisms, including:

• Access control
• Communications security
• Incident management
• Organization of information security
• Human Resource security

It is no surprise that Amazon Web Services is ISO 27001-certified (or that we are!).

But, of course, self-regulation is not the only compliance framework applicable to information security. SaaS contracts will routinely incorporate certain safeguards, most likely attached to their SLAs (Service Level Agreements).

Furthermore, legal (regulatory) security requirements can also make their way into a SaaS procurement process as a side-effect of storing, processing or transferring certain categories of data. Thus, a solution that stores special categories of personal data (ethnic origin, religious belief, health details or sexual orientation) will require an additional level of security in the handling and storage of such data by the EU legal framework -and the many more inspired by it worldwide.

In other words, security compliance may be determined by privacy -or “personal data”- laws (it is no coincidence that two of the most popular marketing SaaS platforms allow PII storage on the condition that special categories of data are expressly excluded).

Quite conveniently, the EU Article 29 Working Party (in charge of enforcing data protection legislation) has specifically pointed to the ISO/IEC standard for Information Security Management Systems as a means to provide that said “additional level of security”.

Although meeting a set of information security standards (and being granted approval by an auditor) can be a daunting task, their cross-border nature ensures a level of confidence in our risk-assessment efforts that we can only dream of when it comes to privacy compliance.

This is in fact an absolute ordeal entangled in a myriad of inconsistent national, regional or state laws, most of them unprepared to deal with the reality of cloud-based services, cross-border data subjects and borderless marketing experiences.

In essence, as they are affected by privacy (or “personal data protection”) laws, SaaS solutions can be classified in two broad types: They either enable the processing of PII or they don’t, the trickiest part possibly being the differing approaches to defining PII (with, for instance, IP addresses possibly qualifying as such in the EU).

Since this distinction is often defined through the subscription contract into which supplier (as a potential “data processor”) and client (as a “data controller”) enter – rather than the solution’s technical capabilities -, the burden of compliance will normally fall on the latter once personal data gathering or storage is prohibited by such subscription contract (this being, for instance, the case with some well-known web analytics platforms).

A more complex scenario opens up when a SaaS platform does allow for the management of PII or personal data, with the following points requiring specific attention whenever such data relates to EU-based individuals:

• If the SaaS infrastructure is not physically located within the EU, it will be required that an EU SCC contract (as in “controller-processor” Standard Contract Clauses) is entered into by vendor and client and then submitted for approval -of the international data transfer that will follow- to the competent data protection authority by the latter (a consequence of “safe harbor” provisions having lost validity on October 6th 2015).
• If the SaaS platform is already making use of EU-based infrastructure, its subscription contract will have to incorporate a data controller-data processor agreement.

Finally, privacy compliance could also be imposed by self-regulation (there is even an ISO for cloud-based PII processing: ISO/IEC 27018). This, however, is not something we normally find in the context of the large enterprise, as regulatory compliance counts on enough incentives (disproportionate fines in the case of the European Union) by itself.

Perhaps the most straight-forward and easily met of the three, confidentiality requirements see the light in the form of private contractual tools, either through a prior Mutual Non-Disclosure Agreement between the parties (as part of a proof of concept or in-depth demo) or through their inclusion in the main SaaS subscription agreement.

Complying with confidentiality requirements will also have a side effect on security compliance, as highly-confidential information will hardly be kept as such without an equivalent set of measures aimed at avoiding the risk of inadvertently sharing information beyond the circle of pre-approved individuals.

Needless to say, confidentiality can have a much broader reach than it would initially seem:

• What does the SaaS platform do with the client’s information (or third party-owned confidential information managed and stored by such client) when the contract expires or is cancelled?
• Will security copies also be deleted within a sensible period of time?
• How about the exceptional access that support teams will have to client data when assisting them in their daily configuration or management tasks? Are those teams properly covered by employee confidentiality agreements? Is there a proper log of specific employees accessing each client account and the sensitive data it may contain?

And it is here that information security standards come to the rescue again, as they do lay out the principles and internal rules by which all of the above are defined. Now, redundant as it is, it does not harm to explain these rules in the subscription contract so that client stakeholders beyond IT/security are fully aware of the conditions attached to the product they are buying.

All in all rather overwhelming, but manageable with the adequate plan in place.

I will be very happy to share mutual experiences on these fronts and others. Looking forward to your comments!