Privacy Compliance

According to the GDPR, personal data are any information which are related to an identified or identifiable natural person.

Examples: name and surname, address, email address such as name.surname@company.com, identification card number, location data, IP address, cookie, advertising identifier of your phone.

One class of personal data is sensitive data. This is data that should not normally be in the public domain. It includes racial or ethnic origin, political opinions, membership of trade unions, religious beliefs, health conditions both physical and mental, sexual orientation, and criminal offence history. If an organization requires this data, then a "higher level of protection" is required. While it is debatable what this requirement means at a technical level, the penalty for not protecting sensitive data can be higher than for not protecting standard personal data in the event of a data leak.

🇨🇭 A feature of the FDAP is to classify genetic and biometric data as sensitive data.

A data subject is an identified or identifiable person to whom personal data relates. Concretely, a data subject is the person whose data needs to be protected. A data subject can be a client, employee, supplier, contractor - so any individual with a relationship with your organization.

A data controller is a natural or legal person, public authority, agency, or other body which "determines the purposes and means by which personal data is processed". Concretely, the controller is the entity to whom a data subject confides his or her data, e.g., public tax authority, e-commerce site, etc. Controllers make decisions about processing activities.

The global digital eco-system is a complicated one. For instance, a company may choose to outsource storage of its data to a tierce cloud provider. For this reason, a third definition exists to capture this type of relationship. A data processor is a natural or legal person, public authority, agency, or other body which processes personal data on behalf of a controller. Processors act on behalf of the relevant controller and under their authority.

The first step towards privacy compliance is to identify those organizational activities that process personal data and ensure that processing has a lawful basis.

List of Processing Activities

Organizations with over 250 employees or who conduct high-risk data processing must take the following steps. Other organizations are strongly encouraged to take these steps also.

• Keep an up-to-date and detailed list of processing activities and be prepared to show that list to regulators upon request. A processing activity corresponds to some business activity, e.g., newsletter, payroll, video surveillance.
• For each activity on the list, you should detail the purpose of the processing, the kind of data you process, who has access to data in your organization, any third parties with access (and where they are located), what you're doing to protect the data (e.g., encryption), and when you plan to erase it (if possible).

Legality of processing

For any of the identified activities, processing of data is illegal under the GDPR unless you can justify it according to one of the following conditions listed in GDPR. The conditions include:

• Consent from data subject, that is, the data subject has explicitly consented to the processing of his data.
• You can argue that the data is needed to conduct a contract with the subject. For instance, a school needs to keep student grades in its database to be able to give diplomas.
• The law of the host country requires that you process that data. For instance, bankers must do background checks on clients for AML due diligence which requires processing of data relating to origin of wealth.
• You can argue that processing the data is in the legitimate interests of the controller. An often-cited example is a commercial company that suspects some client of cheating the company, e.g., by claiming that delivered goods were not received, and therefore implements special processing to validate this suspicion.

For each processing activity, an organization must choose a lawful basis for processing, and document its rationale. If consent is the lawful basis, the organization must consider that consent can be revoked. Furthermore, neither children nor those suffering from dementia can give informed consent.

Privacy Policies.

You need to tell people that you are collecting their data and why (Article 12). You should:

• Explain how data gets processed, who has access, and how your organization is keeping the data safe.
• Include this explanation in a privacy policy, available on your website, in clear and plain language.

To comply with the GDPR, an organization must develop a security posture, by implementing appropriate technical and organizational measures to protect data.

Data protection by default

• Technical measures include encryption, multi-factor authentication, antivirus, firewalls and intrusion detection solutions, strong password management, and keeping software updated with the latest versions.
• Organizational measures include limiting the amount of personal data collected, deleting data you no longer need, and minimizing permissions accorded to employees for data.
• Employees must be aware of these measures.

End-to-end encryption

Tools like email, messaging, notes, and cloud storage should use encryption or pseudonymization whenever feasible. In the context of the Web for instance, https is an example of end-to-end encryption.

Security policy

Create a security policy and ensure team members are knowledgeable about data security.

• A policy should include directives about email security, passwords, two-factor authentication, device encryption, and VPNs.
• Technical and non-technical employees with access to personal data must receive GDPR training.

Data protection impact assessment

For each IT service, a data protection impact assessment aims to understand how your product or service could jeopardize personal data and minimize those risks. You should be able to show the results of the assessment to regulators. The reason for the assessment is to ensure that your organization fully understands the consequences of personal data processing and is convinced that the processing should take place despite any measured risks.

Notification of breach

