Allowed Services, Protocols, and Ports

PCI DSS 4.0.1 Requirement 1.2.5 requires you to maintain an explicit, approved allowlist of every service, protocol, and port permitted through your network security controls, and document the business need for each. To operationalize it quickly, inventory what’s currently allowed, tie each allowance to an owner and justification, and enforce it through standards, change control, and periodic review. (PCI DSS v4.0.1 Requirement 1.2.5)

Key takeaways:

• Build an “allowed services/protocols/ports register” that maps each allowance to a business need, system scope, and approval.
• Enforce the register through firewall/ACL standards and change tickets, not spreadsheets alone.
• Auditors look for completeness (nothing missing), governance (who approves), and evidence that the allowlist drives configurations.

“Allowed Services, Protocols, and Ports” sounds simple, but most PCI gaps come from the operational details: legacy rules nobody owns, open management ports added during an outage, or “temporary” exceptions that never expire. Requirement 1.2.5 is about controlling that drift by forcing a deliberate allowlist posture: if traffic is permitted, you can name it, justify it, and show who approved it. (PCI DSS v4.0.1 Requirement 1.2.5)

For a CCO or GRC lead, the fastest path is to treat this as a governance-and-evidence requirement with a strong technical dependency. You don’t need to personally configure firewalls, but you do need a repeatable mechanism that makes network/security engineers document allowances, obtain approvals, and keep documentation aligned with reality. This page gives you a requirement-level playbook: what’s in scope, what artifacts to produce, how to structure approvals, what examiners typically challenge, and how to avoid common failure modes like “documented allowlist doesn’t match the firewall.”

Regulatory text

Excerpt: “All services, protocols, and ports allowed are identified, approved, and have a defined business need.” (PCI DSS v4.0.1 Requirement 1.2.5)

What the operator must do:
You must be able to produce (1) a complete list of allowed services/protocols/ports for the relevant environment, (2) evidence that each is approved by an appropriate authority, and (3) documentation of the business need that explains why it must be allowed. This is not satisfied by an informal “we only open what we need” statement; it requires an enumerated allowlist and governance around it. (PCI DSS v4.0.1 Requirement 1.2.5)

Plain-English interpretation

If a port is open, you need to know it’s open, know why it’s open, and be able to prove someone approved it for a real business reason. The requirement is designed to prevent “unknown exposure,” where risky protocols (or unnecessary ports) become permanent because nobody tracks them.

Who it applies to

Entity types: Merchants, service providers, and payment processors that must comply with PCI DSS. (PCI DSS v4.0.1 Requirement 1.2.5)

Operational context (where this shows up in practice):

• Network security controls that permit or restrict traffic (firewalls, security groups, ACLs, micro-segmentation rules).
• Connectivity paths into, out of, and within the cardholder data environment (CDE) and connected systems where those controls govern access.
• Shared services that touch the CDE path (management networks, jump hosts, logging infrastructure) when controlled by the same security devices and rulesets.

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

Step 1: Define the “system of record” for allowed traffic

Pick a primary artifact that acts as the control plane for governance. Most teams use a register (table) backed by change management tickets and firewall standards. The critical point: the register must be traceable to actual configurations.

Minimum fields to include in your register

Field	What to capture	Why auditors care
Service/protocol	e.g., TCP, UDP, ICMP; application service name	Proves you understand what is permitted
Port(s)	Single port or range; include directionality	“Range” without justification is a common finding
Source / destination	Network zone, CIDR, system name, or security group	Shows scope control (not “any/any”)
Purpose / business need	Short narrative tied to a process/app	Satisfies “defined business need”
System/asset owner	Named role/team	Establishes accountability
Approver	Security/network + business/app owner (as applicable)	Satisfies “approved”
Control(s) enforcing it	Firewall name, SG ID, rule ID, policy name	Links doc to reality
Change ticket / reference	Ticket ID, CAB approval	Proves governance
Review cadence / last review	Date + outcome	Demonstrates ongoing control

Step 2: Inventory what is currently allowed (reality first)

Work with network/security engineering to export current rules from the controls in scope (firewalls, cloud security groups, Kubernetes network policies, etc.). Normalize into the register format.

