SA-9(1): Risk Assessments and Organizational Approvals

SA-9(1): risk assessments and organizational approvals requirement means you must complete and document an organizational risk assessment before you acquire or outsource information security services, and route the decision through the right internal approvers. Operationalize it by adding a mandatory “security services pre-acquisition risk assessment + approval” gate to procurement with clear risk criteria, sign-offs, and retained evidence. ¹

Key takeaways:

• Put a hard gate in your intake-to-contract workflow: no purchase order or signature until the risk assessment is completed and approved.
• Scope specifically to information security services acquisitions and outsourcing, not generic third-party onboarding.
• Keep examiner-ready evidence: the assessment, the risk decision, and proof the approver had authority.

SA-9(1) sits in the NIST SP 800-53 Rev. 5 System and Services Acquisition (SA) family and targets a failure mode auditors see often: security services get bought “fast” (managed security providers, SOC augmentation, pen test firms, incident response retainers, cloud security tooling with managed components) without a documented risk decision by the organization. The control enhancement is short, but the operational impact is real. You need a repeatable way to identify when a purchase is “information security services,” assess the organizational risk before committing, and capture approvals that match your risk governance.

For a CCO, GRC lead, or Compliance Officer, the fastest path is to embed SA-9(1) into procurement and third-party due diligence so it becomes a required pre-contract step with named approvers, defined risk factors, and consistent artifacts. The outcome you want is simple: any time your organization acquires or outsources information security services, you can show (1) you assessed risk beforehand, and (2) an authorized leader approved the risk posture and conditions. ²

Regulatory text

Requirement (excerpt): “Conduct an organizational assessment of risk prior to the acquisition or outsourcing of information security services; and” ¹

Operator meaning: before you sign, renew, or materially expand a contract for information security services, you must (a) assess risk to the organization and (b) obtain the organizational approvals your governance model requires. The “prior to” language is the key audit hinge: a great assessment completed after signature fails the control intent. ¹

Plain-English interpretation

You need a documented, organization-level risk assessment for buying or outsourcing security services, and you need documented approval from the right decision-makers. This is not limited to “high-risk” vendors. It is triggered by the type of service (information security services) and the timing (before acquisition/outsourcing). ¹

In practice, this means:

• Define what counts as “information security services” in your environment (examples below).
• Route those purchases through a required assessment and approval workflow.
• Keep the artifacts in a place you can retrieve by vendor/service and by contract action (new, renewal, expansion).

Who it applies to

Entity scope: organizations implementing NIST SP 800-53 controls, including federal information systems and contractor systems handling federal data. ¹

Operational scope (what activities trigger SA-9(1)):

• New acquisition of information security services (e.g., managed detection and response, security monitoring, vulnerability management as a service, incident response retainer, managed IAM).
• Outsourcing security functions that were performed internally (e.g., outsourcing SOC operations, SIEM management, security engineering support).
• Material changes that effectively create a new risk decision (renewals with expanded scope, new data access, new integration paths, new geographies, or subcontractor model changes).

What is “information security services” (practical examples):

• MSSP / MDR / SOC-as-a-service
• Penetration testing and red teaming providers
• Incident response firms and breach counsel coordination services (where they handle sensitive technical artifacts)
• Security configuration management and hardening services
• Security tooling that includes a managed service component (vendor-operated monitoring, tuning, admin access)
• Consulting firms with privileged access to systems for security work

If your procurement intake cannot reliably distinguish these from general IT services, SA-9(1) will be inconsistently applied and hard to defend in an audit.

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

1) Put SA-9(1) ownership and decision authority on paper

• Assign a control owner (usually GRC, Security Assurance, or Third-Party Risk).
• Define approvers by risk level (e.g., Security leader, system owner, privacy, legal, procurement; add executive approval for elevated risk).
• Document the approval authority rule (who can accept what). Keep it simple enough that procurement can follow it.
  This aligns to the recommended control approach of mapping SA-9(1) to an owner, procedure, and recurring evidence. ¹

2) Define the trigger: a security-services intake classification

Add an intake question in your procurement/TPRM workflow: “Is this an information security service or outsourcing of a security function?” Provide a short list of examples and a tie-break rule: if the third party will have privileged access, handle security telemetry, or manage security controls, treat it as “yes” and route to SA-9(1).

3) Standardize the “organizational risk assessment” content

Create a template that produces consistent, auditable outputs. Minimum fields that auditors expect to see:

A. Service profile

• Service description and scope boundaries
• What security function is being provided or outsourced
• Whether the third party has admin access, remote access, or physical access
• Data types touched (including logs/telemetry) and where processed

B. Risk analysis (organizational view)

• Confidentiality, integrity, availability impact if the service fails or is compromised
• Concentration risk (single provider for critical security function)
• Subcontractor/4th-party reliance
• Exit/transition risk and reversibility
• Regulatory/customer commitments that depend on this service

C. Required conditions

• Contractual requirements (access controls, incident notification, audit rights, subcontractor controls)
• Security requirements (MFA, logging, segmentation, encryption expectations)
• Operational requirements (RTO/RPO expectations if the service is critical to detection/response)

D. Decision

• Residual risk statement
• Approved / approved with conditions / not approved
• Approver names, roles, and date

4) Integrate with third-party due diligence, not parallel to it

SA-9(1) does not replace your vendor due diligence; it forces an explicit risk decision before acquisition/outsourcing. The clean operating model:

• Third-party due diligence collects evidence (SOC reports, security questionnaire, pen test summary, data flow, etc.).
• SA-9(1) consolidates that input into an organizational risk decision and approval.

If you run SA-9(1) as a separate “GRC memo” disconnected from due diligence, it turns into rework and creates version-control problems during audits.

5) Make the gate enforceable in procurement and contracting

Define a hard stop:

• Procurement cannot issue a PO.
• Legal cannot finalize signature.
• Security cannot provision access. until the SA-9(1) assessment and approvals are attached to the intake record.

Daydream fits naturally here by mapping SA-9(1) to the control owner, the procedure, and recurring evidence artifacts so the gate is repeatable across teams and renewals. ¹

6) Operational cadence: reassess when the risk decision changes

SA-9(1) is “prior to acquisition or outsourcing,” but you should also trigger a refreshed assessment when there’s a material change that creates a new risk profile (expanded access, new systems, new data types, new subcontractors, or a new delivery model).

Required evidence and artifacts to retain

Keep evidence tied to the contract action (new/renewal/expansion) and searchable by third party name.

Core artifacts

• Completed SA-9(1) organizational risk assessment (template output)
• Approval record (workflow screenshot/export, email approval, or ticket approval) showing approver role and date
• Procurement intake record showing the security-services classification and the date the gate was satisfied
• Contract exhibits/clauses reflecting required conditions (security schedule, incident notice terms, audit rights, subcontractor controls)

Supporting artifacts (common audit requests)

• Due diligence packet used as inputs (SOC 2, SIG/CAIQ responses, security questionnaire results)
• Data flow diagram or integration summary for the service
• Access model: who gets privileged access, how it’s granted, and how it’s monitored

Common exam/audit questions and hangups

Auditors and assessors tend to probe four areas:

1. “Show me it happened before signature.” They will compare assessment/approval timestamps to PO and contract signature dates.
2. “How do you decide what qualifies as information security services?” If your definition is fuzzy, sampling will expose inconsistency.
3. “Who approved and were they authorized?” A manager’s “thumbs up” is weak if your governance says the system owner or CISO must accept risk.
4. “Where are the conditions enforced?” If your assessment lists conditions but the contract and onboarding don’t reflect them, you have a design-to-operation gap.

Frequent implementation mistakes (and how to avoid them)

Mistake: treating SA-9(1) as a checkbox attached after the contract is signed.
Fix: put the control into procurement workflow logic as a mandatory pre-signature gate.

Mistake: confusing vendor due diligence with organizational risk acceptance.
Fix: keep both. Due diligence collects facts; SA-9(1) records the organizational decision based on those facts.

Mistake: approvals that don’t match your risk model.
Fix: define approver roles by risk level and enforce it in the workflow. If the approver is out of office, route to a documented delegate.

Mistake: no artifact hygiene.
Fix: standardize filenames, store in a system of record, and link evidence to the contract record so you can respond to sampling quickly.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should frame risk in assessment terms rather than case law. The practical risk is governance failure: outsourcing security capabilities without documented risk acceptance increases the chance of unbounded access, weak contractual controls, and unplanned exit risk during incidents. ¹

Practical 30/60/90-day execution plan

First 30 days (stand up the gate)

• Name SA-9(1) control owner and define approver roles.
• Publish a one-page definition of “information security services” with examples.
• Create the SA-9(1) assessment template and approval record format.
• Add intake questions to procurement/TPRM to trigger SA-9(1) routing.

Days 31–60 (make it real in procurement and legal)

• Implement a “no signature/PO” gate: contract workflow requires attached assessment + approval.
• Train procurement, legal, security, and key budget owners on the trigger and the artifacts.
• Pilot on a small set of active security services (new and renewing) and tune the template.

Days 61–90 (audit readiness and scale)

• Run a sampling exercise: pick recent security-services purchases and verify evidence completeness and timing.
• Close gaps by backfilling missing approvals only where policy permits; otherwise treat as exceptions with documented remediation.
• Operationalize recurring evidence: ensure every qualifying contract action produces the same artifact set and gets stored consistently.
• If you use Daydream, map SA-9(1) to owner, procedure, and evidence artifacts so renewals and expansions stay consistent year over year. ¹

Frequently Asked Questions

What counts as “information security services” for SA-9(1)?

Treat services as in-scope when the third party performs a security function or administers security controls, especially with privileged access or access to security telemetry. If there’s doubt, classify as in-scope and document the rationale.

Do we have to do this for every security tool we buy?

SA-9(1) applies to acquiring or outsourcing information security services, so a pure software license with no managed component may fall outside your defined trigger. If the provider manages, monitors, or administers security controls as part of the offering, route it through SA-9(1). ¹

Can we combine SA-9(1) with our third-party risk assessment?

Yes, as long as the combined workflow produces an organizational risk decision and approval before purchase or outsourcing. The key is an explicit residual risk decision and sign-off, not just completed questionnaires.

What evidence is most likely to be sampled in an assessment?

Assessors usually ask for the completed risk assessment, proof of approval authority, and timestamps showing the assessment happened before contract signature or PO issuance. Keep the contract security exhibits linked to the assessment.

How do we handle renewals where the contract already exists?

Treat renewals and scope expansions as a new decision point when they materially change access, data, or delivery model. Re-run the organizational risk assessment and capture updated approvals before the renewal is executed.

Who should be the approver?

Use your risk governance model, but make it explicit. Common approvers include the system owner for affected systems and a security leader who can accept security risk; add legal and privacy approvers when the service touches regulated data or adds contractual obligations.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5