0

Our organization has historically been very lax with Data Protection and compliance, and we have a number of POS sales positions serving the public and taking payments; both Cash, Chip and Pin and Debit/Credit transactions through an e-portal.

As we're in the UK, the pending 2018 GDPR Act will have huge consequences on Data and information security for us, and as an IT dept. one of our biggest challenges is preparing the organization for the changes, and enforcing best practices on our staff.

It's recently come to light that certain vendors will often be logged on to more than one machine, with a different user performing financial transactions whilst 'borrowing' a colleagues credentials (the colleague in question is aware of this, apparently it 'speeds things up' when they're busy).

Of course this removes our ability to trace and audit transactions, but strictly speaking, is this illegal?

If so, which party would be prosecuted for this? The individual 'borrowing' the credentials, the colleague who has 'loaned' their login credentials out, or us as a company (even if we are unaware of the practice)?

I'm aware this crosses over with 'Law', but is more generally focused on IT protection practices so thought I'd post it here (don't want to cross-post). IF the community deems this off topic for this stack, could an admin kindly migrate it over to Law for me?

schroeder
  • 123,438
  • 55
  • 284
  • 319
John Smith Optional
  • 101
  • 4
  • 3
    "Illegal" and "non-compliant" are different things. GDPR does not outline new laws, just regulations. – schroeder Jan 27 '17 at 13:53
  • 1
    It does not remove your ability to trace or audit. You have a clear audit trail. It only provides for misattribution. Your org is still responsible for what is done by any of the accounts. – schroeder Jan 27 '17 at 13:54
  • @schroeder, but should there be misconduct attributed to a specific sales position, and the users are engaging in such practices; how would we identify the culprit? doesn't PCI compliance require only the staff member using the terminal be performing transactions, exactly for this reason? – John Smith Optional Jan 27 '17 at 13:57
  • Sure, there is requirement in PCI-DSS that accounts are not shared, but that's based on an intentional policy. If users share, the org is not at fault - but the *users assigned to the account* are liable for all actions on that account. It's in their best interest to keep the account to themselves. But if you look at these regs, the *users* aren't at fault, the org is. The org can then look at remedial actions against the account that caused the fault. – schroeder Jan 27 '17 at 14:07
  • ahh, I see. So the act itself is not illegal, but should someone else perform fraudulent activity on another users account, it will be the 'hijacked' user who will face legal recrimination? Or will the organisation likely have to absorb the citations levied, despite the fact it was an individual employee's conduct? I guess we're straying too far into law here.. thanks for the info though. If someone can post an answer from an ICT compliance side I'll be happy to mark correct. – John Smith Optional Jan 27 '17 at 15:01

1 Answers1

2

Article 32 states "the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk".

If a regulator looked at what you were doing and concluded that you hadn't done this, they could certainly impose a penalty on your organisation.

Their conclusion - and the penalty - would of course be very dependant on your exact circumstances.

But off the top of my head, it looks like this behaviour increases risk to the data subjects (because fraud is more possible without a good audit trail) and that you have not implemented appropriate controls (because you wouldn't be asking us for help if HR had fired people until they stopped).

Graham Hill
  • 15,394
  • 37
  • 62