Jusletter IT

In a recent CEDIDAC Bulletin, Sylvain Métille put under scrutiny Art. 3 of the General Data Protection Regulation (GDPR) and the issue to know under which conditions a Swiss entity may or not be subject to the GDPR¹. As the author acknowledges, no matter the answer to that question, the standards set out in the GDPR are likely to soon be regarded as best practices which, although not amounting to legal obligations, may well be part of the due diligence expected from data controllers in terms of privacy management.

This due diligence does not only apply to multinational companies, but to any company processing personal data, thus including small and medium enterprises (SMEs). This due diligence is all the more important at a time when companies increasingly use cloud-based services to benefit from the flexibility and scalability offered by these resources, thus partially losing control over their data. Truth however is that, while multinational companies may have the resources, both from a human and financial standpoints, to support their efforts towards the achievement of a GDPR compliant level, such is not the case of SMEs.

Common grounds for pushback may typically include statements such as: «I have limited resources and budget», «I do not understand what this GR…whatever is about», «I am new to privacy and do not know anything», «I cannot find any checklist that would meet my needs».

Truth is that the very low level of understanding of privacy related matters within SMEs (sometimes even fairly big ones) make it difficult to transpose the approach used within multinational companies to such companies, even in a simplified way. Tools do exist, and the need for companies to comply with GDPR led to significant developments within the legaltech industry in the last two years in that area. While several providers now compete to win it all², their pricing model however demonstrate that their primary target remain multinational companies that have the expertise and financial resources to afford such tools. There is little doubt that few SMEs will afford such luxury.

Consequently, another methodology has to be adopted to demonstrate the efforts undertaken by SMEs to take into account privacy requirements into their day-to-day business practices.

This short paper aims at providing a practical guide to enable SMEs to start implementing privacy management activities through their organization without having to be a privacy expert. Pragmatic in its approach, this paper provides a generic overview meant for newcomers in this field, and should thus not be considered as a scholarly piece. Footnotes and references will be limited to the strict minimum.

Setting up a privacy management program that triggers some privacy awareness within a SME can be achieved without having to hire resources or being a privacy expert. Basic steps consist of the following ones:

A primary step will consist of finding out the data processed by your company. This step is important, as it only is after having assessed the type of data that you process that you will be in a position to decide upon the next steps.

The extent to which personal data are being processed will obviously depend upon your business model, and consumer facing companies involved in e-commerce for instance are likely to process a significantly larger amount of data than a company involved in B2B. No matter your business model, you will in any case process personal data related to your employees. In short, one finds it hard to imagine a company that would not process any personal data.

In today’s world, a company is unlikely to fully control its data processing end-to-end. This means that, at some point, you are likely to have hired vendors to process your data, for instance as a CRM provider (salesforce for instance) or for payroll purposes.

As a result, to map your data properly, which will typically be done on an excel- or spreadsheet³, it will be key to understand the type of data you process (consumer, employee, vendors, else), their categories (name, first name, email, phone, etc.), the reason for processing such data (i.e. the purpose, which can be to enable payment to your employees for instance), by whom such data are being processed (do you have full control or use vendors), where such processing takes place (this matters as any processing taking place outside of EEA will require special safeguards), and for how long such data are being retained. This last point is likely to trigger difficulties, as it has been largely ignored so far by most companies, be they multinational ones or SMEs.

Depending upon the size of your company, mapping your data will likely require to work with the operational and business units of your company, such as HR, customer service, security, procurement, legal, marketing and sales, i.e. all departments that process personal data or impact such processing.

Once carried out, this mapping may serve as a basis for maintaining a future inventory of any new systems, projects, etc. that would involve data processing, similar to the one required by Art. 30 GDPR.

