Supplier Risk Assessment

The supplier risk assessment requirement means you must identify third-party dependencies, assess their cybersecurity risk based on access and criticality, and continuously monitor those risks with documented reviews, follow-up actions, and escalation. Under C2M2 v2.1 THIRD-PARTIES-1.C, auditors will look for a living process, not a one-time questionnaire. ¹

Key takeaways:

• Maintain an inventory of third parties and map each to systems, data, and operational impact in scope. ¹
• Use a repeatable risk method plus ongoing monitoring signals, then track issues to closure with evidence. ¹
• Keep “operating” artifacts: review logs, tickets, escalations, and the monitoring configuration that produced them. ¹

“Supplier risk assessment” in practice is third-party cyber risk management that you can defend under testing. The requirement is short, but the examiner expectation is not: you need to show that external dependencies are identified, risk-rated, and actively monitored over time, with actions taken when risk changes or control failures appear. C2M2 frames this as managing cybersecurity risks arising from external dependencies, which covers far more than traditional procurement. It includes SaaS providers, cloud and hosting, MSPs/MSSPs, OT/ICS integrators, OEMs, contractors with network access, and any partner that can materially affect operations. ¹

Operationalizing this quickly means two things. First, define scope and triage: which third parties matter most based on access, data sensitivity, and operational criticality. Second, instrument the program for evidence: decision records, monitoring thresholds, retention settings, review cadence, and a ticket trail that proves issues were seen and handled. ¹

If you already run third-party due diligence, this requirement usually fails on “monitoring” and “proof of operation,” not on initial intake. The guidance below is designed so a CCO/GRC lead can stand up a defensible control set without turning the effort into a multi-quarter platform project. ¹

Regulatory text

Excerpt: “Cybersecurity risks arising from external dependencies are managed and monitored.” ¹

What the operator must do:
You need an implemented process that (1) identifies external dependencies in scope, (2) assesses their cybersecurity risk in a repeatable way, and (3) monitors that risk over time with documented reviews and tracked remediation. A point-in-time onboarding review is not enough; the “managed and monitored” language requires ongoing oversight and proof that signals trigger action. ¹

Reference: C2M2 v2.1 THIRD-PARTIES-1.C (MIL2). ¹

Plain-English interpretation (what this requirement really means)

A supplier risk assessment program must answer these exam-grade questions with evidence:

1. Which third parties do we depend on, and what do they touch? Systems, networks, OT environments, data, and business processes. ¹
2. What is the cybersecurity risk introduced by each dependency? Based on access level, data sensitivity, operational criticality, and change velocity. ¹
3. How do we know the risk stayed acceptable after contract signature? Monitoring, periodic review, and issue management to closure. ¹

Who it applies to (entity and operational context)

This applies to organizations using C2M2 to assess maturity for a defined scope, commonly energy sector and critical infrastructure operators, including OT environments and IT that supports operations. ¹

Operationally, it applies wherever third parties:

• Have logical access (VPN, SSO, APIs, admin portals, remote support tools).
• Have physical access (facilities, substations, data centers, control rooms).
• Provide core services (cloud hosting, identity, network, EDR, ticketing, monitoring).
• Deliver industrial components or integration (OEM hardware/software, firmware, OT integrators).
• Handle sensitive data (customer data, grid/asset telemetry, incident data, engineering diagrams).

What you actually need to do (step-by-step)

Step 1: Define scope and ownership

• Set scope: align to the C2M2 assessment boundary (business unit, environment, OT/IT segment). Document inclusions/exclusions. ¹
• Assign owners: name a program owner (GRC/TPRM), an intake owner (Procurement/Vendor Mgmt), and technical validators (Security/OT engineering). Record RACI in a one-page memo.

Step 2: Build a third-party dependency inventory that auditors can trace

Create or reconcile a list that ties each third party to:

• Service provided and business owner
• Systems/applications involved
• Data types handled
• Connectivity methods (API, VPN, remote tools)
• Subcontractors/fourth parties if known
• Contract start/end, renewal dates

