Third Party Security Assurance has made a pretty poor name for itself. This is due to many organisations paying lip-service to the requirement and not implementing it properly.
Many organisations view Third Party Security Assurance as the need to send your supplier a questionnaire with some security questions on it, and when (or even IF) they send it back, the organisation simply files it away as job completed.
The implementation of the GDPR has created an awakening in this area. Data Controllers remain responsible for the data they pass to third parties, so if your third party messes up, you have messed up too.
So how do we move away from flat questionnaires and actually provide some supplier assurance in this area? After all, this is regarded as a key risk area for all organisations.
It is fairly standard to see the security questions based on some sort of security framework, with ISO 27001 being one of the key certifications that organisations are looking for their suppliers to achieve.
ISO 27001 as a base
Using ISO 27001 as a base, how do we raise the bar on Third Party Security Assurance?
The most frequent question in these sorts of questionnaires is:
“Is your Organisation certified to ISO 27001?”
Firstly, it is a very closed question and secondly it is likely to provide you with the wrong answer even if answered correctly by the supplier.
How can the wrong answer be provided you ask? Let me contrast this question with the one I think should be used in its place.
“Is your Organisation certified to ISO 27001 for the scope of work you will be providing under this contract?
An Organisation can be certified for numerous scopes. Just because an Organisation holds an ISO 27001 certification, it is not safe to assume that it covers the scope of the work you want them to do for you. They could have an ISO 27001 certification for making widgets for Dyson. It may have nothing to do with any other areas of their business or any other client. So it’s possible for the supplier to answer correctly (Yes), but it will give you completely the wrong information to work from.
Policy
“Please provide a copy of your Security Policies including your Third Party Security Policy”
Under ISO 27001, you should be sharing your policies with your external interested parties on request. You should resist confidentiality reasons for not sharing as a response. The logic is that these Policies, particularly the third party policy is shared with third parties, so there is no confidentiality impact as the supplier already has visibility of these, so why can’t the client have them?
If the supplier says they do not share any of their policies externally, this is a red flag. You want your security contract clauses to flow from you, through your supplier, to their third-parties (and therefore your fourth parties) and beyond. If your supplier is saying they do not share this kind of information with their suppliers, a useful question would be:
“How do you intend to abide by the security contractual clauses if your Policies are not passed down the supply chain?”
Third Party Policy is key
The important part to look at first is the third party policy. It should be a distillation of all the other security policies in a form that the third party can easily understand and abide by. Analyse the third party policy to see if you think it effectively covers all of the areas of concern that have been raised in your security contract schedule. If you do not completely understand or agree with what is in this policy, this is what is being mandated on the lower supply chain, so you need to raise your concerns.
“Your third party policy does not cover X. X is a requirement that we have placed on you and require to be passed down your supply chain. Please explain how you will achieve this.”
In general, you should aim for a two shot process of security assurance. Send the initial questionnaire as the first shot, and then a set of questions that have come from your analysis of what may be potential gaps and concerns.
From the answers to these two stages, you should have enough of a picture to determine a maturity score against a Third Party Security maturity matrix.
Your aim from here is to raise risks for the areas of concern, and determine mitigations to those risks.
Incident Management
Incident Management is an area where you can have far greater visibility than other areas of the suppliers business.
No supplier can refuse a joint data breach exercise/simulation. If you have raised a risk in this area about the maturity of the suppliers processes, you should look to arrange such an exercise. If you are concerned with the suppliers third party policy, or you think there may be risks with all of your security contract clauses being passed down the supply chain, why not run an exercise with your supplier and one of their suppliers?
For large suppliers, there is some form of contract relationship management activity that goes on within your organisation. This might be more about SLAs than security risks, but you can sneak questions into this forum that may guide your supplier. Your Contract Relationship Manager will welcome the leverage that being upset about security can give them in their relationship with the third party.
If you ask repeatedly whether your supplier has conducted any access audits on their third parties, it will not take long for the supplier to realise that if they do one of these actions, you will stop asking and feel happier about the contract overall.
This kind of prodding can be used to get your supplier to improve areas that you believe to be risk areas to your organisation. Evidence in the form of minutes from these supplier meetings will show that you are addressing weak areas with your supplier and trying to get improvements made.
This is all about gathering evidence that your assurance process is having an impact.
Planning
It is perfectly reasonable to ask your supplier if they have any security improvement projects planned for the year. If you get an answer, you can assess where they believe they are on their security maturity journey. It is highly likely you will have a confidentiality card thrown at you, but you need to find ways of extracting this information, even if it is over a coffee.
Try to get the highlights of this plan so you can compare it to your internal assessment of the suppliers strengths and weaknesses. If you think a supplier is strong in one particular control area, and you are told that the supplier has a plan to improve that area, this should raise concerns.
If you think the supplier is weak in access control, there is nothing stopping you asking what improvements they will be making to this area in the coming financial year.
Risk Treatment
This is an area where a lot of organisations get this wrong. Do NOT ask for a risk register from your supplier. They will ALWAYS be economical with the truth, because this is the most likely area to hold significant confidential information for the supplier, like the most likely things that can go wrong with your contract.
What you should be doing, is inferring the risk register from the other actions being taken by the supplier. This is a bit of a jigsaw, but once you have found a number of pieces, new ones are added very easily. Comparisons of different snippets of information will allow you to deduce the areas that the supplier is concerned with.
The point of this activity is not to confirm what the supplier risk register is.
You will have a view of where the suppliers risks are. The supplier will have a view of where their risks are. If the supplier is mature in their treatment of risk, you will see this behaviour in their approach to you.
Example
If your IT Outsourcer provides you a notice of an emergency requirement to patch a key server outside of the agreed window, you know they are doing a lot of things right.
If you get significant lead-time in announcements for moving to a new version of an Operating System, due to End of Life requirements, again you can take a huge amount of comfort that the underlying process for ensuring software is maintained is working correctly.
It is these clues that you need to keep track of, and the conclusions you reach as a result of them.
Take the emergency patch example. If your supplier provides you regular notice of such events and then on one occasion, omits to doing so, you can follow up with questions.
“Why was there no early notice on this occasion?”, “Have you identified the issue?”, “Have you fixed it?”, “Will it re-occur?”, “What lessons were learnt from the root cause analysis?”.
All of the answers to these questions will give you more jigsaw pieces.
If you feel that they indicate a problem in a certain area, think of how you would go about finding monitoring data to prove or disprove your theory, then ask you supplier for that information. You don’t even need to explain why you are asking for it. You can simply say that you have a list of monitoring tasks to check over time, and this is the one that was selected this month. Even not being provided with the information is another jigsaw piece. It may mean they don’t monitor that activity. And then you will have another avenue of questions.
Assurance is an ongoing process
All of these jigsaw pieces then go into your supplier security maturity matrix, that evaluates where your supplier is relative to other suppliers.
This matrix will focus you to the correct suppliers and the correct areas of risk that need further work. Continuous Improvement can be shown by the improvement of the matrix scores over time.
You should heavily weight your supplier matrix, such that large improvements are seen when poor suppliers are no longer used by the organisation. This gives the organisation an incentive to remove suppliers with poor security. This result is then self-perpetuating. Suppliers quickly learn that one of your key requirements is security, and if they want to win contracts with your organisation, that is an area they must visibly evidence.
More in Part 2.
Congratulations on yet another thought provoking blog article. I have more experience in this area than is healthy and I just wanted to pick up on a couple of points and expand on them slightly.
I particularly like your focus on demonstrating the value in your assurance programme. We’re all fighting for our budgets and if you want to do the best by your organisation and continue to pay your mortgage this principle should always be kept in mind.
With regard to the security policy request, in fact requests for all policy documents, I think many people ask for this document and they don’t know what to do with it when they get it.
What you’re actually looking for are more atomic enquires ie;
* Is there a security policy?
* Has it been reviewed within the last 12 months? (to confirm it isn’t shelfware)
* Does someone important own the policy? (to make a reasonable assumption that repercussions will swiftly follow deviation)
* Is compliance with the security policy mandatory with consequences for non-compliance made clear?
* Have staff read the security policy?
* Do staff understand their responsibilities?
So for any piece of information you request it really is essential to know why you are asking for it and what you’ll do with it when you get it. Many supplier security programmes are only satisfied by taking receipt of the actual policy and don’t actually review the contents at all.
I also wanted to call out the ISO27001 question or more generally mentioning any other specific certification. I usually phrase this question along the lines of “Please provide evidence of any independent external verfication of your security capability” and let the supplier choose which certs to provide. An ISO27001 certificate might be on the roadmap but many SME’s just don’t have them yet. Obviously its cleaner and easier to review the security of an organisation that has an ISO27001 cert vs one that doesn’t. But you will usually pay more for that maturity. In terms of remaining relevant and being impactful it is not wise to always be recommending the most expensive suppliers. Also the market is saturated with fintech’s right now spending VC money and none of that VC money was acquired by promising security certs. Essentially what I’m saying is that in a perfect world you’d only pick from suppliers who all have ISO27001 certs, but in this real world the business will pick suppliers from all over.
Best of luck, looking forward to part 2!
Thanks Alex. Totally agree on the general verses specific certification. Smaller companies have not invested in many certification areas yet and it will interesting to see if this evolves into a growth in certification or a reversal of large corporate behaviour to insource more.