Crowne Plaza Hotel and GDPR

PHK

A_Geordie said:

Just to be clear, personal data doesn't need to be shared to be considered a breach and as I pointed out in an earlier post, the unlawful or accidental processing within Crowne Plaza is sufficient to constitute a data breach. The definition of 'processing' under the GDPR is very broad but for this topic, its safe to say that processing card information will fall within the scope of processing of personal data.

Crowne Plaza as the merchant, will submit the OP's card details to its bank, who is the acquirer, who will then process that payment information via a card scheme that manufactured the card such as Mastercard or Visa and then to the card issuer which will be the the OP's bank, and then finally confirm the payment back to Crowne Plaza. So to your question, even though it isn't relevant to the OP's issue, there is clearly the processing and sharing of the OP's personal data with third parties as this is pretty much how every type of payment processing works.

There is no stretch between the two scenarios - a single email sent to the wrong person would be deemed a data breach if there is no legal basis to send that email to the wrong person, since there must be at least one of the legal bases applying each time you are processing someone's personal data (unless an exemption applies). Using someone's personal data to send them marketing information when they have opted out (even if it is just one) will also be considered a data breach. However, not every data breach will result in 'damage' being inflicted on the affected individual or create a sense of distress or anxiety or whatever, and therefore there is no automatic compensation for a mere data breach. So each issue will be fact specific.

Thank heaven for some sense in this thread. 

Something most people have missed is that the hotel (or whatever business) should not be storing card numbers at all. 

When a transaction is processed, the processor generates a token that represents that transaction and can only be used to refund all or part of the transaction. There should simply be no need to take details for a refund (unless the token has expired - which is unlikely here). That they did and apparently stored them is in itself a breach of regulations, let alone possibly a breach of data protection principles. 

A_Geordie

The OP gave the hotel permission to use their debit card data, so there is no breach there.

TLDR, Crowne Plaza committed a personal data breach either unlawfully and/or accidently by using the OP's card details to process a transaction that the OP did not consent to, was not aware of and were not used for the specific purpose intended between the OP and Crowne Plaza. 

The information was given for the specific purpose of refunding 50% of the original hotel booking back in October and the OP said case closed, so must have got that refund credit back into the account.  The first debit of £340 was taken some two months later in December out of the blue. The second debit of £340 which you are referring as an error, came about because the OP said they were asked to provide the card details again. The mistake was not put right, it was made worse and then CP refused to refund despite the OP's request and only obtained a refund by going through their bank.  

Seems to me you are hanging onto the fact that the OP gave their card information so which then gives CP carte blanche to use those card details for any purpose of their choosing, which is simply not true. If someone is going to process personal data in a way that the individual did not contemplate at the time of giving that information, then you are likely to find yourself in breach of the UK GDPR.

The transgression would be a breach of Principle 1 since there was no lawful basis to debit any amount from the OP's card details. Principle 1 was further breached because CP failed to notify the OP that they intended to debit an amount of £340, in breach of their transparency obligations. There is also likely to be a breach under Principle 2 since the details were used for a specific purpose, which was to refund 50% of the original booking. No consent was given to use the card information for the purposes of debiting any amount. 

hermante

PHK said:

Something most people have missed is that the hotel (or whatever business) should not be storing card numbers at all. 

When a transaction is processed, the processor generates a token that represents that transaction and can only be used to refund all or part of the transaction. There should simply be no need to take details for a refund (unless the token has expired - which is unlikely here). That they did and apparently stored them is in itself a breach of regulations, let alone possibly a breach of data protection principles. 

When you book a hotel you have to provide them with card details that can be used to charge you later in case they find you damaged the room after leaving, or if you don't turn up and haven't cancelled before the cancellation deadline. 

Crowne Plaza is a sub-brand of IHG hotels and the IHG booking system stores card numbers in a plain format which is accessible to any staff authorised to work on the front desk / reservations.

At many IHG hotels, prepaid reservations are charged by a member of staff manually typing the card numbers into their card readers.

If this is a breach of GDPR, no EU country has seen fit to complain about it

born_again

A_Geordie said:

Just to be clear, personal data doesn't need to be shared to be considered a breach and as I pointed out in an earlier post, the unlawful or accidental processing within Crowne Plaza is sufficient to constitute a data breach. The definition of 'processing' under the GDPR is very broad but for this topic, its safe to say that processing card information will fall within the scope of processing of personal data.

