- This guide proposes a 24-phase C-SCRM Kill Chain, a prioritized roadmap to build operational supply chain risk management capabilities focused on prevention.
- Core premise. Prevention tied with automated reactive technologies minimizes operational disruptions from both hostile and accidental incidents far more efficiently than reactive-only models.
- Zero Trust Architecture is more than identity-based access. It must account for the validated integrity of systems, applications and services across the entire supply chain.
- Organizations must clarify the difference between compliant versus secure. Minimum Compliance Requirements (MCR) are the floor. Discretionary Security Requirements (DSR) address risk appetite beyond compliance.
- Five building blocks. Operational leadership, secure development practices, procurement practices, risk management practices, and systems / applications / services management.
C-SCRM Has A Worldwide Scope That Is Populated With Known Bad Actors
According to the National Counterintelligence Strategy of the United States (years 2020-2022), the strategic objective for supply chain security is to: “Reduce threats to key U.S. supply chains to prevent foreign attempts to compromise the integrity, trustworthiness, and authenticity of products and services purchased and integrated into the operations of the U.S. Government, the Defense Industrial Base, and the private sector." At the heart of C-SCRM are nation-state "bad actors" and the United States Trade Representative’s Special 301 Report Priority Watch List identifies 10 countries (including China and Russia) on its Priority Watch List, as well as an additional 23 countries on its Watch List. This list of countries sets the stage for identifying potential geography-based threats that can directly or indirectly impact the confidentiality, integrity, availability and safety of an organization's supply chain. Additional scrutiny is required for products and services (1) produced by entities located within those countries or (2) by organizations that have ownership or other Conflict of Interest (COI) concerns with governments listed on those watch lists.
C-SCRM Is A Perception Problem Where False Assumptions Have Real-World Implications
Provenance is the technical means to maintain evidence-based integrity of products and services across an asset's lifecycle. It is the chronology of the origin, development, ownership, location, and changes to a system or system component and associated data. It may also include personnel and processes used to interact with or make modifications to the system, component, or associated data. Provenance helps eliminate false assumptions by governing the integrity of the asset across its lifecycle.
Currently, the are no clear US laws or regulations that mandate suppliers provide multi-tier transparency of supply chains. The closest requirements are narrowly-focused on Controlled Unclassified Information (CUI) as part of several Defense Federal Acquisition Regulation Supplement (DFARS) clauses and Federal Acquisition Regulation (FAR) 52.204-21(2).
C-SCRM is the process of identifying, assessing, and mitigating the risks to the integrity, trustworthiness, and authenticity of products and services within the supply chain. This is often directed at Information and Communications Technology (ICT) that scopes:
Note
A properly scoped C-SCRM program assesses (1) internal risks that are native to every organization and (2) external risks that stem from the third-parties that produce products and/or provide services that make up the acquiring organization's supply chain.
For example, an Internet enabled "smart meter" has more than just softwhere there is no such thing as a "trusted third party" since trust is a luxury that C-SCRM cannot afford. ZTA's goal is to minimize the negative impact of any product or service from being used in a malicious manner. While, C-SCRM relies on ZTA principles to architect, build and maintain secure systems, applications, services and networks, SCRM also relies on the concept of "provenance" where every system and system component has a point of origin and may be changed throughout its existence.
Important Considerations For C-SCRM Planning
National Institute of Standards and Technology’s (NIST) SP 800-160, Developing Cyber Resilient Systems: A Systems Security Engineering Approach, is the authoritative source for "cyber resiliency" and secure engineering principles within the realm of cybersecurity and data protection. A common definition of resilience is “the capacity to quickly recover from difficulties.” Resilience is a measure of an organization’s elasticity – being able to spring back into a pre-determined operational state following an event. Organizations should strive to be resilient to IT and cybersecurity-related incidents both internally and across the supply chain. This concept requires automating Continuous Configuration Enforcement (CCE) across all application technology platforms.
NIST’s National Cybersecurity Center of Excellence (NCCoE) has produced several reference materials intended to support ransomware threat mitigation and all guidance starts with the assumption that devices are hardened - that is NIST's baseline starting assumption for organizations to protect against ransomware. Hardening systems and the automation of security validation is not a new concept where NIST SP 800-31, Guide to Malware Incident Prevention and Handling for Desktops and Laptops, states that "Organizations should have vulnerability mitigation capabilities to help prevent malware incidents. Organizations should have documented policy, processes, and procedures to mitigate known vulnerabilities that malware might exploit. Because a vulnerability usually can be mitigated through one or more methods, organizations should use an appropriate combination of techniques, including security automation technologies with security configuration checklists and patch management, and additional host hardening measures so that effective techniques are readily available for various types of vulnerabilities."
Traditional incident response and recovery operations are not designed with resilience in mind. Recovery is absolutely possible and Service Level Agreement (SLAs) help establish acceptable data loss parameters, maximum outages, etc. However, this is more of a way to bracket risk management decisions and while is an efficient manner to justify budgets for Continuity of Operations (COOP)-related technologies and staffing, it is not sustainable. While reactive operations are often viewed as heroic endeavors that “saved the organization from doom,” it does not mean that reactive model is the best methodology or least expensive path to follow. Resiliency is.
- Effort is on the downstream or “right side” of an incident or event – it is reactive. Baselining and configuration management on the upstream or “left side” of the event is often compliance-focused and are not directly tied to response/recovery operations.
- The traditional, reactive model has minimal focus on baselining and configuration management.
- When an incident occurs, there are structured plans to respond that span from minutes to years in duration:
- Incident Response Plan (IRP)
- Disaster Recovery Plan (DRP)
- Business Continuity Plan (BCP)
- Expense is primarily associated with event detection, response, remediation and recovery operations.
- Effort is on the upstream or “left side” of an incident or event is prevention-focused. A decrease in effort on the upstream side of an event, will likely result in a decreased operational impact on the downstream or “right side” of the event occurrence.
- There is significant effort placed on baselining and automating configuration management operations.
- When an incident occurs, the automated remediation actions minimize impact and the necessity to activate IRPs, DRPs and BCPs.
- Expense is primarily associated with tightly-controlled configuration management practices.
C-SCRM Authoritative Sources
There is a lot of invaluable information on the Internet about what C-SCRM is from authoritative sources, such as the US National Institute of Standards and Technology (NIST), the US Department of Homeland Security (DHS), the Cybersecurity & Infrastructure Security Agency (CISA), the US National Counterintelligence and Security Center (NCSC) and many others. It is important to understand that NIST is the authoritative source on C-SCRM-related matters and provides authoritative guidance on the subject for the US Government:
NIST has several publications and sites that directly frame or support SCRM:
- NIST SP 800-161, Supply Chain Risk Management Practices for Federal Information Systems and Organizations;
- NIST IR 8276, Key Practices in Cyber Supply Chain Risk Management: Observations from Industry;
- NIST IR 8286, Integrating Cybersecurity and Enterprise Risk Management (ERM); and
- NIST's guidance on Executive Order (EO) 14028.
Keep in mind that the NIST publications are merely guidance and there is no formal implementation guidance for C-SCRM.
SCRM Addresses A Tiered Approach To Risk
When you read through NIST SP 800-161, you will see that it leverages the concept for a multi-tiered risk model from NIST SP 800-37 to organize risk into three distinct tiers:
When you look at it in a slightly different layout, you can see how that can start applying to a business when you overlay the realities of what needs to be managed:
Prioritizing C-SCRM Activities
The concept of the Cybersecurity Practitioner's Guide to C-SCRM was to create a proof of concept for an efficient way to plan out a roadmap to successfully implement robust Zero Trust and Cybersecurity Supply Chain Risk Management (C-SCRM) cybersecurity and privacy practices that focus on prevention and automated remediation. The Cybersecurity Practitioner's Guide to C-SCRM highlights the nature of preventative security controls as an efficient way to protect an organization from the expense and operational disruptions associated with incident response and business continuity activities. The end result is a viable approach for organizations to use in order to create a prioritized project plan for C-SCRM practices that avoids a myopic, point solution focus by adopting secure practices that are applicable across the supply chain.
"Zero Trust Architecture (ZTA) is more than just by tying logical access to a user’s identity and should take into account the validated integrity of systems, applications and services across the supply chain."
Cybersecurity Practitioner's Guide to C-SCRM
The concept of a "kill chain" adopts the premise that it is easier to stop and prevent further damage if insecure practices or malicious activities are discovered earlier, rather than later. The intention of using the Cybersecurity Practitioner's Guide to C-SCRM is:
- By applying a prioritized, phased approach towards C-SCRM-related activities, it is possible to avoid rework and cascading failures by addressing dependencies earlier in the process; and
- Focusing resources and efforts on preventative controls, rather than detective controls.
Prevention, tied with automated, reactive technologies can minimize operational disruptions from either hostile or accidental incidents.
The Cybersecurity Practitioner's Guide to C-SCRM breaks the concept of C-SCRM down into 24 major steps, which can then be translated into a project plan. This project was approached from the question of, “If a consultant was hired to build a C-SCRM program, what would the plan be to start from nothing to get a company to where it has operational C-SCRM capabilities?” While the Cybersecurity Practitioner's Guide to C-SCRM maps controls from NIST SP 800-161 to the steps in the model, it is important to emphasize that the prioritization and “bucketing” of controls into phases is a subjective endeavor and not everyone may agree with this approach. If you choose to use the Cybersecurity Practitioner's Guide to C-SCRM, you will invariably need to modify the approach to fit your organization's unique business practices and specific needs.
The Cybersecurity Practitioner's Guide To C-SCRM is made up of 24 phases (these correspond to those shown in the associated infographic). It is important to note that these steps can be applied both to internal practices and External Service Providers (ESP). Realistically, an organization must first “master the fundamentals” and have its own C-SCRM practices in order before proactive oversight of TSPs is feasible.
The Cybersecurity Practitioner's Guide to C-SCRM is based on the principles of the Security, Compliance & Resilience Management System (SCRMS) model:
- Establish context;
- Define applicable controls;
- Assign maturity-based criteria;
- Publish policies & standards;
- Assign stakeholder accountability;
- Maintain situational awareness;
- Manage risk; and
- Evolve process.
Prioritizing C-SCRM Activities
Phase 1
Establish Context for Supply Chain Risks & Implement A Zero Trust & Supply Chain Risk Management (C-SCRM) Program
To build and maintain efficient and effective operations, a C-SCRM program must have a hierarchical vision, mission and strategy that directly supports the organization’s broader strategic objectives and business processes. This process of establishing context involves identifying all applicable external compliance requirements (e.g., laws, regulations and contractual obligations), as well as internal directives (e.g., Board of Directors (BoD), corporate policies, etc.). This is a due diligence element of the C-SCRM program.
This step has 5 subcomponent steps:
- Assign a Chief Supply Chain Officer (CSCO) to establish and run the C-SCRM program.
- Restructure the organization chart to eliminate conflicts of interests among leadership representing Lines of Business (LOB) within the organization.
- Identify applicable external requirements (e.g., laws, regulations & contractual obligations)
- Identify applicable internal requirements (e.g., business practices, BoD dictates, corporate policies, etc.)
- Develop a cybersecurity & data program-specific mission and strategy that supports the broader corporate strategy and business operations.
Phase 2
Define Applicable Zero Trust & SCRM Controls
A tailored control set of cybersecurity and data protection controls must exist. This control set needs to be made of Minimum Compliance Criteria (MCC) and Discretionary Security Requirements (DSR). This blend of “must have” and “nice to have” requirements establish an organization’s tailored control set to ensure both secure practices and compliance are designed for.
This step has 3 subcomponent steps:
- Identify MCC.
- Identify DSR.
- Implement secure engineering principles and adopt a Zero Trust Architecture (ZTA).
Phase 3
Define Maturity-Based Criteria for C-SCRM Controls
The cybersecurity & privacy program must assign maturity targets to define organization-specific “what right looks like” for controls. This establishes attainable criteria for People, Processes, Technology, Data & Facilities (PPTDF) requirements. Tailored maturity level criteria can be used to plan for, budget for and assess against. Maturity targets should support the organization’s need for operational resiliency.
This step has 4 subcomponent steps:
- Establish organization-wide maturity criteria for PPTDF.
- Establish maturity criteria for sensitive data and/or critical systems, applications and services.
- Develop & implement a resource plan (e.g., business plan, budget, road map, etc.) to meet compliance obligations.
- Prioritize objectives from the resource plan for PPTDF requirements.
Phase 4
Publish Policies & Standards for C-SCRM
Documentation must exist, otherwise an organization’s cybersecurity and data protection practices are unenforceable. Formalizing organization-specific requirements via policies and standards are necessary to operationalize controls. Documented policies and standards provide evidence of due diligence that the organization identified and implemented reasonable steps to address its applicable requirements.
This step has 2 subcomponent steps:
- Publish organization-wide cybersecurity and privacy policies to address applicable security and data protection requirements.
- Publish standards to enforce cybersecurity and privacy policies.
Phase 5
Assign Stakeholder Accountability
Controls must be assigned to stakeholders to ensure accountability (e.g., business units, teams and/or individuals). These “control owners” may assign the task of executing controls to “control operators” at the Individual Contributors (IC)-level. Stakeholders utilize the prescriptive requirements from policies and standards to develop Standardized Operating Procedures (SOP) that enable ICs to execute those controls. The documented execution of procedures provides evidence of due care that reasonable practices are being performed.
This step has 5 subcomponent steps:
- Identify "control owners" for all applicable cybersecurity and privacy controls. These are the individuals or teams responsible for the control.
- Identify the "control operators" for all applicable cybersecurity and privacy controls. These are the individuals or teams executing the control.
- Stakeholders ensure control owners develop documented SOP to address the control objective(s).
- Stakeholders ensure control owners develop a System Security Plan (SSP) to document the "who, what, how, why, when & where" for products & services.
- Formalize access agreements for internal and external personnel, including rules of behavior for critical technologies.
Phase 6
Maintain Situational Awareness - Establish An Internal Audit (IA) Capability
Situational awareness must involve more than merely “monitoring controls” (e.g., metrics). While metrics are a point-in-time snapshot into discrete controls’ performance, the broader view of metrics leads to a longer-term trend analysis. When properly tied in with current risk, threat and vulnerability information, this insight provides “situational awareness” that is necessary for organizational leadership to adjust plans to operate within the organization’s risk threshold.
An organization’s Internal Audit (IA) function provides quality control. This function can help validate the scope and impact of risk, which stakeholders may be unaware of. IA practices generate evidence of due care that reasonable steps are in place to validate stakeholder claims and assumptions.
This step has 10 subcomponent steps:
- Create a detailed asset inventory for all business-critical systems, applications and services (internally hosted as well as those hosted by third-parties).
- Create a detailed data inventory for all sensitive data, including "crown jewels" Intellectual Property (IP).
- StakeholdCreate a detailed inventory of contracts that flow-down sensitive data to Third-Party Service Providers (TSP).ers ensure control owners develop documented SOP to address the control objective(s).
- Create a detailed network diagram that includes TSPs and the geographic location where data is stored, transmitted and/or processed.
- Create a detailed inventory of TSP that make up the Direct Supply Chain (DSP) (e.g., direct contracts).
- Categorize TSP based to identify their criticality to the organization's mission and business processes, per LOB
- Create a Data Flow Diagram (DFD) that shows how sensitive data from the organization to TSP, including the TSP's subcontractors.
- Inventory TSP access control for both critical systems and sensitive data.
- Develop C-SCRM -specific metrics.
- Identify key stakeholders for a Quarterly Business Review (QBR) on C-SCRM metrics and issues.
Phase 7
Manage Risk
Proactive risk management processes must exist across all phases of development/information/system life cycles to address confidentiality, integrity, availability and safety aspects. Risk management must address internal and external factors, including cybersecurity, privacy and C-SCRM considerations. To manage risk, it requires the organization to enforce a clearly defined risk threshold and ensure reasonably-expected secure practices are operational.
This step has 3 subcomponent steps:
- Develop & implement a Risk Management Program (RMP) to identify, assess and remediate risk.
- Perform a gap assessment from applicable statutory, regulatory and contractual obligations.
- Create a Plan of Action & Milestone (POA&M) to track and remediate deficiencies.
Phase 8
Change Control
Develop & implement change control processes and workflows, including a Change Control Board (CCB) that is technically competent to evaluate security ramifications for baseline security configuration deviations.
Phase 9
Centralized Configuration Management Plan (CMP)
Develop and implement a centralized Configuration Management Plan (CMP) to enforce secure configurations.
Phase 10
System Hardening
Identify, build & implement secure baseline configurations (e.g., hardening standards) for all technology platforms.
Phase 11
Incident Response
Develop & implement incident response capabilities to detect, respond to and recover from incidents.
Phase 12
Physical Security
Develop & implement physical security capabilities to detect, respond to and recover from physical security incidents.
Phase 13
Continuous Monitoring
Develop & implement continuous monitoring capabilities through log collection and analysis (e.g., SIEM).
Phase 14
Identity & Access Management (IAM).
Develop & implement Identity & Access Management (IAM) to address "least privilege" and Role-Based Access Control (RBAC).
Phase 15
Network Security
Develop & implement network security practices.
Phase 16
Maintenance
Develop & implement proactive maintenance practices.
Phase 17
Attack Surface Management (ASM)
Develop & implement Attack Surface Management (ASM) practices as part of a broader Vulnerability & Patch Management Program (VPMP).
Phase 18
Threat Intelligence
Develop & implement a threat intelligence capability.
Phase 19
Business Continuity
Develop & implement business continuity capabilities (e.g., Disaster Recovery (DR), Business Continuity (BC), Continuity of Operations (COOP), etc.).
Phase 20
Security Awareness Training
Build and maintain a security-minded workforce through training & awareness.
Phase 21
Tamper Resistance & Detection
Develop & implement tamper resistance and detection capabilities.
Phase 22
Information Assurance Program (IAP)
Develop & implement an Information Assurance Program (IAP) to validate control implementation.
Phase 23
Decommission & Migration
Develop & implement system application and service decommissioning and migration capabilities.
Phase 22
Supply Chain Protections
Implement and monitor supply chain protections (contractual obligations, assessments & monitoring compliance).
Properly Manage Supply Chain-Related Threats
To properly manage supply chain-related threats, organizations must evaluate country-based threats posed by its supply chain. This review must cover the geographic concerns where your products, services and support originate from or transit through:
- Transmit, process and/or store your company's or its clients’, data across the SISP's systems, applications and/or services;
- Manufacture products or product components used in your company's operations and/or products; and/or
- Provide services for your company's operations and/or products.
Geographic-specific threat management criteria is refined by guidance from authoritative sources, such as:
- Priority Watch List & Watch List
- Corruption Perceptions Index
- Notorious Markets List
- Designated State Sponsors of Terrorism
- EAR / ITAR restrictions
- Potentially hostile data localization laws
Operationalizing C-SCRM
An organization's executive leadership team drives the success of C-SCRM. On a day-to-day basis, cybersecurity merely has a supporting role, where an organization's non-technology leadership team is the leading factor in the success of a SCRM program. When you start looking at how do you "do C-SCRM" in a practical manner, it is more than just a control set, where a C-SCRM program needs to have authority over several key business functions that impact supply chain security:
- Secure Development Practices
- Procurement Practices
- Risk Management Practices
- Systems, Applications & Services Management Practices
- Innovation and development.
- Onboarding new technologies/services.
- Business operations (e.g., manufacturing, service delivery, etc.).
- Business Continuity & Disaster Recovery (BCDR).
- Third-party relationship onboarding and management (e.g., vendors, service providers, contractors, etc.).
- Decommissioning technologies, services and third-party relationships.
- The CSCO needs to report directly to the organization’s Chief Executive Officer (CEO) to eliminate conflicts of interests among leadership representing Lines of Business (LOB) within the organization.
- The CSCO must be able to influence cybersecurity and data protection controls by being part of the organization’s cybersecurity steering committee.
- Due to the reliance on risk management practices and the underlying cybersecurity and data protection controls that enable a SCRM program to function, the Chief Information Security Officer (CISO) should directly report to the CSCO.
- Due to the supply chain nature of DevSecOps, the Chief Technology Officer (CTO) role should directly report to the CSCO.
- Due to the external focus of the SCRM program, the Chief Contracting Officer (CCO) role should directly report to the CSCO to ensure contracts and procurement actions are in-line with the SCRM program.
- Due to how technology is so integral to business operations, the Chief Information Officer (CIO) role should directly report to the CSCO.
- The CISCO, CIO, CTO and CCO need to be viewed as peers, each with an equal role of importance in the SCRM program, where the CSCO provides operational leadership to orchestrate SCRM activities across the enterprise and its supply chain.
- Maintain close working relationships through frequent visits and communications.
- Mentor and coach suppliers on C-SCRM and actively help suppliers improve their cybersecurity and supply chain practices.
- Invest in common solutions.
- Require the use of the same standards within the acquirer organizations and by suppliers, thereby simplifying communications about cybersecurity risk and mitigations and helping to achieve a uniform level of quality throughout the ecosystem.
- Rules and protocols for information sharing between acquirers and suppliers.
- Joint development, review and revision of incident response, business continuity and disaster recovery plans.
- Protocols for communicating vulnerabilities and incidents.
- Responsibilities for responding to cybersecurity incidents.
- Coordinated communication methods and protocols.
- Coordinated restoration and recovery procedures.
- Collaborative processes to review lessons learned.
- Updates of coordinated response and recovery plans based on lessons learned.
- Increased executive leadership or Board of Directors (BoD) involvement for establishing C-SCRM as a top business priority and to ensure proper oversight.
- Clear governance of C-SCRM activities that includes cross-organizational roles and responsibilities with clear definitions and designation/distribution of these roles among enterprise risk management, supply chain, cybersecurity, product management and product security (if applicable) and other relevant functions appropriate for the organization’s business.
- Leading framework-based policies, standards and procedures that provide guidance to different business units detailing their C-SCRM activities.
- Same policies used internally and with suppliers.
- Integration of cybersecurity considerations into the system and product development life cycle.
- Use of cross-functional teams to address specific, enterprise-wide risks.
- Clear definition of roles of individuals responsible for cybersecurity aspects of supplier relationships (which may be different than those responsible for procurement activities with specific suppliers).
- Establishment of Centers of Excellence (CoE) to identify and manage best practices.
- A set of measures of success used to facilitate decision-making, accountability and improvement.
- Approved and banned supplier lists.
- Use of software and hardware component inventory (e.g., bill of materials) for third-party components.
- Prioritization of suppliers based on their criticality.
- Establishment of testing procedures for the most critical components.
- Establishment of a known set of security requirements or controls for all suppliers, especially robust security requirements for critical suppliers to be used in procurement (sometimes known as master specifications).
- Service-Level Agreements (SLA) with suppliers that state the requirements for adhering to the organization’s cybersecurity policy and any controls required of the supplier.
- Establishment of intellectual property rights agreements.
- Shared supplier questionnaires across like organizations, such as within the same critical infrastructure sector.
- Upstream propagation of acquirer’s security requirements within the supply chain to sub-tier suppliers.
- Assurance that suppliers have only the access they need in terms of data, capability, functionality and infrastructure; bounding this access by specific time frames during which suppliers need it.
- Use of escrow services for suppliers with a questionable or risky track record.
- Provision of organization-wide training for all relevant stakeholders within the organization, such as supply chain, legal, product development and procurement; this training may also be extended to key suppliers.
- Identification of alternative sources of critical components to ensure uninterrupted production and delivery of products.
- Secure requirements guiding disposal of hardware that contains regulated data (e.g., CUI, FCI, PII, CHD, PHI, etc.) or otherwise sensitive information (e.g., Intellectual Property (IP)).
- Protocols for securely terminating supplier relationships to ensure that all hardware containing acquirer’s data has been properly disposed of and that the risks of data leakage have been minimized.
- Activities should involve identifying and assessing applicable risks, as well as determining appropriate response actions.
- Developing a C-SCRM strategy and implementation plan to document selected response actions and monitoring performance against that plan.
- Manage risks. Cyber supply chain risk is associated with a lack of visibility into, understanding of and control over many of the processes and decisions involved in the development and delivery of cyber products and services.
- Manage threats and vulnerabilities. Effectively managing cyber supply chain risks requires a comprehensive view of threats and vulnerabilities.
- Threats can be either “adversarial” (e.g., tampering, counterfeits) or “non-adversarial” (e.g., poor quality, natural disasters).
- Vulnerabilities may be “internal” (e.g., organizational procedures) or “external” (e.g., part of an organization’s supply chain).
- Developing Data Flow Diagrams (DFDs) that track where regulated data (e.g., CUI, FCI, PII, CHD, PHI, etc.) or “crown jewels” IP is stored, transmitted and processed.
- Identifying suppliers that process regulated data or “crown jewels” IP.
- Developing network diagrams that identify suppliers that have access to the acquirer’s system and network infrastructure.
- Threat modeling to determine whether a supplier can become an attack vector by being compromised and allowing threat actors access to the acquirer’s organization.
- For technology companies, whether a supplier can become an attack vector for the technology company’s products or services delivered to customers.
- Controlling the volume of data a supplier has access to or hosts.
- Monitoring the revenue contribution of suppliers (e.g., criticality).