New GDPR Privacy Data Regulations

[Mantra]

Test it at: http://www.graphicz.solutions/gdprcss/ add something to cart and mouseover the frst checkout page fields. If you want the tooltips on the progress bar add the spans there as well.

Thank you for this, Jonathan.
Some usefull CSS application code here.
Only problem is with the test site, I tried this out and it works fine but my wife caught a glimpse of the screen displaying the white gold diamond solitaire ring and thought I was shopping around for a surprise gift for our wedding anniversary next week.
Martin

[Mike Hughes]

I wrote this post a few days ago but for some reason the forum won't let me post it. I'm going to try it in bits and see if I can do it this way. --> I've made it eventually.

I've spent a little time considering the various opportunities for customers data to be accessed and what kind of measures might be appropriate to mitigate them. I'm sure the list isn't complete so please feel free to add, comment, disagree as you like. It would be good if we could come up with a list of risks and measures that covers most of the bases.

1. Early access / Interception. (data open to access coming in / going out of the secure system)

Prevention:

- Encrypt the webpages with SSL.
- Encrypt customer orders while on the Server
- Encrypt the customer emails, uploads, etc - Coming in Sellerdeck 2018

2. Loss or theft of hardware (Computer / Laptop / Backup drives)

Prevention:

- Encrypt the data on the storage media
- Secure access to the computers (strong passwords, HW Keys?)

3. Malicious Access (hackers, viruses, etc)

Prevention:

- Protect the network - HW Firewall on router, secure WiFi, etc
- Protect the computer. Effective Firewall, Anti Virus, etc with regular updates and scans.
- Encrypt sensitive data in the database *** 'someword' (and/or just data that can identify the individual)

*** The forum won't let me post an explanation of this using brackets. It keeps saying "Forbidden You don't have permission to access /editpost.php on this server." ??? It looks as if it doesn't like to see 'database' followed by a '(' which is why I've added 'someword' above..


4. Unauthorised Access

Prevention:

- Password protect the computer.
- HW keys?

One of the things that I am thinking about is Hardware keys and whether I can arrange it so that an encrypted partition can only be access when a USB key is in the computer. I think Goldkey do one but I suspect the cost might be a bit excessive for this kind of application. Whether it's needed for most SMBs I don't know.

PS. I like Martin's approach to quantifying / assessing the risk.

Risk assessment in my experience should be Hazard identification, followed by [L]ikelyhood/frequency of occurrence, [C]onsequence/severity (sensitivity of data), [R]isk [L] x [C] rating then mitigation to reduce risk rating to a level that is acceptable/tolerable, presented in the form of a log (tabular listing). My recollection is that a [R] = [L] x [C] rating of 5 and below was acceptable and between 5 up to and including 10 tolerable with control measures implemented.

I have seen this approach applied many times in industry for H & S assessments using a simple qualitative 5 x 5 matrix with [L] scored down from 5 (highly likely) 1 (extremely unlikely) and [C] scored up from 1 (very low severity) to 5 (catastrophic - extremely severe).

If we can agree a suitable list of hazards then it shouldn't be too hard to come up with a reasonable assessment of the Likelihood of occurrence for various approaches to mitigation.

[Mike Hughes]

I'm going to make a first attempt at quantifying the Consequence / Sensitivity of data side of things.

I see the scale of consequence / sensitivity (on a scale of 1 to 5 where 5 is the most serious) as being somewhere along the lines of :

5: Incredibly sensitive data such as medical records, sexual persuasion, bank records, passport details, credit card details, email servers, credit history, etc. This is stuff that you rightly expect to be protected to the highest level and never exposed publicly.

4. Less sensitive data but still private data that can have serious consequences. Things like political leanings, passwords, purchases from adult websites, photo storage servers, etc.

3. Name, address, phone number and email contacts etc. Things you expect to be kept private but that might be available from public records, phone directories, etc and that aren't that sensitive really because of the low impact of their exposure and / or can be changed without much difficulty if required (such as phone numbers and email addresses, etc).

2. Randomised / encrypted data with nothing that can be used to identify an individual or reveal any private data about them.

To my way of thinking, most of us as retailers will be at a consequence level of 3. Those of us that sell sensitive items such as adult goods or use passwords to access purchase history, etc might be at a higher level of 4.

If Sellerdeck encrypted the names, addresses, passwords and contact details in the database then the consequence level would probably drop to a 2.

What do you think? Does this work as a starting point for assessing the consequences / sensitivity of a data breach?

[Mike Hughes]

And then for the level of protection / mitigation I'm thinking of a scale that goes somewhere along the lines of:

Level 1 - State of the Art

Top level protection across the board with state of the art measures to provide physical barriers, network protection, computer protection, data protection, effective procedural measures and counter measure systems to identify and protect data through intrusion detection, honey traps, etc.