Operational tips:

• Treat “ANY” sources/destinations as a high-priority exception candidate.
• Flag broad port ranges and legacy protocols for challenge.
• Identify duplicates and shadowed rules; they confuse reviews and approvals.

Step 3: Rationalize and classify every allowance

For each allowed service/protocol/port, decide:

• Keep: required, bounded, owner/approver identified.
• Tighten: required but overly broad (scope down sources, destinations, ports).
• Remove: no business need, obsolete dependency, or compensating control no longer valid.
• Exception: temporarily required; add an explicit expiration condition and compensating controls.

Your goal is a defensible allowlist with minimal exposure. If you cannot justify a rule, it should not survive.

Step 4: Establish an approval workflow that matches your operating model

Requirement 1.2.5 says “approved,” but it doesn’t prescribe who approves. Your policy must define this clearly and show it in practice. (PCI DSS v4.0.1 Requirement 1.2.5)

A workable approval pattern:

• Business/application owner approves the business need and confirms the dependency.
• Network/security approves that the rule is correctly scoped and meets standards.
• Change management/CAB records the change authorization for production.

For cloud-native environments, approvals often happen in pull requests:

• PR includes the register entry (or reference) plus the IaC change (Terraform, CloudFormation).
• Reviewers are named approvers; the merge record is evidence.

Step 5: Translate the allowlist into enforceable configuration standards

Documentation alone fails audits if it doesn’t drive configuration. Create standards that engineers must follow, such as:

• Naming conventions for firewall rules that reference the register ID or change ticket.
• Required fields for any new rule request (business need, owner, ports, sources/destinations, expiry for temporary access).
• A “deny by default” baseline for zones connected to the CDE path, with explicit allow rules only.

Step 6: Implement a review-and-recertification motion

Build a routine that revalidates that allowed traffic remains needed and matches configuration:

• Compare the current exported rules to the register (detect drift).
• Require owners to re-attest business need for high-risk or broad rules.
• Close the loop by removing or tightening rules that lack confirmation.

A practical way to run this: schedule recurring control checks, generate a delta report, and route deltas through change control.

Step 7: Cover third parties explicitly

If third parties connect into your environment (support access, hosting, managed services), their connectivity needs to appear in your allowlist register with:

• Named third party, connection method, source IP ranges, ports/protocols, and purpose.
• Contractual or procedural constraints (for example, access via a jump host rather than direct management ports). This prevents “vendor access sprawl” that quietly broadens your inbound exposure.

Step 8: Prepare the audit narrative and sampling package

Auditors typically sample rules. Be ready to show, for each sampled rule:

• The register line item.
• The approval evidence.
• The business need statement.
• The implemented rule evidence (screenshot/export).
• The change ticket or PR that introduced/modified it.

A strong package makes testing fast and reduces follow-up.

Required evidence and artifacts to retain

Keep evidence in a form that survives staff turnover and tool migrations.

Core artifacts

• Allowed services/protocols/ports register (system of record). (PCI DSS v4.0.1 Requirement 1.2.5)
• Configuration evidence from network security controls (exports, screenshots, IaC state) that maps to the register.
• Approval records (change tickets, CAB minutes, PR reviews, email approvals if that’s your defined mechanism).
• Policy/standard defining approval roles and documentation requirements for new/changed rules.
• Periodic review outputs (attestations, meeting notes, delta reports, remediation tickets).

Nice-to-have artifacts (reduce audit friction)

• Rule naming convention document and examples.
• Drift detection reports between register and actual configs.
• Exception log for temporary rules, with expiry and compensating controls.

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me the list of allowed services/protocols/ports for the CDE boundary.” (PCI DSS v4.0.1 Requirement 1.2.5)
• “How do you know the list is complete and current?”
• “Pick three open ports. Show the business need and approval for each.” (PCI DSS v4.0.1 Requirement 1.2.5)
• “Who can approve opening a port, and where is that defined?”
• “How do you prevent emergency changes from bypassing documentation?”
• “How do you handle third-party connectivity and remote administration paths?”

