Image
Accountability
Nothing works unless you pin down vendor, key downstream supplier, partner, and your own responsibilities. A RACI (who is Responsible, Accountable, Consulted, and Informed) solves nothing. But the process of thrashing one out at a useful level of operational granularity with all of those who might have skin in the game can kick off substantial culture change. That’s if you keep an attendant record of all of the dependencies, limitations, assumptions, risks, and issues raised. This is our management system equivalent of walking a mile in each other’s shoes and keeping a diary of the pain when we do. No-one should be able to claim they didn’t know it was their job, assume that the impact is trivial when they drop the ball or throw it over the fence to another team.Demarcation
Almost in the same pot as creating a RACI and fostering associated buy-in, this is about the letter of contract law. It’s about making sure it is a legal requirement to have someone appropriately qualified in post (your side and their side) to perform essential roles. Here, it’s setting out expectations for responsiveness in terms of speed, regularity, and quality of inputs / outputs, then being crystal clear about the point where your job ends and theirs begins. If you don’t, it will work itself out, usually in a lawyered-up standoff within days of some high-profile product launch, critical audit finding, or some system vulnerability getting noisily exploited by a nasty threat. Key targets for this effort (far from exhaustively and depending on nature of supply) are incident management; risk management (especially metric collection, measurement, and reporting); security event logging, monitoring, and management; identity and access management (especially system accounts, remote accounts, offshore support accounts, and god-like access); project management; threat and vulnerability management; their own downstream vendor management; physical and information asset management; cryptographic key and certificate management; backup and recovery management; data retention limitation; secure data and device destruction; and availability and capacity management. And build in an ongoing commitment to review and update that picture in case of change.Escalation
Again, this is fundamentally linked to the above points, but it’s more than worthy of its own paragraph. As I tweeted again just the other day, a system without means to rapidly deal with exceptions is not just broken. It’s destructive. Partnered with another hopefully not too trite one, the later you escalate, the more it sounds like an excuse. Too often as the buffers are hit when trying to get stuff done, people are slow to face the fact they don’t have sufficient means or authority to fix it. Often because those who are one step up the line don’t have the understanding and support of their management team. Using the output of that work to thrash out the RACI (It keeps coming in handy.), set out regular routes to escalate engagement blockages and standard ways to describe risks. Get the conversations to the right places as fast as possible. If you have done the other things recommended, you should have concrete information to go with that, and those you escalate to should be ready to help and know what you need them to do.Rolling assessment
Of course, none of this is one and done. Especially the part we haven’t discussed: the technical and procedural controls assessment. Whether it’s a full SOC II type II audit against standard and bespoke controls, pen testing, red teaming, another own brand of vendor tyre kicking, or taking what the vendor gives you (with more or less lip service paid to actual fitness for purpose and effective operation), it’s out of date from the moment it’s over. There should be a core of continually assessed controls to reassure you of service availability, security and data protection, e.g. metrics for uptime, vulnerability management, IdM, and timely management of data subject requests, followed by at least an annual rechecking of other controls. There should also be tracked treatment of any findings that fall short of your risk appetite. Does that feel like I’m stating the obvious? It should, but too many firms figuratively or literally put the report in a draw until assessment time comes around again, or something goes bang. But that’s where cloud supply is fun. They have little to no motivation to adjust their suite of operational, security, and data protection controls just for you. Their whole value proposition is based on economies of standardised scale. So that is where your risk appetite has to kick in. You have to be clear on what you rely on cloud vendors to provide (how much data processing, how sensitive is the data, where is the data, how available does the cloud service need to be) and pair it with information they can’t or won’t provide plus detail of any gaps in control they are unwilling or unable to rectify. You also need to give your staff (referring back to that detailed demarcation) the time, means, and skills to do their job. Too often, organisations gleefully realise part of advertised savings by divesting themselves of specialist bodies. Bodies they then have to re-employ at exorbitant consultancy rates. There is no place more critical than where you translate and integrate between processes, technologies, and teams. Those folk with the deep local knowledge who up-skilled to understand how the solution dovetails with your network, systems, processes and needs are your cloud service Crown Jewels. Watch out for single points of failure in that space and treat them well.Risk Appetite
You then take that picture, commonly called something like a risk articulation, and put it in front of whoever you ‘RACIed’ as accountable for the fallout. That’s fallout should those things you can’t assess and those things you know are broken end up hurting the data sets, operations, and people in the firing line. Vendor resistance to these kinds of processes, not to mention being unwilling or unable to provide the kind of information described, should be viewed as a red flag. You should then question whether that type of cloud supply or that specific cloud supplier is capable of reliably, securely, and transparently doing what you need. Having that cumulative picture in hand is the single most effective antidote to expensive experiments driven by folk aggressively pitching the latest tech solution in search of a business problem. (At this point, you are invited to find and replace all mentions of cloud with either ‘blockchain’ or ‘A.I’) In the end, it’s all down to your risk appetite, something you should thrash out upfront when it comes to leveraging all flavours of cloud. If you don’t ask for these assurances, you definitely won’t get them, but to ask the right questions, you have to detail your requirements, your ongoing governance expectations, and what’s needed to mitigate your local risks. There’s no better way to start working that out than to run incident scenarios with those same folk you sat down with to thrash out your RACI. Game out what happens with data misuse, a processing mistake, a misconfiguration exposing data, or a ransomware scenario along with the more usual outage related playbooks. And that, at considerable length, is the skeleton of my antidote to Supplier Stockholm Syndrome. You’ll have noticed that what we have explored above is largely lacking discussion of technical specifics. That’s because the problems I see most are not about finer points of configuration. We can contract specialists to get into the finer points of cloud architecture and bucket security (especially bucket security), but that won’t tackle your biggest risks. What we are almost always missing are the mechanisms to arm those managing vendor relationships with the data needed to do their job. The information they need to be sure of their ground, the contractual clarity necessary to put them on the front negotiating foot, and the support needed to maintain competitive distance while they land you and your management team the best, most stable, and most secure return on your investment.Image
