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

SA-9(2) requires you to make external system service providers specify exactly what network functions, ports, protocols, and dependent services are required to use their service, then use that information to enforce least-privilege connectivity (firewalls, proxies, security groups, and monitoring). Operationalize it by baking a “connectivity requirements” deliverable into third-party onboarding and every material change.

Key takeaways:

• Treat SA-9(2) as a procurement and architecture gate: no approved ports/protocols list, no production connectivity.
• Convert provider statements into enforced allowlists, with documented owners, approvals, and expiration or review triggers.
• Retain evidence that ties provider requirements to implemented controls (rules, tickets, change records, and test results).

SA-9(2) sits in the “External System Services” control area of NIST SP 800-53 and targets a failure mode auditors see constantly: organizations connect to third-party services “because it works,” then discover months later that the service requires broad outbound access, unmanaged inbound paths, legacy protocols, or hidden dependencies that bypass standard monitoring.

For a Compliance Officer, CCO, or GRC lead, the fastest way to make SA-9(2) real is to treat it like a standardized due diligence artifact. You want a repeatable method for collecting connectivity requirements from third parties, validating them with Security/Network Engineering, and implementing only what is necessary. You also need to prove, with evidence, that your organization enforces what was approved and revisits it when the third party changes their architecture or when your environment changes.

This page gives requirement-level implementation guidance you can hand to operators: what to collect, how to review it, what to enforce, and what to retain for audits and customer diligence. Citations refer to the NIST SP 800-53 Rev. 5 sources listed in your fact pack. ¹

Regulatory text

Requirement (SA-9(2)): “Require providers of the following external system services to identify the functions, ports, protocols, and other services required for the use of such services: [external system services].” ²

Operator interpretation

You must (1) name which external system services are in scope, (2) require each provider to document the technical connectivity and service dependencies needed, and (3) use that documentation to drive configuration decisions and allowlist rules.

A practical reading is: if a third party cannot or will not specify the minimum required network/service footprint, you cannot safely connect to them. SA-9(2) is a forcing function for least-privilege connectivity and a clean audit trail from third-party due diligence to network enforcement. ³

Plain-English interpretation (what SA-9(2) is really asking for)

For every external system service you use (cloud hosting, SaaS platforms, managed security providers, payment processors, data enrichment APIs, etc.), you need a documented answer to:

• What functions will you use? (admin console, API ingestion, SFTP drop, webhook callbacks, federated SSO, mobile push, email relay)
• Which ports and protocols are required end-to-end? (TCP/443 HTTPS, TCP/22 SSH, UDP/53 DNS, SMTP, etc.)
• What other services must be reachable for the service to work? (identity provider endpoints, certificate/OCSP, logging endpoints, content delivery networks, third-party sub-processors, IP ranges, regional domains)

Then you translate that into controls: allowlists, firewall rules, proxy policies, segmentation, and monitoring rules that match the approved footprint.

Who it applies to (entity and operational context)

Entities

• Federal information systems and programs implementing NIST SP 800-53 controls. ³
• Contractors handling federal data (common in FedRAMP-like or agency contractual security requirements) where NIST SP 800-53 controls are flowed down. ³

Operational contexts where SA-9(2) shows up

• Buying or renewing SaaS (HRIS, CRM, ticketing, SIEM, EDR portals).
• Connecting to APIs (inbound webhooks, outbound API calls).
• Using managed services (MSSP, SOC, managed backups, managed database).
• Allowing remote administration by a third party (support tools, bastions, privileged access).
• Handling data exchanges over file transfer or message queues.

If a third party touches regulated data, has admin access, or requires any network path into or out of your environment, SA-9(2) belongs in the onboarding checklist.

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

Step 1: Define “external system services” in scope

Create and maintain an in-scope list that aligns with your third-party inventory:

• SaaS platforms with production data
• Hosting/IaaS/PaaS providers
• Managed service providers with admin access
• Any third party requiring inbound connectivity into your environment
• Any third party requiring outbound exceptions beyond standard egress controls

Output: “In-scope external services list” mapped to your third-party inventory and system boundary.

Step 2: Standardize the provider request (make it a required deliverable)

