SA-9(2): Identification of Functions, Ports, Protocols, and Services

SA-9(2) requires you to make external system service providers explicitly identify the functions they perform and the network connectivity they require (ports, protocols, and related services) so you can approve, restrict, and monitor those connections. Operationalize it by forcing this data into contracting and onboarding, then enforcing it through firewall rules, security groups, and continuous change control. ¹

Key takeaways:

• You need a provider-supplied “connectivity and function specification” for each in-scope external service, not a generic architecture diagram. ¹
• The output must drive allowlisting decisions (what is permitted) and change control (what changes require re-approval).
• Auditors look for traceability: requirement → provider attestation/artifact → implemented network controls → monitoring and revalidation.

The sa-9(2): identification of functions, ports, protocols, and services requirement is about eliminating “mystery connectivity” to third-party services. If an external provider cannot tell you what the service does and exactly what network communications it needs, you cannot confidently restrict traffic, detect unauthorized changes, or evaluate blast radius when something breaks. SA-9(2) turns that uncertainty into a concrete checklist you can contract for, implement, and validate.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat SA-9(2) as a procurement and technical enforcement requirement: (1) require provider disclosure of functions and connectivity; (2) translate the disclosure into allowlisted rules (firewalls, security groups, proxies, egress filters); (3) monitor for drift; and (4) revalidate when the provider or your integration changes. The strongest implementations treat this as an integration gate: no connectivity goes live until the provider’s ports/protocols/services list is reviewed, approved, and implemented in your environment.

This page gives requirement-level steps, evidence to retain, and audit-ready questions so you can implement SA-9(2) without turning it into an endless questionnaire exercise. ²

Regulatory text

NIST SP 800-53 SA-9(2) states: “Require providers of the following external system services to identify the functions, ports, protocols, and other services required for the use of such services: {{ insert: param, sa-09.02_odp }}.” ¹

What the operator must do:

• Define which “external system services” are in scope for your system boundary (the organization-defined parameter in the control).
• For each in-scope external service, require the provider to supply:
  • the functions the service performs for you (what it is doing and why you use it), and
  • the connectivity requirements (ports, protocols, and any dependent services) needed to use it.
• Use that provider-provided identification to drive restricted, approved connectivity and ongoing change control so unapproved ports/protocols/services do not silently appear. ¹

Plain-English interpretation

SA-9(2) is an “integration transparency” requirement: if a third party provides a service your system depends on, you must get a precise declaration of what the service does and what network pathways it needs. Then you must use that declaration to set boundaries.

A compliant outcome looks like this: you can point to a specific external service (e.g., managed SIEM, identity provider, payment gateway, CRM SaaS, managed DNS), produce a document from the provider listing required inbound/outbound flows (ports/protocols/endpoints/dependencies), and show the corresponding allowlisted rules and monitoring in your environment.

Who it applies to (entity and operational context)

Entities: Federal information systems and contractor systems handling federal data commonly inherit or implement SA-9(2) as part of a NIST SP 800-53 control set. ²

Operational context (what “external system services” usually means in practice):

• SaaS platforms integrated with your enterprise identity, data pipelines, or endpoints
• Managed security services (MSSP/SOC, scanning, DDoS/CDN, managed WAF)
• Cloud service provider managed services you consume as “external” to a system boundary
• Payment, messaging, email delivery, customer support platforms
• Third-party APIs that require egress to specific endpoints and protocols

Important scoping decision: SA-9(2) includes an organization-defined list (“the following external system services…”). You need to write that list down so audits don’t devolve into debate about whether “all vendors” are in scope. ¹

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

Step 1: Define “in-scope external system services” for your system

Create a short scope statement that is testable, such as:

• External services with network connectivity to/from your system boundary
• External services that store, process, or transmit your system’s data
• External services that perform security-relevant functions (identity, logging, monitoring, key management)

Document the scope and assign a control owner (usually Security Architecture or Network Security) plus a GRC partner responsible for evidence completeness.

