Third Party Risk Management (TPRM) is often viewed as a linear process. This is a misunderstanding of the actions that in total represent the processes involved. First, it’s a continuous system, renewing itself in different cycles and frequencies, depending upon the risk level of the third party’s service, and the practices of procurement; second, its processes are bi-directional and can interact through a number of vectors, depending upon the circumstance.
Like any process composed of subprocesses, each with their own data requirements, dependencies, and outputs, failure of one may impact the others. Truly the weakest link determines the combined strength and baselines the overall effectiveness of the program whole. There are external factors too. How well does your TPRM program integrate with procurement, internal audit, compliance, cyber and operational risk? The program does not operate in a vacuum, but must be integrated into operations and planning to be truly effective. But our focus here is upon the core program, so let’s take a look at the key sub-processes that need to be monitored and maintained to keep your TPRM “engine” running smoothly.
Onboarding
Procurement has selected a third party meeting the requirements to fill a business need. Now begins the process of information gathering and vetting the risk worthiness of this selected service provider. There’s some basic information gathering here, much of which may be shared from the procurement selection process, such as business name, location, primary relationship contact, and services to be provided. A credit check is often useful, perhaps essential. Having a system to automate gathering credit and financial data from a vetted source, such as Dunn & Bradstreet, is a clear efficiency and process advantage. Some GRC tools offer this as embedded functionality. This is also where the parameters of service must be defined in terms of potential risk. Will the third party need access to company data? Will they store any of it locally within their enterprise? Or in a cloud? Will they require access to your company’s internet? Internal network? Servers? Data Stores? Other? How will the third party’s users authenticate? Who will manage and control authentication? Whose authentication practices will govern changes when staff change roles or depart? How will you know? How will issues or incidents be reported? Has the third party had any history of data incidents? Privacy issues? Regulatory problems? And more. Review your own processes to ensure you are requesting the answers you need and the process for gathering them is efficient, timely, and effective.
Scoring Risk & Evaluation
The data gathered through the onboarding process informs this effort. Risk scoring is about identifying inherent risk first. During the Due Diligence steps, you may factor in any controls in place to determine residual risk. Your inherent risk scoring process should parallel that used for your own enterprise, and utilize the same scoring scales and methods, common taxonomy of terms, and definitions. How well do you manage the flow of information to your subject matter experts for review? Can you manage timelines so that unattended reviews can flow on to secondary “backup” experts to keep the process timeline fluid? Be certain the scope of the specific third party’s service aligns with the scope of your assessment and scoring. This will ensure that your TPRM process “speaks the same language” as your other risk processes and reports across your enterprise. It simplifies and allows you to leverage reporting designed for other risk scenarios, focusing just upon third party risk, either as a collective group, or individual partners or providers, without significant retooling. There may be gaps in the data you gather for third parties. There may be useful and directive, insightful information in those gaps. We’ll discuss more about that when discussing analytics, later in this post.
Third Party Due Diligence & Remediation
Comparing the results of your risk assessment and scoring to your enterprise risk appetite, risk program standards, regulatory and contractual obligations may identify gaps in third party operating practice and capability to be ranked and prioritized for remedial attention. Managing third party remediation may be a bit different in detail and scope from internal efforts. Terms, reporting commitments and documentation, details of project status, and the like will be between “partners”, rather than internal or contractually dedicated resources. However, your program chooses to monitor remediation efforts, be sure the process generates adequate evidence and artifacts to assure internal subject matter experts have enough detail to determine the completeness and efficacy of remedial efforts. If your TPRM program does not monitor third party remediation adequately your own program’s efforts are by implication and lack of specifics, compromised across the scope of the third party’s service to your enterprise. It potentially compromises your own regulatory and compliance efforts. Or, it may require you to impose awkward contractual terms between you and your clients or customers, and put your own reputation and brand value at needless risk.
Service Level Agreements and Performance
At some point in your TPRM process, the results of onboarding, risk scoring, and remediation requirements will express themselves in the contract or service agreement between your two companies. Some aspects of this expression likely will take the form of service level agreements (SLA’s); what services, how often, at what level of quality, and other terms used to describe agreed-to expectations of third party performance. It’s useful to include performance metrics in these agreements. How these should be calculated, including definitions of data, may be included to assure clarity of what’s being measured, and that supporting data will be captured within the services provided. This is not a pass/fail exercise. Performance metrics can also be diagnostic, so if problems arise these metrics may offer indicators pointing to the source of an issue. They may also become data points to factor into your overall enterprise risk assessment, depending upon the criticality of a particular third party’s service.
Issue Management
Risk management programs would be incomplete without some structured means to address issues and concerns when they arise. The issue management process employed for third parties should reflect the steps and documentation practices for issue management elsewhere in your enterprise. While you likely don’t have direct supervision over your third party’s resources, you may have a primary contact with the supplier who does. That person can be representing your information needs for remediation status, broker direct participation in discussions of actions to be taken, and act as a primary conduit for information exchange. Ideally, this designation of a primary contact, along with key expectations for the relationship, can be represented in the contract with the service provider, at least by role reference. Issue identification processes should include details about escalation practices for significant events, including SLA’s for timing and frequency of updates. Tracking and status reporting for remediation projects should be visible and generate documentation that can be incorporated into your company’s overall enterprise risk assessment process.
Operating Infrastructure: System Integrity and Data Security
Often, we spend so much effort focused deeply upon the details of the specific program component attributes, as noted above, we fail to step back and review these basics. That’s a serious mistake. It’s like tuning the engine of a car, but parking it in the street in a storm, unlocked, with the windows rolled down. It’s important to make continuous monitoring of access controls, activity, and adherence to authentication policies robust and at the forefront of the program. Likewise keep data security, storage, backup, and all other best hygiene practices rigorously in play. This includes regular cyclical training for staff on the policies, methods, and procedures necessary to enforce best practices regarding data and system security. They are just as important regarding the management of third parties as they are for any other aspect of your operating infrastructure. Data recovery and history retrieval are important aspects to consider along the way. If your TPRM data resides in a cloud, you have the extra recursive challenge of a third party being part of your TPRM process itself. Be sure you have paid attention to security, data integrity, recovery, and threat monitoring as part of your overall cloud management strategy.
Oft times, when a third party was small or their engagement was minor, parts of the process were left to paper alone. As the relationship grew, it may have been automated. Be sure to take measures so that all of the relationship’s history is available, should the need arise in the future. Electronic copies of original documents may offer valuable insights into the foundations or intent of contract provisions, enduring SLA’s and more, that may survive staffing changes within your enterprise or your provider’s. Complete records can illuminate an otherwise forgotten time or intent useful in the present.
Analytics, Gaps, and Hidden Insights
We all have been trained by practice and experience to capture basic data and reflect current status, trends, and forecasts versus performance. Modern data representation tools offer rich methods for presenting data visually in combination with tabular or numerical means. But these tools have made some stop analysis there. Visual display offers opportunity. So does raw data. Good reporting answers questions. Here are some often overlooked:
- Where are there gaps in the data?
- Why are they there?
- Do the gaps represent any identifiable trends?
- Are there measures or indicators that drive reported data?
- Might any of these serve as predictive indicators?
Often time we do not explore data beyond its presence. There may be much to learn by examining what we learn and asking why the data is what it is, and why we have no information or there are breaks in its flow that don’t result from some operating error alone. There may be data gathered from other processes for other operating purposes, that can be useful indicators of a cyber or security risk. The oft cited example is one where a shipping company notes that there’s an increase in delays and reduced on-time deliveries. The problem is traced to an issue with down servers providing timely schedules and routing information. The reason the servers were down? They had not been patched in some time. Failure to perform timely patching led to exposure to known threats and possible vulnerability to external intrusion the patches would have prevented. From delayed shipping performance to cyber risk in servers, you can see how tracing straightforward operating data may point to indicators of a whole different nature. These reviews to determine what we can learn from what we measure and can know upfront can offer rich dividends without creating complex new data forms or calculations.
TPRM Platforms and Integration
If you were a carpenter, you’d be certain to keep your tools sharp and well maintained. It makes your work easier, safer, and contributes to a professional result for your work and your reputation. The tools you use to help with TPRM are equally important to maintain. A poorly maintained system or procedure can lead to damage in the finished work. As this article has noted, there are many moving but interrelated parts requiring coordination to effectively manage and govern third party risk. Unless you are a very small concern, with few third parties supporting your operations, you will need automated tools to help manage the workflows, communications, documents, data and reporting needed for all the activities that make up the TPRM processes. Further, you need to integrate TPRM with other enterprise risk management, operations, legal, regulatory, and compliance practices. If you are using a GRC platform, it should offer a TPRM module. There are also stand alone TPRM modules that can be integrated into enterprise risk software as your needs dictate. TPRM is a set of practices where automation can dramatically reduce the labor and material expenses required to deliver an effective program supporting your business needs without applying burdensome overhead to your suppliers. They rapidly pay dividends and return cost savings sufficient to justify investment. Further, they position your firm for growth without sacrificing control, governance, compliance or exposure to needless risk. Like the carpenter’s, your tools are an indicator of your professionalism and dedication to quality and safety for your customers, partners, associates, and stakeholders now and into tomorrow.
About the Author:
Simon Goldstein is an accomplished senior executive blending both technology and business expertise to formulate, impact, and achieve corporate strategies. A retired senior manager of Accenture’s IT Security and Risk Management practice, he has achieved results through the creation of customer value, business growth, and collaboration. An experienced change agent with primary experience in financial, technology, and retail industries, he’s led efforts to achieve ISO2700x certification and HIPAA compliance, as well as held credentials of CRISC, CISM, CISA.
LEARN MORE ABOUT TPRM