It is one thing to say that you are in compliance with data protection regulations, but quite another to actually comply with data protection regulations. And nowhere is this more obvious – or more challenging – than when looking at data protection in older IT systems. This is a problem because legacy systems are not excluded from the requirements of laws like the California Consumer Privacy Act (CCPA) or the European General Data Privacy Regulation (GDPR). One thing we have learned is that data protection authorities are very willing to impose huge – really huge – fines and penalties for data breaches. All this mountains of personal data knowing where it is in your IT environment poses a serious risk to your business that will only grow.
Compliance with data protection regulations requires many things – that personal data (PI) are in separate, manageable silos, that the silos can be managed based on both jurisdiction and data type, and that even data that is on top of refer to a specific person identified, separated and clearly managed. And of course you can then apply some very detailed rules to an increasing number of very tight clusters of data. This is all a big question under the best of circumstances, but on legacy systems, it's often an impossible question.
The systems were initially not designed to achieve this type of conformance and in virtually all cases the data structuring and data entry was done in such a way that this type of conformance scenario was not considered so that the data is coming, poorly identified and hopeless otherwise not well organized for data protection management. And when you are dealing with a large IT environment that may contain hundreds or thousands of legacy systems, the situation becomes problematic indeed – there may not even be a solid institutional understanding of what data is in which systems let alone detailed information about how the data is structured and separated and what metadata and other characteristics it may have. The result is often that the organization is nowhere near privacy compliant and has no real strategy to get compliant in its old IT environment.
Fortunately, it is possible to at least partially remedy this situation. And partially is way better than none – regulators base the size of the fines and other penalties in part on their assessment of how seriously the organization is taking the problem and what steps it has taken to correct the problem. So every positive step you take is going to yield some value. Where do you start
First of all, you need some kind of inventory of your IT resources – which systems and repositories contain personal information and what specific types of personal information are in each repository or system. This may be harder to find than you might think – larger and decentralized companies often lack institutional knowledge of what their own IT system really looks like. At the very least, you need a list of prime suspects and what is likely to be in them that is of interest.
Your next step is prioritization. Some systems and repositories contain large amounts of PI, others less. And not all PI is created equal – things like personal financial information and personal medical information pose a much higher risk to the business if data is breached, over-retained, or otherwise non-compliant than other types of PI. Money and other resources are always limited, so you want to be smart about channeling your resources where they have the most impact, both in terms of actual compliance and how to convince regulators that you mean business when you do undergo a data protection review. And remember that not all systems are created equal. There may be low hanging fruit there in the form of a system that can be fixed quickly and cheaply, and you don't want to miss this opportunity to get a win.
Now you need to make some actual corrections. It gets a little more difficult here. You start with a platonic ideal of a compliance model – a retention plan, restricted access policies, and all the other things an IT system should do about data protection management in an ideal world. Then, for each system, you need to determine how close you can get to that platonic ideal, based on the characteristics of the system itself and the data it contains, budgets and other resource constraints, business needs and all other relevant factors. It's likely going to be a tough negotiation here – you're asking a heavy lift from some IT staff who already have a very full disk, but you need them to get you as close as possible to full conformance to world, So if they tell you it's impossible, you have to push back.
However, you must also take into account that in most cases a legacy system cannot be made fully compatible with your platonic ideal. Hence the operant term is "as close as possible". The goal at the end of the day is to have, document, and execute a "best possible" strategy and outcome for each system or repository. That will be your defense when the data protection officer knocks on the door – "It's not perfect, but it's the best realistic result realistically available." That will at least mitigate the penalties and may well serve to eliminate them entirely.
Repeat the above process a few dozen or a few hundred or a few thousand times and you are done. But if it's a few hundred or a few thousand, it'll take a while, which makes prioritization even more important – the high-risk situations should get your immediate attention and not be left on the streets for years.
It is easy to be overwhelmed by the size of the problem. Getting started creating a plan is your most important step. First, because it establishes that your organization is trying to address the problem. This alone will help reduce your risk. More importantly, if you systematically approach the problem and eat the elephants one bite at a time, you can get some significant results over time. Eventually these bites will add up, and with each one you take, your risk goes down at least a little, and maybe a lot.
For more information on data protection mitigation in legacy systems, see this recorded webcast: Correction of the data protection program to integrate legacy systems
