What are the legal implications of storing bank details and/or debit or credit card details of customers in a database in the UK?
Assuming it's illegal to just simply store them unencypted, how do I store them legally? What technical and legal processes should be followed in order to do this?
Take a look at the website of the Information Commissioner and read the relevant pages.
Peter Crosland
Why would you asssume that?
If you have a legitimate need to store them, and your customers' permission, there will be no problem. I would imagine the only reason you would have, other than temporarily while a transaction is pending (e.g. to retry if it failed the first time, or to be able to make refunds to the card for goods returned) is if you expect repeat orders from the customers and wish to offer them the convenience of not having to re-enter their card details every time.
I don't think there's a technical problem. Encrypt if you like, but I don't think doing so has any great value unless you think it likely that your systems are going to leak the information into the wrong hands. Often such leaks would be an inside job, and any decryption tools would be available to internal crooks anyway, hence encrypting doesn't really gain you anything.
Naturally your systems ought to be impregnable to external attack. That probably rules out Microsoft Windows.
Erm, no if you fail to encrypt I think it highly unlikely that anyone would consider you'd taken due care with the data, I would expect all personal data to be encrypted beyond something basic like name/email address.
Remember physical theft of computers or backup tapes etc. is something that is surprisingly common, and you have to defend against it. Encryption is of course part of that.
Jim.
Nah. Physical theft of filing cabinets full of confidential paper records are possible too. You wouldn't encrypt those either.
I'm not saying encryption would not be a wise thing to do, I'm just disagreeing with the proposition that it would be "illegal" not to.
Well it's certainly not illegal in that there's a law requiring it, however there is a law requiring appropriate levels of security, I would suggest that you're not going to convince a judge that not encrypting was appropriate, given how trivial it is.
Jim,
What law is that, then? And who's to say that "appropriate" would not be satisfied by simply password-protecting login-access to the machine, and setting appropriate file permissions?
In any case, it's not trivial at all, given the requirement that the computer which is going to be stolen must itself already contain the decryption capability, given that the purpose of holding the data is to make them available on line. Typically you would present an online customer with a payment form on which the card details are already pre-filled in, so the customer can confirm the details or replace them with those of a different card.
It would be the equivalent of storing paper records in a locked safe, but leaving the key in the door, or, in the case of a combination lock, writing the combination on a pice of paper taped to the door.
I was imagining the Data Protection Act:
| Having regard to the state of technological development and the cost | of implementing any measures, the measures must ensure a level of | security appropriate to- | (a) the harm that might result from such unauthorised or unlawful | processing or accidental loss, destruction or damage as are | mentioned in the seventh principle, and | (b) the nature of the data to be protected.
Well I certainly would, and so have every computer security expert I've discussed it with.
Erm, no it doesn't! there are many reasons for securing passwords that do not require the decryption ability be on the same machine, indeed none of the ones you've mentioned do. The Refunds and Repeat business are simply done by sending the encrypted version from the DB to the seperate machine for decryption, that's how I've always seen it implemented when done remote appropriately.
I've never seen a solution where full card details are echo'd back to the user, nor a reason to (card number ending in 1234, is the normal method) It's a really bad idea, it's also bad socially as it's suggestive of weak security, so HCI people tend not to like it (just like passwords are rendered as *'s even in plain text environments.)
I think you should spend more time in computer security, it's not at all the same.
Jim.
Under the Data Protection Act, you have a legal obligation to make sure that the data is secure - the 7th principle:
Iain
That's all very well if the data are stored on a separate machine. What if they're not?
*If* the data and the decryption recipes are on the same machine, then it *is* the same. It is also somewhat the same if they're on different machines, if the two machines can both be stolen together. To guard against that, you would have to keep the machines on separate sites, but even that would not make you totally safe from a really determined effort to steal both the data and the decrytion keys by breaking into both sites simultaneously and stealing both machines.Going off-site also introduces risk of harm resulting from temporary loss of access to data, should a break in connectivity arise.
you're building a secure system here, you simply do not do that, it's unsafe, it's insecure.
Yes, but that's like saying "if I leave the front door open, it's the same as leaving the key under the mat" well sure, but in discussing if it's a good idea to not secure your house it's irrelevant, both are wrong, and you do secure your house.
Of course, but seperate machines at seperate sites is a bloody good start, and is certainly reasonable - remember we only ever discussed doing what is reasonable, and encrypting is certainly a minimum requirement.
Jim.
In message , Jim Ley writes
That puts about 95% of the data stored in trouble then!
I imagine the OP posted here because he was seeking "expert technical advice". Where should he go?
Unlikely as the reasonableness is also related to the damage the data can do, names, email addresses, how much someone has been paid etc. has very little damage that can be done.
Credit cards with addresses and cv numbers however have a lot of potential for damage...
Jim.
No, building a secure system is not the principal aim here. It is doing what's reasonable within the overall constraints given, and even the Act acknowledges that cost is one of them. If you're running only a very small business, for example, it is entirely possible that you may have only one machine available, and so the option of storing the data elsewhere simply does not exist.
You may well lock your house, but hey, if the burglar can just kick the door in, or smash a window, you might as well leave the key under the mat.
I would agree encryption is a jolly good idea, but if data and programs are on the same machine (and as I've illustrated, it is not entirely unreasonable, in some circumstances, for this to be the case), then there seems not an awful lot of point. So no, it's not a "minimum requirement" at all.
Yes, but 95% of the data stored is publicly available. It raises an interesting question. The data I have stored about the members of my tennis club is not encrypted but there is no data stored that is not in the telephone book. However, their record in my database reveals the, otherwise secret, fact that they _are_ members of the tennis club. Might I be obliged to encrypt the data to obscure this fact?
I doubt a single bank would issue a merchant account in such a situation, realistically a 3rd party option is the only one that would make economic sense, and there's little chance of getting anyone else to provide a non-hosted solution.
Are you an expert in the field? Would a judge consider your advice when ruling, I'm not an internet security expert (despite newspapers having claimed I am) but I have talked to a lot, and I can't see any who would give the advice you're giving, so I can't see any judge receiving similar expert advice in a resulting court case.
Jim.
My mistake! I realised after posting my reply that it had been cross-posted to other newgroups other than uk.legal where I read it.
Iain
Ideally, you should implement British Standard 7799 (ISO17799) - Information Security Management. Whether you also choose to be audited to the Standard depends on whether you need to satisfy others as to your compliance. Personally, I use Protx for most transactions, so I never see those card details, and, if I do take a card number, I destroy all records of it once the payment is accepted. For one thing, it increases customer confidence if they know you don't hold their data on file.
Colin Bignell
Well your expectations are not going to be met then.
I have worked for numerous organisations, many of which hold quite sensitive personal data.
I have never yet come across one where any of it is encrypted.
The only data that is routinely encrypted is password data.
BeanSmart website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.