Why It’s So Hard to Design Something Simple
In our previous blog post, Adam Nelson and I suggested that you set aside time with other people in your organization and familiarize yourselves with General Data Protection Regulation (GDPR) and its requirements. Have you done that yet? Don’t be embarrassed to admit that you haven’t. Because either way, there’s a good chance you’ve already figured out that those requirements can get pretty complicated.
That’s what I was thinking last year when we set out to find a way to help organizations like yours understand what GDPR is all about. I’ve got to be honest here. After reading the 261 pages of regulations over and over and consulting numerous legal writings, it didn’t take long for me to realize that there was nothing simple about it.
Creating something simple can be incredibly difficult. No news there, right? It’s rumored that over 500 years ago, Leonardo da Vinci observed that “simplicity is the ultimate sophistication.”
For starters, while the regulation has a lot to say about what you need to do, it doesn’t tell you how to do any of those things. So I started doing my homework. I consulted with numerous colleagues. I read reports, explored use cases, shared ideas, and we argued with one another (just a little).
All along, I held onto the idea that whatever we created had to be simple. That meant no complicated, multidimensional matrices or giant reference architecture charts no one could understand. In the end, we agreed there would be no lists of what to do or what to buy to become GDPR-ready, because no one product could possibly do that.
A Simple Framework for Your GDPR Journey
Instead, I returned to the idea of keeping things simple. I preached it over and over. After at least a dozen iterations, I finally came to develop a five-phase framework that addresses both privacy and security, approaching GDPR as a journey on which some organizations might be just starting, while others would be further along. We also decided that this wouldn’t be meant as a readiness assessment checklist. And we didn’t want it to focus exclusively on IBM.
The framework acknowledges that every organization will have its own needs to consider. We also knew from the outset that no two organizations would likely be starting at the same place. Its simplicity allows you to “jump in” at whichever point is appropriate for you.
Where do you begin? That’s a question we asked ourselves more than once. In fact, we found ourselves asking it a lot. The first thing we decided was that each of the framework’s five phases had to address both privacy and security issues — because GDPR requires organizations to ensure both. And right there, things got complicated, since it can sometimes be hard to distinguish between the two.
So we needed to nail down the definitions. Here’s the result: Privacy is all about the policies and practices that dictate what data you collect and why you manage, share, process and move it around. And security is all about how you control and protect that data. Here’s another way to think about it: You can have security without privacy, but you can’t have privacy without security.
Looking at the five phases of the IBM GDPR security framework, it’s pretty easy to see how all the pieces fit together. But I can assure you that there was a lot of discussion about what should happen when and where. So we began at what logic told us was the beginning.
In Phase 1, you assess your situation. You figure out which of the data you collect and store is covered by GDPR regulations, and then you plot a course to discover it.
Phase 2 is where you design your approach. You need to come up with a solid plan for data collection, use and storage. And you need to develop an architecture and strategy that will balance risks and business objectives.
Your goal in Phase 3 is to transform your practices, understanding that the data you deem valuable to your organization is equally valuable to the people it represents. This is where you need to develop a sustainable privacy compliance program, implement security and governance controls (TOMs — Technical and Organizational Measures) and potentially appoint a Data Protection Officer.
By the time you get to Phase 4, you’re ready to operate your program. Now you’re continually inspecting your data, monitoring personal data access, testing your security, using privacy and security by design principles and purging unneeded data.
And Phase 5 — the final phase — is where you’re ready to conform with the necessary GDPR requirements. Now you’re fulfilling data subject requests for access, correction, erasure and transfer. You’re also prepared for audits with documentation of your activities and ready to inform regulators and data subjects in the event of a data breach.
A Direct Approach to GDPR Readiness
The good news is that, since I created the framework, we have adopted and expanded it to create the overall IBM GDPR Framework, which adds further details such as a simplified capability architecture that includes information governance and a set of pathways to help you get started across your organization.
So there you have it: a direct approach to GDPR readiness. The journey itself may not always be easy, but the path should be clearer. Yes, there’s a lot going on in each of those five phases. And yes, you may need help along the way. But that’s what we’re here to offer. Learn more about how IBM Security can help you navigate the journey to GDPR readiness here.
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.