External System Services | Identification of Functions, Ports, Protocols, and Services

To meet the External System Services requirement for identification of functions, ports, protocols, and services, you must contractually require each third party providing an external system service to document exactly what the service does and what network communications it needs (ports, protocols, endpoints, and supporting services). Then you must validate that information and enforce it through firewall rules, segmentation, and change control.

Key takeaways:

• Require the third party to provide a complete “service interface specification” (functions + ports/protocols + dependencies).
• Verify the specification against real traffic and restrict network access to only what is documented and approved.
• Treat changes to ports/protocols/functions as a formal change event with review, testing, and updated evidence.

SA-9(2) is a procurement-and-operations control disguised as a network hygiene control. It forces discipline around a common failure mode: teams buy or connect to an external system service (SaaS, API provider, managed security service, payment processor, cloud-based scanning, outsourced IT) without a precise, enforceable understanding of what connectivity is required. The result is overbroad firewall openings, “temporary” rules that become permanent, undocumented outbound access, and blind spots during incident response.

This requirement is narrow but operationally sharp: you must require providers of external system services (as defined by your organization) to identify (1) functions and (2) the ports, protocols, and other services needed to use them. Your job as a Compliance Officer, CCO, or GRC lead is to turn that into: contract language, intake questionnaires, architecture/security review gates, and technical enforcement and monitoring.

If you build this correctly, you also get practical benefits: faster security reviews, less debate with network teams, cleaner diagrams for auditors, and a defensible answer when assessors ask, “Why is this port open to that third party?”

Regulatory text

Requirement excerpt: “Require providers of organization-defined external system services to identify the functions, ports, protocols, and other services required for the use of such services.” (NIST Special Publication 800-53 Revision 5)

Operator meaning: You must (a) decide which external services are in scope, (b) require the third party to provide a precise description of required functionality and network/service interfaces, and (c) use that information to approve, constrain, and monitor the connectivity needed to consume the service. The requirement is satisfied on paper only if your operational controls match the documented requirements.

Plain-English interpretation (what the control is trying to prevent)

You are preventing “unknown or unnecessary connectivity” to external parties. If a third party can’t tell you which ports/protocols/endpoints are required, you cannot confidently restrict network paths, evaluate encryption expectations, confirm logging points, or investigate suspicious traffic. SA-9(2) makes the third party declare what they need; you then implement least-necessary connectivity based on that declaration.

Who it applies to (entity + operational context)

This applies when your organization uses external system services that interact with your systems or data. Common in-scope cases in FedRAMP-aligned environments include:

• SaaS platforms that integrate via inbound/outbound APIs or agents (HR, ticketing, CRM, EDR consoles).
• Managed service providers (MSP/MSSP) requiring VPN, remote management tools, or log ingestion.
• Payment, identity, or messaging providers that require specific egress destinations and TLS settings.
• Cloud-to-cloud integrations (webhooks, event streaming, SFTP drops, SCIM provisioning).
• Third-party scanning/monitoring services (external vulnerability scanning, uptime monitors).

Operationally, the requirement touches procurement, security architecture, network engineering, and change management. If those teams are not aligned, SA-9(2) becomes a documentation exercise with no enforcement value.

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

Treat this as an intake-to-enforcement workflow.

1) Define “external system services” for your environment

Write a short scoping statement that GRC, Security, and Procurement can apply consistently:

• Include SaaS, APIs, managed services, and any third party requiring network connectivity to your boundary.
• Exclude pure “offline” professional services unless they require remote access or system-to-system data exchange.
• Define ownership: who approves new external connections (often Security Architecture + Network).

Output: documented scope statement used in procurement and architecture review.

2) Create a required “Service Interface Specification” deliverable

Require each external service provider to supply, at minimum:

A. Functions required

• What business functions you will use (features/modules)
• What data flows are involved (high-level categories, not necessarily data classification detail here)
• Which components are optional vs required

B. Connectivity requirements

