Acquisition Process | Functions, Ports, Protocols, and Services in Use

To meet the Acquisition Process requirement for functions, ports, protocols, and services in use, you must contractually require the developer (or third-party provider) to document exactly what the product will do and exactly what network interfaces it needs, then verify those claims before authorizing use. Your goal is a controlled, evidence-backed “allowed communications and services” baseline you can enforce in configuration and monitoring. ¹

Key takeaways:

• Put the requirement in procurement: the developer must identify functions, ports, protocols, and services intended for your use. ¹
• Convert documentation into enforceable allowlists (firewalls, security groups, service disablement, configuration baselines).
• Validate in testing and continuously monitor for drift so “documented” matches “real.”

SA-4(9) sits in the System and Services Acquisition family because this is fundamentally a procurement control, not a purely technical one. If you wait until deployment to ask “what ports does this need?” you’re already negotiating from a weak position, and you risk inheriting unnecessary exposure that is hard to unwind. The requirement is straightforward: you must require the developer of a system, component, or service to identify the functions, ports, protocols, and services intended for your use. ¹

For a Compliance Officer, CCO, or GRC lead, operationalizing this control means translating a single sentence into a repeatable intake gate: contract language, a standard evidence package from the third party, technical validation steps, and an enforceable configuration outcome. Done well, SA-4(9) reduces attack surface, speeds ATO/reauthorization conversations, and eliminates “mystery connectivity” that undermines incident response and boundary definitions.

This page gives you requirement-level implementation guidance you can hand to Procurement, Security Architecture, Network Engineering, and Vendor Management without losing intent.

Regulatory text

Requirement: “Require the developer of the system, system component, or system service to identify the functions, ports, protocols, and services intended for organizational use.” ¹

What the operator must do: Build a contractual and procedural mechanism so you (1) obtain the developer’s explicit statement of intended functionality and required communications, (2) review it for risk and fit, (3) implement only what is required (deny by default), and (4) retain evidence that this happened before production use. ¹

Plain-English interpretation

You are not being asked to discover ports and services by scanning alone. You are being asked to make the developer responsible for declaring what the product needs and does, before you buy, integrate, or deploy it, and then to treat that declaration as a control input (allowlist, hardening decisions, monitoring rules).

Think of the output as a “connectivity and service truth set”:

• Functions: What business/technical capabilities you will enable (and what you will not).
• Ports: TCP/UDP ports required inbound/outbound, including administrative interfaces.
• Protocols: HTTP(S), SSH, RDP, SNMP, LDAP, SMTP, proprietary protocols, and their secure variants.
• Services: OS/application services that must run (and those that can be disabled).

Who it applies to

Entity types: Cloud Service Providers and Federal Agencies operating or acquiring systems/components/services under the control baseline that includes SA-4(9). ¹

Operational contexts where it matters most:

• New SaaS/PaaS/IaaS onboarding where network paths, integrations, or agents are required.
• Software purchases that introduce local services (agents, collectors, endpoint tools, database clients).
• System components like appliances, virtual appliances, containers, and managed gateways.
• Major upgrades where ports/protocols/services change (new admin console, new API endpoint, new telemetry pipeline).
• Subcontractor-delivered components (your “developer” may be a third party or your prime’s supplier).

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

1) Put SA-4(9) into acquisition language (Procurement gate)

Create a standard contract clause or procurement checklist item requiring the developer/third party to provide a Functions, Ports, Protocols, and Services (FPPS) Declaration covering:

• Intended functions/features for your environment (include optional modules and whether enabled).
• Required inbound/outbound ports by component, with directionality and purpose.
• Protocols and required security settings (for example, TLS use, mutual auth expectations).
• Services/processes that must run; admin interfaces; default accounts; remote support methods.
• Dependencies (DNS, NTP, certificate services, identity providers, update repositories).
• Data flows tied to connectivity (telemetry, logging, patching, licensing callbacks).

Acceptance condition: “No production use until FPPS is delivered, reviewed, and implemented as an allowlist.”

2) Standardize the FPPS evidence package (make it easy to review)

Ask for FPPS in a structured format (table/spreadsheet) plus authoritative references (admin guide, hardening guide). Minimum fields that prevent back-and-forth:

Field	What you need	Why auditors care
Component name/version	Exact build and modules	Prevents “doc mismatch” vs deployed
Function(s) enabled	Explicit features in scope	Ties to least functionality
Port/protocol	TCP/UDP + protocol name	Enables enforceable rules
Direction	Inbound/outbound + source/dest	Defines boundary and trust
Purpose	“Admin UI,” “API,” “DB replication,” etc.	Validates business necessity
AuthN/AuthZ method	SSO, keys, certs, local accounts	Flags weak admin access paths
Can be disabled?	Yes/no + how	Shrinks attack surface

3) Do a risk and architecture review (GRC + Security + Network)

Run a short structured review meeting focused on:

• Necessity: Do we need every function/module? Remove optional services.
• Exposure: Are any ports internet-facing? Are admin ports separated from user traffic?
• Protocol hygiene: Prefer encrypted and authenticated protocols; flag legacy cleartext.
• Operational monitoring: Can we log and alert on these services and flows?
• Boundary alignment: Do the proposed flows match your system boundary and data flow diagrams?

Output: a signed-off FPPS review record with explicit approvals and conditions (for example, “SSH allowed only from jump host subnet,” “no vendor remote support without change ticket”).

4) Implement enforceable technical controls (turn paper into configuration)

Convert approved FPPS into:

• Firewall/security group rules: explicit allow rules, deny-by-default posture.
• Host hardening: disable unnecessary services; remove optional modules.
• Load balancer/WAF rules: only required listener ports; restrict admin paths.
• Kubernetes/network policy (if relevant): namespace/service allowlists.
• IAM and admin access patterns: restrict management plane access to named roles and networks.

Tie each rule back to an FPPS row (traceability). This is what makes the control auditable.

5) Validate the developer’s claims (before production)

Validation should include:

• Configuration review: confirm only documented services are enabled.
• Network verification: test that only documented ports are open and only documented egress occurs.
• Functional testing: confirm business functions work with the restricted ruleset.

Record any variance as a finding:

• If the product needs extra ports: require updated FPPS from the developer and re-approval.
• If undocumented services are present but not needed: disable and document.

6) Maintain the baseline through change management (keep it true)

SA-4(9) fails over time if upgrades add listeners, agents add egress, or “temporary” support access remains.

• Add FPPS review to change tickets for upgrades, new integrations, and new modules.
• Add drift detection: alert when new ports/services appear relative to the approved baseline.
• Require periodic reconfirmation from the third party when versions change.

Practical tooling note: Many teams track FPPS in a spreadsheet that goes stale. If you already run third-party workflows in Daydream, store FPPS as a required intake artifact and map each approved port/protocol to a control check in the onboarding task list so Engineering has to close the loop before go-live.

Required evidence and artifacts to retain

Keep evidence in a package auditors can follow end-to-end:

1. Contract/SOW/RFP language requiring FPPS identification by the developer. ¹
2. FPPS Declaration (versioned) from the developer/third party.
3. Architecture/risk review record: approvals, conditions, and exceptions.
4. Implemented allowlist evidence: firewall/security group configs, screenshots/exports, IaC pull requests.
5. Validation results: test notes, scan outputs, or verification checklist showing “as built” matches “as declared.”
6. Change management records showing FPPS updates for upgrades and new integrations.

Common exam/audit questions and hangups

• “Show me where the developer identified ports/protocols/services for this system.”
  Hangup: You have internal notes but no developer-provided identification.
• “How do you ensure only approved ports are allowed in production?”
  Hangup: Documentation exists, but enforcement is informal.
• “What happens when a new outbound connection appears?”
  Hangup: No drift monitoring or change trigger tied to FPPS.
• “Are admin services separated and restricted?”
  Hangup: Admin interfaces exist on the same listener as user traffic or are broadly reachable.

Frequent implementation mistakes (and how to avoid them)

1. Treating FPPS as a one-time questionnaire.
   Fix: bind FPPS updates to version changes and change tickets.

2. Allowing “any outbound” because the product is complex.
   Fix: require the third party to enumerate egress destinations and purposes; approve explicitly.

3. Accepting marketing docs instead of technical truth.
   Fix: require a structured FPPS table plus validation in a test environment.

4. Missing hidden paths (support tunnels, auto-updaters, telemetry).
   Fix: explicitly ask for remote support methods, update mechanisms, logging/telemetry endpoints.

5. No traceability from approval to enforcement.
   Fix: map each approved port/protocol to a specific firewall/IaC rule ID or change request.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so don’t expect a neat “gotcha” headline to anchor the risk story. Treat the risk as operational and audit-facing: undocumented or unmanaged ports/services expand attack surface, complicate boundary definitions, and slow incident containment because responders do not know what “normal” looks like. SA-4(9) gives you a defensible basis for deny-by-default networking and least functionality during acquisition. ¹

Practical 30/60/90-day execution plan

First 30 days (establish the gate)

• Draft the FPPS contract clause and add it to procurement templates and third-party onboarding checklists. ¹
• Publish the FPPS Declaration template (table format) and review checklist.
• Identify systems already in production without FPPS; open remediation tickets for highest-risk items (internet-facing, privileged admin paths, broad egress).

Next 60 days (make it enforceable)

• Train Procurement, Vendor Management, and Security Architecture on “no FPPS, no production.”
• Implement traceability: every approved FPPS row maps to a config artifact (IaC PR, firewall rule, security group ID).
• Add a lightweight validation step in pre-production (port/service verification + egress confirmation).

By 90 days (operationalize and reduce drift)

• Add FPPS update triggers to change management for upgrades and new integrations.
• Stand up drift detection and an exception workflow for newly observed ports/services.
• Centralize evidence (for example in Daydream) so auditors can pull one package per system: clause, declaration, review, implementation, validation, and changes.

Frequently Asked Questions

Does SA-4(9) require us to scan for open ports?

The requirement is to require the developer to identify functions, ports, protocols, and services intended for your use. ¹ Scanning is still a strong validation step so you can prove the deployed state matches the developer’s identification.

Who counts as “the developer” for SaaS?

Treat the SaaS provider (a third party) as the developer for this purpose. You need their statement of required ports/protocols/services and any required customer-side agents or network paths. ¹

What if the third party refuses to provide a ports/protocols list?

Escalate as an acquisition risk: you cannot meet the requirement without developer identification. ¹ In practice, teams either negotiate the deliverable, select an alternative, or document a formal exception with compensating controls.

How detailed does the “functions” part need to be?

Detailed enough that Security and Engineering can disable what you are not using and justify what remains. List enabled modules, admin features, remote support features, and integrations that change network exposure.

We buy COTS software through a reseller. Who provides the FPPS declaration?

The evidence must originate from the developer or be an authoritative developer document packaged by the reseller. If the reseller writes it from memory, treat it as insufficient unless the developer attests or the docs are official. ¹

How do we keep FPPS current during rapid releases?

Tie FPPS to versioning and change management. Require an FPPS delta for each major upgrade and use drift alerts to catch surprises between releases.

Footnotes

1. NIST Special Publication 800-53 Revision 5