Step 2: Add a provider disclosure requirement to procurement/onboarding

Add a contractual or onboarding requirement that the provider must supply and keep current a Functions & Connectivity Specification. Keep it structured so engineers can implement it.

Minimum fields to request:

• Service name, environment (prod/non-prod), and integration owner
• Functions performed (business and security functions)
• Data types involved (high-level categories)
• Network flows required:
  • direction (ingress/egress)
  • ports and protocols
  • DNS names / IP ranges (provider’s published ranges if available)
  • required third-party dependencies (e.g., identity federation endpoints, update repositories)
• Authentication method at the network/service layer (e.g., mTLS, token-based)
• Change notification commitments (what changes they will notify you about)

Practical tip: require the provider to state what is not required (for example, “no inbound connectivity from internet to customer networks”), because negative assertions reduce ambiguity during audits and incident response.

Step 3: Review and approve the specification (security + engineering)

Run an internal review that answers:

• Do the functions align with the business purpose and approved data use?
• Are requested ports/protocols consistent with your security standards?
• Are there alternatives (private connectivity, proxying, egress gateways) that reduce exposure?
• Do we have monitoring coverage for the approved flows?

Record a formal approval outcome (approved / approved with conditions / rejected).

Step 4: Implement allowlisted connectivity based on the approved spec

Translate the provider’s identified requirements into enforceable controls:

• Firewall rules, security groups, NACLs
• Egress filtering / outbound proxies
• API gateways
• VPN/private link connectivity where applicable
• DNS allowlisting and certificate pinning/mTLS where applicable

Your evidence goal: every approved port/protocol/service in the provider spec maps to an implemented rule, and anything not listed is blocked by default.

Step 5: Monitor for drift and manage change

SA-9(2) breaks most often after go-live when providers add endpoints, change IP ranges, or introduce new service dependencies.

Operationalize change control:

• Trigger re-review when any of these change:
  • provider functionality (new modules/features enabled)
  • ports/protocols/endpoints
  • authentication methods
  • sub-processors or dependent services relevant to connectivity
• Detect drift with:
  • egress logs (proxy/firewall flow logs)
  • cloud configuration monitoring for security group changes
  • periodic validation by integration owners (attest “no change” or submit updated spec)

Step 6: Make it auditable (traceability)

Create a simple traceability map per external service:

• Provider Functions & Connectivity Spec (dated, versioned)
• Internal approval ticket/record
• Implemented rule identifiers (firewall change record, SG IDs)
• Monitoring references (log source names, alert rules)
• Revalidation record (provider update notice, internal attestation)

Daydream (as a workflow system) fits naturally here by tying each third party service to a requirement checklist, routing approvals, and producing an evidence packet that matches the SA-9(2) testing story without manual spreadsheet stitching.

Required evidence and artifacts to retain

Keep evidence per external service, in a consistent folder structure or GRC system:

1. Scope statement listing the in-scope external system services categories (and any exceptions).
2. Provider Functions & Connectivity Specification (versioned, dated).
3. Contract language / security addendum requiring the disclosure and change notification (or onboarding policy if contracting cannot be modified).
4. Risk/architecture review record (ticket, meeting notes, sign-off).
5. Network implementation evidence: firewall/security group rule exports, change tickets, configuration snapshots.
6. Monitoring evidence: flow log enablement, alert rules, periodic review results.
7. Change control records for updates and re-approvals.

Common exam/audit questions and hangups

Auditors and assessors usually probe these points for SA-9(2):

• “Show me which external services are in scope and why.”
• “Pick one external service. Where is the provider’s list of required ports/protocols/endpoints?”
• “How do you ensure only those ports/protocols are permitted?”
• “What happens when the provider changes IP ranges or adds new endpoints?”
• “How do you detect unauthorized connectivity or drift?”
• “Who approves exceptions, and how are exceptions time-bounded or revalidated?”

