THIRD-PARTY AND SUPPLY CHAIN RISK PROCEDURE

Vendor Tiering · Evidence by Tier · Contract Clauses · SBOM · International Access · Supply Chain Compromise Team (SCCT)

Table of Contents

1. Purpose and Scope
2. Roles and Interface to Procurement / ERM / BR
3. Vendor Tiering
4. Cyber-Specific Score Adjustment
5. Evidence by Tier
6. Differences by Vendor Type
7. Approved Provider and SaaS Catalog
8. Contract Security Clause Library
9. Shared Responsibility Matrix
10. International Access, Denied by Default
11. SBOM and Software Integrity
12. CIP-013 Supply Chain Plan
13. CUI Subcontractor Flow-Down
14. FedRAMP Equivalency Evidence
15. Supply Chain Compromise Team (SCCT)
16. Continuous Monitoring and Re-Assessment
17. Regulatory and Framework Alignment Summary
18. Document Control

1. Purpose and Scope

The policy makes third-party and supply-chain security Principle 8. Subordinate standards each impose specific requirements: IT/cloud/SaaS approval and attestation tracking, OT vendor assessment and CIP-013, CUI flow-down and FedRAMP equivalency, SBOM and software integrity. Until this procedure, those obligations had no shared operating model.

This procedure defines how CERG engages with the broader enterprise vendor program, where CERG’s cyber-specific work begins and ends, what evidence is collected at each tier, and how the program responds when a vendor is compromised. It operationalizes the edge types defined in the Edge Register — specifically the Vendor, SaaS, and Software Supply edges.

CERG Doesn’t Own Vendor Management, It Owns the Cyber Slice

Procurement, Enterprise Risk Management, and Business Resiliency typically own vendor tiering, contract lifecycle, and business continuity. CERG accepts the business tier as the starting point and adjusts only where cyber-specific concerns are material enough to alter it. This boundary is the difference between a TPRM program that ships and one that drowns in vendors.

2. Roles and Interface to Procurement / ERM / BR

3. Vendor Tiering

CERG uses a 5-tier vendor model that maps to the typical enterprise model. Business rating sets the baseline; CERG adjusts only via Section 4.

3.1 Tiering Inputs

CERG accepts the business tier from ERM / Procurement as the starting point. Inputs include data classification handled, system access granted, regulatory scope, blast radius, and operational dependency.

4. Cyber-Specific Score Adjustment

CERG adjusts the vendor tier up only when one or more cyber-specific concerns are material. Adjustments down (vendor “isn’t as critical as Business says”) are not permitted, Business owns criticality.

4.1 Adjustment Triggers

Adjustments Are Documented, Not Negotiated

Every cyber-driven tier adjustment is recorded in the TPRM tool with the trigger, evidence, and reviewer. If a Business Owner disagrees, the resolution path is CERG-PRC-RM-001 Section 8, never an off-record handshake.

5. Evidence by Tier

Evidence requirements grow with tier. The table below names the cyber evidence required at minimum; specific subordinate standards may require more (e.g., FedRAMP for CUI scope).

5.1 Evidence Currency

• T1 evidence is reviewed annually, no later than 30 days before attestation expiry.
• T2 evidence is reviewed annually.
• T3 evidence is reviewed every 24 months unless conditions change.
• T4/T5 evidence is reviewed on contract renewal.

Material vendor events (breach, ownership change, regulator action) trigger an out-of-cycle review regardless of tier.

6. Differences by Vendor Type

Requirements differ by what the vendor is. The table below summarizes the most-different requirements; subordinate standards govern detail.

6.1 Low-Control / High-Dependency Operating Model

Not every provider relationship allows the organization to configure, monitor, patch, or test. CERG recognizes four control levels that determine what can be required of a provider and how residual risk is managed.

The control level is recorded per provider in the Approved Provider Catalog and re-assessed at each annual review. A provider at Contractual or Opaque levels must have a documented kill-switch procedure tested at least annually.

CERG does not pretend to control what it cannot control. The distinction between “we require this” and “we hope this” is not a compliance failure — it is operational honesty. Document the gap, monitor what is visible, plan the exit.

6.2 MSP and MSSP Hard Requirements

