Consent as a Service

GDPR: Data Subject Consent as a Service (DSCaaS), it’s Coming

In [X]aaS, The Outsource of Everything I made fun of the trend to “…as a Service.” everything under the sun, and that eventually we would run out of letters. Well, that happened years ago, so we’re now doubling and tripling up on the letters. Data Subject Consent as a Service (DSCaaS) is my latest attempt in a long line of failures to coin an acronym.

It’s every security professional’s dream.

And yes, Privacy Consent as a Service (PCaaS) would have been better, but that was taken by those damned Personal Computers!

Regardless of what it’s called, I believe the service is not only viable, it’s basically a necessity. 99% of organisations simply do not have the skill-sets, knowledge, or technical capability to manage the collection and management of consent. Especially in a fashion that has been vetted by privacy experts and kept up to date with EU-wide precedent.

Not that consent will be an organisation’s first choice for complying with GDPR. Legitimate Interest, contractual language, even binding corporate rules will likely be easier to maintain. But to get any of these to work requires each organisation to hire their own lawyers, and I’m fairly sure a lot of us would rather pay for a technology instead.

One of the first hurdles for any service like this is to explain to organisations that having yourselves the data is not your competitive edge. Making the best use of the data is. The only thing you should really care about is getting what you need out of the data, not what it took to get there, and definitely not where the data is. And let the experts worry about how to do that in line with the GDPR.

It’s like when I ask a room-full of merchants if credit cards are core to their business. 99% of them say yes, when it’s actually being paid that’s core to their business, not how they were paid.

So what does DSCaaS look like?

  1. First, it must clearly be a Cloud-based service with a seamless iFrame-esque integration with your organisation’s webpage. Where you would normally collect the personal information on your webpages, you would simply redirect this collection to a 3rd party provider;
  2. Depending on the type of information collected and the reason for collection, very simple consent notices can be developed. For e-commerce for example, these consent notices can be pretty much boiler-plated into; payment authorisation, product/service updates, customer service, marketing, etc. For HR, these would be in-line with the individual employment contract and so on. This consent is now tracked by the DSCaaS provider;
  3. The existing personal data previously collected by the organisation would be normalised/parsed and imported into the service in order to allow for the following:
    1. The removal of the vast majority personal data from an organisation’s systems (using tokenisation and APIs to link existing systems if required);
    2. tracking and collection of consent, plus renewal of consent where necessary;
    3. automated personal data removal/destruction based on data retention policies;
    4. online portal for data subject to change/erase data, or demand processing cessation;
    5. all data controller and processor contracts in place.
  4. DSCaaS provider would need to be able to demonstrate ‘appropriate security measures’ through compliance with (and/or certification to) well-known standard like ISO 27001, ITIL, COBIT, NIST and so on;
  5.  DSCaaS provider would have existing and robust relationships with supervisory bodies (ICO in the UK for example) to standardise reporting of processing (if required).

Clearly this is oversimplified, but if there’s one thing missing in all of these bandwagon ads for GDPR services it’s the spreading of the cost across multiple parties. Especially as it’s very likely that the millions of smaller organisation cannot afford privacy expertise on an individual basis.

The intent of the GDPR is a good one, and organisations have to understand that the data they are making so much money off does not belong to them. While I have no issue with them doing so – as long as I also benefit – I want complete control over what happens to it. The vast majority of organisations in the UK cannot even comply with the existing DPA, let alone one amended inline with the draft Data Protection Bill. For organisations to ‘comply’ with the intent of the GDPR, they will need help, and that help will not come from cybersecurity organisations, ‘certified’ GDPR practitioners, and not even privacy lawyers. It will come from organisations who combine all of these skills into a service where access to data is appropriately controlled.

Gone are the days when you could do whatever you wanted to profit from personal information. It’s what you do WITH the data that matters, and it’s almost always the best ideas that win out. We all need help doing that appropriately.

[If you liked this article, please share! Want more like it, subscribe!]

PCI L1 Service Provider

From FinTech Concept to PCI Compliant in 6 Months?