Hangup to expect: teams present a generic SOC 2 report or a high-level architecture diagram. That rarely answers “which ports/protocols/services are required,” which is the explicit SA-9(2) ask. ¹

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating this as a one-time vendor questionnaire.
   Fix: Put the connectivity spec under change control and revalidation; require provider update notifications.

2. Mistake: Capturing ports/protocols but not the “functions.”
   Fix: Require a short function statement tied to the business purpose and security relevance; auditors want to see you understand what the service is doing.

3. Mistake: Allowlisting “any/any” egress because it’s faster.
   Fix: Enforce default-deny egress patterns where feasible, with explicit exceptions tied to the approved spec.

4. Mistake: No mapping from provider spec to implemented rules.
   Fix: Add a simple mapping column in your evidence pack: Spec item → rule ID → change ticket.

5. Mistake: IP ranges and endpoints not maintained.
   Fix: Track endpoint sources (provider documentation) and assign an internal owner to review updates and push rule changes.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat it as an assessment-readiness and risk-reduction control rather than a “cite a case” obligation.

Risk-wise, SA-9(2) reduces:

• Unauthorized network paths to third-party services
• Over-permissive egress that weakens incident containment
• Integration outages caused by undocumented dependencies
• Audit findings driven by missing traceability and incomplete third-party due diligence artifacts ²

Practical 30/60/90-day execution plan

First 30 days (establish the gate)

• Assign control owner and RACI for SA-9(2).
• Write the in-scope definition for “external system services” for your system boundary.
• Create the Functions & Connectivity Spec template and add it to onboarding/procurement intake.
• Pilot with your highest-impact external services (identity, logging, network/security services).

Days 31–60 (convert disclosure into enforcement)

• For each piloted service: collect provider specs, complete reviews, implement allowlisted rules.
• Create a standard evidence packet format and store it consistently.
• Add change triggers to your third-party management process (provider notices, internal change tickets, new features/modules).

Days 61–90 (make it durable)

• Expand coverage to remaining in-scope external services.
• Implement drift detection reporting (flow logs review, configuration monitoring alerts).
• Run an internal “mock audit” for one service end-to-end: scope → provider spec → approval → implemented controls → monitoring → revalidation.
• Decide how Daydream (or your GRC workflow tool) will systematize evidence collection, approvals, and reattestations to keep SA-9(2) from becoming a spreadsheet obligation.

Frequently Asked Questions

What counts as “functions” for SA-9(2)?

Functions are the specific things the external service does for you, stated plainly (e.g., “federates user authentication,” “stores customer support tickets,” “receives security logs and generates alerts”). Tie functions to the integration and data flow so reviewers can judge necessity. ¹

Do I need exact IP addresses, or are domains enough?

Ask for whatever is enforceable in your environment. Many teams capture domains plus the provider’s published IP ranges where available, then implement controls at the right layer (proxy/DNS/firewall) to match.

How do we handle SaaS providers that refuse to share ports/protocols details?

Treat refusal as a risk decision. You can (a) constrain connectivity through a controlled egress path you manage, (b) require written confirmation of required connectivity at a minimum, or (c) select a different provider for high-risk integrations.

Does SA-9(2) apply to cloud managed services we buy from the same hyperscaler?

It can, depending on how you define “external system services” for your boundary. If the service is outside your authorization boundary and requires defined connectivity/dependencies, apply the same identification and mapping discipline. ¹

What’s the difference between SA-9(2) and a standard network diagram?

A network diagram is descriptive and often incomplete. SA-9(2) demands an explicit provider-identified list of required functions and ports/protocols/services that you can enforce and revalidate.

What evidence do assessors accept as “provider identification”?

Best is a provider-authored document or portal export that lists required ports/protocols/endpoints and dependencies, dated and versioned. If you must compile it yourself, retain provider confirmation (email/ticket) that validates your compiled specification.

Footnotes

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

2. NIST SP 800-53 Rev. 5