• Source/destination: IP ranges (if static), FQDNs, regions, tenant URLs
• Direction: inbound to you, outbound from you, or both
• Ports and protocols: TCP/UDP, HTTP/S, SSH, SFTP, SMTP, etc.
• API patterns: REST/gRPC, webhooks, callback URLs, authentication method (e.g., mutual TLS, OAuth)
• Encryption expectations: TLS versions/ciphers (state what you require; capture what they support)

C. “Other services required” (dependencies)

• DNS requirements (resolvers, domains queried)
• NTP requirements
• Certificate authorities, OCSP/CRL endpoints if relevant
• Identity dependencies (SAML/IdP endpoints, SCIM)
• Logging/telemetry endpoints if agents forward data out

D. Operational constraints

• Maintenance windows that may cause endpoint changes
• Change notice commitments (how you’ll be notified before endpoint/port/protocol changes)

Output: a standardized template you can attach to security reviews and contracts.

3) Put the requirement into contracts and onboarding gates

SA-9(2) is explicit: you must require providers to identify these items. Do this in two places:

• Third-party onboarding/security questionnaire: makes it a precondition to technical integration.
• Contract/SOW language: makes it enforceable, including change notification obligations.

Practical contract clause components:

• Provider must supply and keep current the service interface specification (functions, ports, protocols, dependencies).
• Provider must notify you before any material changes to endpoints/ports/protocols/functions that affect connectivity.
• Provider must support testing/validation of connectivity changes in a non-production path where feasible.

Output: executed contract language + completed onboarding package.

4) Validate the third party’s claims against reality

Do not accept a PDF and stop there. Validation options:

• Network review: network/security engineers confirm ports/protocols and ensure they map to approved architectures.
• Traffic observation: during pilot, capture egress flows (FQDNs, IPs, ports) and compare to the specification.
• Agent review: if a software agent is installed, confirm it only communicates as documented.

Output: validation notes, approved exceptions (if any), and an “approved connectivity” record.

5) Enforce least-necessary connectivity

Translate the approved spec into technical controls:

• Firewall/SG rules restricted to required destinations, ports, and protocols.
• Prefer FQDN allowlists where supported, or controlled egress via proxy.
• Block “any/any” outbound rules justified by “SaaS needs internet.”
• Require segmentation for high-risk integrations (admin access, privileged protocols, remote management).

Output: change tickets, firewall/proxy rule evidence, and architecture diagrams.

6) Operationalize changes (ports/protocols/functions are not static)

Treat any change as a controlled event:

• Trigger: provider notice, internal feature expansion, or traffic deviation alerts.
• Review: security/network assess delta against current approval.
• Implement: update rules, update the service interface specification, and retest.
• Record: preserve approval and implementation evidence.

Output: change records tied to updated spec and rules.

Required evidence and artifacts to retain

Auditors typically want to see both “requirement exists” and “it works in production.” Maintain:

• Policy/procedure for onboarding external system services and requiring interface details.
• Service Interface Specification per third party (versioned).
• Contract/SOW language or addendum requiring the provider to identify ports/protocols/functions and notify changes.
• Architecture/security review sign-off showing the connectivity was evaluated.
• Firewall/proxy/SG change records that implement the approved connectivity.
• Validation evidence (traffic logs/screenshots, test plans, pilot results).
• Exception records for any broad access, with compensating controls and expiry.

A clean evidence pattern is: spec → approval → implemented rules → validation → monitoring/change control.

Common exam/audit questions and hangups

Expect these:

1. “Show me how you require providers to identify ports/protocols.”
   They will look for contract language or a mandatory onboarding artifact, not an informal email.

2. “How do you know the documented ports are the only ones in use?”
   Have validation evidence (pilot traffic review) and ongoing monitoring or egress filtering.

3. “What counts as ‘other services required’?”
   Be ready to show you considered DNS, NTP, identity federation endpoints, and certificate validation dependencies, as applicable.