Managed Service Providers and Managed Security Service Providers operate inside the organization’s trust boundary with elevated access. The following requirements apply to every MSP/MSSP relationship, regardless of tier:

MSP/MSSP onboarding requires: contract language covering all eight requirements, evidence of the provider’s own security posture (SOC 2 Type II or equivalent), a completed shared responsibility matrix, and a successful kill-switch test before production access is granted.

MSP/MSSP offboarding requires: revocation of all access within 24 hours of contract termination, confirmation that provider-owned artifacts (logs, configurations, credentials) have been returned or destroyed, and a final access review confirming no residual access paths remain.

7. Approved Provider and SaaS Catalog

CERG maintains an Approved Provider and SaaS Catalog as the system-of-record for which third-party services may be procured for which scope.

Procurement consults the catalog at intake; CERG updates it at each evidence cycle and after each SCCT closure.

8. Contract Security Clause Library

CERG provides Legal with a clause library; Legal owns negotiation. Clauses below are the minimums to seek; alternative language with equivalent intent is acceptable.

9. Shared Responsibility Matrix

Every T2+ cloud / SaaS provider has a Shared Responsibility Matrix on file. Where the vendor publishes one, CERG annotates it; where they don’t, CERG produces it and seeks vendor confirmation.

The matrix is the single source of truth for cross-team conversations about “who handles X.”

10. International Access: Denied by Default

International access to in-scope systems and data is denied by default. Where business need requires it, access is treated as a documented exception with conditions.

10.1 Operating Model

• A Country Risk Register classifies each country into tiers: Permitted · Restricted · Conditional · Prohibited.
• Permitted countries are those with established trust relationships, low geopolitical risk, and acceptable law-enforcement / data-protection regimes; access is allowed without exception (logged, monitored).
• Restricted countries require an exception per CERG-PRC-RM-001, with named controls (managed-device-only, session recording, enhanced detection routing).
• Conditional countries require additional senior exec / CISO approval, time-boxed access windows, and possible per-session approval.
• Prohibited countries do not get access; business need is resolved by alternative means (US-based delivery, alternate vendor).
• The Country Risk Register is reviewed at least quarterly; geopolitical events can trigger reclassification at any time.
• All international access is logged to SIEM with country-of-access metadata; the SOC routing pack includes country-tier as a fast-triage field.

10.2 Vendor Implications

• Vendors must disclose all proposed countries of access at onboarding and at any change.
• Vendor international-access tier above the country’s permitted level triggers a contract addendum and exception.
• Vendor non-disclosure of country-of-access discovered post-onboarding is a material event triggering SCCT.

11. SBOM and Software Integrity

11.1 SBOM Collection — Tiered Requirements

Material update = new minor/major version, security patch release, or dependency change affecting >10% of components.

SBOM delivery method: Vendor provides via secure channel (TPRM portal, signed email, or API). Internal builds generate in CI/CD per Section 11.3.

11.2 SBOM Processing Pipeline

1. Ingest: SBOM received → validate format (CycloneDX/SPDX) → parse components
2. Scan: Cross-reference components against NVD, GHSA, vendor advisories → findings → PRC-VM-001 pipeline
3. Enrich: Map to machine-readable/cerg-sbom-schema.yaml fields → store in SBOM registry
4. VEX: Request/validate VEX from vendor for Critical/High findings → record vex_status
5. Approve: Governance reviews → approval_status set → evidence linked in TPRM tool
6. Monitor: Quarterly re-scan for T1/T2; pipeline scan on every build for internal

11.3 Internal SBOM Generation (CI/CD Integration)

All internal production builds shall generate an SBOM as a pipeline artifact:

• Build-time: Generate CycloneDX SBOM from lockfiles / dependency graph (Syft, Trivy, or language-native tool)
• Scan: Immediate vulnerability scan against generated SBOM — fail build on Critical/High without VEX
• Sign: Cosign/Sigstore sign the SBOM artifact
• Publish: Push SBOM to artifact registry and CERG SBOM registry (machine-readable consumer)
• Gate: Production promotion requires approval_status = approved for the build’s SBOM

Pipeline snippet reference: tools/sbom-generate.sh (see below).

