Skip to main content

Designing a GDPR-compliant consent workflow for eCommerce

It's been quite a journey for me, to date, as I find my way along the twisty path that is understanding GDPR.

Through attempting to better understand what 'compliance' for the Photobox Group looks like, and in a renewed attempt to better understand its likely impact upon us, something I've found hard to find are good examples of 'GDPR compliant' user interfaces for eCommerce around the provision of user consent.

Ultimately we need to ensure that for each and every GDPR-relevant interaction our brands have with our customer's data, we have their appropriate consent.

The question is, how granular the explicit Opt-In requirements need to be?

The ICO does a good job of publishing high-level 'consent guidelines' as below:
  • Explicit consent requires a very clear and specific statement of consent. 
  • Keep your consent requests separate from other terms and conditions.
  • Be specific and granular. Vague or blanket consent is not enough.
  • Name any third parties who will rely on the consent.
  • Keep evidence of consent – who, when, how, and what you told people.
  • Avoid making consent a precondition of a service.
In an attempt to map these guidelines to four key areas where I believe our interaction with PII requires consent, I've landed on the following position - and, as always, would welcome industry and specialist commentary:

In summary, I believe within GDPR you can distill any initial account creation UI/form to a single consent tick box:

[1 - Acceptance of T&Cs and Privacy Policies]
1x tick box appears on the UI (below name and email fields) to confirm acceptance of T&Cs and Privacy Policy. Here I would suggest you include the minimum age requirement for your users within the T&Cs to avoid needing a separate tick box just for age verification, as well as a statement around a  requirement for them to provide 'accurate' data for any provided Personal info (name, email address). Naturally wording would be more brand-aligned, and 'clear' than my ramblings here.

Of course you should then validate the provided email address as an asynchronous workflow to the account sign-up process. This ensures accuracy of stored PII (another GDPR requirement).

This could be all that is required to create an account - assuming all you're asking for is no more than a customer's name(s) and email address.

However, if we consider adding the following second tick box to the account creation dialogue, I feel it far more likely that you gain consent for future marcoms than if you leave the attempt to gain consent to a separate interaction post-account creation:

[2- Consent for automated profiling and marketing communications]
1x tick box to confirm Opt-In for you to be able to automate data profiling of the customer's personal data for the purposes of sending tailored marketing comms / offers etc. If you plan to use 3rd parties for processing I believe a strong position would see you listing them in your Privacy Policy, including a clear description of what they are used for. As a processor they will not be retaining the PII for their own purposes, but I feel that being clear and explicit of their processing services to us as an eCommerce business/controller 'democratises' our approach and treatment of PII so there are never any surprises for our valued customers.

Naturally, if a post account-creation UI is the preference to gain this marcoms consent, then you could offer a more traditional 'sign up' approach. Such an example is shown below - instead of a tick box method. Then you can build the consent info and email verification process as part of that sign-up flow instead:

e.g.

[Taken from 'The Guardian' website's footer as example]

Now, for a Group dealing extensively in user-provided Photo data (which I argue should be treated as 'Special' data in GDPR, although legal advisors differ on this opinion suggesting plain PII is a satisfactory classification) I would propose that only on the FIRST presentation of a photo upload UI to a signed-in user, we include the following, specific tick box:

[3 - Consent for Automated Photo Data Processing]
1x tick box to confirm Opt-In to automated data processing of photo data that is specifically aimed at image enhancement, suggesting 'best selection' and content identification. This could include a link to a more detailed page describing the image-recognition processing and purposes. Now every eCommerce business will have their own 'photo data' conundrum, and here is ours: it is for our Group to recognise and agree how much a failure to gain consent for this automated processing request will break the ability for our user's to upload and purchase from our brands. This question is an especially tricky one as GDPR is very picky about making consent mandatory ('freely given') for the provision of services:

Art 7(4): Where the performance of a contract, including the
provision of a service, is made conditional on consent to the
processing of data that is not necessary for the performance
of that contract, this is likely to call into question the extent
to which consent can be considered to be freely given.


Any provided consent (in each case, per user) should be logged and be presentable at point of audit. But this fact also plays to our advantage as it serves as a neat way for you to lookup pre-existing consent and avoid future presentation of the (photo-processing - in our case) question on subsequent uploads. I don't believe there is a challenge to this position from GDPR.

Now I appreciate none of what I'm describing is rocket science, but having spend much time reading and digging around a number of sources of GDPR expertise I believe this approach will put our Group, and your own eCommerce businesses, in good stead for GDPR.

[4 - Consent for future concepts e.g. 'Search Suggestion']
Thinking to the future you should consider more generic consent scenarios for improved eCommerce features (such as 'suggested search') where the results are based upon the profiling of a customer's PII, or metadata that is inextricably linked to their PII (again, best practice but arguably not a full requirement - let's set the tone for GDPR in eCommerce!) In this example, consent could be gained via a simple dialogue/bubble that appears on-screen asking something along the lines of 'Can we use your order history [or whatever data is relevant] to make some great suggestions while you browse?' Again, as long as the wording is clear and unambiguous, the user Opts-IN to consent to this use of their data and you record their response, I argue you should be well within compliance of the GDPR.