In the event of a data breach, you must:

• Notify the data protection authority in your jurisdiction within 72 hours.
• Communicate data breaches to your data subjects unless the breach is unlikely to put them at risk (for instance, if the stolen data is encrypted).

This theme considers how an organization oversees the implementation of GDPR.

Accountable person

Ensure some person in your organization is accountable for GDPR compliance – meaning he evaluates data protection policies and their implementation.

Data processing agreements

Services should have a standard data processing agreement available on websites for review.

• The agreement must mention any third-party services that handle the personal data, including analytics software, email services, cloud servers, etc.
• Agreement spells out rights and obligations of each party for GDPR compliance.
• Only use third parties that are reliable and give sufficient data protection guarantees.

Foreign representative

If you process data in an EU member state, you need to appoint a representative in that country who can communicate on your behalf with the local data protection authority.

Data protection officer

A Data Protection Officer (DPO) interacts with data subjects and surveys implementation of GDPR in the organization, assesses data protection risks, advises on data protection impact assessments, and cooperates with regulators and local data protection authorities.

• It is recommended that every organization have a DPO.
• Public authorities and organizations whose business model requires large scale processing of personal data are obliged to have a DPO.

GDPR is about handing control of personal data back to citizens. This is achieved through the provision of a series of rights that all citizens may exercise.

Right to consult

Data subjects have the right to see what personal data your organization has about them.

• They have a right to know how long you plan to store their information and the reason for keeping it.
• In response to a request from a data subject, you must send them a copy of the personal data you hold for free, but you may charge a reasonable fee for subsequent copies.
• You must comply with such requests within a month.
• Data must be sent in a commonly readable format (e.g., a spreadsheet).
• Data subjects can ask for data to be sent to a third party they designate, which may even be a competing business of yours.

Data accuracy

Keep data up to date by putting a data quality process in place and make it easy for data subjects to view and update their personal information for accuracy and completeness.

Right to forget

When consent is the legal basis of processing, citizens have the right to ask you to delete all the personal data you have about them.

• You must honor their request within a month.
• Grounds to deny the request include the exercise of freedom of speech or compliance with another legal obligation (e.g., salary data must be conserved for 10 years in some Swiss cantons).

Another approach to understanding the GDPR, and later FADP, is to consider how these laws impact on core activities that all organizations encounter.

Your company will hire new people and publish job announcements on the Web in the hope of receiving CVs.

There are many interesting aspects about this activity:

• A CV will contain much personal data of the candidate: name, age, address, sex, education record, former employment, potential situation of health and handicap, driving license if the job requires mobility, etc.
• A CV can contain personal information of people other than the candidate, like the names and phone numbers of references and former employers.
• The employer may desire to share candidate information with other organizations, e.g., judicial authorities to know if the candidate has a criminal record. This means that the hiring company may collect more information about the candidate than the candidate includes in his CV.

Your organization must take the following steps:

• Ensure that only people who need to process CVs (HR department) or who take decisions about hiring (supervisors, etc.) have access to a CV.
• The Web portal through which candidates upload CVs should contain a privacy policy.
• Special category information like religion, health, or political beliefs may never be shared.
• CVs of unsuccessful candidates should be deleted after the hiring process. If you wish to retain the CV of an unsuccessful candidate for a period after the hiring decision has been made, in case another position becomes available, then the candidate must give his explicit consent.

Managing prospect and customer data is essential to a company’s business.

Before the organization begins its privacy compliance journey, it must handle its existing customer databases. If these customer data were entered without explicit consent, then you cannot keep these data.

Many organizations use CRM software for this purpose, and today such software must help the organization be compliant to GDPR. For instance, the CRM should record all consent choices, provide a means for customers to update or withdraw consent and permit responses to subject access requests (where the customer asks for a copy of his or her personal data). The customer must understand how personal data is processed and how it is protected.

Often customer relations begin with the exchange of business cards. After receiving the business card, before you enter the client’s contact data into a system, you must ask that client by email if he consents to this. The physical exchange of a business card is not enough to indicate explicit consent, principally because there is no auditable trace of consent being given.

Onboarding is a special kind of business relationship. It refers to the activities necessary to turn a prospect into a customer. In the finance domain, onboarding requires due diligence, identification, and verification. For wealthy clients for instance, anti-money laundering (AML) and Know-Your-Customer (KYC) checks must be made which entails collecting data relating to the prospect’s nationality and origin of wealth. If your organization makes these checks, then you could consider such processing as a “legal obligation” that justifies processing of this personal data without explicit consent.