This is the point to state that the GDPR makes a distinction between the information to be collected for record purposes, and the ones to be collected when a data protection impact assessment (DPIA) within the meaning of Art. 35 GDPR is required. Suffice it to say that the requirements to perform a DPIA are fairly restrictive and should be the exception rather than the rule for most companies that are subject to the GDPR; such will only be the case when «the processing is likely to result in a high risk to the rights and freedoms of natural persons», such as in the case of automated decision making processes, processing of special categories of data (such as health related), or a systematic monitoring of a publicly accessible area on a large scale (such as CCTV).

In practice, the launch of a new project for companies subject to the GDPR should start with a risk assessment (also sometimes referred to as criticality assessment), followed by a privacy impact assessment, which consist of some basic intake questions enabling to maintain an inventory for record purposes in accordance with Art. 30 GDPR. In cases when the requirements set out under Art. 35 GDPR are met, a DPIA shall then, and only then, be carried out⁴. For Swiss companies that are not subject to the GDPR, DPIAs do – at least for the time being – not come into play.

Data privacy policy and notices are sometimes mixed for one another, but are not interchangeable.

A data privacy policy consists of the baseline foundation of your company meant to describe the organization’s handling practices of personal data. It will tell employees what they may do with personal data, how, and is therefore internally focused. A privacy policy may typically contain sections as to its scope (type of information, who the policy applies to), a policy statement (expected behavior and consequences of non-compliance), the protection and destruction standards as well as the relevant contact details.

A data privacy notice is a statement made to a data subject that will describe how the organization collects, uses, retains, and discloses their personal data. Unlike the policy, it is thus externally facing, telling notably customers what the organization does with their personal data. A data privacy notice will typically consist of the following sections⁵: (i) the type of data collected (what) (ii) the purpose of such collection (why) (iii) the retention period (how long), (iv) the recipients with whom you share the data and the reasons for such sharing (with whom), (v) the location of such processing and potential transfer to third countries of such data (where), (vi) the technical and organizational measures in place to ensure the confidentiality, integrity and authenticity (CIA) of the data, (vii) the data subject rights with regards to such data and (viii) contact details in case of any question.

In addition to these elements, it will be important to find out the lawful basis for processing the data, which will typically consist of (i) consent, (ii) legitimate interest, (iii) performance of a contract or (iv) a legal obligation. Taking into account that lawful basis for processing is important, as opting for one or another may trigger some difference, notably if your entity is submitted to the GDPR. We shall briefly comment on these below.

To comply with all these requirements may prove lengthy and burdensome. This may also stand in contradiction with a tendency, underlined by Art. 12 GDPR, to prefer concise, transparent, clear, intelligible and plain language that avoids any legalism⁶. To try and take into account such transparency requirements, a favored approach consist of adopting a layered approach where a basic header will point out to a generic wording while enabling interested users to click on the full text⁷. Others mix visual (through videos) and textual elements⁸. Finally, privacy notices may also be tailored to specific needs, such as an icon that will notify data subjects of the presence of a CCTV for instance.

As a result, a first step will consist of finding out whether your company already has such policies or notices in place and, in the affirmative, to revisit these documents in light of current requirements, bearing in mind that these may have to be translated to be intelligible to your customers should they reside in different markets and speak different languages. Any amendment to existing policies or adoption of new ones should also be communicated to existing customers through a defined process (for instance by email or through an online notice).

The GDPR now puts more emphasis on the requirement to opt for a given basis to lawfully process data, as set out in Art. 13–14 GDPR.

While consent has been heavily used in the past as a basis for data processing, privacy professionals tend to dis-recommend such basis as (i) any consent can always be withdrawn, thus rendering any further processing illegitimate and potentially putting business continuity at stake, and (ii) consent needs to be freely given which, notably in employment relations, is considered an undesirable basis to process employee data in most instances⁹.

Rather than consent, your entity may try and focus on the need to process any data based upon (i) performance of a contract (for instance in an employment relationship, or for a sales contract) or (ii) legitimate interests (for instance related to the data collected prior to entering into an agreement by candidates, or for direct marketing by mail).

