Users sharing passwords may breach data protection regulations
June 21, 2007
The Data Protection Act 1998 (DPA) can be seen as a very straightforward piece of legislation. Properly applied, it protects the rights of individuals to ensure that data about them is processed properly, securely and only for the purposes they originally gave that information.
In a ruling yesterday the Information Commissioner’s Office decided that allowing staff to access data without proper controls (by using each other’s passwords) is not in compliance with the Act. This kind of lax IT management does not ensure that personal information will only be accessed by authorised people who have a good reason to do so. This does not meet the Act’s requirements that a Data Controller should have appropriate “technical and operational measures” to ensure data is processed in line with the Data Protection Principles.
The DPA is often mis-applied to situations in which it is entirely inappropriate. We have all come up against a call centre drone who won’t tell you whether your gas bill has been paid because it is in your spouse’s name and they “can’t because of Data Protection, you know”. While this kind of rubbish has perhaps reduced some people’s respect for it’s application, the Act does provide some very powerful protection for the man in the street, and (in theory at least) some real repercussions for businesses that choose to abuse the information they hold about you.
However, at its core it places obligations on business who store and use personal data to ensure that this is processed in a manner which affords a suitable level of confidentiality. One area in which this affects IT is in discussion of data security – you might interpret it to mean that your backups must use encryption, for example.
This latest ruling covers breaches by two companies, but the one of most interest from an IT perspective is the part which concerns Orange (emphasis mine):
The ICO received a complaint regarding the way in which Orange processed personal information, and in particular the way in which new members of staff were allowed to share user names and passwords when accessing the company IT system. Following its investigation, the ICO found that Orange was not keeping its customers’ personal information secure and therefore was in breach of the Data Protection Act.
I have lost count of the number of times I have patiently explained to someone why it is not smart to just give the new person (sometimes a temp) their own credentials.
In one case I found that the second temp covering a position during holiday leave was using the username and password the first one handed on to them – which was the personal logon the PA of a department head had given to temp one in the first place. This gave them access to all sorts of emails and appraisal information which were entirely inappropriate for someone who had not necessarily been vetted thoroughly nor had time to build up a level of trust within the organisation. IT had not been told of either of these people, and only became aware because of a helpdesk call which was logged by the second temp.
When explaining these things you may have to resort to making it personal rather than talking about corporate responsibility. “Lack of individual accountability within the system” means little or nothing to the average office worker; “you might get blamed for anything bad they do” gets through in most cases.
Now, I do live in the real world. I know that no matter how much I harp on about this to my clients and their individual employees, they will always find a reason why they feel that today’s special circumstances justified them breaking this rule. So, to meet this real-world challenge I have a number of tactics:
- make sure that people understand that with appropriate authority I can give someone else access to things they need using their own credentials. Don’t let Alice log on as Bob to access his home drive, I can give Alice those permissions and temporarily map a drive, for example, assuming I have Bob’s say so.
- use a sensible password expiry period so that even when (NB: not if, this is the real world) Charlie gives Dianne his password, it will stop working after a while. If Dianne leaves the firm this protects external access methods (such as OWA, say). It also addresses my principle that if something breaks now and again (Dianne finds the password does not work) then the user will come to IT to find out why and you get to find out about these practices and re-educate the person appropriately.
- write a computer use policy, publish it, and get explicit agreement to it from all staff. Make clear in that policy that anything done with their user account is sufficient to hold them responsible for it. You don’t have to prove it was them – they are responsible for any activity in just the same way that they would be if they gave someone the keys to the office safe.
So now I get to add another angle to this: tell the directors (who are ultimately liable under DPA if found to be negligent) that they are personally as well as corporately liable to a substantial fine if found guilty of an offence under the Act. This means if they do not put in place appropriate measures to ensure their employees do not share passwords they could be found in breach of the DPA. While an enforcement notice is the most likely outcome for a first offence, frequent or badly negligent offenders may find themselves paying out.