Anyone wanting to start a new business in FinTech/payments – digital wallets for example – has to address PCI. Like it not, payment cards are still the dominant form of non-cash payment on the planet. By far.

So what if you have a great idea in this amazing world of opportunity, but your skill-set is in payments and innovation, and not IT or cybersecurity. How do you get your service to market, AND play by the rules? Can you do this in time to be ahead of game given the incredibly short timeframe of today’s competitive advantage?

Well, you could just self assess, but you are restricting yourself to a maximum of 300,000 transaction annually.  But more importantly, would you trust your money to a service provider who self assesses? No, neither would I.

However, I’m talking about full Level 1 Service Provider compliance through a reputable QSA (yes, there are some out there). How can you set up the infrastructure, get all the documentation in place, AND get all the way through a PCI DSS Level 1 assessment in 6 months? And if you do, have you really done it properly?

The answer is yes, you can, but there are MANY caveats, and if you deviate from these steps you will not get there. I am only interested in helping organisations get compliant properly, I have no interest in adding more crap service providers to the ecosystem.

First, you have to completely ignore the PCI DSS. Any plans you make to design both your physical infrastructure and your security program from scratch must be with real security in mind. Never compliance alone. For that, many organisations turn to the ISO 27001 standard. There are others, but try finding affordable consultants who can help you implement them. As long as you realise they are all just frameworks, not step-by-step instructions, then you’re ready to start asking questions.

So What Are the Steps to Compliance?


  1. Get Help – This should be no surprise. I don’t perform emergency appendectomies, I’m not remotely qualified, why would you try to achieve compliance when that’s not your experience or skill-set. Yes, is can be expensive, but nowhere near as expensive as any of the alternatives. There are some very good consultants out there, do your homework and find the best one for you.
  2. Outsource the Infrastructure – Unless you’re an expert in everything from hardened operating systems, to logging and monitoring, to firewall management, you will want to outsource as much of the platform as you possibly can. Unfortunately, finding a single provider who can take on anything more than physical hosting and some networking stuff is still ridiculously difficult. Amazon Web Services (AWS) for example is about as bad as you can get. Unless of course you want a dozen or so independent service providers to manage along with Amazon.
    You MUST ask the right questions, and this is where your  consultant comes into play. S/he will write your RFP, interview providers, and eventually produce a responsibility mapping of services against the PCI DSS. This will match their Attestation of Compliance, as YOU should only do business with L1 PCI compliant service providers.
    You are welcome to use my mapping if you don’t have one: PCI DSS v3.2 SP Responsibility Mapping
  3. Policies, Standards & Procedures – You have to start somewhere, so you will likely want to buy a Policy Set. Once again, you have to be very careful as there are dozens of options but few will be fit for purpose. In this case, ‘fit for purpose’ means the service must 1) get you through compliance, 2) provide a platform for your unique culture, and 3) be self-sustainable for the long-term.
    If you buy a Policy Set with ‘PCI’ in the title, you have already failed. Buy one that your consultant can customise on your behalf, and then teach you to manage yourself. Get one that; 1) Is already mapped to both the PCI DSS and your chosen framework (usually ISO 27001), 2) has document management built in (numbering, content standards, assigned coordination etc.), and 3) is easily distributed to the subject matter experts best placed to maintain them.
    I have written a quasi-white paper on how to choose the right the right service, you use the questions as an RFP: ‘Selecting the Right Policy Set
  4. Hire a Completely Independent QSA – While it may be very tempting to have your consultant take care of all the ‘PCI stuff’, bite the bullet and keep these separate. No, you don’t have to be an expert in this stuff, but if you are relying completely on your consultant you are building in a single source of failure. By all means have your consultant run with the assessment, but be involved. If you don’t, you’ll have no idea what you paid for in the first place. In fact, you may even want to build in some SLAs regarding how much remediation is required from by QSA. There will always be some, but if it involves significant scope creep or capital cost, your consultant has failed you. Remember, you have outsourced almost the entire function of PCI to your platform provider, validation of compliance should be a formality.