4. “How do you control changes?”
   Provide change tickets tied to updated specs and rule modifications.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Accepting “HTTPS (443) to the internet” as sufficient.
  Fix: require destinations (FQDNs/IP ranges), tenant URLs, and documented dependencies. If they cannot provide it, treat as a risk decision with compensating controls (proxy inspection, strict egress, monitoring).

• Mistake: Documenting ports but not functions.
  Fix: tie connectivity to business functions. This prevents “we opened admin APIs but only needed reporting.”

• Mistake: No ownership for keeping specs current.
  Fix: assign a service owner who must re-attest the spec when renewing the third party or enabling new modules.

• Mistake: Change notices don’t reach implementers.
  Fix: route third-party change notices into a ticketing workflow owned by Security/Network, not only Procurement.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat risk in operational terms: undocumented or overly broad connectivity increases exposure to data exfiltration paths, complicates incident containment, and creates audit findings around boundary protection and third-party oversight. SA-9(2) is a straightforward control for demonstrating you know, and limit, how external services communicate with your environment. (NIST Special Publication 800-53 Revision 5)

Practical 30/60/90-day execution plan

Use this phased plan to stand up SA-9(2) quickly without boiling the ocean.

First 30 days (Immediate)

• Define scope: what you classify as an external system service in your environment.
• Publish a one-page Service Interface Specification template.
• Add a gating step: no new third-party integration goes live without a completed spec and security review.
• Update standard contract addendum language to require the provider’s identification and change notification.

Next 60 days (Near-term)

• Triage existing external services: identify the highest-risk integrations (remote admin access, production data flows, privileged protocols).
• Backfill specs for prioritized third parties; record exceptions where providers cannot specify endpoints.
• Align network enforcement: convert broad rules into documented allowlists for the prioritized set.
• Establish a lightweight validation step: pilot traffic review and sign-off.

Next 90 days (Operationalize and scale)

• Integrate into third-party risk management: store specs with third-party records and renewal workflows.
• Add monitoring: alert on traffic to unapproved destinations/ports for integrated services.
• Run a tabletop: simulate “provider changes endpoint” and confirm your notice-to-change workflow works end to end.
• Prepare your audit packet: sample of specs, contracts, rules, and change tickets for several representative third parties.

Where Daydream fits: Daydream can serve as the system of record for third-party onboarding evidence, storing the service interface specification alongside contracts, reviews, and renewal tasks so specs stay current and audit-ready.

Frequently Asked Questions

Does SA-9(2) require the third party to give exact IP ranges?

The text requires identification of ports, protocols, and other services required, but it does not specify IP ranges. In practice, request IP ranges where possible, and otherwise document FQDNs/tenant endpoints and enforce through proxies or controlled egress.

What if the provider says, “We only use HTTPS 443” and won’t provide endpoints?

Treat it as an exception with a risk decision. Use compensating controls such as egress proxying, tighter outbound controls, enhanced monitoring, and a contractual obligation to notify you if connectivity requirements change.

Do webhooks count as inbound connectivity?

Yes. A webhook is an inbound call path into your environment (or into your public endpoint). Document the callback URL, authentication method, source IPs (if available), TLS requirements, and any rate-limiting or WAF controls you rely on.

How detailed do “functions” need to be?

Detailed enough to explain why connectivity exists. If you can’t map a firewall rule to a function (e.g., “log forwarding from agent,” “SCIM provisioning,” “payment authorization API”), you will struggle to justify it in an exam or incident review.

How do we keep the documentation from going stale?

Tie the spec to change control and renewal. Make “spec current and re-attested” a renewal requirement, and require service owners to update it when enabling new modules, regions, or integration patterns.

Is this a network team control or a GRC control?

It’s both. GRC owns the requirement, contract language, and evidence; Security/Network owns validation and enforcement. You need a single workflow that connects the third party’s spec to implemented rules and monitored traffic.