Practical tip: Start with AP/vendor master, SaaS spend, SSO app catalog, firewall/VPN partner lists, and OT integrator rosters. The goal is a defensible minimum viable inventory you can improve over time.

Step 3: Triage with a simple inherent risk rating

Define a consistent inherent risk rubric so teams stop debating each supplier from scratch. A workable rubric uses factors you can justify:

• Access: none, user, privileged/admin, persistent remote support
• Data sensitivity: public, internal, confidential, regulated/critical
• Operational criticality: non-critical, important, mission/operations critical
• Change exposure: static service, frequent releases, frequent access into environment

Output: a tier (for example: low/medium/high) that drives due diligence depth and monitoring intensity.

Step 4: Perform the supplier risk assessment (due diligence + technical validation)

For each in-scope third party based on tier:

• Due diligence package: security questionnaire or equivalent attestations, breach/incident history disclosures (as contractually available), and key policy excerpts (IR, vulnerability management, access control).
• Technical validation: confirm the third party’s access path and controls in your environment (SSO settings, MFA, least privilege, network segmentation, logging coverage).
• Contract controls: ensure security obligations exist (notification, audit rights where feasible, incident cooperation, data handling, subcontractor flow-down).

Keep the assessment outcome explicit:

• Accepted risk
• Conditional approval with remediation plan
• Not approved / require alternate

Step 5: Establish “managed and monitored” operations (the part most programs miss)

C2M2’s requirement is satisfied by operating monitoring, not just initial scoring. Build monitoring around signals you can actually collect and act on.

Minimum monitoring categories:

• Access and authentication events: third-party accounts created/removed, privilege changes, unusual login patterns.
• Connectivity events: VPN sessions, remote tool sessions, API key creation/rotation, failed connections.
• Control health signals: EDR coverage on managed endpoints (if applicable), log source health, certificate expiry, critical integration failures.
• Supplier change events: contract renewal, scope expansion, new integration, subcontractor changes (captured via procurement/IT change workflows).

Two control expectations from the provided best-practice guidance should be implemented as written:

• Document the systems, events, thresholds, and retention settings that support supplier risk assessment. This becomes your monitoring control narrative and is easy to test. ¹
• Keep review evidence, follow-up tickets, and escalation records that show logged events are actively monitored and resolved. This is your operating effectiveness proof. ¹

Step 6: Run a repeatable review and escalation loop

Define a standard workflow:

1. Monitoring produces an alert, review finding, or renewal trigger.
2. Analyst reviews and records disposition (benign, needs follow-up, confirmed issue).
3. Create a ticket with owner and due date; link it to the third party record.
4. Escalate based on predefined conditions (privileged access anomaly, unresolved critical findings, third-party incident, or refusal to remediate).
5. Close with evidence: screenshots, email confirmations, meeting notes, updated access lists, or contract amendments.

Operational reality: Most audit failures happen because findings exist in inboxes, chats, or spreadsheets, but not in a traceable system with closure evidence.

Required evidence and artifacts to retain

Auditors typically test both design and operation. Maintain artifacts that map cleanly to “managed and monitored.”

Program design (static or slowly changing):

• Third-party risk assessment policy/standard and scope statement
• Risk rating rubric and tiering criteria
• RACI and workflow diagram (intake → assessment → approval → monitoring → offboarding)
• Monitoring specification: systems, events, thresholds, retention settings (explicitly required) ¹

Operating evidence (time-bound records):

• Third-party inventory with system/data mappings
• Completed assessments and approvals (including exceptions)
• Review logs (who reviewed, when, what was checked, outcomes)
• Tickets, follow-ups, and escalation records (explicitly required) ¹
• Offboarding evidence: access removal, account disablement, key revocation
• Contract/security addenda repository and renewal reviews

Daydream note (earned, not forced): If you struggle to keep assessments, monitoring outputs, and tickets linked, Daydream can act as the system of record that ties third-party profiles to evidence and follow-up tasks, which reduces exam scramble without changing your underlying tools.

Common exam/audit questions and hangups

What examiners ask:

• “Show me your highest-risk third parties and why they are rated that way.”
• “Which third parties have privileged access, and how do you monitor their activity?”
• “Provide evidence of ongoing monitoring and follow-up for a sample of suppliers.” ¹
• “How do you handle scope changes, renewals, and subcontractors?”
• “Demonstrate retention settings for logs used to monitor third-party access.” ¹

Hangups that stall audits:

• No complete inventory; conflicting lists across Procurement, IT, and Security.
• Risk scoring exists, but there is no monitoring narrative or operating evidence.
• Tickets exist, but they are not traceable to a specific third party record and assessment.

Frequent implementation mistakes and how to avoid them

1. Treating “supplier” as procurement-only.
   Fix: include contractors, integrators, SaaS, cloud, and partners with access or data exposure.

2. One-and-done assessments.
   Fix: make renewal, integration change, and access change explicit triggers for reassessment.

3. Monitoring without documentation.
   Fix: publish the monitoring specification: log sources, event types, thresholds, and retention settings. ¹

4. No closure discipline.
   Fix: require tickets and closure evidence for findings; keep escalation records. ¹

5. Ignoring offboarding.
   Fix: integrate with IAM and network access removal. Offboarding is a control, not an HR courtesy.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. The practical risk is still direct: if supplier risk assessment is incomplete or not reviewed, suspicious activity and control failures can go undetected, and you may lack operating evidence during internal control testing, audits, customer diligence, or regulator review. ¹

Practical 30/60/90-day execution plan

First 30 days (stand up the minimum viable control set)

• Define scope, owners, and approval workflow.
• Produce the first dependency inventory from available sources (AP, SSO, VPN/remote access, OT integrators).
• Publish inherent risk rubric and tiering rules.
• Draft the monitoring specification (systems, events, thresholds, retention settings). ¹

Days 31–60 (execute assessments and start operating monitoring)

• Triage inventory into risk tiers; identify the highest-risk third parties.
• Complete assessments for the highest-risk set; document approvals and exceptions.
• Start review logging: who reviewed what, findings, and dispositions.
• Open tickets for gaps; establish escalation criteria; store evidence of follow-ups and closures. ¹

Days 61–90 (prove repeatability and audit-readiness)

• Run a second review cycle for a sample set to prove the process repeats.
• Test offboarding for at least one third party (access removal evidence).
• Validate retention settings and retrieval of logs needed for monitoring.
• Package an “audit binder” view: inventory, rubric, sample assessments, monitoring spec, review logs, tickets and escalations. ¹

Frequently Asked Questions

Does “supplier risk assessment” only apply to vendors we pay?

No. Treat “supplier” as any external dependency that can affect cybersecurity risk, including contractors, integrators, and partners with access or sensitive data exposure. The requirement is about external dependencies, not accounts payable categories. ¹

What’s the minimum evidence I need to prove we “monitor” suppliers?

Keep a written description of monitoring systems, events, thresholds, and retention settings, plus review records and follow-up tickets showing issues were handled. Examiners test operating evidence more than slide decks. ¹

Do we need a formal questionnaire for every third party?

Use tiering. Low-risk third parties can be handled with lighter controls, but higher-risk dependencies should have documented due diligence and technical validation tied to their access and criticality. ¹

How do we handle fourth parties (subcontractors)?

Capture known subcontractors during assessment, require flow-down obligations where feasible, and treat material subcontractor changes as a reassessment trigger tied to renewal or scope change.

Our monitoring tools are owned by Security, not GRC. Can GRC still satisfy the requirement?

Yes, if GRC can produce the monitoring specification and obtain review logs, ticket evidence, and escalation records. Ownership can sit with Security; accountability and evidence retention must be clear. ¹

What if a critical supplier refuses to remediate findings?

Record the risk decision explicitly (accept, transfer, mitigate, avoid), document compensating controls, and capture escalation and executive sign-off. Examiners typically accept informed risk acceptance better than undocumented exceptions.

What you actually need to do

Use the cited implementation guidance when translating the requirement into day-to-day operating steps. ²

Footnotes

1. Cybersecurity Capability Maturity Model v2.1

2. DOE C2M2 program