ID.RA-10: Critical suppliers are assessed prior to acquisition

To meet the id.ra-10: critical suppliers are assessed prior to acquisition requirement, you must define what “critical supplier” means for your business and run a documented cybersecurity and operational risk assessment before you sign, renew, or acquire that supplier relationship. Make the assessment a gated step in procurement, with clear approval criteria, remediation tracking, and retained evidence.

Key takeaways:

• “Prior to acquisition” means no contract execution or onboarding until the critical-supplier assessment is complete and approved.
• Scope hinges on a defensible criticality definition tied to business impact, data sensitivity, and dependency.
• Audit readiness depends on repeatable workflow + evidence (intake, risk findings, approvals, and exceptions).

ID.RA-10 sits in the NIST Cybersecurity Framework (CSF) 2.0 Risk Assessment category and targets a common failure mode: critical third parties are onboarded quickly, while risk reviews happen late, partially, or not at all. The operational goal is simple: for suppliers that could cause outsized harm if compromised or disrupted, you must assess their risk posture before your organization becomes dependent on them.

For a CCO, compliance officer, or GRC lead, the fastest path to operationalizing ID.RA-10 is to treat it as a procurement control with security input, not a security best-effort. Define “critical supplier” in a way your business and auditors will accept, create a standard pre-acquisition assessment package, and enforce a “no approval, no purchase” rule with a documented exception path.

This page gives requirement-level guidance you can implement quickly: who is in scope, what the assessment must cover, how to embed it into sourcing and M&A motions, what evidence to retain, and where teams get stuck during exams and internal audits. The aim is a control you can run repeatedly, defend in writing, and improve over time based on outcomes and incidents. ¹

Requirement: ID.RA-10 pre-acquisition assessment for critical suppliers

Requirement statement: critical suppliers must be assessed prior to acquisition. ¹

Practically, this means:

• You identify which suppliers are “critical” before purchase decisions are locked in.
• You perform and document a risk assessment proportional to the supplier’s criticality.
• You use the results to approve, reject, require remediation, or accept risk with explicit sign-off.
• You retain evidence that the assessment happened prior to commitment.

Plain-English interpretation

If a third party can materially affect your ability to operate, protect sensitive data, deliver regulated services, or recover from incidents, you must not onboard them until you understand their risk and decide how you will manage it. “Assess” is not a single questionnaire by default; it is a decision-quality review that produces findings, required actions, and an approval outcome.

Who it applies to

Entity scope

• Any organization running a cybersecurity program and using NIST CSF 2.0 as a framework baseline. ²

Operational scope (typical “critical supplier” contexts)

• Cloud and hosting providers supporting production systems
• Managed service providers (MSPs/MSSPs) with privileged access
• Payment processors and core transaction platforms
• Identity providers (SSO), PKI/certificate services
• Software suppliers whose code runs in production (including key open-source support vendors)
• Data processors handling sensitive, regulated, or high-volume personal or customer data
• Single-source manufacturers or logistics providers where disruption stops delivery

Trigger events to treat as “acquisition”

• New third-party onboarding
• Contract renewal with material scope increase (more data, higher privileges, new region)
• Major product/module adoption within an existing supplier
• M&A or business acquisition where a critical supplier comes “embedded” in the acquired entity’s stack

Regulatory text

“Critical suppliers are assessed prior to acquisition.” ¹

Operator expectation: Build a procurement gate so critical suppliers cannot be contracted (or inherited through acquisition) without a completed assessment and documented decision. Your procedure must specify (1) how you classify criticality, (2) what assessment steps are required, (3) who approves outcomes, and (4) how you document exceptions.

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

Step 1: Define “critical supplier” with decision criteria

Create a short criticality rubric that procurement and the business can apply during intake.

Example criticality factors (use what fits your environment):

• Business dependency: Would outage materially disrupt operations or customer delivery?
• Data sensitivity: Will the third party store/process sensitive data?
• Access level: Will they get admin access, network access, or code deployment capability?
• Concentration risk: Is there a practical alternate provider or exit path?
• Regulatory exposure: Does the service support regulated activities or reporting commitments?

Output artifact: “Critical Supplier Definition & Tiering Standard” owned by GRC, approved by Security and Procurement.

Step 2: Embed a hard gate in procurement and onboarding

Make the assessment non-optional for critical suppliers:

• Add a required intake field: “Critical supplier? (Y/N) + justification”
• Configure your sourcing workflow so contract signature and PO issuance are blocked for critical suppliers until GRC/security approval is recorded.
• Define an exception path for true emergencies (documented business justification, time-bound compensating controls, senior risk acceptance).

What auditors look for: evidence the gate prevents “rubber-stamp after the fact.”

Step 3: Run a pre-acquisition assessment proportional to risk

For critical suppliers, your assessment should produce a clear risk view and decision. A workable package often includes:

A. Inherent risk profile (your risk)

• Service description, data types, integration points
• Access model (accounts, keys, admin paths)
• Hosting and subprocessor dependencies
• Geographic/data residency constraints

B. Supplier control posture (their risk controls)

• Security governance and policies
• Incident response and breach notification capability
• Vulnerability management and patching practices
• Identity and access management for privileged operations
• Encryption practices for data in transit/at rest
• Logging/monitoring and audit trails
• Business continuity and disaster recovery capabilities
• Subcontractor/subprocessor management

C. Contract/security requirements alignment

• Minimum security clauses (right to audit, security incident notification, data handling, subcontractor controls)
• SLAs tied to availability and support responsiveness (define internally; avoid copying generic templates without enforcement)
• Termination, data return/destruction, and exit assistance

D. Outcome

• Approve / approve with conditions / reject / escalate to risk acceptance committee
• Document required remediation items and deadlines
• Record compensating controls if you proceed with gaps (e.g., reduced access scope, segmentation, additional monitoring)

