The cybersecurity industry is aflutter with news of attacks. Through each incident, the spotlight centers on what the organization did wrong. Human error is the assumed root cause, and rightly so considering its role across high-profile attacks.

But industry is also seeing more novel schemes eke out the security foundation companies hope to rely on. When an organization is working with a vendor, any security assessment pre-contract could mitigate a supply chain-style attack.

A vendor with a checkered security incident past is not automatically disqualified from future contracts. Rather, there is a playbook for due diligence, one where executives ask how vendors respond. And in the event of a past security incident, a customer can make an informed decision about whether the organization has invested enough in its security technologies and strategy. 

Cybersecurity Dive asked executives whether they'd sign a contract with a vendor that previously suffered a security incident. The comments below have been lightly edited for length and clarity.

Ryan Leirvik, CEO of GRIMM

---

"Being clear on what the real risk is means identifying the key critical assets and systems that endanger the organizational sustainability or threaten the organization's core business functions."

Ryan Leirvik

CEO of GRIMM

---

Very few events increase a company's interest in cybersecurity like an incident. The sheer realization of an uncovered risk has an uncanny influence on both executive and management attention on risk management of future events. 

For many companies, executives and boards tussle with exactly how to understand and manage cybersecurity risk. Typically, and many times unfortunately, organizations began to focus on what is most valuable to protect after a breach or an incident. 

The protection of critical assets becomes a sharp, well understood risk to manage after an organization experiences a cybersecurity incident. Being clear on what the real risk is means identifying the key critical assets and systems that endanger the organizational sustainability or threaten the organization's core business functions.

This means having a sharp understanding of the risk through categorizing the critical assets and determining the causes of an incident. Once exposed, these risks typically become the center of a new, or renewed, interest in cybersecurity for the organization, usually leading to a longer term, sustainable cybersecurity risk management program. 

So, when asked "would you sign a contract with a vendor that previously suffered a security incident?" there are three probing questions one could ask the vendor to gain sufficient insights into the organizational thinking and fundamental management in cybersecurity, post-incident: 

• Do you have a clear understanding of the risk? 
• How are you managing that risk?
• How are you measuring the reduction of cybersecurity risk?

Then, make the sign or not sign decision. 

Oliver Tavakoli, CTO at Vectra

---

"The question is not whether a vendor has suffered a security incident, but what you can surmise about the vendor's security practices from the published information about those incident(s)."

Oliver Tavakoli

CTO at Vectra

---

One must start by defining the criteria for how bad an attack must be to earn the label "security incident." If one employs a broad definition for this label, then not signing contracts with companies who have previously suffered a security incident will seriously limit the choice of products available.

It would also bias purchasing decisions toward younger and less mature vendors who may simply not [have] been around for long enough to be hacked or have not achieved sufficient relevance to warrant attention by skilled hackers – which does not necessarily mean that they are less likely to be hacked in the near future. 
 
So, the question is not whether a vendor has suffered a security incident, but what you can surmise about the vendor's security practices from the published information about those incident(s).
 
I base my judgment on a vendor's commitment to safeguarding the customer data they hold and protecting the software they build on the following factors:

• Has the vendor been repeatedly hacked and is there a pattern that points to the organization not learning from past mistakes?
• How sophisticated were the attacks which led to the breaches? Form your own opinion on this rather than trusting the vendor's characterization which will almost always characterize the attack as "extremely advanced" and "unprecedented in scope."
• Has the vendor disclosed the breaches in a timely manner and with sufficient transparency, or have they tried to whitewash and stonewall?

A vendor who has few security incidents, gets hacked as a result of substantial effort and skill by an adversary and is timely and transparent in disclosing the breach gets my business – more so than a company which has only been shipping product for 12 months and has not had security incidents.

Matt Klein, cybersecurity executive advisor at Coalfire

---

"If an organization wants your business or wants to keep your business (and your trust), they will work to answer questions about the security incident, how they are addressing the situation and any long-term plans to reduce the chance it will happen again."

Matt Klein

Cybersecurity executive advisor at Coalfire