Crowne Plaza as the merchant, will submit the OP's card details to its bank, who is the acquirer, who will then process that payment information via a card scheme that manufactured the card such as Mastercard or Visa and then to the card issuer which will be the the OP's bank, and then finally confirm the payment back to Crowne Plaza. So to your question, even though it isn't relevant to the OP's issue, there is clearly the processing and sharing of the OP's personal data with third parties as this is pretty much how every type of payment processing works.

There is no stretch between the two scenarios - a single email sent to the wrong person would be deemed a data breach if there is no legal basis to send that email to the wrong person, since there must be at least one of the legal bases applying each time you are processing someone's personal data (unless an exemption applies). Using someone's personal data to send them marketing information when they have opted out (even if it is just one) will also be considered a data breach. However, not every data breach will result in 'damage' being inflicted on the affected individual or create a sense of distress or anxiety or whatever, and therefore there is no automatic compensation for a mere data breach. So each issue will be fact specific.

Can you show a link to card details being personal details?

We all go shopping do we give them permission to share this data? It's all part of the payment process. There is nothing in putting you card details into a machine that shares anything other than a 16 digit number.

born_again

PHK said:

A_Geordie said:

Just to be clear, personal data doesn't need to be shared to be considered a breach and as I pointed out in an earlier post, the unlawful or accidental processing within Crowne Plaza is sufficient to constitute a data breach. The definition of 'processing' under the GDPR is very broad but for this topic, its safe to say that processing card information will fall within the scope of processing of personal data.

Crowne Plaza as the merchant, will submit the OP's card details to its bank, who is the acquirer, who will then process that payment information via a card scheme that manufactured the card such as Mastercard or Visa and then to the card issuer which will be the the OP's bank, and then finally confirm the payment back to Crowne Plaza. So to your question, even though it isn't relevant to the OP's issue, there is clearly the processing and sharing of the OP's personal data with third parties as this is pretty much how every type of payment processing works.

There is no stretch between the two scenarios - a single email sent to the wrong person would be deemed a data breach if there is no legal basis to send that email to the wrong person, since there must be at least one of the legal bases applying each time you are processing someone's personal data (unless an exemption applies). Using someone's personal data to send them marketing information when they have opted out (even if it is just one) will also be considered a data breach. However, not every data breach will result in 'damage' being inflicted on the affected individual or create a sense of distress or anxiety or whatever, and therefore there is no automatic compensation for a mere data breach. So each issue will be fact specific.

Thank heaven for some sense in this thread. 

Something most people have missed is that the hotel (or whatever business) should not be storing card numbers at all. 

When a transaction is processed, the processor generates a token that represents that transaction and can only be used to refund all or part of the transaction. There should simply be no need to take details for a refund (unless the token has expired - which is unlikely here). That they did and apparently stored them is in itself a breach of regulations, let alone possibly a breach of data protection principles. 

Retailers have a right to store card details. Especially hotels where further payments can be taken. They can not store CVV (card regulations) They need to store transaction details for 6 years for tax purposes.

Ditzy_Mitzy

A_Geordie said:

pinkshoes said:

Your case isn't really a GDPR breach, as you provided them with means to pay. It's just some muppet seemed to think the money had to be debited rather than credited. If the £680 had caused you to go over-drawn and incurred fines from the bank, then by all means they should be compensating you to cover your out of pocket expenses. 

Out of curiosity, let's say the OP did incur overdraft charges or there were other charges because the money taken by Crowne Plaza was supposed to be used for other bills, what would be the OP's legal cause of action if Crowne Plaza refused to pay these losses and the OP was required to issue legal proceedings?

It can't be in negligence because pure economic losses are not recoverable without physical damage occurring, except for a couple of very exceptional circumstances that don't apply here. And it can't be based on a contractual relationship because the previous contract was settled when the OP got refunded.

So, what action other than a GDPR breach do you think the OP be able to rely on in order to successfully sue Crowne Plaza? If there is no legally recognised cause of action then the OP doesn't have a claim for those losses inucrred.

Surely an overdraft charge incurred as a result of the OP being out of pocket would count as a consequential loss, were a legal claim to be mounted.  Any charge of that nature would stem from the original breach - taking money from the OP's account without permission, here.  

In any case, large firms generally won't quibble about such things if they occur.  When I worked in financial services, I'd routinely compensate for third-party fees arising from my employer's errors.  There's precedent for this sort of thing in most sectors.

On another note: still not convinced this is a GDPR issue.  

PHK

I think some people on here need to look at PCI DSS. and also learn the difference between various acts and regulations. (and also update their knowledge)

voluted

PHK said:

I think some people on here need to look at PCI DSS. and also learn the difference between various acts and regulations. (and also update their knowledge)

PCI DSS has nothing to do with the GDPR though, which is the topic of this thread.