It’s one thing to say you’re privacy compliant, but quite another to actually be privacy compliant. And no place is this more apparent – or more challenging – than when contemplating privacy in legacy IT systems. And that’s 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’ve learned is that privacy regulators are very willing to hand out big – really big – fines and penalties for privacy violations. So all those mountains of personal data residing who knows where in your IT environment pose a serious risk to your organization that’s only going to grow.
Legacy Systems are Rarely Orderly
Privacy compliance assumes a great many things – that personal information (PI) is in distinct, manageable siloes, that the siloes can be managed on the basis of both jurisdiction and data type, and even that data relating to a particular individual can be identified, segregated and managed uniquely. And of course, that you can then apply some very granular rules to what is becoming an increasingly large number of very narrow data clusters. Under the best of circumstances, that’s all a big ask, but in the case of legacy systems, it’s often an impossible ask.
The systems were not designed to achieve this sort of compliance to begin with, and in virtually all cases, the data structuring and data input was done in a way that did not contemplate this sort of compliance scenario, so the data is hopelessly comingled, poorly identified and otherwise not well organized for privacy management. And when you’re dealing with a large-scale IT environment that can contain hundred or thousands of legacy systems, the situation becomes problematic indeed – there may not even be any sound institutional knowledge of what data is in what systems, much less detailed information about how the data is structured and segregated, and what metadata and other characteristics it may have. The result is often that the organization is not even close to being privacy compliant, and has no real strategy for becoming compliant in its legacy IT environment.
Fortunately, it’s possible to remediate this situation, at least partially. And partial is far better than none – regulators base the size of fines and other penalties in part on their judgment of how seriously the organization is taking the problem and what steps it has taken to remediate things, so any positive step you take will yield some value. So where do you begin?
Assess the Information Siloes
To begin with, you need some sort of inventory of your IT assets – what systems and repositories contain personal information, and what specific kinds of personal information are in each repository or system. That may be harder to come by than you might think – larger and decentralized organizations frequently lack institutional knowledge of just exactly what their own IT system really looks like. At the very least, you need a list of the major suspects and what’s likely to be in them that’s of interest.
Your next step is to prioritize. Some systems and repositories will have large amounts of PI, others not so much. And not all PI is created equal – things like personal financial information and personal medical information pose a much higher risk to the organization in the event of data breach, excessive retention or other noncompliance than do other kinds of PI. Money and other resources are always limited, so you want to intelligently direct your resources to the places where they will have the greatest effect, both in terms of actual compliance and in persuading regulators that you’re serious should you find yourself undergoing a privacy audit. And remember, not all systems are created equal either. There might be some low hanging fruit there in the form of a system that can be remediated quickly and on the cheap, and you don’t want to miss that opportunity to score a win.
Partner with IT for Remediation
Now you have to do some actual remediating. That’s where things get a little tougher. You begin with a platonic ideal of a compliance model – a retention schedule, policies on access restriction, and all the other things that, in an ideal world, you’d like an IT system to do by way of privacy management. Then, for each system, you have to determine how close you can get to that platonic ideal based on the characteristics of the system itself and the data that resides in it, budgets and other resource constraints, business needs and whatever other factors may be relevant. There’re probably going to be a tough negotiation here – you’re asking for a heavy lift from some IT folks that already have a very full plate, but you need them to get you as close to full compliance as is possible in the real world, so if they tell you it’s impossible, you need to push back.
But you also need to bear in mind that in most cases, a legacy system can’t be made fully compliant with your platonic ideal, so “as close as possible” is the operant term. The goal at the end of the day is to have, document and execute a “best achievable” strategy and outcome for each system or repository. That’s going to be your defense when the privacy regulator comes knocking at the door – “It’s not perfect, but it’s the best real-world outcome realistically available.” That will at least mitigate 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, as the case may be, and you’re done. But if it’s a few hundred or a few thousand, that won’t be for a while, which makes the prioritization all the more important – the high risk situations should command your immediate attention, and not get pushed down the road for years.
The Most Important Step is Getting Started
It is easy to be overwhelmed by the magnitude of the problem. Getting started an putting a plan in place is your most important step. First, because it establishes that your organization is seeking to address the problem. This alone goes helps reduce your risk. More importantly, you can achieve some significant results over time if you approach the issue systematically and eat the elephant one bite at a time. Eventually those bites will add up, and with every one you take, your risk goes down at least a little, and maybe a lot.
For more on legacy systems privacy mitigation, check out this recorded webcast: Privacy Program Remediation to Incorporate Legacy Systems