Finally, note that profiling prospective clients is another form of processing.

Marketing emails remain a popular means of advertising your company products today.

Be aware that cold emailing is a form of processing under the GDPR, and it is only allowed if either the data subject has consented, or there is another legal basis. An example of the latter is a justified interest by the company for sending these mails; this can happen in the context of a B2B relation. Profiling prospective clients is another form of processing.

To become compliant with respect to mailing lists, a good place to start is with an audit of your current email database. It is important to understand how you acquired the current emails. Current data practices should be disclosed (in the marketing emails for instance) and your organization must ensure that there is "freely given, specific, informed, and unambiguous" consent from all email receivers. Guidelines for obtaining consent include:

• Get consent from an opt-in, not pre-ticked boxes on Web forms.
• Keep consent requests separate from other terms & conditions. If subscribing to a newsletter is required to download a whitepaper, for example, then that consent is not freely given.
• Make it easy for people to withdraw consent - and tell them how to do it.

Question: should your company purchase a list of email addresses (under the GDPR)?
Probably not!

Your company may be a client of a cloud service provider, be these services IaaS, PaaS, or SaaS.

Cloud Service Provider

Cloud providers can demonstrate compliance with security in several ways: through a Data Protection Impact Assessment (DPIA) or by being ISO 27001 certified.

Company websites frequently offer services like white papers or proprietary content which users only have access to if they enter names or email addresses. Companies have used this practice in the past to build their mailing list. The practice is still possible, but it must comply with the GDPR.

The first step to make a website GDPR compliant is to publish a privacy policy on the site’s pages. The policy should clearly explain what data is being collected and what this data is used for. The website policy must also make it clear how a person may contact someone in the organization with a request to see his or her personal data or to have it erased – formally called a subject access request (SAR) under the GDPR.

The website must be built using secure technologies. Indeed, several companies have been fined under the GDPR for collecting personal data through insecure websites. Among the measures that website owners are now expected to implement are i) use https instead of plain http, ii) use strong authentication methods for access to the database behind the website, and iii) ensure that the website software is kept up to date with the latest versions.

When websites do collect personal data, user consent must be sought for this. Consent forms on a web page must not be pre-ticked, meaning that the default option for a user is not to consent. Several consent options are possible, such as one consent option for receiving a newsletter and a second option for receiving marketing information.

A well-known issue for websites is cookies. A cookie is a small file that websites send to client Web browsers, and which browsers can send back to websites so that the site remembers users. Among the classes of cookies, we find:

• Authentication or session cookies. These allow browsers to remain “logged in” when the user returns to a website after having logged in earlier. Without these cookies, it would not be possible to implement features like shopping carts on e-commerce sites.
• Layout cookies. These handle user layout and presentation preferences. For instance, when a user returns to the website, he finds the same language and layout preferences that he chose on his first visit to the site.
• Analytics cookies. These are used to track the behavior of users on a site, e.g., to record the number of visits, type of device used to visit site (mobile or desktop, Windows, or Linux, …).
• Advertising cookies. These cookies record user characteristics such as age and location. They are used by marketeers to customize advertisements presented to users when they visit the site.

Most forms of cookie are considered privacy-invasive, and a website that uses these cookies must ask for explicit permission and must even offer the option to users of surfing the site with cookies disabled.

The new Swiss data protection law came into effect on September 1st, 2023. The FADP is very similar to the GDPR for two reasons:

1. The GDPR has become a standard for privacy laws across the world.
2. Switzerland is now on the list of countries that the EU considers as having adequate data protection measures. Not being on the list, as was the case prior to January 2024, was prejudicial to Swiss cloud providers, so a law that resembles the GDPR was needed to get Switzerland back on this list.

Though similar, there are some minor differences in the FADP. For instance:

• Biometric and genetic data is included in the categories of sensitive personal data.
• The maximum fine for an FADP violation is 250 kCHF – compared to up to 20 MEUR for a violation of the GDPR. Also, the FADP calls for a person in the organization to be fined, rather than the organization itself.
• A potential data leak must be declared “as soon as possible” under the FADP; the GDPR requires a leak to be declared within 72 hours.
• A data protection officer (called an adviser under the FADP) is not mandatory for the FADP – though it remains highly recommended in practice.

Despite the FADP text appearing les strict than the GDPR, it remains to be seen how strictly the authorities will enforce the law. For instance, if an organization fails to report a data leak within 72 hours, it is possible that a court will consider this a failure to declare the leak “as soon as possible”.