Of course this is oversimplified, but I’m already way over my self-imposed word limit. However, while I haven’t included any of the inevitable challenges, the process is a simple as security itself, it’s up to you to find someone who can make it simple.

[If you liked this article, please share! Want more like it, subscribe!]

PCI DSS v3.0: Service Provider Agreements (Req. 12.8.X)

There seems to be quite a bit of confusion about the ‘new’ requirements for service provider contracts. I say ‘new’ sarcastically because this should have been part of your vendor due diligence processes from the beginning.

From a merchant’s perspective, unless they have hired a QSA (or other PCI expert) to help define the service requirements and contractual obligation, it’s very difficult for them to ask the right questions. From a  service providers perspective, I’ve seen the gamut from complete ignorance of their obligations, to out-and-out lies in terms of what they are and are not providing.

The DSS v3.0 requirements of 12.8.X go a long way to resolve this, but not far enough in my opinion. The bottom line is that someone has to be responsible for each requirement, and there are only the following choices;

  1. SP agrees to be fully responsible for the requirement;
  2. SP agrees to be partially responsible, and;
  3. SP pushes the entire requirement back on you.

That’s it.

The above list is fairly obvious, but for the service provider’s clients the challenges are now twofold:

  1. If the service provider accepts full responsibility, are they PCI compliant for the service(s)?
  2. If they are only partially responsible, EXACTLY what part of the requirement is left?

Does the service provider need to be fully PCI compliant for you to achieve compliance? The answer is no, but if they are not, you have just doubled your assessment scope. Again, someone has to answer the questions, so if your service provider has not validated compliance for the services they are offering, you need to add them to your validation efforts.

As for the partial responsibility, that’s easy, get your service provider to tell you what they’re doing. For example;

DSS Req. #


Service Provider Responsibility Client Responsibility

Examine data-flow diagram and interview personnel to verify the diagram:

*  Shows all cardholder data flows across systems and networks.

*  Is kept current and updated as needed upon changes to the environment.

SP will provide initial diagrams in Visio format for the pre-production environment but will not own, manage, or keep up-to-date the data-flow diagrams post-production.

 This requirement is not part of SP PCI Report on Compliance dated [Mmm dd, yyyy]

Client must own, manage, and keep up-to-date all data-flow diagrams for inclusion into their own PCI compliance efforts once services have reached a production state.

You must repeat the above for EVERY requirement in the PCI DSS v3.0, then add this as an addendum or annex to your signed service contract. This applies not only for the services they are providing DIRECTLY, but the SP has a responsibility for any SUB-contractor they may bring in, and so on down the line.

Again, SOMEONE has to answer the questions!

However, let’s back up a bit and handle each DSS Requirement in turn:

12.8.1 Maintain a list of service providers

Easy, just maintain a list of Service Providers, with – at a minimum – the following detail;

  • Company Name
  • Service Description
  • Is [CONFIDENTIAL] Data Shared?
  • Regulatory Compliance Date
  • Status Verified By

12.8.2 Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess or otherwise store, process or transmit on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.

Even easier, they wrote it down for you!! Include – again, at a minimum – the language in red in your contracts. You will likely want significantly more than this as there is no declaration of LIABILITY, or even SLAs.

12.8.3 Ensure there is an established process for engaging service providers including proper due diligence prior to engagement.

If you don’t have robust vendor due diligence and vendor on-boarding/off-boarding processes you are really asking for trouble. For PCI services, if you have not ensured they are PCI compliant for the services they are providing AND you have the full details written into contact, then you have created a world of pain for yourself.

12.8.4 Maintain a program to monitor service providers’ PCI DSS compliance status at least annually.

Does this say anything about the service providers actually working towards PCI compliance? No, it doesn’t, so the status could be; “They will never achieve PCI compliance.” and this is good enough for PCI. This should NEVER be good enough for you.

12.8.5 Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.

This we’ve already covered, all you need is a table, like the above, of every PCI requirement handled by each of your service providers and their sub-contractors. Your QSA can then tell you precisely what is left for you to cover for full compliance.