In terms of implementation efforts, this is the kind of stuff banks, government agencies, etc should be doing.

Level 2 - Professional Implementation

Similar in scope to the above but may not using the best, latest and most effective measures. Still professionally implemented by people who know what they're doing.

This is the stuff you'd expect most large companies should be doing to protect data that is maybe not the most sensitive.

Level 3 - Practical Implementation

Systems implemented to a practical level by people who aren't experts in their fields. Still using a good level of security for data loss mitigation where appropriate. So using decent firewall, good anti-virus software with regular updates, strong passwords for computer / wifi / encryption, hard disc encryption, etc.

This is probably the level we should all be aspiring to.

Level 4 - Practical with some clear weaknesses.

Similar to Level 3 but maybe with some weakness that make the system less secure. Maybe use weak passwords, free anti-virus, only update software occasionally, don't use encryption on the hard disc, maybe carry a laptop around with them containing the data, etc.

Level 5 - Poor.

Any system that doesn't achieve the higher standards.

[Mike Hughes]

So where does that leave us?

If we assume that we should be protecting Level 3 Consequence data to at least a Level 3 mitigation level then we end up saying that in general the acceptable Risk level is somewhere around 9 or less (Being the Consequence x Protection Level)

This seems fair enough and I'm sure for each Hazard we can assess the Likelihood of occurrence and therefor work out what level of mitigation is acceptable.

There are a couple of immediate thoughts that come to me from looking at this.

1. Being able to reduce the Consequence risk by encryption of the sensitive data in Sellerdeck would immediately make our task much easier to achieve and much more secure overall. I realise this in itself is really a mitigation factor but it's certainly something I'd like to see (for the sensitive data only much as it has been done for card details in the past. And ideally for selectable fields).

2. If the assumption is correct that storing passwords raises the Consequence level because of their sensitivity (as these are often used by the individual across several sites) then that does suggest there's an impact on the level of mitigation we need to be using. Does anyone know if the user passwords to access order progress, etc are encrypted in the sellerdeck database as that would potentially be of benefit in achieving the desired data protection as well. Alternatively, it might be better to not offer that facility because of the security implications and the extra cost of protecting them to an appropriate level.

Mike

[John Ennals]

Mike,

Thank you for sharing the work you've done on this. It sounds like a perfectly sensible basis for a risk assessment, and I'm doing mine tomorrow (as rain is forecast).

I've found that the GDPR has really made me think about how I process personal data, and most of the changes I've made have been to do with handling paper records and purging old data once there's no legal basis for keeping it.

The final piece in the jigsaw will be to upgrade to Selledeck 2018 to provide TLS emails and secure FTP. The cost of renewing the SD Cover contract to get this upgrade has been far and away the most expensive aspect of the exercise, and I think it may have been unnecessary as Article 32 says that cost may be taken into account alongside the level of risk when implementing technical solutions. Oh well...

John

[Mantra]

The final piece in the jigsaw will be to upgrade to Selledeck 2018 to provide TLS emails and secure FTP. The cost of renewing the SD Cover contract to get this upgrade has been far and away the most expensive aspect of the exercise, and I think it may have been unnecessary as Article 32 says that cost may be taken into account alongside the level of risk when implementing technical solutions. Oh well...

There is a complimentary taster of Sellerdeck's GDPR White Paper that can be downloaded from Sellerdeck 2018 microsite https://2018.sellerdeck.co.uk/gdpr-w...per-taster.php.

This includes a list of actions you should take to comply with GDPR and some interesting commentary on the valid legal basis for marketing concerning "Consent" and "Legitimate Interest".

The view taken is that, provided an appropriate process is gone through which can justify Legitimate Interest, then this basis can be used for marketing similar products to people who are customers.

However, remember that an opt-out option must still always be provided, and we (Sellerdeck) will be supplying more information on how to go about this to Sellerdeck Desktop 365 Plus customers.

It goes on to say that Sellerdeck will be making available a Full White Paper to Sellerdeck Desktop 365 Plus customers providing further information on the above points, to help understand the regulation and assist in becoming compliant.

Reading this it seems to me that a critical GDPR requirement - marketing opt-out option has not been addressed for Sellerdeck 2018 release.

This is very dissappointing for those of us that have recently renewed our cover contracts and will not be updated and given access to further information, that according to the White Paper taster, will be provided to Sellerdeck Desktop 365 Plus customers.

Martin Nichols
Mantra Audio

[John Ennals]

Sellerdeck have stated that v18.0.1 is to be released shortly with additional GDPR-related features.

John

[Buzby]

This is very dissappointing for those of us that have recently renewed our cover contracts and will not be updated and given access to further information, that according to the White Paper taster, will be provided to Sellerdeck Desktop 365 Plus customers.

Martin Nichols
Mantra Audio

