6 years after becoming enforceable, the GDPR has not died out in popularity as a conversation topic among board members. While is remains the elephant in the room for many a stakeholder, non-EU companies who have embraced its application and requirements are finding it much easier to remain contenders on the European market. This article How can non-EU companies get started complying with a regulation they believe does not apply to them?
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:
- 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. - 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. - 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.