By Dave Cartwright, The Register
I spend a lot of time telling people that information security isn’t the IT department’s problem. And it’s not: everyone in the business is responsible for making his or her contribution to the security of the organisation’s information, and for protecting the personal data the organisation uses.
I can’t help thinking, though, that any day now there’s going to be a raft of requests landing in the IT people’s “to-do” lists. Because the EU’s General Data Protection Regulation (GDPR) is coming in May, and all the related events were attended by audiences almost uniformly comprised of business managers, compliance people and the like. That is, people who are responsible for operating and overseeing GDPR compliance. And they’re defining processes, asking colleagues what data they hold, and getting the company lawyer to update standard contract terms and write privacy notices. But they can’t really do all this stuff on their own.
Now, a surprising number of IT friends have commented to me lately that they’ve not been particularly troubled by GDPR preparations. I find this a bit puzzling, because in fact they’re precisely the people who can help with the process of becoming compliant (or, for that matter, demonstrating that you already are). Yes, the business types can tell the compliance people what type of data they use from day to day but it’s IT that provides a dump of the database schema and who gives a guaranteed-correct version, containing all the stuff the users forgot when they rattled off the list.
It’s the IT team, too, who have the unique access required to scan the various file stores – local hard disks and networked file shares – for the bazillion files of unstructured personal data that people have squirrelled away over the years in emails, spreadsheets, meeting minutes and the like. Why, then, have so many companies engaged business types to provide a best guess when the techies could just as easily provide incontrovertible facts?
Leaving aside the discovery phase, though, it’s even more important to be engaging the IT team ready for the operation of our data protection regime. Take subject access requests (SARs), for example: I bet you’ve hardly ever had one because nobody’s really been sufficiently bothered to spend the money and ask what data you hold about them.
Now, I don’t subscribe to the scaremongers’ theory that making a subject access request free of charge will suddenly provoke a tsunami of requests, but I do reckon you’ll see more than you’ve seen in the past – at least in the first weeks after GDPR comes into force.
While you could of course handle SARs manually on an individual basis, why not engage the technical team to help you out and perhaps script at least part of the exercise? If you can interrogate your core systems from a script – maybe through a database connection into Excel, even – the time and effort spent on SARs could be optimised.
The other thing you need to understand is whether there’s a gap between how you think you work and how you actually work. My favourite example here is backups: even though your backup strategy is documented, do you really understand how it’s implemented by the tech teams? How your disk-to-disk-to-tape setup really works? Who transports the tapes to offsite storage? Do you destroy tapes when you say you will? If you’ve erased someone’s data on request, does the tech team re-delete the data from the live system if they’ve had to restore from backup?
So, then, although data protection isn’t the IT department’s problem, IT does need to be centrally involved because, while the management and compliance types write the policies and procedures, its technical teams who are core to their implementation. In fact, getting them involved sooner rather than later can make compliance easier by providing you with the tools and data.
And the data aspect is important. Becoming compliant is one thing, but being able to quantify compliance is quite another. Anyone who’s read BS 10012 (Data protection – Specification for a personal information management system) will be familiar with clause 9.1, which is all about “monitoring, measurement, analysis and evaluation”.
When it comes to a breach (or a suspected breach, for that matter) the ability to quantify the damage is essential – and being able to show the authorities precisely what was accessed, by whom, and when will tangibly reduce the sanctions they impose on you. And even when you’re operating normally, it’s refreshing to be able to know – and to demonstrate to the board – that you’re operating normally and that you can prove it.
Much of this means basic stuff like turning up the system logs and perhaps using a SIEM-like setup to collate and report on them, but equally I’d like to see you implementing stuff like Data Leakage Prevention to monitor all the data flying in and out of the business and spotting stuff that shouldn’t be crossing the border between you and the rest of the world.
Techie involvement in the GDPR process is absolutely crucial, then. And by that I mean real, hands-on techies – the day-to-day system managers, email administrators, desktop support people and so on – as opposed to simply the IT manager or the CIO. These are the individuals who know the systems, who see the users from day to day, who have a feel for all the wacko non-standard stuff that’s scattered around the organisation’s technology world.
If you’re a non-techie doing a GDPR implementation, then, ask yourself whether you’ve involved the people at the IT coalface enough. You’ve written new policies about data retention and disposal, but can they be implemented with the technologies you use? You’ve produced a register of the data you hold, but are you really sure there’s not a few hundred gigabytes of unstructured stuff sitting in people’s 10-year-old inboxes or personal file stores?
If you’ve not worked with the people who actually do the back-end work, there may well be a gap between what you’re aiming to do and what’s technically possible.
And if you’re a techie managing systems that have personal data on them, have you been involved in GDPR preparations? Have you seen any of these new policies? Were you consulted when they were being written? Are you being asked to implement stuff, or to explain the art of the possible with regard to protection and measurement? No? Probably a good time to go and ask questions, then. You really don’t want your first involvement to be when the incident response procedure has been invoked as the result of a breach.