External System Services | Risk Assessments and Organizational Approvals

SA-9(1) is a procurement gating control disguised as a security control. It requires two things: (1) a risk assessment performed at the organizational level before you acquire or outsource information security services, and (2) explicit approval by personnel or roles you define in advance. The practical goal is to prevent teams from contracting for security-relevant services (managed security, external monitoring, vulnerability scanning, incident response retainer, identity services, etc.) without understanding the downstream operational, compliance, and supply-chain risk.

For FedRAMP Moderate programs and federal agency environments, this requirement often fails in two predictable ways: the risk assessment happens after a contract is signed (“we assessed during onboarding”), or approvals are informal (“Security said OK in email”) and not tied to defined roles, thresholds, or acceptance authority. Examiners want to see that your organization consistently evaluates risk before committing, and that risk acceptance is owned by the right decision-makers—not by whoever initiated the purchase.

This page gives you requirement-level steps, artifacts, and an execution plan to operationalize SA-9(1) quickly without building a bureaucracy that blocks delivery.

Regulatory text

Requirement (verbatim): “Conduct an organizational assessment of risk prior to the acquisition or outsourcing of information security services and ensure that the acquisition or outsourcing of information security services is approved by organization-defined personnel or roles.” (NIST Special Publication 800-53 Revision 5)

Operator interpretation (what you must do):

1. Before you sign, renew, or expand scope for an external information security service, you must perform an organizational risk assessment that evaluates impact and exposure to your mission/system(s), not just the project team’s preferences.
2. You must define who can approve these acquisitions (roles), and ensure the acquisition is actually approved by those roles each time.

This is not “do a vendor questionnaire at some point.” This is a formal decision gate that must occur before commitment.

Plain-English interpretation

If a third party will provide a service that affects your security posture, you must:

• Assess the risk early (what could go wrong, how bad would it be, how you reduce it).
• Get the right people to sign off (based on predefined roles and risk thresholds).
• Prove it happened in the correct order (assessment first, approval next, then purchase).

Who it applies to (entity and operational context)

Entity types (typical):

• Cloud Service Providers operating under FedRAMP authorizations
• Federal agencies acquiring outsourced security services (NIST Special Publication 800-53 Revision 5)

Operational context (where this shows up):

• Buying or outsourcing information security services, including (examples you can adapt to your environment):
  • Managed detection and response (MDR) / SOC services
  • Penetration testing, vulnerability scanning, attack surface monitoring
  • Incident response retainers and forensics support
  • Identity proofing, MFA services, privileged access management as a service
  • Security configuration management services
  • Security awareness and phishing simulation platforms (if they integrate with corp identity/email)
• Renewals and scope expansions that materially change data access, integration depth, or operational reliance.
• Emergency purchases during incidents (you can fast-track, but you still need pre-defined approver roles and a recorded risk decision).

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

Step 1: Define your scope trigger (“information security services”)

Create a one-page definition and include examples plus edge cases. Keep it operational:

• In scope: any external service that monitors, configures, tests, responds to, or materially influences security controls, security telemetry, identity, access, encryption, key management, or incident handling.
• Also in scope: services that require privileged access, deep integrations (SSO, API tokens), or access to security logs.
• Out of scope (optional): generic IT services with no security control impact, unless they access sensitive system data.

Add a procurement intake question: “Does this third party provide information security services or require privileged access/security log access?”

Step 2: Build a lightweight “organizational risk assessment” template

Keep it consistent and scorable. Your template should capture:

• Service description and business purpose (why you need it, what it replaces)
• Systems and data touched (including whether it affects FedRAMP boundary systems)
• Access model (admin access, read-only, break-glass, shared accounts prohibited)
• Integration points (SSO, agents, API keys, log forwarding)
• Failure modes and impact (service outage, bad detections, data exposure, misconfiguration)
• Third-party dependency risk (subcontractors, hosting, support locations, data flows)
• Control expectations (logging, incident notification, audit rights, encryption)
• Residual risk statement (what risk remains after mitigations)
• Recommendation (approve, approve with conditions, or reject)

This can be produced by GRC, Security, or Procurement, but it must represent an organizational view (not just the requestor’s).

Step 3: Define approval roles and decision thresholds

SA-9(1) requires “organization-defined personnel or roles.” Make it role-based and auditable:

• Minimum roles to define:
  • Information Security (control owner review)
  • Privacy (if personal data is involved)
  • Legal/Contracts (terms, liability, audit rights)
  • Procurement/Sourcing (commercial control point)
  • Authorizing official / risk executive / designated risk acceptance role (final risk acceptance)

Add thresholds so approvals are predictable:

• High-impact systems, privileged access, or security telemetry access requires risk acceptance by the designated risk role.
• Lower-risk tools may be approved by Security + Procurement, with escalation criteria.

Document this as an “External Security Services Approval Matrix” and reference it in your procurement workflow.

Step 4: Embed the gate in the buying process (so timing is provable)

You need a hard stop before purchase. Practical options:

• Purchase requisition workflow: require the completed risk assessment attachment and route to defined approvers.
• Contracting checklist: Legal cannot finalize without the assessment ID and approval record.
• Security architecture review board: for higher-risk services, make board approval the gate.

Auditors look for “prior to acquisition.” The simplest proof is timestamps: assessment completed date, approval date, then PO/contract signature date.

Step 5: Contract conditions that reduce residual risk

Your risk assessment should feed contracting requirements, such as:

• Minimum security requirements (encryption, access control, logging)
• Incident notification and cooperation expectations
• Audit support and evidence obligations
• Subcontractor transparency where relevant
• Offboarding and data return/destruction requirements