A user's ability to revoke consent is a key aspect of GDPR, and it should be as simple as having an easily located section within their 'My Account' screen: Here you could list all consent(s) that have been provided (or are able to be freely given - it doesn't just need to be a 'revoke' screen), and there being a tick/slider for Yes/No next to each consent option.

Now, I'm not a lawyer, and admit I am growing to learn more and more around GDPR, DPA and InfoSec every day, and so industry comment and feedback here would be hugely welcomed. But it feels logical and hopefully offers a sound steer to the rest of the eCommerce industry who may be seeking guidance, answers or simply a point of debate.

I look forward to hearing your thoughts!


Comments

Popular posts from this blog

Cultural mugs

One of the main challenges that drew me to Information Security (and management in general) was that of helping to build a working culture that is genuine, sustainable and is aligned to support 'the vision'. I've had the benefit to have learned directly, and from the experiences of past bosses, leaders and mentors how not to approach cultural change initiatives: Knowing what bad change-approaches looks like, usually without any real clarity around what perfect (or even good! ) may be is a useful head-space to occupy. At least in the absence of knowing what to do, knowing what not to do provides a useful reference point. I find that this simple psychological tool helps me to sanity check if I'm falling into those past gotchas and traps as shared with me by the wise few who've been there, seen it, burnt that bridge, picked themselves up and started all over. Haven't we all? The challenge of raising Information Security awareness through driving a work

Introducing the Conosco Security Division

One thing you’ll notice is that I quite like to blog about what I’m up to at Conosco. As the CEO for a private company, this may be somewhat unusual, and it would certainly make other company Boards nervous.  Thankfully not ours.  We believe that being ‘open’ betters the understanding among our staff, future employees, clients and prospects of what Conosco does, how we do it, and what we strive for. It also follows an ethos that I believe has helped mature the Information Security community – sharing knowledge that adds insight and value to its members. This approach has allowed the Information Security community to build strong bonds,  improve its members’ collective defences and lower the barrier to knowledge proliferation as a result. Conosco has a new and niche security offering for the SME market that has benefitted from such open thought, opinion sharing and an honest approach to solving our clients’ genuine security needs. The new Conosco Security Division provides

A SOC is cooking - with a sprinkle of Machine Learning and SRE

This week sees the start of an exciting new chapter in our ever-maturing InfoSec story, with our Group Security team forming a new Security Operations Centre (SOC). It has been founded using key staff from our existing Network Information Security (NIS) and AppSec analyst capabilities and I believe we are taking an interesting approach to the its creation that sees us using our ASV ( Surecloud ) as our first internal SOC client: The rationale is simple - Surecloud's consultants are tasked with poking and probing our applications, network and supporting infrastructure (all BAU as part of our PCI-DSS routines), and our SOC is challenged to be able to report back to the testers what it is they did. To achieve this the new SOC team has been empowered (provided time, creative freedom, engineering resource access and budget) to architect whichever technical solution(s) they require to be gain the required insight, and so a Red/Blue team dynamic is born between 'them' a