When does the GDPR apply?

The GDPR applies when public or private organization process personal data. These assume one of two distinct roles, either as a data controllers and data processors. When discussing role distribution in supplier or customer relationships, we label one or the other as data controller or processor, respectively. However, one logically determines this at the level of a single processing activity.

The law is extremely clear about the territoriality, targeting and offering of goods and services. Thus, the GDPR applies to your non-EU company if: 

1. you establish a company or a subsidiary in the EU.
   No matter your product or service, your employees are people too and their data is protected by law. This places you under data controller obligations.
2. you provide goods and services (for a fee or not) to people in the EU.
   Since processing their personal data is a requirement to provide said goods and services, you are under data controller obligations.
3. you provide processing services (SaaS, PaaS) to a company to which the GDPR applies by virtue of the above points.
   The GDPR becomes applicable when handling personal data for a company established in the EU. In this case you likely assume data processor obligations.

Supplying services to end users

Beyond the letter of the law, your sales teams faces demanding questions from client procurement teams and end users alike. This is the case whether you offer B2B, B2B2C or B2C goods and services. Sales teams need to understand what procurement teams asked of them. At the very least, it communicates a sense of preparedness. In practice, they should only occasionally forward less obvious questions to the tech, product or legal teams.

Your internal or external data protection officer (DPO) or chief privacy officer (CPO) should sit comfortably astride legal and tech. If they do, have them train sales to reduce back and forth communication. These individuals see data processing from the technical perspective of data flows. Importantly, they understand risk from the perspective of risk to the data subject.

Leveraging privacy

Being able to address data subject requests (DSRs) in a timely manner, ensures you remain a contender in your client’s procurement shortlist. Some clients operate in a highly regulated field so compliance is crucial to them. Others show high ethical drive and understand non compliance as a risk to their operations. For clients who don’t care, your common relationship will deteriorate at the first privacy pinch from data subject requests. Pressure will come from their own vertical relationships in the supply chain, or enquiries by supervisory authorities.

If your business enjoys a direct relationship with people in the EU, you likely assume a data controller role. This is the case with the provision of B2C goods and services. The full requirements of transparency, security and accountability apply, so do the performance of data subject rights. Subjects are savvier now about exercising their rights. You can expect their privacy experience with you to make it onto social media if they don’t trust your practices.

Supplying services to other organizations

When supplying SaaS or PaaS solutions, the B2B / B2B2C scenario likely makes you a data processor. The requirements for security and accountability apply to both controllers and processors. Yet, transparency obligations are fulfilled by the data controller. This is done through their own channels or via a notice your platform allows them to provide to their end-users. However, your ability to be forthcoming with demonstrations immediately satisfy your customers’ expectation that you are set up to help them demonstrate how they comply.

Transparency is not the only obligation you will help your customer fulfil. Say you provide a platform that corporate customers can use to create user retail experiences. They remain responsible for collecting proof of consent to the data processing resulting from triggering your platform features (e.g. shopping cart memory or reward schemes). Your platform being the front-end of user interaction for your customers, ask yourself whether your platform

• provides your customers with consent collection mechanisms, collecting proof of consent and allowing for user revocation of consent;
• provides APIs to push data from your platform to your customer’s ERP, therefore triggering data transfers and access right management;
• helps generate records of processing activities that satisfy GDPR Article 30 requirements;
• helps generate a privacy notice based on the factual data processing caused by the user’s choice of features.

Engaging a non-compliant SaaS solution remains the data controller’s statutory responsibility. Yet remember that their DPO and legal counsels can be powerful show-stoppers when signing procurement contracts. No one appreciates manual work, much less when it involves getting it from the less responsive solutions providers out there.

Are employees people too?

You bet they are. Tunnel vision is frequent when focusing on exporting your product. Yet, when setting up a subsidiary to manage staff locally or remotely contracting staff in the EU, the data you process about them for employment and project management purposes is subject to regulation. Job boards and recruiting agencies allow you to tap into talent but the nature of the services you use may vary. Yet your obligations on the underlying data remain those of transparency, lawfulness and retention.

When onboarding and during the employment lifecycle, employees yield and generate tons of personal data. Some of that data may be highly sensitive, such as that associated with sick leave and disabilities. Remember that your HR systems may not be contracted in the EU and likely plug into other tools. That is often the case with payroll management, training and employee development. As you would expect, this tool landscape comes with additional challenges for complex organizations sharing services across multiple jurisdictions. Due diligence should take place before onboarding a tool and continuously while feature testing.

What about applicants?

No evidence suggests that merely looking at profiles on LinkedIn triggers GDPR obligations. The GDPR refers to that data as publicly available. However, the moment you make use of a third party tool or structure information, requirements are triggered. This customarily takes the form using spreadsheet trackers for driving applicants through a conversion funnel or sharing them for assessment. Not all applicant tracking software is created equal. Identifying a supplier based in the EU does not guarantee that its compliance is up to par. At the very least, you should expect them to know what compliance you need their solution to offer. 