It might obviously be tempting for companies to use legitimate interest as a basis for most of their processing. One however needs to be cautious and should bear in mind to test its entitlement to use legitimate interests as a basis for processing through a legitimate interests assessment, by answering the following questions¹⁰:

• Is the processing necessary? Is there another way to achieve the desired outcome?
• Does the processing meet the reasonable expectation of the individual?
• Is the processing likely to interfere with the rights and freedoms of the individual?

Ultimately, one may consider that legitimate interests may:

For Swiss entities subject to the GDPR, it is worth remembering that, although using legitimate interests as a lawful basis may enable you to avoid the issue of consent withdrawal when such consent is the lawful basis for processing, data controllers will still have to face the entitlement of data subjects to object to such processing, as set out in Art. 21 GDPR. Unlike consent which, once withdrawn, mandates the processing to immediately be stopped, the right to object will however still enable data controllers to defend themselves and raise some defense to further process the data at stake.

As a result of the emphasis put on the basis for processing, one will need to wonder while mapping its data the following:

• Do we have a suitable basis?
• Will we have to transition from one basis to another?
• Will there be a need to requalify all our processing based upon consent (for instance because we have no log related to such consent, or because our data subjects were not informed of the entitlement to withdraw their consent)?
• Can we collect, store and maintain evidence of consent?
• Are we able to store and maintain evidence of our legitimate interest assessment?

Vendor management will typically require you to: (i) assess your existing agreements and make sure that they comply with privacy requirements and (ii) make sure that future vendors meet their privacy obligations. This is a step where legal support, if not provided in-house, will be hard to avoid.

A basis issue faced by all companies first consist of tracing and finding the existing agreements, a task that regularly proves daunting.

If the number of agreements at stake is minimal, you may try and address them all; if you have hundreds, you will obviously have to prioritize after having carried out a risk assessment and identified the most critical agreements from a privacy standpoint (based upon different criteria such as, for instance: categories and types of data at stake, their volume, purpose of the processing, location of the processing).

Rather than reviewing each and every agreement, a more efficient way to process consist of drafting a data processing agreement (whose content will shortly be discussed below) that will be attached as a schedule to existing agreement, to supersede and replace any privacy provision in place.

SMEs however have to be realistic; their – regularly – limited bargaining power will prevent them from being able to exercise much pressure on big players. As data controllers, SMEs however remain accountable to ensure that their vendors comply with their obligations; should it not be the case and should the vendors be unwilling to engage on your data processing agreement or have their own adequate privacy provisions in place, you will have no other choice but to take a business decision as a result of a risk assessment to decide whether to go on with that vendor or terminate the relation (which may well result in a dispute or prove difficult should all your fees have been prepaid) and look for an alternative supplier.

Privacy by design will require any data controller to assess their vendors and willingness to comply with privacy requirements, including, where applicable, as part of an RFP process. In practice, Art. 28 GDPR requires any form of data processing by a vendor to be contractualized. This agreement, that may be your data processing agreement, will typically have the following provisions in place:

• Subject matter and duration of the processing;
• Nature and purpose of the processing;
• Type of personal data;
• Categories of data subjects;
• Obligations and rights of data controllers;
• Data will only be processed on documented instructions from the controller (typically resulting from the agreement);
• Persons authorized to process have committed themselves to confidentiality;
• Adequate technical and organizational measures have been taken considering the data processed;
• Assistance to data controller with regards notably to data subject requests;
• Data return or deletion at the end of processing;
• Providing all information necessary to demonstrate compliance and allow for and contribute to audits.

As part of your due diligence as data controller, you should also ensure that your vendor’s employees are trained and have some privacy awareness.

Ideally, you may also try and ensure that data will be processed (and notably stored on servers located) in EEA, although the recently enacted Clarifying Lawful Overseas Use of Data Act (so-called CLOUD Act, H.R. 4943) is likely to restrict the protection sought for¹¹.

