by Nikolay Filipets
In this article I would like to cover basic TPRM Policy components. While there are multiple ways to go around writing and implementing TPRM policy, whichever approach and format you choose, the policy must contain basic components that would cover needs and requirements of regulators, auditors and clients.
Before we jump into the details about TPRM policy components I would like to take a step back and set the stage for the mindset required to create a successful TPRM policy. I recommend applying systems thinking when designing your TPRM policy. According to MIT’s xPRO course on Systems Thinking, systems thinking can be applied “to improve the performance of your projects” and understanding of how TPRM policy will affect the whole organization, including processes outside the TPRM program.
A well-designed TPRM policy should move your organization from disconnected operations into a more cohesive state and brake down organizational silos.
Some of the effective approaches to establish a documented policy framework that worked in my experience are the following:
1. Create a Framework document describing your overall approach to the third party risk management and reference individual policy documents per oversight area, such as:
Information Risk Management
Business Continuity
Compliance and Privacy, etc…
This scenario would be more applicable for larger companies with a dedicated enterprise-wide TPRM program (where program is made up out of independent departments all working toward a common TPRM objectives); OR
2. Create a comprehensive TPRM master policy that would describe your overall approach to the third party risk management and include policy statements about all oversight areas as sections within the policy.
This scenario would be more applicable for smaller companies where TPRM program and subject matter experts are centralized within one team.
As it relates to some of the must-have sections, I would outline the following as minimal required for a cohesive policy:
Overview/Statement of Policy
Definitions
Policy Scope
Stakeholders Involved
Defining Controls
High Level Risk Management Process (including standard life-cycle phases: Supplier On-boarding & Ongoing Monitoring & Termination)
Risk Treatments and Issue Management (including escalations)
Reporting and Board Accountability
Versioning/Revision History
In conclusion, before including “FINAL” in the name of your policy document and uploading it to SharePoint site, make sure you worked with your Internal Audit team; as I always say work with your “police”. Also don’t forget to obtain a sign off from your TPRM program sponsors and hold recurring meetings with them, because accountability flows from the top down. Lastly, assign ownership of the policy and implement refresh cycles; version control is important.
If you have any ideas or thoughts about this topic I will be happy to hear you out; contact me at filipets888@gmail.com
Kommentare