ISO 20000 defines the objective of incident management (part 1, 8.2) as: To restore agreed service to the business as soon as possible or to respond to service requests. Third-party incident management (TPIM) has the same goal with the added complexity of mitigating risk from a vendor product or service.
There are an increasing number and severity of third-party incidents, and, as I like to say, everyone is someone else’s vendor (third party). This means everyone is experiencing an increased level of incidents and breaches of their third (and fourth) parties. Prior to the pandemic, many studies showed that around 70% of companies had no more than an ad-hoc cyber incident management plan. Further, more than 60% of companies reported having no more than an ad-hoc cyber third-party due diligence program. Organizations are struggling to develop and run both in this ultra-active cyber environment. The steps to getting on track and achieving better control of this orphan process start with the who, what, when, where, why and how of TPIM.
Who: Depending on the size and space of an organization, the personnel involved in the incidents needs to be decided. In most cases, a company’s cyber incident management team owns the incident management process for cyber events. That should not change, but a vendor incident requires someone to investigate if there is a relationship with this outside company. In most cases, an attorney should be involved if the level of the event rises to a specific threshold (more on that in the “when” section). Whether you are in a highly regulated space or not, there are often requirements to notify both the regulators and any customer who is victim to a breach at your third party. Who does the vendor notify at your company? Do not make it more than one or two roles at the most. Provide a phone number along with an email address: with ransomware attacks, oftentimes their email is not available or is suspect.
What: As with anything needing to be organized and dealt with, there must be an inventory or database of all third parties a company works with. This cannot be done if there is no system of record with valuable information about the relationship, such as type and quantity of data, an internal business owner or other connections between the third party and a company. What are the dependencies for your organization on this vendor for other critical activities? These dependencies need to be mapped out for critical third parties prior to any incident or event so important decisions can be made about whether to sever a connection in the event of a breach.
When should a team act and escalate versus process the incident or issue as any other vendor gap or finding? There must be levels or priorities given to the events. Define an incident versus a breach: where an incident is a security event where data was exposed, but not exfiltrated. A breach is when the data is taken. The level of risk and concern should be different for not just these two types of events, but the priorities of activities within them. A breach of 50 customer accounts versus 50,000 will involve different levels of concern and activity. Establish levels or priorities within the process to aid with ensuring the best protocol based upon the risk to the company.
Where is your data? The inventory discussed in the “who” section requires a follow up: which third parties have access to sensitive data. The answer is not always with a third party — a fourth party, such as a cloud services provider, could have direct access to data instead. Asking vendors where sensitive customer information is held (what zone and disaster recovery zone) is crucial. This can allow an organization to understand items such as concentration risk.
Why should the vendor inform a company of a security event? Because it is in the contract. There is no reason to do so without a contractual obligation. When a vendor is going to process or store sensitive customer information or have a connection to your network, there must be cybersecurity-related language in the contract. Be sure to require notification in case of a security incident or breach within no more than twenty-four to forty-eight hours. Define the terms “incident” and “breach” in the contract and ensure that the legal liability lies with the vendor due to their failure. Due to the potential for expensive litigation and regulatory penalties and fines, there is no reason why a third party would notify a company if they are not contractually compelled to do so. Get it in writing.
Finally, how will your organization perform the TPIM process? The activity can start by asking “How do we get notified in the event of a cyber incident?” This can come in a myriad of ways, like email or phone notification. However, it could come from the news, a cyber intelligence feed, or a colleague who heard from another peer. Once the intake methods are cataloged, the information must reach the agreed-upon employee. The “who” then determines the personnel involved, what they do and who they hand steps off to in the TPIM plan. Mapping out the steps of who is involved, what databases are checked for vendor data risk, when is the risk elevated or not and where the sensitive data is stored leads to a repeatable process that can get more mature with tabletop exercises and collaboration from critical vendors.
Third-party incident management is now a required piece of any incident management plan. Define some answers to the common six questions of who, what, when, where, why and how to get the solutions needed to this reduce this critical cyber risk.
Source: https://www.securitymagazine.com/articles/96362-the-five-ws-of-third-party-incident-management