Any data processing taking place outside of EEA by your vendor will indeed require specific safeguards. It is key to bear in mind that «processing» is not limited to the storage or modification of data as most businesses will tend to believe; «processing» is actually broadly construed, and merely accessing data remotely, for instance through an IT support provided from Bangalore in India, will be sufficient to amount to a form of processing taking place outside of EEA.

In that case, you will need to ensure that you have an adequate transfer solution in place to allow such processing to take place. In practice, this will most of the time consist of the implementation of Standard Contractual Clauses (so-called Model Clauses), which also present the advantages of requiring information fairly similar to the ones requested in Art. 28 GDPR as part of their Annexes¹². While US vendors will sometimes try and rather refer to the Swiss-U.S. Privacy Shield, most customers should try and avoid such reference, whose future still remains unclear (but whose validity is not at stake, yet)¹³.

Some vendors may also refer to their BCRs. BCR, if approved in accordance with Art. 47 GDPR, will enable the transfer between affiliates within the same group, including outside of EEA¹⁴. It is however worth remembering that the BCR will only enable the transfer of data intragroup, but will not justify the initial collection of such data outside of EEA, for which an adequate transfer solution such as Model Clause will still be required.

Ultimately, data controllers should try and ensure that their vendors provide sufficient security safeguards, notably if they are cloud based, which can take the form of certifications such as ISO27001 or the delivery of a SOC2 Report (most commonly used ones), or that their service is hosted with a well-regarded cloud provider such as AWS or Azure.

In my perspective, no matter your size, the most common issues faced when negotiating data processing agreements meant to align with GDPR requirements relate to the following provisions:

• Subprocessors: in theory, while processors may benefit from a general written authorization to engage subprocessors, they should inform the data controller of any intended change concerning the addition or replacement of other processors, so as to enable controllers to object to such changes. In practice, compliance with this requirement for cloud-based vendors is tricky; considering the multi-tenant environment their business model is built upon, they cannot allow any customer to veto one of their sub-processors, so that any such objection will in practice result in the termination of the agreement subject to a potential refund of any pre-paid fees. Most vendors will however be reluctant to implement a process to even inform their customers of any change to their existing list of sub-processors and, at best, refer to a URL link that will be updated and that customers are expected to check from time to time. This obviously is far from complying with the information requirement set out in Art. 28(2) GDPR, but so it is.
• Assistance: while Art. 28 GDPR requires processors to assist controllers on several accounts (such as to address data subject requests or the execution of a data protection impact assessments), some vendors that are concerned about the potential costs resulting from such support will make a distinction between the provision of reasonable information (at no cost) and the further support that will be considered a professional service to be paid for, or will try and refer to a limited number of man days where their support may be requested at no cost.
• Technical and organizational measures: finally, some vendors will try and invite their customers to assess their technical and organizational measures so as to assess their adequacy with regards to the data to be processed, get their approval and, consequently, tentatively be exempt from any liability resulting from these measures deemed appropriate by their customers. In my view, this clearly is unacceptable, in the sense that vendors then try to shift the risk resulting from their own obligation to ensure that they have adequate technical and organization measures in place upon their customer, notwithstanding a clear separate and distinct obligation as processor to that effect in accordance with Art. 28 GDPR. It is up to vendors to make sure that they have the sufficient safeguards in place to comply with their obligation, rather than to get their customer’s blessing to that effect.

Most SMEs are unlikely to be the primary target of data protection authorities' investigations. Such investigations may however be triggered as a result of a data breach. While data breach response plans are common in the United States of America, where each State has its own legislation on that regard, the obligations contained in Art. 33 GDPR are new on this side of the Atlantic. No matter whether your company is subject to the GDPR or not, the implementation of such a response plan sounds like a good practice in accordance with the accountability principle faced by any data controller. Contracting a cybersecurity insurance may also soon be part of the basics for any company and certainly appears to be a must at a time when the question of a data breach occurrence does not start with an «if», but rather «when».