Whether you’re assessing for the first time, or re-assessing under v3.0, you need to start these conversation with your service providers NOW, as while this may be simple, it is not easy.

Advice for Merchants:

  • Only choose PCI compliant service providers (start here; Visa Europe Merchant Agent List)
  • Only choose service providers who have already addressed 12.8.2 and 12.8.5 up-front. You should not have to ask for this from SP worth their salt
  • If you have existing SPs and don’t know where to start, hire a decent consultant who is familiar with the PCI DSS to help

Advice for Service Providers:

  • Get your responsibility mappings and your contract language sorted out now, BEFORE you are asked
  • If you need help, ask for it, ignorance is not an excuse your clients can accept, nor can the card schemes

Easy huh?

The Future of Retail Payments (The Rise of the Service Provider Integrator)

[It’s clear that this topic has wayyyy too much material for just a blog, so at some point I’ll back this up with a white paper or some such. Please accept this as an amuse-bouche];

Today, the savvy buyer does their homework on all major retail expenses, ensures they have they the funds for it (debit or credit), and finds the best deal BEFORE buying.

The non-savvy, or impulse buyer, tends to get hosed, which may result in several things; the buyer either changes their minds and returns the item (and/or gets into financial difficulty), the merchant has a second-hand system to get rid of AND has the hassle of a charge-back, and the financial institution behind the payment runs the risk of non-repayment of the resulting bad debt.

While you’re never going to get away from consumers making bad decisions, you CAN make level the playing field, and make the experience for all parties less risky, more efficient, and potentially cheaper all round.

Two of the challenges we face today are:

  1. The vast majority of new businesses in the payments space are innovators, and have a very narrow focus. i.e. see a need, fill a need from a niche perspective. So if you’re looking around for those types of services, you have hundreds of small organisations from which to choose, and you either gamble, or wait until the market settles down and risk missing out entirely on a potential competitive edge.
  2. Every player in the payments ecosystem is either a dependent, or in competition, leaving everyone worse off, especially the consumer. You just have to look at the number of e-wallets, coupons, or loyalty point systems to see that 99% of them are unsustainable. The corollary is that new innovations in the retail space are very slow to be adopted, if at all.

So how do you choose the right combination of payment services for YOUR business?

Choose the right one(s) and the benefits are clear and ongoing, choose the wrong one(s) and you’ve potentially damaged your brand reputation. How many times have you collected loyalty points (for example), and never had the opportunity to enjoy the benefits?

The biggest issue the payments ecosystem faces it that the true cost of an expense if rarely apparent up front, and your payment options are limited to the offers of either your existing financial institutions, or of the retailers themselves.  Instead, what if the banks made available enough information at the time of purchase for you to choose the RIGHT payment option?

Bob Mackman wrote a short white paper How to Pay: The Future for Mobile in m-Commerce, in which he posits that for a mobile application to;

…weigh up the advantages of each [payment method] by looking at things such as: available credit, due date, interest rates and any loyalty schemes and give them the pros and cons of each for this particular purchase at this moment in time. Perhaps putting them into an order of preference.

…that the background financial institutions would first need to provide;

“…direct access to the information from the bank and card accounts being used. If the providers made API’s available for even just some basic transactions then this would be possible.”

You can imagine how often his happens currently.

But, if the banks could see the amazing potential this provides, then this would not be the “pipe dream of a romantic“, as Bob puts it, but a reality in which anyone NOT providing these services is left behind.

Like most things, it’s not that easy. For this to truly work you have to consider all of the following and many more:

  1. Authentication – ALWAYS the primary consideration in payments
  2. Ratings & Reviews integration – against financial services, retailers, products etc.
  3. Big data analytics and customer profiling resulting in targeted displays / coupons based on instant access to metadata of preferences (e.g. material / colour / designer)
  4. Existing payment technologies – PEDs, EMV, NFC, e-wallets and so on…
  5. New[er] payment technologies – Bluetooth beaconing, geolocation, bio-metrics and so on…
  6. Payment choices / instant credit through existing financial institutions (which has dependencies on single purchase interest rates and unaffected credit ratings etc.)

