We are all increasingly dependent on third parties for our security, and most folk are doing a shockingly bad job of managing related risks.
Target and their air conditioning supplier, OPM and just about all their key suppliers, Mossack Fonesca and 2.6 BILLION odd Panama papers, potentially relating to ALL 300,000+ clients it has acted for…and the risks come from a number angles:
Security vendors: From the odd independent consultant, to fully outsourced security operations and related processes. And for clarity, that’s ‘fully outsourced’ in name only:
You always retain the lion’s share of legal/regulatory liability, the most impactful share of potential brand damage, responsibility to set/check benchmarks, and control of the majority of usage related risks. And that is relevant to all supply arrangements.
Large IT providers: The days of fully owned data centres are numbered. Who can afford it beyond the biggest financial institutions? Even if you own your data centre, you almost certainly outsource large portions of other IT provision, starting with your network support and telephony. In other words these are the players who rate a ‘critical’, ‘material’, ‘strategic’ or other top right quadrant spot on your procurement risk matrix.
Other vendors: From the milkman to your CRM system provider, your lawyer (topical as mentioned above), other cloud solution providers of various flavours, data analytics vendors (a risk minefield all of it’s own) and everyone else down from those top tier IT providers. Each and every one has potential to cause your business security related risk. You have a responsibility to assess and confirm if the risk caused by the small fry is tolerable, and do due diligence/assess/regularly govern the rest.
These 10 focal points (half now, half in part two) are relevant to all of them. And (here’s the kicker) NONE of these things rely on a GRC tool. There’s plenty of data to wrangle, but it’s about legwork and persistence in the beginning.
First steps; early engagement, doing triage, clarity about vendor selection and contractual requirements, building agreement to future-proof, and accountability…or…backing up to the alphabetic beginning… EDCBA:
ONE – Early engagement:
If you don’t hear about a supplier, you can’t assess the risk. If you hear about a supplier just before, or (all too frequently), after contracts are signed, your only remaining control is hope that they have their security house in order. Plug into procurement, change initiation, legal, architecture, and strategy approval forums and functions. Wherever you find a bright ideas factory you need a seat at the table and a mandatory hook for engagement. And, as back stop, spend one financial cycle reviewing accounts payable against the list of suppliers you get to find out about. Shadow supply isn’t free supply. Unless staff are personally financing new services or products, that’s where you’ll find details.
You can’t fix shadow supply single handedly, nor are security functions liable to do so, but you can flag the residual risk to effectiveness of your process and to the business.
Don’t have a CISO reporting to the board? Don’t feel you have the clout to open those doors? Then KNOCK. Effective engagement is helped by seniority and sponsorship, but getting sponsorship and effectively engaging is not dependent on seniority. Do your research on the scale of the risk linked to your 3rd parties and pick up the phone.
TWO – Doing triage:
When engaged, if early, what’s being procured is frequently only understood at a high level. You need to triage on equally high level bases to understand the level of due diligence and on-going engagement required, then ensure that view is refined as requirements crystallise.
- Will staff, systems, sites or processes hosted/supplied/developed, handle confidential data?
- What data (payment cards, PII/PSI, financial reporting data, intellectual property, insider info – e.g. mergers and acquisitions info)?
- How much data?
- Where geographically (cross-border data protection, threat level, surveillance oversight)?
- Will they be an operationally critical supplier (recovery and resilience)?
- Will they need physical access to company premises?
- How many employees will be involved in servicing the requirement (a solid correlation to inherent risk of a data breach according to new research – see the graph from Vivo Security below).
The latter represent a subset of the high level absolute and conditional criteria typically used to produce a first heat-map view of the supplier base. If people bringing a suppliers on board don’t know answers to these kinds of questions before contracts are signed, they should be
shot rapidly educated.
Don’t fall into the trap of trying to ask about specific controls and how they operate at this stage. It’s a false economy for 3 reasons:
- Each additional layer of information requested exponentially increases the length and complexity of questionnaires. And, as a direct result, reduces the likelihood of a high response rate.
- Going into control detail makes it more likely specialist knowledge is needed to answer. You want business contacts who initiate and manage supplier relationships to be able to answer. If they have to refer to specialists, or the supplier themselves, it degrades the value and delays completion.
- Asking about control specifics, or too much detail lowers the likelihood that questions can be answered early. You will likely be TTFO until the agreement is far closer to getting a signature on the dotted line, at which point, there’s no point.
There are quick, simple, smart ways to plug this triage activity into related processes and ensure reliably high engagement, including backfilling for pre-existing suppliers (you are welcome to get in touch to ask how – no rocket science involved).
THREE – Clear and fit for purpose pre-contract and contractual requirements:
Your security policy does not equal the benchmark for supplier security. It is an expression of YOUR risk appetite based upon YOUR risk profile and environment.
“Thou shalt comply with our policies!”
…and you’ll spend more time trying to deal with commercial/lawyer push-back and exceptions than getting what you want. Build requirements that can be filtered to apply to different supply arrangements where the triaged view of inherent risk indicates a policy, regulatory, or legal need. Include them in Requests For Information (RFIs) and Requests For Proposals (RFPs) to set expectations, then refer out to them from contracts.
Critical things to pin down in contracts* beyond your security benchmarks?
- Who has final say in a dispute over ‘adequate’ security
- Who pays for remediation when security standards fall short
- Service demarcation. Where do supplier responsibilities stop and yours start? Especially critical where PCI scope is potentially affected.
- Right to assess/audit including any pen testing and continual control / vulnerability monitoring justified by service type.
- Requirement to evidence control status, not just existence/design of controls.An ISO27k certificate, or ‘letter of confidence’ after a SOCII audit doesn’t prove compliance. It proves some kind of assessment has been done on controls…which could be totally broken.
- Requirement to create and maintain a physical kit AND information asset inventory. What, how much, classification, owners their side and your side, location, who it’s shared with, unique identifiers.
- Requirement to notify you if data is shared with anyone new, or the geographical location changes.
- Requirement to be able to locate and return data within defined timescales at contract exit, when legal retention time is up, to service clients’ Subject Access Requests (right to know what data you hold about them) and Right To Be Forgotten.
- Requirement to have a named security expert as primary liaison on both sides. Evidences security capability and commitment on their part and enables smooth operation of incident notification, governance, and escalation.
- Requirement to share requirements with downstream suppliers and provide assurance they are meeting them where they are involved with servicing contractual needs.
- Incident notification timescales and mechanisms. Frequently also turned into SLAs based on legal/regulatory vs policy notification requirements – the new EU Data Protection Requirements have potentially game changing notification requirements.
Organisations will need to report a personal data breach to DPAs “without undue delay and, where feasible, not later than 72 hours after having become aware of it” unless that breach is “unlikely to result in a risk for the rights and freedoms of individuals” Out-law.com, 16th December 2016
- Requirement to attend regular governance meetings at a defined frequency
- Requirement to report at a defined frequency on status a subset of continually operated controls. It is always worthwhile to shift oversight of controls away from ‘big bang’ point-in-time assessments, but metrics need to be fit for purpose.
- Don’t, PLEASE DON’T, put granular control requirements verbatim in contracts. List them in a separate schedule, or an entirely independent document refererenced in the contract. Why? See point four.
*I am not a lawyer, but I have worked incredibly closely with many, many lawyers on many, many contracts (including a billion pound outsourcing deal). Don’t however take my word for it. Talk to your own legal team.
FOUR – Build agreement to future proof requirements:
Requirements will likely be out of date before the end of the contract term (the bigger and riskier the contract, the longer the likely term – 10yr deals are not as rare as they should be for big outsourcing arrangements), or you’ll give ‘permission by omission’ to exclude controls not initially specified.
Technology evolves, threats evolve, new vulnerabilities are reported, and new exploits are developed to take advantage of them. Your risk appetite, business objectives, and use of pre-existing suppliers all evolve. It is therefore utterly nonsensical to set your security requirements in immovable contractual stone. Make a review of security requirements a contractually defined part of contractually required regular governance.
FIVE – Accountability:
There’s a strong argument for this being number 1. If there’s poor/late engagement despite best efforts, or a supplier who says “Hard luck, you’ll get the security we give you and lump it” you need someone to tell. A person who can own any potential risk if those problems aren’t fixed, or if you’ve done an assessment and problems are found.
Mears said the legal department is “the first line of defense,” noting 61 percent of survey respondents said their company relies on contractual agreements to obtain visibility into their vendors’ data practices. “I think that it is entirely possible that the general counsel or the legal department will become more and more integrated into third-party management,” she said, adding that managing third-party cyber risk is still an “immature” process at most companies. Rena Mears, a managing director focused on cybersecurity at BuckleySandler in this Bloomberg article
I don’t agree (not just on the basis Mears works at a law firm). No single team is the first line of defence. Having a robust view of key responsibilities, and role holders who formally accept accountability and responsibility, is the first line of defence. Having clear, easy to use, and mandatory means to engage the right stakeholders at the right time comes a close and dependent second.
It was someone’s bright idea to employ that supplier and payment is coming from someone’s budget. Procurement systems are therefore a good place to start, but a full RACI should be thrashed out as part of setting up any vendor security governance programme. Below is an example to consider.
TIP: Neither the security function, nor procurement can own the risk of an incident caused by broken security related controls…unless they are 100% responsible for operation and maintenance of controls, and the only team potentially impacted by an incident. Your rule of thumb for risk ownership is who will say “Why wasn’t I told about this!?” after an incident. That single cultural ‘misunderstanding’ is enough to derail any effort at getting this (or any other security undertaking), right.
Not just that, “It says so in the contract” is your backstop. A backstop that should be relied upon only when something has gone wrong. Getting those contractual benchmarks, levels of liability, remit demarcations, and audit requirements right is vital. Ditto for landing that RACI. But as soon as contracts are signed – in the BAU churn – making sure the supplier continues to do the right thing is about relationship management and expert communication more than anything else.
So that is part 1. Part 2 out soon with some more vendor security ABCs (or CBAs). And here, if interested, is a link to the full set of slides featured in parts of this post.