Without going into the details of what has been the subject of whole books¹⁵, the implementation of a data breach lifecycle will typically consist of the following phases:

• Identification of the incident: who reported the incident internally? To whom? When and at which location? How was the incident discovered? Who are the key stakeholders that should be included?
• Evaluation of the incident: before referring to a «breach», one should make sure that such a breach did actually tale place through primary investigations. What is the nature of the compromise? What type of information has been affected? What is their volume? What is the likelihood of the harm (for instance unlikely if all data were encrypted)? Do we need to hire external resources (such as a forensic company or a breach response remediation provider)?
  In case of an actual breach, your company will have three primary concerns: (i) to contain the incident and any affected system, (ii) have business back and running, and (iii) to assess whether notifications have to take place in accordance with applicable laws.
• Reporting obligations. One has to make a distinction between internal reporting within the company and notification obligations. No matter the type of communication, these have to be locked down so that inaccurate or incomplete information is not spread around your company or externally.
  Only the incident response team should be responsible for any such communication. The response team should consist of a minimal number of individuals to remain efficient, such as: legal counsel (internal, external), compliance (security, privacy), appropriate business unit whose data are at stake (finance, HR, marketing, etc.), IT and an executive decision maker.
  Question as to whether formal notification has to take place will have to be assessed by your legal counsel, who will have to answer the following questions: what are the applicable laws? Do we have a «breach» under these laws and what are the requirements? Do we have to notify and in what timeframe? To whom? Bear in mind that, should you have a cybersecurity insurance, your insurer is likely to play an important role and require regular communication.
• Conducting notifications: it is recommended to already have templates at disposal that might serve as a basis to notify relevant authorities and/or data subjects of the breach and to document and record all these notifications. Typical questions that may arise consist of finding out where affected individuals reside and whether you actually have all addresses required to notify (if need be).
• Recordkeeping and debrief: to record all steps and notifications taken will then enable you to track certain key performance indicators (KPI) such as, for instance: (i) how many notifications could be sent in a complete or partial format, (ii) what has been the average time to provide notice and (iii) how many missed deadlines or delays have you suffered.
  Once the breach is over, a debrief session with the privacy response team is recommended to learn the lessons from the past and answer questions such as: which parts of the process worked as intended? Which did not work at all? Why? Has any unforeseen difficulty been encountered? How much did the breach cost to the company?

Privacy frameworks, as demonstrated by the GDPR, puts a strong emphasis on data subjects, not only through principles such as privacy by design and by default, but also through the granting of additional subject rights to put individuals in control on their data¹⁶: right of access, right to rectification, right to erasure, right to restriction of processing, right to data portability and right to object.

The goal here is not to analyze each of these rights, but rather to ensure that companies have the relevant mechanisms in place to handle such requests (within a month when subject to the GDPR¹⁷), in answering the following type of questions:

• Is there a documented policy or procedure to address Data Subject Access Requests (DSAR)?
• Is your organization able to respond to DSARs within one month?
• Are there procedures in place to provide personal data to data subjects in a structured, commonly used, and machine-readable format? Data portability is, based upon my experience, one of the most difficult part for companies to comply with.
• Where applicable, are there mechanisms in place to allow personal data to be deleted or rectified?
• Are there mechanisms in place to stop the processing of personal data when a data subject seeks to restrict the processing?
• Are individuals informed about their right to object to certain types of processing?
• Are there mechanisms in place to stop the processing of personal data when individuals object to it?
• Are you able to deal with varying workloads?
• Are you able to check the data subject identity?

While this set of questions is focused on GDPR, they may easily be transposed to SMEs that are not subject to the GDPR but will still have to face DSARs.

While security is key, data breach will in most instances be the result of negligence employees. In short, raising privacy awareness within your company is crucial and part of your accountability as data controller.

