Third-Party Risk Management

So far, we’ve learned about IT risk management and the different methods to perform a risk assessment and response, as well as monitoring. In this chapter, we will dive deep into third-party risk management (TPRM), how to assess downstream third parties (vendors) and support businesses for upstream third parties (customers), and how to manage emerging risks. We will also look at how to manage issues, findings, and exceptions that may impact the business operations of an organization.

This chapter aims to help you learn about the concepts of TPRM and how to perform an effective third-party risk evaluation. We will also learn about issues, findings, and exceptions and how to manage them effectively.

In this chapter, we will cover the following topics:

• The need for TPRM
• Managing third-party risks
• Upstream and downstream third parties
• Responding to anomalies

With that, let’s dive into the first section: The need...

The need for TPRM

Before we start learning about TPRM, I think we should talk a bit about why these third parties are required in the first place and what specific purpose they serve for the contracting organization.

Third-party outsourcing is a form of delegating services to another party, such as day-to-day operations, software services, storage, compute, networking, and more, so that the enterprise can focus on its most essential services while delegating the services that can be performed by another organization.

The relationship between the enterprise and the third party is defined in a legally binding contract. The contract includes the set of provisions that the enterprise and hence the outsourcing organization needs to adhere to, such as data storage, compliance with local laws and regulations, jurisdiction in case of disagreements, indemnification clauses, payment terms, service-level agreements (SLAs), and security and privacy requirements that the third party needs...

Managing third-party risks

Whenever an organization determines a service that needs to be outsourced, a risk practitioner should be involved in assisting the business in determining the right partners, as well as performing due diligence on the selected vendor. The typical process to determine the right partners and manage the third-party risk should go like this:

1. The business process owner comes up with a use case for outsourcing a service to a third party and has all the necessary approvals from relevant stakeholders.
2. A request for proposal (RFP) or similar is published or key players in the space are reached out to so that they can assess the availability and alignment of the requirements of the organization.
3. Of all the vendors, a selected few are moved to the next stage so that they can demonstrate how their capabilities are aligned with the requirements of the organization, any niche features that are not available with other vendors, and budget considerations...

Upstream and downstream third parties

Often, when we think of third parties, we only think about the vendors providing services to us. However, there is another set of third parties that are equally if not more important than the vendors – our customers. I am not sure whether this is a term that is used in the industry to describe customers, but for the sake of this chapter, we will consider downstream third parties as vendors providing services to us and upstream third parties as customers to whom we provide services.

While we assess our vendors and perform due diligence, our customers must perform the same due diligence on us. Therefore, it is important to ensure that the organization maintains a robust internal risk management and cybersecurity program.

One of the best ways to streamline all the components of a risk management program to satisfy third-party requirements is to conduct an external certification such as ISO 27001 or HITRUST CSF or perform an independent...

Responding to anomalies

Regardless of stringent security controls, an organization will always have some issues and exceptions. The goal of a risk practitioner is to ensure that sufficient controls are put in place and procedures are developed in the case of an issue or exception that might pose a risk. For instance, an organization may have implemented an overarching policy of disabling USB access for all employees, but it may be required by the sales team to show a demo of an application or the developers to run a code snippet and perform thorough testing. In those cases, the risk manager should strive to balance such one-off cases by defining a mechanism to manage these requests. In the following section, we will review a few ways to manage these issues, findings, and exceptions.

Managing issues, findings, and exceptions

The following are a few formal approaches to managing issues, findings, and exceptions:

• Configuration management: Configuration management requires...

Summary

At the beginning of this chapter, we learned about the risk posed by third-party entities and how it can be managed. We then learned about the importance of managing downstream as well as upstream third-party relationships. With the recent trends and an uptick in third-party attack vectors, risk managers should keep themselves abreast of the latest trends and ensure that the risk posed by these threat actors can be minimized by implementing a TPRM program. Next, we learned about issues, findings, and exceptions and the role of configuration, release, exception, and change management to manage these risks. Finally, we learned about the importance of CAB in approving these changes. The goal for risk practitioners is to strike a balance of security and usability without compromising the organization’s security goals.

In the next chapter, we will learn about control design and its implementation.

Review questions

1. Which of the following would bind a third party to provide monetary credits to the organization in case of a service failure?
   1. Master service agreement
   2. Service-level agreement
   3. Non-disclosure agreement
   4. External audit
2. Which of the following should be signed with the third party to protect the intellectual property and interests of the organization?
   1. Master service agreement
   2. Service-level agreement
   3. Non-disclosure agreement
   4. External audit
3. Which of the following is not the final output of an external audit?
   1. SOC 2 report
   2. ISO 27001 certification
   3. HITRUST certification
   4. Non-disclosure agreement
4. The IT team is implementing new software across the organization and is defining the baseline control settings for end users. This is an example of ___.
   1. Release management
   2. Change management
   3. Configuration management
   4. Exception management
5. The risk practitioner should review and verify the granted exceptions are still required at least ___.
   1. Weekly
   2. Monthly
   3. Quarterly
   4. Annually
6. The CAB should...

Answers

1. B. A breach in the SLA allows the organization to demand monetary credit.
2. C. Non-disclosure agreements protect the intellectual property and interests of the organization.
3. D. Non-disclosure agreements are agreed upon and signed within the organization and by third parties. All the other options are the results of an external audit.
4. C. Baseline controls are set as part of configuration management.
5. D. The granted exceptions should be verified at least annually.
6. D. The CAB should consist of all relevant stakeholders.