Should I retire my existing cybersecurity framework and redesign a TPRM-focused one from scratch?
Can TPRM programs integrate with my existing cybersecurity framework?
These are just some of the questions troubling stakeholders at the precipice of a TPRM program implementation. While left answered, these questions cause delays in the onboarding of an initiative that could prevent a catastrophic third-party breach.
Whether you’re considering implementing a TPRM program, or not sure how to even begin the implementation process, this article will be your guiding light.
What is Third-Party Risk Management (TPRM)?
TPRM is the process of mitigating all risks arising from third-party vendor relationships. These risks include any vendor network-related events that could potentially disrupt business continuity.
While the term’s definition could be expanded to include all potential disruptions to supply chain continuity, it’s most commonly used to describe the management of third-party risks across two primary categories- infosec and compliance.
The Third-Party Risk Management Lifecycle
In order to effectively manage risks across these complex categories, a TPRM strategy must be capable of adapting to evolving third-party vendor relationships.
Today, third-party vendor relationships aren't only growing; they’re more complex, and they require more nuanced access to sensitive assets.
To accommodate this updated requirement, a third-party risk management lifecycle has evolved from a rudimentary point-in-time monitoring model to a more iterative process involving trigger-based monitoring and data-driven risk identification.
The updated Third-Party Risk Management lifecycle is capable of adapting to any third-party risk changes occurring in the period between due diligence and recertification - the process of reassessing vendors.
The five stages of the updated TPRM lifecycle are outlined below. With a high-level understanding of the entire TPRM process, you’ll begin to understand the framework’s natural connections to your existing Enterprise Risk Management framework.
1. Risk Planning
- Evaluate your third-party risk appetite - Based on acceptable levels of inherent and residual risks. This risk appetite will likely be modified after onboarding when applicable regulatory and compliance requirements are considered in greater detail. You should combine the vendor risk profile with the risk profile of the engagement.
Learn how to calculate your risk appetite.
- Evaluate and determine how to best tier your vendors - This is an important step that’s often overlooked. Tiering vendors based on the information they will have access to, the product/service they’re providing, or their regulatory/compliance requirements will help you determine the level of risk monitoring and due diligence each vendor requires. Intelligent vendor tiering will also help you track the reassessment (or recertification) schedules of each vendor grouping.
Learn more about Vendor Tiering.
- Source potential third-party vendors - Complete a preliminary evaluation of each potential vendor’s public security posture through external vulnerability scans if these tools are available to you. If not, completing a simple search on the vendor's web page for available security or privacy information will give you a high-level indication of their security posture.
2. Due Diligence
- Determine critical due diligence questions - Multiple data sources should be referenced when designing these questionnaires, including previous quarterly risk reports, internal audit reports, industry standards/regulations, and previously completed risk assessments - such as those available on an UpGuard Shared Profile.
- Evaluate each vendor’s inherent risk score - Prior to considering any third-party security controls that will be required in a partnership arrangement, a security risk baseline should be established through a simple risk assessment or questionnaire. This will help you understand the vendor's cyber security maturity, their inherent risk rating, and what the potential residual risk rating could be as you consider any compensating controls in your assessment.
- Confirm the validity of due diligence processes - The validity of all due diligence risk assessments should be confirmed with a security rating scoring system based on multiple attack vectors.
3. Contract Negotiations
- Establish security standards in vendor contracts - this will depend on the jurisdiction you operate in.
- Consider the addition of a 'Right to Audit' clause in vendor contracts - this will give you the right to review each vendor’s internal security processes, audits, self-assessments, and controls.
- Review stipulated SLAs - to ensure the standards meet your business and compliance requirements.
- Seek TPRM platform onboarding approval - Confirm the vendor's approval of being onboarded onto your company's TPRM platform.
- Segregate each TPRM project - Designate an internal primary business owner of each TPRM relationship.
4. Ongoing Monitoring
- Continuous attack surface Monitoring - Implement systems that track the performance and status of all third-party security controls that are in place.
- Establish Internal Monitoring triggers - Monitoring systems triggered during critical security events, such as weakening security postures and deviations from regulatory compliance standards.
- Service Level Agreements Compliance Tracking - Track and assess alignment with stipulated service standards.
- Follow a reassessment schedule - performing routine reassessments of all current vendors based on internal policy and regulatory requirements
- Offboarding and Contract Termination - Revoke all data access and perform a final review of security policy and regulatory standard compliance.
- Data Deletion - In some jurisdictions, data deletion and proof of this action is required. Check your regulation requirements to confirm the need for data deletion and a certificate of deletion confirmation
The feedback loop added to the updated TPRM lifecycle creates an iterative model that can adapt to any changes in risk appetites, security policies, regulatory compliance standards, and business relationships.
The updated lifecycle model is also capable of considering special third-party risks falling outside of the cybersecurity category, also known as special categories of risk.
Special categories (or non-traditional categories) of risk include entities that have the potential of becoming third-party breach attack vectors despite not commonly being targeted by cybercriminals.
The management of special third-party risks is especially an important capability for financial institutions. Regulators are increasing third-party risk scrutiny in the financial sector, and this trend is likely to continue as digital transformation deepens indirect relationships with sensitive financial data.
Some common examples of special third-party risk categories are listed below:
- Insurance agents
- Third-party administrators
- Powers of attorney
- Indirect lenders
- Correspondent lenders
- Data marketing firms
- Corporate law firms
- Foreclosure and bankruptcy law firms
- Regulated entities
- Financial market utilities
- Lobbying firms
Third-Party Risk Management doesn’t have a destination. It's an ongoing effort of learning about the evolving security risks associated with all your vendors over the course of the entire business relationship.
How Does TPRM Fit Into Your Existing Cybersecurity Framework?
The most common frustration amongst businesses considering a TPRM implementation is not knowing how the program fits with an existing cybersecurity framework.
The good news is you don’t need to replace your existing cyber framework with an entirely new one.
Think of a Third-Party Risk Management framework as a roadmap to maturing your existing cybersecurity framework into one that includes a TPRM component. It’s an extension of your current cyber framework, with adjustments accommodating for different risk appetites and regulatory requirements in each vendor relationship.
This symbiotic relationship will make greater sense in the 7-step guide below, where the process of integrating a TPRM framework against a generic cyber framework is outlined.
But to ensure you get the most value from an explanation of the integration process, it’s important to first cover some essential prerequisite knowledge.
What’s the Difference Between a Third-Party Risk Framework and a Third-Party Risk Management Program?
Most TPRM implementation frustrations stem from a poor understanding of the difference between a Third-Party Risk framework and a Third-Party Risk Management program.
These terms are not variations of the same definition; each refers to an entirely different component of third-party vendor security.
A Third-Party Risk Framework refers to a cybersecurity framework that includes third-party security controls. A Third-Party Risk Management Framework, on the other hand, is a series of processes based on the TPRM lifecycle outlined above.
Because of this, a TPRM program will not naturally follow the implementation of a Third-Party risk framework. To understand how these terms relate to one another, think of the TPRM framework as the skeletal structure of your future TPRM program; it indicates all of the foundational security controls you need to build out a TPRM program.
The Third-Party Risk Control Overlap Between Popular Cybersecurity Frameworks
With the threat of third-party data breaches rising, an increasing number of cybersecurity frameworks are being updated to include a greater focus on third-party security controls.
Because cybersecurity frameworks are expanding into the third-party risk mitigation space, it’s likely that your current cybersecurity framework already has a foundation in place for a future TPRM program.
TPRM controls are shared between multiple frameworks. To prevent doubling up, it’s important to be aware of the vendor risk controls that are present in the cybersecurity frameworks that are relevant to you.
For example, here’s a list of compliance frameworks that include third-party risk controls for the parent risk category Supply Chain Risk Management (SCRM):
- NIST CSF: ID.SC-1
- ISO 27002: 15.1.1
- NIST 800-53: PS-7 & SA-4
- NIST 800-171: 252.204-7008, 252.204-7012, NFO PS-7
A significant security control overlap exists between the framework’s NIST 800-53, ISO 27001, and NIST CSF.
7 Step Guide: Integrating a TPRM with your Existing Cybersecurity Framework
The following 7-step process will help you map your existing risk controls to a TPRM program. This general process can be applied to most cybersecurity frameworks.
Remember, a TPRM program does not replace your current cyber framework. You are augmenting both initiatives to broaden your security risk management capabilities.
Because UpGuard can detect third-party risks across the entire attack surface, the platform can be used to simplify the entire TPRM implementation process. To illustrate this, a relevant feature of the UpGuard platform is introduced in each step below.
Step 1: Review your Enterprise Risk Management Framework
Your ERM framework should be updated to align with the increasing emphasis on third-party risk controls across regulations and compliance standards.
Updating your ERM framework should trigger an update of all your risk registers across each department. Every business unit across most industries utilizes some degree of third-party service, so every business unit should have a risk register.
If you come across any risk registers that have recently been updated, check to make sure their risk data is based on the most updated list of third-party vendors and products in use.
After updating a risk register, always confirm its alignment with the risk appetite outlined in your ERM framework
How UpGuard Can Help
If you are using the UpGuard platform, you can:
- Import all vendors and start tracking their security posture performance.
- Add an explanation of how to discover the third-party risks associated with each vendor.
- Tier vendors based on risk criticality, regulatory requirements, or assessment requirements.
- Organize your vendor relationship network with custom labels.
Step 2: Update or Create a Corporate Risk Appetite Statement
A well-defined risk appetite should govern your understanding of managing and scoring risks across each risk register at an organizational level. Your risk appetite should be defined at an organizational level and feed into every business unit.
This will set an objective risk threshold that every business register is measured against, allowing critical third-party risks at a department level to be easily identified.
A strong risk appetite statement will address all third-party risks threatening the achievement of business goals and include plans for identifying and addressing those risks.
To design a risk appetite statement, you need to:
- Clearly define a growth roadmap - Understand the organization’s overall strategic goals and objectives.
- Develop a risk appetite scale - Define a scale of the level of risk your organization is willing to absorb to achieve its strategic goals and objectives.
Learn how to develop a risk appetite scale
- Involve stakeholders - Senior leadership should be consulted and involved with this process, particularly the design of your risk appetite scale.
- Use common language when developing the risk appetite statement - By defining your risk appetite clearly and concisely, internal and external stakeholders will understand your statement and make risk-intelligent decisions. This means the risk appetite statement should be expressed in a common language that is used throughout the organization. This can be aligned to the language in policies, procedures, and any manuals.
If you don’t have a corporate risk appetite statement, you can refer to USAID’s 2018 statement as a template for your own design.
The cybersecurity component of your risk appetite statement should be an honest evaluation of your current security efforts and outline an achievable pathway for elevating the security posture of your entire ecosystem, including your third-party vendor network.
- Define your risk tolerances - Your risk tolerance is the level of acceptance around a particular set of risk-based objectives. It’s a measurement of exactly how much of a loss an organization is willing to experience for a given cyber event. Your calculated risk tolerance should result from careful consideration of all the potential risks your assets could face and your overarching risk appetite.
- Develop prioritization tools - These tools should help your business units make better risk-based decisions during their day-to-day activities and projects. This is where the risk consequence and impact tables can come into use.
Using UpGuard to Monitor your Inherent and Residual Risks
UpGuard’s security score projection feature predicts the impact of certain remediation actions on your overall security posture.
You can use this feature to help you decide which remediation processes should be prioritized to maintain alignment with your enterprise risk appetite.
Use this feature to also help you compose a TPRM component in your risk appetite statement. Perform a scan to detect all of the third-party security risks in your vendor network, and design a remediation program that elevates your third-party security posture to its desired score as quickly as possible.
Step 3: Draft TPRM security policies
Create TPRM policies to align the cybersecurity objectives of your entire organization against processes outlined in the TPRM lifecycle.
Besides an overarching TPRM that you include in your risk appetite statement, TPRM policies should be drafted for each business unit in the context of each unit’s unique risk profile.
When writing each TPRM policy, it’s important to consider your internal third-party risk requirements (as outlined in your ERM framework) and the compliance requirements of any relevant regulatory standards.
Relevant regulatory standards include those that pertain to your industry and the industries of each of your vendors.
Here’s a list of popular compliance standards to support your TPRM policy writing efforts:
- Cybersecurity Maturity Model Certification (CMMC)
- European Banking Authority (EBA)
- Cloud Security Alliance (CSA)
- Financial Conduct Authority (FCA)
- General Data Protection Regulation (GDPR)
- Federal Financial Institutions Examination Council (FFIEC)
- ISO 27001
- ISO 27002
- ISO 27018
- ISO 27036-2
- ISO 27701
- Health Insurance Portability and Accountability Act of 1996 (HIPAA)
- North American Electric Reliability Corporation Critical Infrastructure Protection (NERC CIP)
- NIST 800-53
- NIST 800-161
- NIST Cybersecurity Framework (CSF)
- Stop Hacks and Improve Electronic Data Security (SHIELD) Act
- SOC 2
- OCC Bulletins
- PCI DSS
Step 4: Select a TPRM framework
Select a TPRM framework that best unifies your TPRM policies, calculated risk appetites, and ERM framework.
Your selected framework should be capable of:
- Highlighting the risks within your appetite and those falling outside of the threshold.
- Identifying all of the security controls your third-party vendors are expected to implement
Step 5: Design Third-Party Vendor Onboarding Contracts and Due Diligence Processes
At this point, you’ll have enough personalized third-party risk data available to create security contracts for new third-party vendors and establish your due diligence processes.
This step will combine the outcomes of stages two and three of the TPRM lifecycle.
For an outline of the vendor security contract creation process, refer to stage three of the TPRM lifecycle.
Vendor Due Diligence
Vendor due diligence processes include all of the questionnaires and assessments required to accurately describe each vendor’s security posture.
The terms Security Questionnaire and Security Assessment are often used interchangeably because they both refer to the same due diligence processes.
Your choice of questionnaire depends on your unique compliance and cyber threat mitigation requirements outlined in your ERM framework.
If you require a more targeted third-party risk evaluation, you can create your own assessments by combining relevant questions from any of the above questionnaires. However, without a risk management platform like UpGuard, this effort will likely depend on spreadsheets and manual processes, which isn’t a scalable Vendor Risk Management foundation you should build upon.
How UpGuard Can Help You with the Vendor Due Diligence Process
With UpGuard, you can create your own custom risk assessments by either modifying an existing design or building one from a blank canvas.
This feature allows you to align each risk assessment to the unique risk thresholds of each third-party vendor.
The UpGuard platform can also map compliance gaps to the regulatory standards of each vendor based on the response of each submitted risk assessment, thereby making the ongoing monitoring effort of the TPRM lifecycle much easier.
Watch the video below for a tour of UpGuard’s questionnaire builder feature.
Step 6: Identify all of the Regulations that Apply to You and Your Vendors
Identify all of the regulations that apply to you and your vendors and then group together vendors that are impacted by the same TPRM controls; this will make the TPRM processes easier.
To support this effort, the list below identifies all of the third-party security controls for popular cybersecurity frameworks and regulations.
Payment Card Industry (PCI)
The Office of the Comptroller of the Currency (OCC)
Sarbanes-Oxley Compliance (SOX)
- 5.02 External Parties
- 05.i Identification of Risks Related to External Parties
Refer to the following sources for guidance on how to meet the TPRM requirements of specific cybersecurity regulations
- How to Meet Third-Party Risk Requirements of NIST 800-161
- Meeting the Third-Party Risk Requirements of the CCPA
- Meeting the Third-Party Risk Requirements of The NY SHIELD Act
- Meeting the Third-Party Risk Requirements of the GDPR
- Meeting the Third-Party Risk Requirements of 23 NY CRR
- Meeting the Third-Party Risk Requirements of NIST 800-53
- Meeting the Third-Party Risk Requirements of PCI DSS
- Meeting ISO Third-Party Risk Management Requirements
Step 7: Tier Your Vendors
For your TPRM program to be effective, it should be capable of identifying vendors with the most critical security vulnerabilities so they can be addressed first. This will help you establish an efficient and scalable third-party risk remediation program, preventing overwhelment amongst your TPRM security members.
Vendor Tiering Guidelines
Vendors could be tiered by either criticality or risk assessment requirements.
Tiering vendors by criticality
Criticality tiering makes the monitoring stage of the TPRM lifecycle easier. Vendors with the highest potential of negatively impacting your security posture should be monitored with greater scrutiny. By grouping these vendors into one tier, they can all be simultaneously monitored for security vulnerabilities that can then be rapidly addressed.
Tiering vendors by risk assessment requirements
To make the management of ongoing risk assessments easier, vendors requiring similar risk evaluations could be tiering together. This will allow you to send scheduled risk assessments to all vendors in a tier rather than selecting each vendor individually.
How UpGuard Can Help with Vendor Tiering
The UpGuard platform includes a vendor tiering feature giving you complete control over the tiering process. You can tier vendors by risk criticality, assessment requirements, evidence requirements, or any standard that makes sense with your unique TPRM requirements.