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

SA-9(1) requires you to complete an organization-level risk assessment before you acquire or outsource information security services, and to route the decision through your organization’s approval process so risk is explicitly accepted or mitigated before contracting. Operationally, this is a “no assessment, no purchase” gate tied to procurement and security governance.

Key takeaways:

• Build a hard intake trigger for any third party providing information security services, including MSSPs, SOC services, scanning, and managed detection.
• Produce a documented risk assessment with defined risk owners, treatment decisions, and recorded approvals before signature.
• Retain an evidence bundle that ties the assessment to the specific acquisition decision, contract artifacts, and approval record.

SA-9(1) sits in the NIST SP 800-53 “System and Services Acquisition” family and targets a recurring failure mode: organizations buy or outsource security capabilities quickly, then discover the arrangement introduces unacceptable risk, unclear accountability, or ungoverned access into sensitive environments. The control enhancement is narrow but operationally sharp. You must assess risk before you acquire or outsource information security services, then obtain organizational approvals so the decision is deliberate and traceable ¹.

For a CCO, GRC lead, or compliance operator, the fastest path to implementation is to treat SA-9(1) as a procurement control gate plus an evidence standard. The “assessment” cannot live only in someone’s email or as an informal security review. It must be repeatable, owned, and tied to approvals that reflect your governance model (security leadership, risk, procurement, legal, and the business sponsor). This page gives you a requirement-level runbook: who it applies to, how to wire it into intake and contracting, the minimum artifacts auditors expect, and the common traps that cause control failure.

Regulatory text

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

What the operator must do

• Before you sign a contract, issue a purchase order, or otherwise commit to an outsourcing/acquisition of information security services, you must document an organizational risk assessment covering the proposed service and how it will be delivered in your environment ¹.
• You must route the result through organizational approvals so risk is explicitly accepted, mitigated through required actions, or the acquisition is rejected. SA-9(1) is commonly implemented as a “stop/go” decision point tied to procurement workflow ¹.

Practical reading: “Organizational assessment” means it cannot be only a technical team’s preference. Your risk function, security governance, and procurement authority need a clear role in the decision.

Plain-English interpretation

If you hire a third party to do security work (monitoring, scanning, incident response retainer, identity services, managed firewall, etc.), that third party will almost always receive privileged access, sensitive logs, or operational control. SA-9(1) requires you to evaluate the risk of that arrangement before you commit, and to document who approved taking that risk.

This is not the same as “the provider is secure.” Your assessment must also cover:

• how the service connects to your systems,
• who gets admin access,
• what data leaves your boundary,
• what happens during an incident,
• what your exit plan is if the relationship fails.

Who it applies to

Entity scope

• Federal information systems and programs implementing NIST SP 800-53 controls ².
• Contractor systems handling federal data where 800-53 controls are flowed down contractually or used to satisfy federal customer requirements ³.

Operational scope (what counts as “information security services”)

Treat SA-9(1) as in-scope when a third party:

• provides managed security operations (SOC, MDR, MSSP),
• performs vulnerability scanning, penetration testing, or red teaming,
• runs identity/security tooling on your behalf (managed SIEM, managed EDR, key management),
• provides incident response services or forensics,
• has administrative access to security controls, logs, or production systems to “secure” them.

Borderline cases (decide explicitly): security advisory consulting, GRC tooling, security awareness training platforms. If the service touches sensitive security telemetry, credentials, or control-plane access, treat it as in-scope.

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

1) Establish the trigger and intake gate

Goal: no assessment, no acquisition.

• Add a required intake question in procurement/TPRM: “Is this an information security service (managed or outsourced)?”
• Define trigger events:
  • new engagement,
  • renewal with material change (scope, access, hosting location, subcontractors),
  • incident or major performance failure prompting re-evaluation.
• Make the intake gate block contracting until the risk assessment and approvals are attached.

Operator tip: If procurement cannot block, enforce through finance: require an approved risk package before vendor setup or invoice payment.

2) Define the minimum risk assessment content (one template)

Use a short, standardized assessment template so teams can execute quickly and consistently.

Minimum sections to include:

