Now that Adam Nelson has walked you through the Assess phase of the IBM Security General Data Protection Regulation (GDPR) framework in our previous blog post, I’m here to talk about what comes next: the Design phase. Because if the Assess phase represents the concept of what you need to do, the Design phase is where you need to determine how you’re going to do it.
I’m always fascinated by the different ways in which people react to the term “design.” Some see it as an opportunity to start dreaming up new ideas. Just thinking about the possibilities makes them want to jump in with both feet. Others start by asking lots of questions about form and function. They think of design as an exercise in problem-solving. And then there are those who are truly daunted by the prospect of designing anything at all. All those choices and decisions are just too overwhelming.
The truth is there’s no best way to design your approach to GDPR readiness. But there are some best practices you should be thinking about.
Balancing Risk and Business Objectives
Let’s start by recognizing that the way you design your organization’s GDPR readiness plan should reflect your specific needs and your overall situation. It should outline a strategy that balances risks and business objectives. And it should provide a detailed plan for dealing with what you learned during the Assess phase.
For example, your assessment should have identified the specific controls you already have in place. Now it’s time to determine whether you can adapt what’s there or need to create something new. That’s what the Design phase is all about: deciding how you’re going to move from your current state of GDPR readiness to a more mature state of readiness.
Making Tough Decisions
You may need to take a deeper look at what’s required to execute the plan you’re designing. There’s no sugarcoating the fact that designing your GDPR program may force you to make some difficult decisions regarding the investments and resources necessary to operationalize it. That’s especially true when you’re looking at things such as data access rights, vendor management, employee access and encryption policies.
Getting to a clear perspective on the needs and trade-offs can be challenging. That can be especially true when it’s the legal and/or compliance teams that are taking on the job of completing the GDPR readiness. They’re the ones reading the regulation, looking at the requirements and determining where there are gaps between what you’re currently doing and what GDPR wants you to do. And while they’re clearly good at understanding the law and its implications, they may not be in the best position to understand the technology — or the resources — required to make the changes they’re recommending.
So while your assessment may point out that you need to tweak the way you’re currently handling something such as an encryption policy, for example, you know there are multiple systems involved in that process — meaning it could actually take multiple people and many months to get it done. And that’s especially true if you’re planning to automate your processes instead of doing things manually. In other words, you may need to decide whether it’s better to make a quick change right away or invest the resources needed to revamp the process completely.
Asking the Right Questions About GDPR
Make sure you’re paying enough attention to the details and asking the right questions. GDPR has explicit rules for incident response, for example. That could be a huge undertaking, since GDPR requires that you notify regulators of a breach within 72 hours — and that you may have to notify data subjects as soon as possible. How will you plan for that? Can you automate it? Should you?
Then there’s the issue of vendor management. GDPR says you’ve got to do it, but how? How will you determine whether a vendor is following the rules as a data processor? These are among the most difficult decisions that GDPR calls on you to make.
And let’s not forget about the right to erasure. Have you thought about what could be involved in truly eliminating someone’s data from all your records? How many times have those files been copied and where are they now? This could end up being one of your biggest challenges.
Privacy and Security By Design
Think about the concept of privacy and security by design. That means building privacy and security components into everything you do from the very beginning. If you’re not already doing it — and many organizations aren’t — you should be.
Start with the approval process, from inception to budget approval. Figure out who’s going to do the work and how you’re going to weave it into the project management office function or its equivalent, if you have one. Or will you need to create new project management approval processes that include privacy and security checks? How will you ensure that basic processes and policies are put in place? How will you prove the work has been done? You can have great playbooks and guidelines, but you need to show that you’re following them as part of your project management process.
There are plenty of ways to do it. It can be as simple as a sign-off document that shows processes were followed. Or you can institute a design review panel. It all depends on the size of your organization and the size of your budget. And, like most GDPR-related decisions, it will ultimately be determined by what you’ve got and what you need.
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.