Doing the right thing on ID management isn’t enough. It’s proving that you did it

In a previous article we looked at Identity Management and access provisioning as an end in itself, and from the perspective that there are benefits to be had from being on top of who’s using what. For many organisations, however, identity management is a necessity, imposed through the demands of regulatory compliance.

Regulation has an identity management impact – it is no coincidence that the more highly regulated industries are also the ones that tend to handle more information about the public. Also regulation is not just limited to large companies. In recent research conducted across 700 of Europe’s smallest (sub-100 employee) businesses we found that small organisations in finance and the public sector were just as likely to be subject to regulation as their enterprise brethren:

Just because some industry verticals are more highly regulated, this does not mean they are all equally good at responding to the regulations. In the above example, if we look behind the chart at the industries more likely to have to deal with sensitive data, we find that financial services are more capable, and public sector or healthcare less so.

This is relevant for identity management. In general, regulation cares more about the data than it does about devices, computer systems, software packages or other assets – though of course, these have an impact on how the information is handled.

Some regulation, like the UK Data Protection Act, is more concerned with information being suited to its defined purpose – for example, an insurance company shouldn’t need to know the names of your children in order to process a claim. Other regulations, like Sarbanes Oxley, are more concerned with corporate transparency to guard against underhand practice. From an identity management perspective, regulations tend to be targeted at ensuring that:

1. The confidentiality and privacy of people who the data is about is appropriately protected

2. The information cannot be modified or otherwise tampered with

3. An audit trail can be kept of how information is accessed, for example in case of a discovery request

So how does this translate into day-to-day identity management? If, as suggested in the previous article, it is impossible to maintain a complete log of every single corporate IT asset and who is using it, then some prioritisation needs to take place – focusing initially on what information is subject to regulation, where it goes, who can access it and how. Information can be classified according to whether it is under the regulatory cosh; if it is, the right policies need to be in place to ensure it is handled correctly.

From this point on, it’s a case of ensuring that whatever tools, technologies and processes you have in place are defined and configured to take your compliance needs into account. The key element across all three areas is the audit trail – as in, if something goes wrong you will need to work out what happened, and even when it is going right you will need to prove you did whatever was necessary.

Whatever identity management capabilities you have in place, it’s this historical auditability that provides the litmus test of whether they are up to the job of supporting your compliance needs. As discussed, complexity is no excuse; “I just couldn’t keep on top of it all” is no defence in the eyes of the law. But by focusing on the right information first, and treating audit as part of ongoing management rather than by exception, you should stand yourself in better stead.

Content Contributors: Jon Collins