Don’t take their word for it, challenge their assertions and document their response.

What does it take for non-EU companies to become compliant?

How is compliance defined and measured?

At its heart, compliance is about developing and maintaining the ability to demonstrate awareness of risk and risk control. Note that in data protection we do not measure risk in financial terms, nor in terms of corporate reputation. We see privacy risk through the lens of impact to the data subject. However, whether you rely on staff that is good at understanding ISO norms or legal officers good at interpreting legal provisions, your compliance essentially relies on whether your product owners understand:

• what data they need (data);
• what they are doing with it (purpose);
• to whom they have provided access to -e.g. through APIs- (recipients);
• where it comes from (source & confidentiality),
• how they legitimize its handling (legal basis), and
• what rights can be exercised against that data (DSRs).

This inventory is not established in a week. Not unless employees actually speak to one another and have nothing else on their plate. Needless to say, the inventory is never perfect. Worse, it is often erected on erroneous assumptions. For instance, ruling too quick on what is not personal data or failing to register the implementation of an API as triggering a processing activity. Have you ever had an awkward discussions with partner procurement teams?

For organizations making use of the ISO27001 security management cookbook. The 27701 extension is the cherry on top to help demonstrate, to customers and authorities, the organization is serious about compliance. Serious enough that it allows a third party to independently audit its compliance management system (ISMS and PIMS respectively). 

What do you need in order to demonstrate compliance?

You’ll need Records of Processing Activities (RoPA) to start with. That will put everyone on the same page; from your tech teams, to your legal teams, your product owners, your sales and procurement teams. It will allow you to update your privacy notices, enter (and exit!) sales discussions comfortably. You’ll need to review all your 3rd party contracts to identify where Data Processing Agreements (DPAs) and international transfer mechanisms are missing. You may also need to perform impact assessments based on whether your activity is blacklisted.

You might need to drop vendors with appalling documentation or those refusing to provide it. For instance, consent management platforms will lur your into thinking you don’t process personal data. If you are not willing to change suppliers, then maintain a list of vendors to deprecate for compliance issues and communicate it to upper management. You’ll need robust security documentation, and a fair share of training and awareness raising at all levels of the organization. Perhaps least discussed but most wanted on your compliance journey, is an organizational appetite for change management.

Much like that of ISO27001, whether your company is EU or non-EU-based, what helps you demonstrate GDPR compliance is the amount of available, relevant, readable, useful [and used !] documentation that demonstrate accountability. Compliance and product teams are already getting creative with MS copilot, allowing it to read through emails, repositories and spreadsheets. Are your ready to let an algorithm adjudicate on your company’s compliance and leave you none the wiser? AI is likely to become an audit support tool in first and second party audits. It is however unlikely to replace the auditor’s judgement and decisional independence any time soon for third party audits that rely on market-leading certification bodies.

The post Embracing the GDPR as a non-EU company appeared first on TechGDPR.

Cold calling individuals is like throwing a rock in a pond with the hope of catching a fish. Obviously, the success rate is high enough to justify manning the phone with a single person all the way up to outsourcing a floor’s worth of call center advisers. But how can you continue making cold calls when you have purchased personal data?

With lots being said about the GDPR signalling death of sales and marketing as we know it, it’s hard to make sense of how much room remains for your organisation to call up an unsuspecting prospect in a compliant way. While you can’t avoid raising suspicion as to where the data subject’s number originated from, there is a wide spectrum of practices ranging from downright non-compliance data collection to the fully-fulfilled duty to inform. Though it is limiting to approach the Regulation with a single use case it remains the best way to avoid opening the floodgates to exceptions. For the purposes of this post, I’ll cite the following example:

Can personal data be sold and bought under the GDPR?

Inheriting personal data sets from a third party with no proper documentation (e.g.: legal basis for initial collection, records of the duty to inform being fulfilled by the initial controller, recorded consent or readily available consent matrix) is a liability for both the personal data broker and the purchaser. At the very least, records of processing activities should establish a trace of the transaction since personal data sold to a third party is a data transfer to a recipient. Additionally, your organisation will need to prove that subjects were informed this transfer would take place or that you informed them within a month of purchasing their personal data that your organisation now processes it. More on this further on. 

Failing to document what information was communicated and what legal base apply violates both the data protection principles of lawfulness and transparency and that of purpose limitation, exposing you to the heaviest of fines: 4% of annual turnover. If your organisation had purchased personal data from a third party source, don’t hide that information. Should your staff turn down a data subject request to know what the origin of that data is, make sure the staff has been trained to recognize the request as a genuine data subject request. Article 14.2.f) makes it compulsory for organisations to inform data subjects if requested as to the source of the data that was not collected from them directly.