• Service description and boundary: what the third party does, for which systems, in which environments.
• Access model: accounts, privileges, remote access method, break-glass procedures, MFA requirements.
• Data handling: logs, alerts, case artifacts, customer data exposure; encryption and retention expectations.
• Dependency and concentration risk: single points of failure; operational reliance; key person risk.
• Incident roles: notification paths, evidence handling, chain-of-custody expectations, IR collaboration.
• Fourth parties: subcontractors used to deliver the security service.
• Exit and reversibility: how you transition off the provider, data return/destruction, continuity plan.
• Risk rating and treatment: residual risk statement, required mitigations, and who owns each mitigation.

Keep scoring simple if you don’t have a mature model. Auditors care more that you made a reasoned decision and recorded it than the elegance of the math.

3) Perform due diligence inputs that make the assessment defensible

SA-9(1) does not prescribe a specific due diligence list, but your assessment needs credible inputs. Common inputs:

• security questionnaire focused on access, logging, and incident workflows,
• architecture diagram / connectivity description,
• SOC reports or independent assessments if available,
• list of privileged roles and support model,
• draft contract/SOW and proposed SLAs.

Tie each input to a risk statement. Example: “Provider requires persistent VPN with admin privileges” → risk: expanded attack surface and lateral movement potential → mitigation: privileged access management, time-bound access, session recording, IP allowlisting.

4) Route organizational approvals (define who must sign)

Create an approval matrix based on risk and access.

Approval model (practical):

• Business owner approves budget and business need.
• Security approves technical risk posture and required controls.
• Risk/Compliance (GRC) confirms the assessment is complete, consistent, and retained.
• Procurement/Legal confirms contract language matches required mitigations and audit rights.

Escalate high-risk engagements to a security steering committee or risk committee. If your governance model uses formal risk acceptance, require a named executive risk owner.

5) Contracting linkage: ensure the deal matches the assessed assumptions

The assessment is meaningless if the contract contradicts it. Require a check that:

• security requirements and access restrictions are in the SOW/MSA,
• incident notification and cooperation terms are explicit,
• right to audit/assess is addressed where applicable,
• termination and data return/destruction clauses align to exit plan.

6) Define exceptions and emergency buys (without breaking the control)

You will have emergency incident-response retainers or urgent tool purchases. Handle this with:

• a short-form emergency assessment,
• time-boxed approval (temporary acceptance),
• a required “full assessment due by” task tracked to closure.

Auditors accept exceptions when they are controlled, approved, and remediated.

7) Operate and test the control

SA-9(1) fails most often as a “one-time paperwork exercise.” Add a recurring control health check:

• sample recent security-service acquisitions,
• verify the assessment exists and is dated before signature,
• confirm approvals match the matrix,
• confirm mitigations were implemented or tracked to closure.

If you use Daydream to manage third-party due diligence, this is where it helps: a control card, a required evidence bundle, and workflow gates reduce the odds that a security-service purchase bypasses risk review.

Required evidence and artifacts to retain

Create a minimum evidence bundle per acquisition. Store it in your GRC system or a controlled repository.

Evidence bundle (minimum):

• Completed SA-9(1) risk assessment (dated, scoped to the service)
• Intake record showing trigger and classification as “information security service”
• Due diligence inputs (questionnaire responses, architecture/access description, assurance reports if provided)
• Risk treatment plan (mitigations, owners, due dates) and tracking ticket(s)
• Approval record (names, roles, date/time, decision: approve/approve with conditions/reject)
• Contract/SOW version that includes required security terms (or redlines showing insertion)
• Exception record (if applicable) and closure evidence

Retention period should follow your internal policy and applicable contract requirements; SA-9(1) cares that you can produce it on demand and show it was completed pre-acquisition.

Common exam/audit questions and hangups

Auditors and federal customers usually probe three things:

1. “Show me that this happened before contracting.”
   Hangup: assessments dated after signature, or approvals recorded after onboarding.

2. “How do you define ‘information security services’?”
   Hangup: teams treat MSSPs as normal IT vendors and skip the gate.

3. “Who can accept the risk?”
   Hangup: approvals are informal (Slack/email) with no authority, or only security signs without business ownership.