Step 4: Decide, document, and track remediation before go-live

Treat “approve with conditions” as a tracked plan, not an email thread.

• Create a remediation register tied to the supplier record
• Assign internal owners for each condition (security, IT, procurement, business)
• Define acceptance criteria and verify completion before production cutover where possible
• If you must proceed, document the rationale and compensating controls with sign-off

Step 5: Operationalize recurring evidence collection (make it sustainable)

ID.RA-10 is easiest to defend when you can show it is systematic:

• Map the requirement to a policy, procedure, control owner, and recurring evidence collection cadence for critical suppliers. ¹
• Automate reminders and workflow steps in your GRC tool or procurement system.
• Maintain a “critical supplier inventory” that ties supplier records to systems, data, and business owners.

Where Daydream fits: If you need fast audit-ready implementation, Daydream can centralize your critical supplier inventory, standardize pre-acquisition assessment workflows, and collect recurring evidence tied directly to ID.RA-10 so you can show consistent operation without rebuilding artifacts each audit cycle.

Required evidence and artifacts to retain

Store evidence so you can prove timing (“prior to acquisition”) and decision quality.

Minimum evidence set (critical suppliers):

• Criticality determination (tiering rubric result + justification)
• Completed assessment package (questionnaire, document review notes, findings)
• Supporting documents received (security attestations, policies, incident process summaries, architecture diagrams if provided)
• Risk rating and summary memo (what matters, why, and residual risk)
• Approval record (security/GRC + business owner; procurement confirmation)
• Contract/security addendum or clause checklist showing required terms addressed
• Remediation plan with owners and status
• Exception approvals (if any), including compensating controls and time bounds

Common exam/audit questions and hangups

Questions you should be ready to answer with artifacts:

• How do you define “critical supplier,” and who approved that definition?
• Show three examples where the assessment was completed before contract signature/PO.
• What happens if a business tries to bypass the process?
• How do you handle inherited suppliers during M&A or business acquisitions?
• How do you track remediation items and verify closure?
• How do you reassess when scope changes (more data, new access, new region)?

Typical hangups

• Procurement timestamps do not align with assessment timestamps.
• “Critical” is decided ad hoc, with no rubric.
• Assessments exist, but results do not drive contractual requirements or go/no-go decisions.
• Exceptions are common and undocumented.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: treating a questionnaire as the assessment.
   Fix: require a written risk summary and decision outcome, even if inputs are a questionnaire.

2. Mistake: defining “critical” too narrowly to reduce workload.
   Fix: tie criticality to business impact, sensitive data, and privileged access. Document rationale and review it with leadership.

3. Mistake: allowing signature “pending security review.”
   Fix: implement a procurement block or contract routing rule for critical suppliers.

4. Mistake: no exception governance.
   Fix: create a formal exception template with approvers, compensating controls, and an expiration date.

5. Mistake: no linkage to remediation and contract terms.
   Fix: create a clause checklist and a remediation tracker; require closure evidence.

Enforcement context and risk implications

NIST CSF is a framework, not a penalty schedule. The risk is practical: if a critical supplier fails or is breached, you may face operational disruption, contractual claims, customer churn, and regulatory scrutiny under sector-specific rules that expect third-party risk governance. Your most defensible position is showing that you assessed the supplier before dependency, documented known gaps, and made an explicit risk decision aligned with leadership accountability. ²

Practical 30/60/90-day execution plan

First 30 days (Immediate)

• Publish a “critical supplier” definition and tiering rubric with named approvers.
• Add a procurement intake question for criticality and a basic routing rule for security/GRC review.
• Standardize a pre-acquisition assessment template and an approval memo format.
• Stand up an exception process with required sign-offs and a repository location.

By 60 days (Near-term)

• Build a critical supplier inventory and map each to systems/data/business owners.
• Implement a contract clause checklist for critical suppliers (security + procurement owned).
• Pilot the workflow on active sourcing efforts; collect evidence in a consistent folder structure or GRC system.
• Create remediation tracking and tie it to onboarding/go-live checkpoints.

By 90 days (Ongoing operations)

• Expand the gate to cover renewals with material changes and M&A inherited suppliers.
• Add periodic reporting: critical supplier pipeline, approvals, open remediation, exception count.
• Run a tabletop test: simulate urgent onboarding and prove the exception path works without bypassing documentation.
• Review and tune the rubric based on what created rework (missing data types, unclear access models, subprocessor surprises).

Frequently Asked Questions

What counts as “prior to acquisition” for ID.RA-10?

Treat it as “before you commit the organization.” For most teams, that is before contract signature, PO issuance, or provisioning access for production.

We already have a third-party risk program. Do we need a separate control for ID.RA-10?

No, but you do need a clearly mapped control that proves timing and gating for critical suppliers. Auditors will ask for evidence that the process blocks onboarding until approval.

How do we handle M&A where suppliers are already in place?

Add an M&A intake step that identifies critical inherited suppliers and triggers an expedited assessment before integration or renewal. Document transitional exceptions if immediate assessment is impossible.

What if the supplier refuses to share security documentation?

Record the refusal as a risk finding, assess impact, and require compensating controls or contractual commitments. If the service is critical, escalate to a formal risk acceptance decision.

Can we rely on a SOC 2 report alone?

A SOC 2 can be a strong input, but you still need an inherent risk profile, scope fit (services and locations), contract clause alignment, and a documented decision outcome.

How do we prove the assessment happened before acquisition?

Keep timestamped artifacts: intake submission date, assessment completion date, approval record, and contract signature/PO date. Auditors commonly test chronology.

Footnotes

1. NIST CSWP 29; NIST CSF 1.1 to 2.0 Core Transition Changes

2. NIST CSWP 29