I have just cancelled my cover, and this was one of the deciding factors. The start of a two tier support structure. For my £1260 a year, I want to feel supported, and not cheated!

Imagine the AA saying they will recover your car a week Thursday, unless you have car insurance with them in which case it will be an hour.

I signed up to support, not a cut down version of it, with a 25% increase.

[JimboS]

Just want to clarify one thing from the publication about eCommerce Marketing to existing customers.

This nothing to do with GDPR but covered by PECR.

According to a conversation I have had with the ICO you are still allowed to soft-opt in customer in (on the assumption they will want to hear form you) they just have to be given the chance to opt out if they want to.

So a message saying we are signing you up unless you opt out by ticking this box is fine, for a customer.

It is not okay though for a prospects e.g. enter out competition and you will be signed-up unless you tick here.

James

[Mantra]

I wrote this post a few days ago but for some reason the forum won't let me post it. I'm going to try it in bits and see if I can do it this way. --> I've made it eventually.

I've spent a little time considering the various opportunities for customers data to be accessed and what kind of measures might be appropriate to mitigate them. I'm sure the list isn't complete so please feel free to add, comment, disagree as you like. It would be good if we could come up with a list of risks and measures that covers most of the bases.
If we can agree a suitable list of hazards then it shouldn't be too hard to come up with a reasonable assessment of the Likelihood of occurrence for various approaches to mitigation.

Mike

I copied the text from your 4 posts into a word file and made some minor changes in red text.

Overall I believe you have made a very good first attempt at assessing the impacts of consequence/severity on the data side of things and the levels of protection/mitigation.

The only change I am suggesting is that personal name, address data excluding email addresses are categorised down to C2 and that randomised encrypted anominity data is categorised down to C1.

I believe GDPR applies to data generally not just that which is stored electronically, so storage of paper records may also need to be considered and addressed.

I have used this as a basis to produce the working draft risk assessment complete with the edited version of your posts as a first attempt at a risk assessment that could be used, amended, added to by others to suit their own business operations.

We are not set up to enable customer registration/logins and do not use third party carriers or order tracking, so these aspects are not included but will need to be considered by those businesses that do.

Regards

Martin
Mantra Audio

[Mike Hughes]

Hi Martin,

Mike

The only change I am suggesting is that personal name, address data excluding email addresses are categorised down to C2 and that randomised encrypted anominity data is categorised down to C1.

That makes sense to me. It expands the scale and differentiates between names and addresses, which are typically publicly available, and email addresses which tend to be a bit more sensitive and more open to abuse if revealed.

Mike

[graphicz]

Presta Shop have made their White Book on GDPR free to all: https://www.prestashop.com/en/guides/gdpr-whitepaper

It is a shame that SD are having such a blatant scramble towards income generation often at the expense of long standing customers and developers/partners (whatever they call us).

IMHO they owe a debt of loyalty to the huge raft of existing customers.

That's me off the Christmas card list - again!

[Mantra]

Just want to clarify one thing from the publication about eCommerce Marketing to existing customers.

This nothing to do with GDPR but covered by PECR.

According to a conversation I have had with the ICO you are still allowed to soft-opt in customer in (on the assumption they will want to hear form you) they just have to be given the chance to opt out if they want to.

So a message saying we are signing you up unless you opt out by ticking this box is fine, for a customer.

Sellerdeck/DPO please clarify/confirm the above as it impacts on the wording and form of opt-out option required.

Martin

[JimboS]

If it helps this is an extract from my conversation with the ICO:

====
[10:43 AM] ico_craigm: What is a ‘soft opt-in’?

The term ‘soft opt-in’ is sometimes used to describe the rule about existing customers. The idea is that if an individual bought something from you recently, gave you their details, and did n ot opt out of marketing messages, they are probably happy to receive marketing from you about similar products or services even if they haven’t specifically consented. However, you must have given them a clear chance to opt out – both when you first collected their details, and in every message you send.

The soft opt-in rule means you may be able to email or text your own customers, but it does not apply to prospective customers or new contacts (eg from bought-in lists). It also does not apply to non-commercial promotions (eg charity fundraising or political campaigning).
….
[10:54 AM] ico_craigm: You cant have a pre ticked box.
[10:54 AM] James Sutton: But we coudl have an unticked box then that says 'if you DO NOT wish to receive our emails, please TICK this box'?
[10:55 AM] ico_craigm: Correct
====

And confirmed by an 'expert' in the field:

If your customers are B2C (includes sole traders, individuals and partnerships) then you do need to adhere to PECR for the purposes of electronic marketing (see attached doc for an overview), and in this case where they have had or currently are buying products from you, then you can apply the soft opt-in. You would then rely upon 'Legitimate Interest' under GDPR for the processing of the contact details.

I suppose it all depends if you are happy with using 'legitimate interest' to market to an existing customer or if you want to use 'explicit consent'.

James