The worst scenario on your call-center floor is for an agent to downplay that request and respond that the subject’s phone number was communicated by their line manager. You may need to review your processes, knowledge base and staff training as to how to handle data subject requests. You would be surprised how many people use built-in or third party app call recorders on their phones

While you can sell and purchase personal data, you have to be very clear about it. Unlike the CCPA, the GDPR does not make it a requirement to disclose that the data will be sold, instead it makes it a requirement to disclose who will be receiving it.

In that respect, the CCPA more explicitly acknowledges the commercial uses of personal data. It makes it a requirement to disclose such uses, to provide subjects to opt their data out of the sale. To that respect, it allows for slightly more traceability in the data supply chain than the GDPR does. Keep in mind that small print at the end of a 10-page privacy policy will not impress authorities. Requirements of concision and clarity can be found in Article 12.1.

Can our organisation cold call data subjects?

Yes, it can.

Central to data protection is your duty to inform. Fulfilling it puts your organisation in line with GDPR’s principle of lawfulness, fairness and transparency (GDPR Art.5.1).

It is likely that the applicable legal basis for processing personal data in your case is legitimate interest. Yet having determined an applicable legal base is not compliant unless the purpose and the legal base are formally communicated to the data subject.

Can data subjects refuse to be the target of your direct marketing?

Yes, under Article 21.1 of the GDPR, an individual has the Right to Object. While, typically this right designed to put the burden of proof on the controller that its processing of personal data is done in the controller’s legitimate interest, the data subject also has the right to outright object to the use of data for direct marketing. This means that your company will have to mark the personal contact data to prevent it from being used for that purpose. This is one of the only technical and organisational measures explicited in the GDPR. Apply it if the data is nonetheless required to serve other purposes such as the performance of a contract. Should the data serve no other purpose, the best practice principles of data minimization and purpose limitation dictate the complete deletion of the personal data.

As hinted above, do not expect the data subject to officially formulate a deletion or objection request via your data protection officer. Treat their request on the phone as officially as you can. Which naturally increases expectation on staff compliance training.

Must I perform my duty to inform during the call?

Where the CCPA does not makes it compulsory for organisations to disclose having transferred or sold their data unless the subject requests to know, the GDPR makes it a requirement to inform proactively about the transfer of personal data to a third party or recipient.

While a strict reading of the GDPR might lead you to believe that you should read your complete privacy policy on the phone, in reality the situation is not that extreme but needs to be broken down at little.

If, prior to the call, you have collected the contact information from the data subject, you will have already informed them, and collected consent (if such is your legal basis), on the purpose of processing. On the call itself, you might be inclined to remind the data subject of the legal base on which you are currently operating but there is no GDPR provision making this a requirement other than building trust and plain courtesy.

If you have not collected data from the data subject but amassed their contact details from a different source, or third party, then, you should inform data subjects of your full identity and contact details, what data you have collected, under what legal base(s) you have done so, what retention period governs that data processing and what rights the data subjects can exercise. GDPR. Art.14.3a) sets the duty to inform time frame to within a reasonable period after obtaining the personal data and no more than one month.

Should you place a call to the data subject before having informed them of the above, you should understandably be prepared to read this information out to them and facilitate the exercise of their data subject rights (GDPR Art.12).

A full list of elements your communication should include is available in Articles 12 to 14.

What if the data subject actually consents to their data being used when on call?

Technically, you could record the call to document consent but consent for that form of data collection -audio recording- would first be needed. Recording a call is nothing short of collecting biometric and personal data and, in many cases, transferring that data to servers or cloud services across the Atlantic. If your cloud provider is not listed under the EU-US / Swiss-US Privacy Shield and no other legal instrument allows for that transfer, the call recording would fail the compliance test on many levels.

A best practice often witnessed involves sending an opt-in email immediately after the call which recaps the essence of your phone conversation, what you agreed to share, the data the subject consented to disclosing and which were the purposes stated. You might want to consider including the date at which the conversation took place in the body of the text, i.e.: not relying on the email client’s automated time stamp.

Yes, your organisation can sell or purchase persona data and place cold calls.

The GDPR only prohibits both forms of personal data processing unless they are done unlawfully.
Unlawful data processing in the case of direct unsolicited marketing by phone is characterized by depriving data subjects of their rights, violating data protection principles of fairness, transparency and accountability, failing to inform them upon acquisition or collection of their data, depriving them of information when you first come in contact with a subject’s personal data and not supporting them in the exercise of their rights. If you have these items under control, you’re good to proceed with a fair degree of confidence in your compliance.

If you need help with reviewing your data protection practices, your data flows, your compliance documentation and call center staff or management training, get in touch.

TechGDPR specialises in digitised environments and products including AI, machine-to-machine / IoT transactions and Blockchain applications. We offer consulting packages, hourly support, staff training and workshops.

The post Personal data and cold calling under the GDPR appeared first on TechGDPR.