This is the third in a three-part guest blog series looking at risk management throughout the lifecycle of a third-party relationship. Previously we looked at the onboarding process, then we explored ongoing security monitoring throughout the relationship [link to posted article], and now we look at offboarding and terminating a relationship.
Goodbyes are difficult. Humans tend to avoid goodbyes. If it is a beautiful close relationship or one that ends in frustration, anger, and tears… most do what they can to avoid goodbyes because they are difficult. Ironically, this is true of organizations as well.
The most neglected part of the lifecycle of a third-party relationship is the goodbye. The termination of the relationship. It doesn’t matter if the relationship was very productive and served, or even exceeded its purpose, or if the relationship soured and failed. In either scenario, organizations neglect proper offboarding and closure procedures in a relationship.
This is a critical concern in the context of information security. I have encountered organizations’ network connections, VPN access, and access to systems that remain active long after the relationship is over. Even if there was no network access, or if that access was terminated, there still may be data and property of the organization that the third party has internally on file servers, physically, and can live on in archives.
Terminating a relationship is not to be approached haphazardly at the end of a relationship but should be carefully defined in contracts and controls in the onboarding of the relationship. As relationships change over time, such as expanding services, it is also necessary to update the scope, controls, and responsibilities for termination throughout the relationship. The last thing an organization wants at offboarding is to look for termination provisions and notice they’re missing.
In terminating a relationship, it is critical that an organization follow these steps:
Contract and Security Policy Review
A final communication of the contract and related security policies (including privacy policies) should be required with the third party. Specific reminders should be given of provisions and requirements that live on past the termination of the relationship, such as confidentiality and privacy. The organization should get a formal attestation/acknowledgment of the third party that they understand and will continue to adhere to the contract requirements on these provisions that continue past the relationship.
Property and Data Disposition
The organization should have an inventory of what data, information, intellectual property, and physical property was given to the third party. It should work with the third party to identify and ensure that what can be returned is returned, and what cannot be returned has been properly deleted/destroyed. However, in areas of backups and archives, this may not be possible and the organization should get assurance of the security of this information until it is destroyed.
Disposition of Access
The organization should also have a record of all network connections, remote/VPN access, as well as access given to internal systems of the organization. In each access and connection, the organization should ensure that this has been terminated and is no longer accessible.
Security Audits and Onsite Inspection
In high-risk relationships it may be warranted to do an onsite inspection or have a third party conduct one, to review and validate that the organization’s data is destroyed and physical technology and systems have been returned. Data itself cannot always be destroyed as it may reside on backup tapes, and some regulations require the retention of data for a period of time (which can vary). Data disposition should be documented to and attested in the third-party termination process and inspection.
Goodbyes are difficult, but they are necessary. The organization should have these steps clearly defined with workflow and tasks for each in the context of each relationship as it comes to an end.
I trust this three-part blog series on the lifecycle of a third-party relationship has been beneficial to you. If you have any thoughts, comments, or other points I may have missed in the summary, please contact Panorays for more information and advice on the matter, or me for further discussion about the article – mkras@grc2020.com.
About Michael Rasmussen
Michael Rasmussen is an internationally recognized pundit on governance, risk management, and compliance (GRC) – with specific expertise on the topics of enterprise GRC, GRC technology, corporate compliance, and policy management. With 25+ years of experience, Michael helps organizations improve GRC processes, design and implement GRC architecture, and select technologies that are effective, efficient, and agile. He is a sought-after keynote speaker, author, and advisor and is noted as the “Father of GRC” — being the first to define and model the GRC market in February 2002 while at Forrester.