Add a required artifact to procurement/onboarding: Connectivity Requirements Sheet (one per service). Minimum fields:

• Business function(s) used
• Data types involved (at a high level)
• Network directionality (inbound to you, outbound from you, both)
• Source/destination endpoints (domains, FQDNs, IP ranges if fixed)
• Ports and protocols required
• Authentication method (mTLS, OAuth, SAML, API keys, VPN)
• Encryption expectations (TLS versions/ciphers if the provider specifies)
• Dependencies (“service requires access to X”)
• Change notification expectations (how the provider will notify you of endpoint/IP changes)

Contract language can be simple: “Provider will maintain and provide current technical requirements, including ports, protocols, and dependent services necessary to use the service.”

Output: Completed provider Connectivity Requirements Sheet (dated, versioned).

Step 3: Validate with architecture and security (don’t accept marketing answers)

Run a quick technical review:

• Confirm each port/protocol is necessary for the specific functions you plan to use.
• Identify whether requirements imply overbroad access (examples: “allow all outbound,” “open inbound from any IP,” “SSH from the internet”).
• Check for hidden dependencies (CDNs, subdomains, third-party telemetry collectors).
• Decide the right connectivity pattern: private connectivity, VPN, IP allowlisting, proxy-only, or blocked from sensitive segments.

Decision record: accept, accept with constraints, or reject pending changes.

Step 4: Translate requirements into enforceable allowlists

Implement the minimum required connectivity:

• Firewall / security group rules limited to required ports and destinations
• Egress proxy allowlists by FQDN where feasible
• Ingress rules limited by source IP ranges and authentication
• Segmentation so third-party connectivity cannot laterally move to unrelated systems
• Monitoring rules (alerts for denied traffic spikes; new destinations; protocol anomalies)

Key control point: The “approved requirements” and “implemented rules” must match. If the network team implements broader access “temporarily,” treat it as an exception with an owner and expiry.

Step 5: Test and document

Before production go-live:

• Functional test: service works with the allowlist in place
• Negative test: blocked traffic remains blocked (spot checks)
• Confirm logging: firewall/proxy logs capture connections to the third party endpoints

Output: Test evidence (ticket notes, screenshots, or exported results) tied to the change record.

Step 6: Operate it as a lifecycle control (change-driven)

SA-9(2) breaks when providers change endpoints or when your architecture changes. Define triggers:

• Provider announces IP range/domain changes
• New features enabled (webhooks, SSO, new integrations)
• Renewal/annual due diligence refresh
• Security incident affecting the provider
• Significant internal network redesign

On trigger: request an updated sheet, re-approve, and update rules.

Step 7: Make it auditable with a “control card” and evidence bundle

This is where many programs fail: they do the work once, then cannot prove consistent operation later. Create a lightweight control card:

• Objective, scope, owner (Security Architecture or Network Security)
• Process trigger events
• Steps above
• Exception handling (temporary broad access requires risk acceptance)

If you use Daydream, treat SA-9(2) like a requirement page attached to each third party record: store the Connectivity Requirements Sheet, approvals, and change tickets in one place so you can answer audits without Slack archaeology.

Required evidence and artifacts to retain

Keep an evidence bundle per external system service:

1. Connectivity Requirements Sheet from the provider (versioned).
2. Architecture/security review notes or approval (ticket, email, or meeting record with decision).
3. Firewall/security group/proxy change record (request, approval, implementation details).
4. Rule configuration export or screenshots showing allowed ports/protocols/destinations.
5. Test evidence (service works; deny rules enforced).
6. Exception records (if any), with business justification and expiry.
7. Ongoing monitoring proof (sample logs, alert configurations tied to the service).

Retention should follow your broader security documentation retention policy; auditors mainly care that you can produce the artifacts for current services and show a trail for material changes.

Common exam/audit questions and hangups

Auditors and assessors tend to ask:

• “Which external system services are in scope for SA-9(2), and how do you know the list is complete?”
• “Show me the provider’s identification of ports/protocols and your approval.”
• “Prove that only the identified ports/protocols are allowed in production.”
• “How do you detect when the provider changes endpoints or adds dependencies?”
• “How do you handle exceptions, and who can approve them?”

Hangups you should preempt:

• Provider documentation exists, but it is generic and not tied to your actual enabled functions.
• Network rules are broader than the provider requirements “to avoid outages.”
• No defined trigger to revisit requirements after onboarding.

Frequent implementation mistakes (and how to avoid them)

Mistake 1: Accepting “TCP/443 to the internet” as sufficient documentation

Fix: Require destinations (FQDNs/domains, IP ranges where applicable) and identify which functions require them. If the provider uses dynamic infrastructure, require their published endpoint list and change notification method.

Mistake 2: Treating this as a one-time procurement checkbox

Fix: Make it change-driven. Provider endpoint changes are routine. Build an update path that results in a new version of the sheet and a corresponding change record.

Mistake 3: No mapping from requirement to enforcement

Fix: Add a mandatory field in the onboarding ticket: “Implemented rule IDs / config references.” Auditors want traceability, not a PDF in a folder.

Mistake 4: Exceptions that never expire

Fix: Require an expiry and a rollback plan for any temporary broad access. Track to closure.

Mistake 5: Forgetting “other services required”

Fix: Ask explicitly about dependencies: identity providers, logging, certificate validation, webhook sources, sub-processors that introduce new endpoints.

Enforcement context and risk implications

No public enforcement cases were provided in your source pack, so this page does not cite specific regulator actions.

From a risk perspective, SA-9(2) reduces:

• Unnecessary attack surface created by overly permissive ingress/egress.
• Third-party introduced pathways that bypass your segmentation and monitoring.
• Incident response ambiguity when you cannot quickly determine “what should be talking to what.”

It also improves audit outcomes because you can demonstrate a clean chain: provider requirement → internal approval → implemented technical control → monitoring and updates. ³

Practical 30/60/90-day execution plan

First 30 days (stand up the control)

• Assign ownership: Network Security or Security Architecture owns the requirement; Procurement and TPRM enforce intake.
• Draft the Connectivity Requirements Sheet template and add it to third-party onboarding.
• Identify the highest-risk external system services (admin access, inbound connectivity, sensitive data).
• Create a standard approval workflow (ticket type + required fields).

Days 31–60 (apply to the riskiest services and close gaps)

• Collect sheets for the highest-risk services and validate accuracy with engineering.
• Compare approved requirements to actual firewall/proxy/security group rules; open remediation tickets where rules are broader than justified.
• Define exception handling and an approval matrix (who can accept risk for temporary broad access).

Days 61–90 (operationalize and make it durable)

• Expand coverage to remaining in-scope services.
• Add monitoring hooks: alerting for new destinations, repeated denies, and inbound attempts outside allowlists.
• Add lifecycle triggers to your third-party management process: renewals, changes, incidents.
• Run a “control health check” sample: pick a few services and verify documentation matches implementation; track findings to closure.

Frequently Asked Questions

Do we need the third party to provide exact IP addresses, or are domains enough?

Accept domains/FQDNs when the provider uses dynamic IP ranges, but require an authoritative endpoint list and a change notification path. Where fixed IP ranges are available, capture them and use IP allowlisting to tighten access.

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

Functions are the specific service capabilities you enable, like SSO, API access, webhooks, admin console access, or file transfers. Documenting functions prevents approving connectivity for features you do not use.

How do we handle a provider that refuses to share ports/protocols details?

Treat it as a due diligence failure and escalate as a procurement risk decision. If the business proceeds, document the exception, the compensating controls, and the conditions for revisiting the decision.

Does SA-9(2) apply to outbound-only SaaS that users access via browser?

Yes if you control egress or need to define what enterprise systems can connect to that SaaS. Browser-only access may still require documenting domains, SSO endpoints, and any integrations that add non-browser paths.

How do we prove compliance during an audit?

Show the provider’s Connectivity Requirements Sheet, the internal approval, the implemented firewall/proxy/security group rules that match it, and evidence of testing and monitoring. Auditors focus on traceability and least-privilege enforcement.

How often should we refresh the connectivity requirements?

Refresh on trigger events: provider endpoint changes, new enabled functions, renewals, or material architecture changes in your environment. A calendar-based refresh can be added, but triggers usually catch the real risk first.

Footnotes

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

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

3. NIST SP 800-53 Rev. 5