11.4 Software Integrity

• Releases signed by the vendor; signatures verified before deployment.
• Container images signed (cosign / sigstore); admission gate per CERG-STD-CFG-001 Section 7.
• Firmware (OT) verified per CERG-STD-OT-001; firmware updates follow CIP-010 process per CERG-PLN-CIP-001.

12. CIP-013 Supply Chain Plan

For BES Cyber Systems, CERG maintains a CIP-013 Supply Chain Risk Management Plan as a CERG-PLN-CIP-001 component, satisfying CIP-013-2 R1. The plan includes:

• Identification of supply chain risks across procurement and installation.
• Vendor security controls expectations (incident notification, coordination of access controls, software integrity, vendor remote access management, disclosure of known vulnerabilities).
• Procurement controls, clauses, evaluation, approvals.
• Implementation and verification, how controls are verified at installation and over time.
• Coordination with this procedure: vendor records here are CIP-013 records.

13. CUI Subcontractor Flow-Down

14. FedRAMP Equivalency Evidence

Where a CUI-relevant SaaS / cloud service is not FedRAMP-authorized but is proposed for use, CERG requires a documented FedRAMP-equivalency package:

• SOC 2 Type II with NIST 800-53r5 Moderate baseline mapping.
• 3PAO-equivalent assessment letter or independent assessor attestation.
• Customer-side configuration commitments (CUI label, region, key control).
• Sub-service organization carve-outs reconciled.
• Re-papering trigger documented (FedRAMP authorization issued, attestation lapses, scope change).

The package is recorded in the TPRM tool as the vendor’s Inheritance Evidence Package for the CUI overlay.

15. Supply Chain Compromise Team (SCCT)

When a vendor reports, or is publicly disclosed as having, a material cybersecurity incident affecting their service or product, CERG activates the Supply Chain Compromise Team (SCCT).

15.1 SCCT Membership

At minimum:

• SOC / Incident Response lead: coordinates investigation and customer-side detection / containment.
• CERG, Risk (TPRM): vendor liaison; assembles vendor-supplied facts; updates TPRM record.
• CERG, Governance: regulator notification path; CUI / NERC-CIP / SOX reporting if applicable.
• Legal: contractual remedies, regulator interface, communications review.
• Procurement: vendor relationship; commercial leverage.
• Business Owner of the affected service: operational decision authority; user / customer communications.

Other invitees as needed: CISO (declared briefing), Privacy (PII implications), Engineering, OT operations (OT vendors), Communications.

15.2 SCCT Activation Triggers

• Confirmed vendor breach affecting our data, systems, or service.
• Material vulnerability in a deployed vendor product (e.g., critical CVE, supply-chain implant).
• Vendor’s regulator action affecting our reliance on their service.
• Public reporting of a vendor compromise where our exposure is plausible.
• Vendor non-disclosure of country-of-access discovered.
• Discovery of unauthorized vendor sub-processor handling our data.

15.3 SCCT Workflow

1. Activate. TPRM declares SCCT, notifies membership within 4 business hours of trigger (1 business hour for T1 vendors).
2. Assemble facts. Vendor advisory, public reporting, internal exposure analysis (which systems, which data, which scopes).
3. Contain. Coordinate with SOC / IR on containment, credentials rotation, vendor session termination, IOC sweep, detection tuning.
4. Decide. Disposition: continue use with conditions / suspend use / terminate. Documented and owned by Business + CISO.
5. Communicate. Internal user / customer notification per Legal; regulator notification where required (CUI DC3, NERC-CIP O&P, SOX disclosure committee).
6. Remediate. Risk register entries, exception updates, contract addenda, monitoring uplift.
7. Close. SCCT after-action with lessons learned; feeds threat intelligence and detection.

15.4 SCCT Evidence

Every SCCT activation produces an SCCT record with: trigger, membership, timeline, decisions, notifications, risk register updates, vendor-side commitments. Records are retained for the longer of the vendor relationship + 3 years or the regulatory retention requirement.

Why a Named Team Instead of “We’ll Pull People In”

Naming the team in advance, with a roster, a trigger, and a 4-hour clock, converts vendor compromise from a panicked phone-tree exercise into a procedure. The first SolarWinds-class event tests every assumption about your TPRM program; SCCT is how that test doesn’t surprise you.