Privacy training should therefore be conducted, both in general terms but also tailored to different units (such as HR or marketing for instance), and refreshed on a periodic basis¹⁸. Measuring attendance to these trainings as a KPI and making them mandatory might be a good practice as well.

To maintain privacy awareness, the setting up of an internal data privacy portal, news and poster may also create over time a privacy mindset and culture within your company that should not be neglected.

Finally, depending upon the significance of your processing, having a member of your team attend conferences, seminars, webinars or even get certified may prove valuable¹⁹.

The requirement for a Swiss SME to appoint a data protection officer within the meaning of Art. 37 GDPR will be rare. Such will only be the case if your company’s core activities require regular and systematic monitoring of data subjects (residing in EU) on a large scale²⁰. Typically, this may happen if you run an e-commerce website targeted towards EU residents (because you have a local version registered under the ccTLD of an EU country, and/or because of the currency used on your website).

Ultimately, this should be the exception rather than the rule²¹. From a governance standpoint, it will however be important to have someone in charge of ensuring that your privacy obligations are met and that will act as a contact person for privacy related matters. Ideally, it always is easier to have someone in charge internally, as such person will know your company and processes, but an outside counsel, typically a law firm, may come into play if you consider such external hiring more efficient. Depending upon the size of your company, involvement of cross functions such as IS/IT, HR or Marketing may also come into play through the appointment, for instance, of a privacy champion that will be the liaison point within the unit for privacy related questions after having been trained himself, thus creating a privacy team within your company.

As highlighted in this paper, setting up a privacy management program can be achieved through basic steps which, although cost and time consuming to some extent, remain achievable even if you are not a privacy expert, in particular considering the numerous digital resources now available.

While the methodology may obviously depend, typical steps will include:

• Data Mapping, with the objective to understand the type of data you process, by whom, from where. The mapping will be the starting point for your due diligence exercise and may serve as a basis for any future inventory.
• Privacy policies and notices. To draft from scratch or review your existing policies is likely to be the next step, notably to take into account current practices and requirements, which may lead you to reassess your basis to ensure lawful processing and document such basis accordingly.
• Vendor management. Largely ignored, vendor management will require you to make sure as a data controller that your vendors comply with their obligations in accordance with applicable data protection laws by having a relevant set of provisions in place. This ideally should not only relate to vendors with whom you may engage in the future, but also with existing ones. Having a data processing agreement template in place that can be attached to vendor agreements as a schedule might be a good starting point.
• Data Breach Response Plan. Incidents are likely to be the triggering event raising authorities' attention for SMEs. As a result, it is key to have a proper response plan in place and know the resources (notably external ones) that you may have to promptly contact should any such breach occur. Typical steps will consist of: (i) identify the incident; (ii) evaluate the incident; (iii) report obligations; (iv) conduct notifications and (v) record keeping and debrief.
• Maintain Procedures for Inquiries and Complaints. Legislators, as in the GDPR, consider it key to enable individuals to control their data. To that effect, individuals increasingly benefit from different rights that will require an internal assessment to make sure that you have the proper resources, mechanisms and processes in place to comply with such obligations.
• Training. Having a privacy management program on paper without bringing it to the attention of your team makes little sense. Training is considered a key concept of privacy by design within a company, and general as well as tailored training to be delivered to the different units, ideally mandatorily and refreshed on a period basis, thus become a must to demonstrate your accountability.
• Data Protection Officer. Last but not least, if will be important to assess whether, considering the mapping carried out and your business model, the appointment of a data protection officer is needed as set out under Art. 37 GDPR. Such should rarely be the case for Swiss SMEs. Notwithstanding the absence of a mandatory appointment of a data protection officer, having someone acting both internally and externally as a point of contact for any privacy related matters to ensure compliance on an ongoing basis and address data subject requests will be important.

Philippe Gilliéron, Attorney at Law (TIMES Attorneys), Professor at Lausanne Law School.