---

The answer is… it depends!
 
A security incident, especially incidents that result in sensitive data loss — think privacy and personal information theft — can severely impact trust. If this is a new company you are doing business with, do your due diligence as you normally would but certainly bring an elevated amount of scrutiny to your third-party risk management processes. If this is an existing supplier or partner, elevate the discussion to the proper executive levels of the organization.
 
If an organization wants your business or wants to keep your business (and your trust), they will work to answer questions about the security incident, how they are addressing the situation and any long-term plans to reduce the chance it will happen again.

Ask tough questions of the CEO, CIO, CTO and CISO. And when you ask those tough questions, pay close attention to the answers. Do the responses feel genuine, honest, and transparent? Some example questions might include:

• Did the organization discover the security incident or was the incident revealed by a security researcher or major media outlet? (To understand detection capabilities)
• What were your incident response procedures, and which external organizations were involved in the recovery? (To understand recovery capabilities)
• What has this incident meant for the funding for your information security program? (To understand organizational improvement intent)
• What are the major improvements you need to make to reduce the chance for another security incident? (To understand if an improvement plan exists)
• Does the organization support what it takes to stop future security incidents from occurring? (Overall, is there commitment to be better) 

Remember, many organizations have security incidents. As a buyer or business partner, you will want to know if the organization is serious about security and doing the right things to reduce the chance and impact of another serious incident. Have your tough questions ready.

If you don't like the answers, take your business elsewhere.

Kevin Dunne, president at Pathlock

---

"An incident track record is a backwards-looking metric that doesn't predict the risk to you as a customer when you go forward with a particular vendor."

Kevin Dunne

President at Pathlock

---

Security incidents are commonplace nowadays — any vendor that thinks they are immune simply hasn't been targeted yet.

A single (or even multiple) security incidents are not grounds alone for disqualifying a vendor for business. What matters most is how the vendor is prepared to prevent, detect, and respond to security incidents in a predictable fashion.  
 
An incident track record is a backwards-looking metric that doesn't predict the risk to you as a customer when you go forward with a particular vendor. Understanding a vendor's security program and posture is time consuming and it's typically not feasible for a customer to perform in depth due diligence on each and every vendor that they might plan to work with.  
 
Security certifications and audits, such as SOC 1 and SOC 2, as well as ISO 27001, are becoming a key requirement for vendors looking to work closely with enterprise organizations, especially when they operate in the cloud and/or process customer data.  

Vendors that want to earn the trust of enterprises should look to achieve these certifications as a testament to their security posture and ability to avoid major security incidents going forward.

Eddy Bobritsky, CEO and co-founder, Minerva Labs

---

"If the vendor gave me the relevant information and it seemed like the case has been taken seriously and the right steps have been made to prevent incident and breaches, I would sign a contract."

Eddy Bobritsky

CEO and co-founder, Minerva Labs

---

A security incident has a lot of meanings, some of them are severe and some hardly make any difference. Security incidents can also happen for various reasons, some are very easy to fix, and some are deep and will need a lot of investment to repair. 

The most important thing when signing a contract with a vendor that previously suffered a security incident, is to have a complete and transparent explanation from the vendor itself, explain what has happened, why and most importantly, what are the steps that have been made to prevent this (and other) incidents in the future. 

For example, if the security incident is a leak of marketing data and has happened due to an employee that leaked this information, it is not that risky for the customers.

However, it is important to understand if other and more sensitive data was at risk and what are the steps that have been made to prevent from employees from leaking information (educations, the right permissions etc.) 

If the security incident was a ransomware attack, it is important to understand what data was compromised, how long it took to end the attack and why it has happened in the first place. If the answer will be that the company used complex tools that needed a very highly skilled security team (that it obviously a wide path for mistakes), and that the client data was very reachable, and the steps that have been made were only updating the cybersecurity platform, it might prevent me from signing a contract. 

In conclusion, if the vendor gave me the relevant information and it seemed like the case has been taken seriously and the right steps have been made to prevent incident and breaches, I would sign a contract.