16. Continuous Monitoring and Re-Assessment

16.1 Automated Monitoring Signals

CERG continuously monitors the vendor landscape using automated signals. The following sources are integrated into the TPRM monitoring pipeline:

16.2 Periodic Re-Assessment Triggers

Vendors are re-assessed on the following cadence based on tier:

16.3 Vendor Performance Metrics

The Vendor Risk Analyst tracks the following metrics for each T1 and T2 vendor:

16.4 Escalation Paths for Deteriorating Vendor Posture

16.5 Integration with Approved Provider Catalog

Continuous monitoring results directly affect the Approved Provider Catalog (APC) status values:

• Green (Approved): All monitoring signals within acceptable thresholds; evidence current.
• Amber (Conditional): One or more signals outside Green threshold; remediation plan accepted. Automatic review at 90 days.
• Red (Restricted): Critical finding or breach unresolved; new engagements restricted until status returns to Amber or Green.
• Black (Prohibited): Vendor determined to pose unacceptable risk; existing services transitioned off per the offboarding procedure.

16.6 Integration with Threat Intelligence

Vendor monitoring is integrated with CERG-PRC-TI-001 for threat intelligence specific to vendors:

• The Threat Intelligence Analyst produces a Vendor Risk Note (per PRC-TI-001 §6.5) when threat intelligence reveals TTPs, CVEs, or campaign activity relevant to a vendor in the APC.
• Vendor-specific IOCs from threat intelligence are deployed to detection tooling per PRC-TI-001 §4.6.
• Quarterly threat briefings to the Vendor Risk Analyst summarize the threat landscape affecting the vendor portfolio.

16.7 Vendor Offboarding

When a vendor relationship ends, a structured offboarding process ensures access is revoked, data is retrieved or destroyed, and residual obligations are met.

Offboarding Triggers

Offboarding Checklist

Post-Termination

Surviving contractual clauses (confidentiality, data handling, audit rights) remain in effect. Evidence is retained per CERG-PRC-AUD-001. Offboarding completion is signed off by the Vendor Risk Analyst and Business Sponsor.

16.8 Fourth-Party Risk Management

Fourth-party risk arises when a critical vendor relies on subcontractors (sub-processors) the organization does not have a direct relationship with.

Disclosure Requirements

• T1 and T2 vendors must disclose all critical sub-processors
• Vendors must notify the organization of sub-processor changes at least 30 days before the change
• The organization reserves the right to object; the vendor must provide an alternative or allow contract termination without penalty

Evidence for Critical Sub-Processors

Concentration Risk

The Vendor Risk Analyst monitors for multiple vendors relying on the same sub-processor. If a single sub-processor supports ≥ 3 T1/T2 vendors, a formal concentration risk assessment is conducted.

16.9 Business Continuity and Disaster Recovery (BCDR) for Vendors

Critical and high-tier vendors must demonstrate BCDR capability proportional to the criticality of the service they provide.

BCDR Requirements by Tier

RTO/RPO Expectations

RTO (Recovery Time Objective) and RPO (Recovery Point Objective) expectations are set based on the organization’s dependency on the vendor:

• If the organization’s own Tier 1 service depends on the vendor, the vendor’s RTO must be ≤ the organization’s RTO for that service.
• If the vendor processes regulated data (CUI, SOX), RPO must be ≤ 1 hour.
• RTO/RPO commitments are documented in the contract and reviewed at each vendor re-assessment.

BCDR Assessment

During vendor assessment, the Vendor Risk Analyst evaluates: - Does the vendor have a documented BCDR plan? - Has the plan been tested? When? What was the outcome? - Are RTO/RPO commitments compatible with the organization’s requirements? - Does the vendor’s BCDR plan account for dependencies on its own critical sub-processors?

Assessment results are recorded in the TPRM tool and reviewed at each re-assessment cycle.

16.10 Metrics

17. Regulatory and Framework Alignment Summary

18. Document Control

Source: procedures/CERG-PRC-TPRM-001_Third_Party_and_Supply_Chain_Risk_Procedure.md · Download .md · View on GitHub