3 ms·

It depends on the circumstances of each scenario, but it would be completely reasonable if large numbers of smallish companies acknowledge that they lack the ca

It depends on the circumstances of each scenario, but it would be completely reasonable if large numbers of smallish companies acknowledge that they lack the capacity to handle personal data properly and the recommended strategy for GDPR compliance is that they should simply stop requesting and storing that data. That's not a reasonable strategy at all. Any company doing more than selling basic goods in person for cash probably needs to process some level of personal data for legitimate reasons. In fact, it will probably be legally required to do so in several respects. It's all very well arguing that you want to reduce processing of personal data, but I think what you really mean is that you want to reduce processing of personal data in ways you don't like. Some amount of processing of personal data about you is always going to be necessary, and indeed essential to your vital interests and the normal functioning of society.

PeterisP 7y ago
"Any company doing more than selling basic goods in person for cash probably needs to process some level of personal data for legitimate reasons." is a bit tricky, and I'm not certain that it's true. I'd say that many common business processes use personal data for reasons of tradition, but don't really need it. 1) "Selling for cash" - accepting credit cards and wire transfers (paying by check isn't really a thing in most of EU) doesn't necessarily require you to store PII. Yes, you could get cardholder name, but perhaps you shouldn't; just as you (most likely, for PCI DSS reasons) don't handle CC numbers but delegate it to e.g. some merchant gateway service, if you also delegate CC fraud analysis to them, then you don't need any details about the transcaction beyond the amount and ID. 2) "Selling in person" - delivery is tricky, but you can reduce the exposure a lot by having the information be transient. If you're delivering pizza, then you don't need to store every order's phone number and address forever; and if you don't store the delivery data beyond the delivery, then if someone requests all the data you have on them, then you can honestly say "nothing". etc. Of course, details matter, and yes, that definitely don't fit all cases, but it's my feeling that they work in half the cases where companies had my data.
- pbhjpbhj 7y ago
  >you don't need any details about the transcaction beyond the amount and ID. // That's a lot of trust in the merchant services. "What transaction?", then if all you had was a transaction ID what do you do? Also, to process refunds you need to have payment details. In your second case only store the details if people explicitly want you to. You can do repeat customer discounts by sending vouchers for a later order with the present order confirmation. (You can't restrict discounts to those who give up their PII if I'm reading things right.)
  - PeterisP 7y ago
    What do you mean by ""What transaction?", then if all you had was a transaction ID what do you do?" - that's a common process in online stores, you make a contract with an acquiring bank with the default scenario that you won't be processing transactions yourself (as most smallish customers can't or don't want to handle full PCI DSS compliance), then you (or the bank) contracts with one of the merchant gateway providers, and whenever you forward them a customer order session and get back a confirmation token, then you verify it afterwards (usually next morning after closing of business day) with your bank that you've got each transaction. Or something similar, details may vary - but it's an established process that works for thousands and thousands of companies without any significant trust issues. Yes, the gateway has to be trustworthy - in part that's the service they provide, to handle card data in a trustworthy manner because you don't want to be required to be trustworthy because doing things in a trustworthy manner is complicated and expensive - secure facilities, regular audits, four-eyes principle, separation of duties that's infeasible for smallish companies, etc, etc. You also have to trust your acquiring bank, and Visa/Mastercard network, that's also part of the deal. "Also, to process refunds you need to have payment details." this is false, merchant gateways (in general, not all of them) can also execute refunds (or recurring payments) without you having any sensitive details but just that same transaction confirmation token they give you when the initial transaction was made, I've written code relating to these processes.
    - pbhjpbhj 7y ago
      Well, in our shop [no longer open, was a micro-business] someone comes in for a refund, but doesn't have the receipt, there's no way to process a refund except to open the safe and get the receipt because you need to refund the same card and you don't know the card without keeping some record of it. We've had transactions that failed to upload but were processed normally on the [mobile] card terminal, and we had to give the merchant services details to complete the processing of the transaction. Sometimes a transaction would fail during processing [cardholder not present (CNP), via phone] but we wouldn't realise until the phone was down, so in some cases we contacted the customer (our business required contact details, it couldn't run without them; this was pre-GDPR anyway). Other times the bank network would be out, so we'd be unable to process transactions without keeping customer data (temporarily). >as most smallish customers can't or don't want to handle full PCI DSS compliance // The banks were real bastards for this. Despite providing us mobile card terminals that don't connect to local network they required us to pay for PCI compliance audits of local equipment or pay a penalty amount [you could audit it yourself, took me about 8 hours of reading documentation to establish the protocol as they apparently didn't want us to do it but wanted us to pay instead]. The PCI stuff was basically a hidden-cost scam AFAICT.

PeterisP 7y ago

"Any company doing more than selling basic goods in person for cash probably needs to process some level of personal data for legitimate reasons." is a bit tricky, and I'm not certain that it's true. I'd say that many common business processes use personal data for reasons of tradition, but don't really need it. 1) "Selling for cash" - accepting credit cards and wire transfers (paying by check isn't really a thing in most of EU) doesn't necessarily require you to store PII. Yes, you could get cardholder name, but perhaps you shouldn't; just as you (most likely, for PCI DSS reasons) don't handle CC numbers but delegate it to e.g. some merchant gateway service, if you also delegate CC fraud analysis to them, then you don't need any details about the transcaction beyond the amount and ID. 2) "Selling in person" - delivery is tricky, but you can reduce the exposure a lot by having the information be transient. If you're delivering pizza, then you don't need to store every order's phone number and address forever; and if you don't store the delivery data beyond the delivery, then if someone requests all the data you have on them, then you can honestly say "nothing". etc. Of course, details matter, and yes, that definitely don't fit all cases, but it's my feeling that they work in half the cases where companies had my data.

pbhjpbhj 7y ago
>you don't need any details about the transcaction beyond the amount and ID. // That's a lot of trust in the merchant services. "What transaction?", then if all you had was a transaction ID what do you do? Also, to process refunds you need to have payment details. In your second case only store the details if people explicitly want you to. You can do repeat customer discounts by sending vouchers for a later order with the present order confirmation. (You can't restrict discounts to those who give up their PII if I'm reading things right.)
- PeterisP 7y ago
  What do you mean by ""What transaction?", then if all you had was a transaction ID what do you do?" - that's a common process in online stores, you make a contract with an acquiring bank with the default scenario that you won't be processing transactions yourself (as most smallish customers can't or don't want to handle full PCI DSS compliance), then you (or the bank) contracts with one of the merchant gateway providers, and whenever you forward them a customer order session and get back a confirmation token, then you verify it afterwards (usually next morning after closing of business day) with your bank that you've got each transaction. Or something similar, details may vary - but it's an established process that works for thousands and thousands of companies without any significant trust issues. Yes, the gateway has to be trustworthy - in part that's the service they provide, to handle card data in a trustworthy manner because you don't want to be required to be trustworthy because doing things in a trustworthy manner is complicated and expensive - secure facilities, regular audits, four-eyes principle, separation of duties that's infeasible for smallish companies, etc, etc. You also have to trust your acquiring bank, and Visa/Mastercard network, that's also part of the deal. "Also, to process refunds you need to have payment details." this is false, merchant gateways (in general, not all of them) can also execute refunds (or recurring payments) without you having any sensitive details but just that same transaction confirmation token they give you when the initial transaction was made, I've written code relating to these processes.
  - pbhjpbhj 7y ago
    Well, in our shop [no longer open, was a micro-business] someone comes in for a refund, but doesn't have the receipt, there's no way to process a refund except to open the safe and get the receipt because you need to refund the same card and you don't know the card without keeping some record of it. We've had transactions that failed to upload but were processed normally on the [mobile] card terminal, and we had to give the merchant services details to complete the processing of the transaction. Sometimes a transaction would fail during processing [cardholder not present (CNP), via phone] but we wouldn't realise until the phone was down, so in some cases we contacted the customer (our business required contact details, it couldn't run without them; this was pre-GDPR anyway). Other times the bank network would be out, so we'd be unable to process transactions without keeping customer data (temporarily). >as most smallish customers can't or don't want to handle full PCI DSS compliance // The banks were real bastards for this. Despite providing us mobile card terminals that don't connect to local network they required us to pay for PCI compliance audits of local equipment or pay a penalty amount [you could audit it yourself, took me about 8 hours of reading documentation to establish the protocol as they apparently didn't want us to do it but wanted us to pay instead]. The PCI stuff was basically a hidden-cost scam AFAICT.