So who’s going to be able to put this all together? No-one currently, but in much the same way that the enormous growth of telecoms options resulting in a spin-off industry of consultants providing consolidation / savings services, the soon to be exponential growth of payment technologies will spurn a new breed of consultant; the payments Service Provider Integrator (SPI).

From banks, to payment gateways, to ratings & reviews, to loyalty, to anti-fraud, the SPI will be able to seamlessly integrate all the niche providers into a whole-istic solution designed to meet an organisations goals.

Here I must stop, but this will continue in more detail in the pending white paper.

If you have any ideas around this stuff, please share, I’ll make sure to build it in.


Vendor Due Diligencce

Vendor Due Diligence: Assessing Cloud / Service Providers

There is a lot of confusion about how to treat Cloud providers from a vendor due diligence, or compliance assessment perspective.  I’m not sure why, they are just another service provider. The Cloud, in and of itself, adds nothing.

My thoughts on The Cloud are not a secret; Don’t Get Me Started On ‘The Cloud’, but it needn’t be all negative.

So you have – or you want to – outsource/d some aspect of your business function, usually an ancillary part, unless your business is almost entirely white labeled (like in e-commerce for example), and must therefore ensure that the service provider treats your data and/or systems the same way (or better) than you do.

In theory, the only reason you would not be able to measure your service/cloud provider against a defined standard, is if you don’t have one.  You have one, right?  That, by itself, precludes your compliance with ANY standard or accepted good practice.

All too often the real issue is that organisations are trying to outsource their problems (PCI compliance for example), and not focusing on their business needs in general.  While you can outsource almost every business function you can never outsource responsibility.  You can even outsource some of the liability (cyber-insurance for example), but it’s your name that will be dragged through the mud if things go wrong.

It bears repeating; You can NEVER outsource, or in any way deflect, the responsibility for the protection of the data you control.

The way to look at this is to see all 3rd parties / vendors as just a different department of your organisation.  You should have THAT kind of control, and it’s up to you to ensure that they are meeting their commitments.  Service Levels Agreements (SLAs) are a difficult concept, especially for Cloud providers, but that should not your problem, it’s should be theirs.

Here’s a lengthy but good article from IBM on SLAs; Best Practices to Develop SLAs for Cloud Computing

They may have just chosen to jump on the cloud bandwagon, and see this as a way to multiply their client base using the same, or retro-fitted, infrastructure (you need built for purpose).  Calling it a cloud service is, in this case, another phrase for smoke and mirrors.  However, there are some excellent cloud/service providers out there, and you will know them by the way in which they answer, or in some cases entirely pre-empt, your concerns.  They will:

  1. come to you with detail about how they will manage your systems / apps etc, and this will almost certainly support your policies or compliance. Ideally the services will be independently certified as compliant (against PCI for example, and if relevant).
  2. have no problem incorporating your policies or regulatory reporting needs into their service.  They may already exceed yours in this respect if they follow the concept of go-with-what’s-hardest-and-everything-else-is-covered.
  3. have various levels of SLA already defined from which to choose.  Be VERY wary of any cloud / service provider who has no pre-defined SLAs.
  4. have a seamless way for you to measure them against the SLAs.  The old misquoted cliche; You can’t manage what you can’t measure, while irritating, is completely appropriate here.
  5. be able to assist, or train you, to find everything you need during a compliance assessment.  YOU must be able to answer your auditors/assessors questions, you can’t just point at your vendor.

If you don’t have a vendor due diligence program, you need to get one.  If you don’t have a set of defined policies and business need SLAs, get them.  And if you don’t know how to go about any of this, ask someone who does!

Just like in Top 10 Roadblocks to PCI Compliance, not knowing how to do something is not an excuse, there are quite literally hundred of experts who can help you.

Find one.

[If you liked this article, please share! Want more like it, subscribe!]