Don’t over-promise. Put only what you can enforce and monitor.

Step 6: Handle renewals, changes, and emergencies

Define a re-assessment trigger:

• Renewal with no material change: abbreviated re-assessment plus re-approval.
• Material change (scope, access, new integration, new data types): full reassessment.
• Incident/emergency acquisition: expedited assessment plus documented after-action confirmation that the right approvers accepted the risk before engaging the service.

Step 7: Operationalize with tooling (where Daydream fits)

Most failures are workflow failures, not policy failures. A system like Daydream can centralize: intake, scoping, risk assessments, approval routing by role, and evidence retention so each acquisition leaves a clean audit trail. The win is consistency: every security service goes through the same gate, with the same artifacts, stored in the same place.

Required evidence and artifacts to retain

Keep artifacts that prove (a) assessment happened, (b) it happened before purchase, (c) the right roles approved:

• External security services intake record (ticket or form)
• Completed organizational risk assessment (with version history)
• Approval matrix (roles, thresholds, escalation rules)
• Approval records (workflow logs, e-signatures, or dated approvals tied to roles)
• Procurement records showing timing (requisition, PO, contract signature date)
• Contract clauses or addenda driven by the assessment (security addendum, SOW requirements)
• Renewal/change reassessment records and re-approvals
• Exceptions register (if you allow exceptions, with documented compensating controls and approvals)

Common exam/audit questions and hangups

Expect questions like:

• “Show me three examples where you assessed risk before signing the contract.”
• “Who is authorized to approve outsourcing of information security services, and where is that defined?”
• “How do you ensure project teams can’t bypass Security for renewals?”
• “How do you determine which third parties count as information security services?”
• “What triggers re-assessment for scope changes or renewals?”

Hangups:

• Approvals are by individuals (names) rather than roles; staff turnover breaks the control.
• Risk assessment exists but is clearly after the fact (contract predates assessment).
• “Security reviewed” but no documented organizational risk acceptance.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Treating this as a generic vendor due diligence questionnaire	SA-9(1) requires organizational risk assessment and defined approvals before acquisition	Add a pre-purchase gate with assessment + approvals tied to roles
“We do this in onboarding after purchase”	Timing requirement is explicit	Move the assessment to requisition stage and require timestamps
No defined approver roles, only ad hoc emails	Approvals are not repeatable or auditable	Publish an approval matrix and enforce it in workflow routing
Only Security signs off	Organizational risk includes legal, operational, privacy, and mission impacts	Require cross-functional review; escalate based on thresholds
Renewals auto-renew without review	Scope and risk drift over time	Add renewal triggers and require re-approval for security services

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, SA-9(1) maps to common failure patterns seen in audits: undocumented risk acceptance, shadow procurement of security tooling, and third parties gaining privileged access without a formal decision. The risk is not theoretical: outsourced security providers often sit on high-value telemetry and admin paths. A weak gate increases your exposure to supply-chain incidents, misconfigurations, and audit findings tied to inadequate governance.

Practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Define “information security services” scope triggers and add them to procurement intake.
• Publish an approval matrix with roles and escalation thresholds.
• Deploy a standard risk assessment template and require it for new requests.
• Identify current security-service third parties and flag upcoming renewals for reassessment.

Days 31–60 (Workflow enforcement)

• Implement the hard stop in your purchasing/contracting workflow (no assessment, no signature).
• Train Procurement, Security, and Legal on the decision flow and required artifacts.
• Run a tabletop test: simulate a high-risk security service acquisition and verify approvals route correctly.
• Stand up a central evidence repository (or configure Daydream to capture intake → assessment → approval → contract artifacts).

Days 61–90 (Scale and audit readiness)

• Expand to renewals and material changes with explicit reassessment triggers.
• Perform an internal mini-audit: sample completed acquisitions and verify order-of-operations evidence.
• Create an exceptions process with time-bound approvals and compensating controls.
• Convert your “top security services” into pre-approved patterns (standard contract clauses + baseline requirements) to reduce cycle time without weakening the gate.

Frequently Asked Questions

What qualifies as “information security services” under SA-9(1)?

Treat any third party service that monitors, tests, configures, or responds for security controls, or that needs privileged access or security log access, as in scope. Write your definition down and force the question at intake so teams don’t decide case-by-case.

Does SA-9(1) apply to renewals or only new purchases?

The text says “prior to the acquisition or outsourcing,” which you should interpret to include renewals and scope expansions where you are re-committing to the service. Define renewal triggers so the control stays effective as contracts roll forward.

Who should be the “organization-defined personnel or roles” that approve?

Use roles that can accept risk and commit the organization, typically Security leadership plus a designated risk acceptance authority, with Legal and Procurement as required reviewers. Document the roles and thresholds in an approval matrix and route approvals through a system workflow.

Can we approve by email if the approver is in the right role?

Email can work as evidence, but it is fragile and hard to audit at scale. A routed approval workflow tied to roles (with timestamps and immutable records) reduces rework and makes “prior to acquisition” easy to prove.

What does “organizational assessment of risk” mean versus a project-level assessment?

It means the assessment reflects enterprise impacts: system boundaries, shared controls, incident response obligations, auditability, and downstream dependencies. A project-only view (“we need this tool”) is not enough without enterprise risk acceptance.

How do we handle emergency incident-response retainers or urgent security services?

Pre-define an expedited path with the same roles, shorter assessment depth, and clear documentation of risk acceptance before engaging the third party. After the emergency, complete a formal assessment package for the record and for renewal decisions.