Playing It Smart for Data Controllers and Processors
Lots of people have been asking me lately about managing vendor relationships with General Data Protection Regulation (GDPR) in the mix. I tell them to think about watching a group of kids playing a board game where the kids have come up with their own rules. Those kids are having a great time until an adult steps in and tells them they need to play by the rules that came in the box.
At first, there’s going to be lots of frustration. Some kids may throw tantrums and leave the game, but others will decide to figure out how the rules change things. In the end, there’s a good chance they agree that the new rules actually make the game more fun. Even the kids who walked away are likely to end up rejoining. And then they all live happily ever after.
Of course, in real life, nothing is ever that simple.
So, when it comes to GDPR, how do we change the game midplay and deal with new obligations regarding controller and processor governance?
Defining the Roles of Data Controllers and Processors
Let’s start by defining what GDPR means when it refers to data controllers and processors:
- A controller is “the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data.”
- A processor is “a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller.”
For example, a department store (controller) collects the data of its customers when they make purchases, while another organization (processor) stores, digitizes and catalogs all the information produced by the department store. The processors can be data centers or document management companies, but both the controller and the processor are responsible for handling the personal data of the store’s customers.
In the pre-GDPR world, European Union (EU) data protection responsibilities were outlined in the Data Protection Directive (officially Directive 95/46/EC), and controllers were responsible for compliance. Now, however, both data controllers and data processors have a shared level of responsibility and duty. They need to be in sync about what personal data is transferred and how it’s transferred, processed (respective of all active data subject rights and choices) and reported (providing accountability, access control and incident breach reporting). That means managing your entire data supply chain, regardless of where in the world the data processors and other parties are located. And there’s one more thing: Now you’ll likely need to have a contract in place unless the controller and processor are part of the same organization.
Developing a GDPR Governance Plan
Given all these changes, here are some things to keep in mind when you’re deciding how to develop your controller and processor governance plan.
Cover the Basics
Start with some basic rules. In general, you should consider three stages for your vendor compliance program: contractual readiness, ongoing governance, and compliance and audit. Contractual readiness entails enhancing your contractual relationship with your vendor in accordance with the tougher provisions of the GDPR statutes. Ongoing governance means enhancing your vendor prequalification and onboarding programs. And when it comes to compliance and auditing, consider which tools and processes you’ll need to implement to ensure your vendors are meeting their obligations and providing audit trails where necessary.
Classify Vendors by Risk Level
Take a time-out to create buckets so you can classify your vendors according to categories and their potential level of risk. You might want to consider what kind of data they collect, manage or process, the type and volume of processing involved and where that data is going to end up. It’s possible that you’ll need to take these steps more than once for a single vendor. For example, you could have multiple types of relationships with the same vendor, who might be providing both support and development — or even hosting.
Contact Your Vendors
Decide how you plan to contact vendors and which contracts you’re likely to put in place. If you’re a processor, you may want to reach out to your data controllers to get the ball rolling if they haven’t already done so.
Define Your TOMs
Bring your buddy TOM into the game. As you may recall from our earlier blog posts, TOM stands for technical and organizational measures. These are the uniform practices and standards you should require your vendors to adopt. If you’re a controller, be sure to have your TOMs well-defined and identify the specific controls you need. And if you’re a processor, take the time to assess your current contracts and any existing controls that could help meet these new obligations. It’s all good preparation for vendor discussions.
If you’re a controller, you should create a formal communication plan for contacting vendors. For example, you could launch a mass mailing that sets out the new contract, terms and TOMs. Then confirm that the documents were received by the right individual and track your progress until you’ve succeeded in reaching everyone on your list.
Processors should review the new controls with everyone on their team, including the appropriate IT and security people. You should also perform a gap analysis and create an implementation plan that includes monitoring and reporting. Anticipate — and prepare for — controller audits and complaints from controllers or the Data Protection Authority (the GDPR-designated regulator).
As a controller, be aware that your smaller vendors may not even know about GDPR — so don’t assume otherwise. Consider providing some of the same training that you gave your employees. You’ll also want to educate your vendor management team, along with your marketing, human resources and product development groups. They often have greater insight into the nature of the supplier relationships, the types of data being handled and the relative maturity of the vendor. And that can help determine how you work with your vendors and handle any issues that may arise.
Document Your Moves
Create a central supplier lookup repository to help you gain visibility into your vendors. It should provide details about who has been notified, signed a contract, completed education and who has been audited. It should also include information about any exceptions that need to be addressed. And if you’re a controller, your repository should also provide a link into your data mapping repository, since Article 30 of GDPR requires that you identify both those processors who work with personal data and any additional vendors that may be involved.
Stay in the Game
If you’re a controller, you should specify the types of audits you’re planning to conduct, how frequently you plan to conduct them and how you’re going to track your progress. And you need to figure out how you’ll deal with vendors who aren’t meeting their obligations. Meanwhile, if you’re a processor, you need to determine who’s going to handle your audits.
In conclusion, vendor management requires an ongoing vendor governance and compliance program.
Notice: Clients are responsible for ensuring their own compliance with various laws and regulations, including GDPR. IBM does not provide legal advice and does not represent or warrant that its services or products will ensure that clients are in compliance with any law or regulation. Learn more about IBM’s own GDPR readiness journey and our GDPR capabilities and offerings to support your compliance journey here.