4. “Where is the evidence, and is it complete?”
   Hangup: evidence spread across tools with no linkage to the specific purchase.

Frequent implementation mistakes (and how to avoid them)

Mistake 1: Treating it as a questionnaire-only exercise

Fix: Write the risk assessment as your conclusion, supported by inputs. The assessment should contain risk statements, treatment decisions, and residual risk, not only collected documents.

Mistake 2: No hard procurement gate

Fix: Add a required field and attachment requirement in procurement onboarding. If your tools can’t enforce, set a finance control that blocks vendor setup until the package exists.

Mistake 3: Approvals don’t match governance

Fix: Publish an approval matrix. Require named role-based approvals and document delegations of authority.

Mistake 4: Contract doesn’t reflect mitigations

Fix: Add a contracting checklist step: “Confirm risk mitigations are contractual obligations or operational commitments with owners.”

Mistake 5: No follow-through on required mitigations

Fix: Track mitigations like findings. Assign owners, deadlines, and closure evidence. Include them in periodic control health checks ¹.

Enforcement context and risk implications

No public enforcement cases are provided in the source catalog for SA-9(1), so this guidance focuses on audit and customer diligence expectations rather than specific penalties.

Risk implications are still concrete:

• Security-service third parties commonly require privileged access and can become a high-impact entry point.
• Poorly documented approvals create governance gaps where nobody can explain why the organization accepted certain risks.
• Weak linkage between assessment and contract creates “paper compliance” that fails during incidents or disputes.

Practical 30/60/90-day execution plan

First 30 days (establish the gate and template)

• Assign an owner (TPRM, GRC, or Security Risk) and publish a one-page control runbook aligned to SA-9(1) ¹.
• Define “information security services” for your environment and list in-scope examples.
• Build the intake trigger in procurement and third-party onboarding.
• Create the assessment template and approval matrix.
• Define the minimum evidence bundle and storage location ¹.

Days 31–60 (run it on real purchases and tighten)

• Pilot the workflow on current in-flight security-service purchases and renewals.
• Calibrate risk ratings and required approvers based on what you see in practice.
• Add a contracting checklist so mitigations become binding commitments.
• Stand up exception handling for urgent buys.

Days 61–90 (make it durable and auditable)

• Run a control health check over a sample of completed acquisitions and document results ¹.
• Create a remediation tracker for missing artifacts, late approvals, or unclosed mitigations.
• Train procurement, security, and budget owners on the “no assessment, no purchase” rule.
• If you use Daydream or another TPRM/GRC workflow tool, automate required fields, attachments, and approval routing so SA-9(1) cannot be bypassed by process drift.

Frequently Asked Questions

Does SA-9(1) apply to buying security software (SaaS) or only to outsourcing people?

Apply it whenever the third party provides an information security service or operates security functions on your behalf. If the provider gets privileged access, processes sensitive logs, or runs security operations for you, treat it as in-scope.

What counts as “organizational approval” in practice?

It’s an approval recorded by roles with authority under your governance model, typically the business owner plus security/risk, and procurement/legal where contracting terms are involved. Email can work if it is retained and traceable, but workflow approvals are easier to evidence.

Can we do the risk assessment after we sign if we need the service urgently?

The requirement is “prior to the acquisition or outsourcing” ¹. If you have emergencies, use a controlled exception path with a short-form pre-approval and a tracked requirement to complete the full assessment promptly.

How deep does the risk assessment need to be?

Deep enough to support a decision: service scope, access paths, data handling, incident responsibilities, key dependencies, and an explicit risk treatment decision. Avoid generic write-ups that don’t mention your actual environment and integration points.

What evidence do auditors ask for most often?

They usually ask for proof the assessment and approvals happened before contracting, plus the completed assessment, approval record, and the executed SOW/MSA that reflects required mitigations.

We already have third-party risk management. How do we avoid duplicating work?

Add a specific SA-9(1) branch in your intake workflow for information security services. Reuse your standard third-party due diligence pack, but require an explicit security-service risk narrative and the tighter approval matrix for privileged access and security telemetry exposure.

Footnotes

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

2. NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 DOI

3. NIST SP 800-53 Rev. 5