Hangup to anticipate: teams provide a network diagram or a generic firewall policy statement instead of an enumerated allowlist tied to actual rules. That typically triggers expanded sampling.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating the firewall rulebase export as “the list.”
   Fix: Convert exports into a governed register that includes business need and approval links. Rule exports rarely contain the justification auditors need. (PCI DSS v4.0.1 Requirement 1.2.5)

2. Mistake: Documenting ports but not sources/destinations.
   Fix: Make “scope” mandatory (zone, CIDR, security group, system). Open ports with broad scope are where risk concentrates.

3. Mistake: “Temporary” rules with no expiry or owner.
   Fix: Require an owner and an explicit expiry condition in the register, and track exceptions until closed.

4. Mistake: Relying on tribal knowledge for business need.
   Fix: Force a written justification tied to an application/service, plus an accountable owner who can answer audit questions.

5. Mistake: Separate documents for cloud, on-prem, and SaaS without consolidation.
   Fix: Use one register schema across environments, even if data comes from different tools.

Enforcement context and risk implications

No public enforcement case references were provided in the source catalog for this requirement, so treat enforcement risk here as examination-driven rather than case-law driven.

From a risk standpoint, unmanaged allowed ports/protocols create avoidable attack paths: exposed administration interfaces, legacy protocols that lack modern security properties, and lateral movement opportunities between network segments. Operationally, the biggest risk is “unknown open” becoming “permanently open” because nobody owns the rule.

A practical 30/60/90-day execution plan

First 30 days: Stabilize and inventory

• Assign accountable owners: network security control owner, register owner, approval authority.
• Export current allowed rules from in-scope controls and normalize into a draft register.
• Define “minimum documentation” for each rule: business need, owner, approver, enforcement reference. (PCI DSS v4.0.1 Requirement 1.2.5)
• Identify obvious high-risk items: any/any rules, broad ranges, unknown owners, legacy protocols.

Days 31–60: Rationalize and enforce governance

• Run rule-by-rule rationalization workshops with app owners and engineers.
• Remove or tighten rules that lack business need.
• Implement the approval workflow in your ticketing/PR system and update engineering runbooks.
• Align naming conventions so rules can be traced to register entries and change records.

Days 61–90: Prove ongoing control

• Implement a recurring review cycle with drift detection between register and configurations.
• Build an audit-ready sampling packet template and pre-populate it for a subset of rules.
• Add third-party connectivity entries and confirm contract/process constraints are reflected in allow rules.
• If you use Daydream to manage compliance evidence, map each register item to its approval and configuration artifacts so audit requests can be satisfied from one place.

Frequently Asked Questions

Do I need to document every open inbound and outbound port, or only “internet-facing” ones?

Requirement 1.2.5 applies to services/protocols/ports allowed through your network security controls in scope, not only internet-facing rules. Practically, focus on boundaries and segmentation points relevant to the CDE path, then expand to internal controls that govern that scope. (PCI DSS v4.0.1 Requirement 1.2.5)

Can a firewall rule export count as the “identified” list?

It can support identification, but it rarely satisfies approval and business need by itself. Auditors typically expect a register or documented mapping that adds owner, justification, and approval evidence. (PCI DSS v4.0.1 Requirement 1.2.5)

What counts as “defined business need”?

A short statement that ties the allowed traffic to a specific application function, operational process, or dependency, with an accountable owner. “Required for operations” without naming what breaks and who owns it is usually too thin. (PCI DSS v4.0.1 Requirement 1.2.5)

How do we handle ephemeral cloud ports and dynamic workloads?

Document the allowed policy intent (for example, security group rules, load balancer listeners, service mesh policies) rather than individual transient endpoints. Tie the intent to IaC/PR approvals and keep evidence from the control that enforces it. (PCI DSS v4.0.1 Requirement 1.2.5)

Do we need a formal periodic review schedule?

The requirement text focuses on identification, approval, and business need, but review is how you keep those true over time. Define a review cadence that matches change velocity and risk, and keep evidence of reviews and resulting tickets.

Our third party manages the firewall. Are we still responsible?

Yes. You can outsource operation, but you still need the allowlist, approvals, and business justification artifacts. Make these explicit deliverables in the third party’s scope and require rule evidence on request. (PCI DSS v4.0.1 Requirement 1.2.5)