PCI DSS 1.3: restricting network access to the CDE

PCI DSS 1.3: what the requirement asks for and why teams struggle with it

Requirement 1.3 asks you to deny all network traffic into and out of the cardholder data environment (CDE) unless it is specifically needed, and to place network security controls between every wireless network and the CDE. An assessor testing this will want to see that each permitted path has a documented reason and that everything else is blocked by rule, not by assumption. The risk is straightforward: every unneeded path is a route an attacker can use to reach stored or transmitted card data, or a route through which data can leave the environment unnoticed. Requirement 1.3 is the control that keeps the CDE reachable only through approved doors. The requirement has three sub-requirements. Requirement 1.3.1 covers inbound traffic to the CDE: only necessary traffic may be allowed, and all other inbound traffic must be specifically denied. Requirement 1.3.2 applies the same logic to outbound traffic from the CDE. Requirement 1.3.3 covers wireless: a network security control must sit between every wireless network and the CDE, and wireless traffic into the CDE is denied unless it has an authorized business purpose, whether or not the wireless network is itself in scope. Confirm with your QSA how they will treat wireless networks that have no path to the CDE, since the boundary they draw determines which networks need controls. The work is hard for two reasons. Rule sets grow over time as projects add services, vendors need access and emergency exceptions become permanent, so the ruleset drifts away from its original intent. The deeper problem is evidence: you cannot prove a rule is necessary without a documented business purpose tied to a named service, owner and port. Start by listing every rule that touches the CDE, then ask who owns each one and what would break if it were removed. Rules that cannot be justified are the ones an assessor will question first.

Which systems, flows and wireless networks fall under 1.3

Requirement 1.3 only applies to what sits inside or next to the cardholder data environment, so the scoping decisions come first. Each card below names one decision that changes how many rules you write, which flows they cover and which systems must be checked before an assessor arrives.

Systems that store, process or transmit account data

The PCI SSC glossary defines the cardholder data environment as the people, processes and system components that store, process or transmit cardholder data or sensitive authentication data. Every server, database, payment application and workstation that touches that data belongs in the CDE boundary, and each one needs its traffic restricted under 1.3.1 and 1.3.2. Ask for a current inventory of these components and confirm that the boundary matches the data-flow diagram rather than the team's assumptions.

Systems with unrestricted connectivity to the CDE

The CDE definition also covers system components that have unrestricted connectivity to CDE components, even if they never handle account data. Domain controllers, monitoring agents, jump hosts and shared management servers often fall here. Each one that can reach the CDE without a restriction widens the set of inbound and outbound rules you must justify, so review every flat network segment that shares an address range with payment systems.

Inbound and outbound CDE flows

Requirement 1.3.1 requires inbound traffic to the CDE to be limited to what is necessary, and 1.3.2 applies the same discipline to outbound traffic. Each permitted flow needs a documented business purpose, a source, a destination, a port and a protocol. Outbound flows are often under-scoped, so check package repositories, time servers, payment gateways and update services, and confirm that every allowed destination has a reason to be there.

Administrative access paths

Administrative sessions, bastion hosts, VPN concentrators and remote management consoles are routes into the CDE that engineers use every day. Each path must appear in the rule set as an explicitly allowed flow, with the source limited to authorized administrators and the destination limited to the systems they manage. Ask which administrative routes exist outside the documented design, such as direct SSH from a developer laptop or a vendor remote tool installed on a server.

Third-party and service provider connections

Payment processors, hosting providers, managed security services and software vendors that connect into the CDE create flows you do not fully control. Each connection needs its own inbound or outbound rules, and the vendor's source addresses should be limited to the ranges agreed in writing. Confirm which third-party links are active, who approved them, and whether any remain open after the project that required them has ended.

Every wireless network, whether or not it is a CDE

Requirement 1.3.3 requires network security controls between every wireless network and the CDE, and the rule applies even when the wireless network itself is not part of the cardholder data environment. Under this requirement, wireless traffic into the CDE is denied by default and only wireless traffic with an authorized business purpose is allowed. Ask for a list of all wireless networks at each site, including guest and staff networks, and confirm each one has a documented control between it and the CDE.

How an assessor tests network access controls to the CDE

This table compares what a QSA does for each sub-requirement of 1.3, from reviewing the network diagram through testing wireless paths. Read each row as a test step with the evidence to prepare and the findings that most often cause gaps. The main takeaway is that assessors compare documents against the live ruleset, so a rule without a documented purpose fails as readily as a missing rule.

Test area	What the assessor does	Evidence requested	Common findings
1.3.1 Inbound CDE traffic	Traces each inbound path into the CDE on the diagram, then reads the NSC rules that enforce it and confirms a final deny for all other traffic.	Current network and data-flow diagrams, exported NSC rulesets, documented business purpose per inbound rule.	Allow-any or broad source ranges, no explicit deny at the end of the ruleset, inbound rules with no owner or purpose.
1.3.2 Outbound CDE traffic	Lists every outbound destination the CDE can reach, checks each against a documented need, and confirms default deny for everything else.	Approved outbound destination list, outbound ruleset exports, justification records for each permitted destination.	Outbound to 'any' for updates or convenience, forgotten vendor or test endpoints still allowed, no review of outbound flows.
1.3.3 Wireless networks to the CDE	Identifies every wireless network in or near the CDE, then tests whether an NSC sits between it and the CDE and whether wireless traffic is denied unless it has an authorized business purpose.	Wireless network inventory, wireless-to-CDE NSC configuration, documented authorized purposes for any permitted wireless flow.	Guest or corporate Wi-Fi with a route into the CDE, no NSC between wireless segments and the CDE, wireless rules copied from wired rules without review.
Diagram and data-flow match	Compares the documented diagram with the NSC configuration and, where possible, with observed traffic, looking for paths the diagram omits.	Diagram with version date and approval, configuration files, traffic or flow logs, any change records since the last review.	Diagram shows a segmented CDE but rules allow unrecorded paths, diagram not updated after a migration or new vendor connection.
Rule ownership and stale rules	Samples rules and asks who requested each one, why it still exists, and when it was last reviewed.	Rule register or change tickets linking each rule to a business purpose, review records and approvals.	Rules with no owner, temporary rules that were never removed, rules for decommissioned systems still active.
Documented versus running state	Compares exported configuration with the device or cloud policy actually in force, and checks that the two match at the time of assessment.	Configuration exports, screenshots or API output from the live platform, change logs showing who altered rules and when.	Rules changed directly on the device without a ticket, cloud security groups differing from the infrastructure-as-code definition, config drift between primary and standby devices.
Sampling and testing evidence	Selects a sample of rules across inbound, outbound and wireless paths, then tests whether traffic is actually permitted or blocked as documented.	Sample selection record, test results such as connection attempts or scan output, and logs showing the deny rule firing.	Test results not retained, deny rules never exercised, samples drawn only from the newest rules and missing older exceptions.

Implementing 1.3 step by step, and what each step produces

This sequence takes a CDE from an unverified network boundary to a default-deny NSC configuration in which every permitted inbound, outbound and wireless path has a documented purpose, an owner and a tested rule. Each step ends with an artifact an assessor can examine.

Confirm the CDE boundary and data flows
Start by agreeing with the payment, network and application owners which system components store, process or transmit cardholder data or sensitive authentication data, and which components have unrestricted connectivity to them. Map every network path into and out of that boundary, including administrative access, vendor connections, backup transfers and monitoring. The output is a current network and data-flow diagram that the team signs off. You know this step is done when every flow on the diagram traces to a named system and no path is marked as unknown.
Document a business purpose for each flow
For every inbound and outbound flow that crosses the CDE boundary, record the source, destination, port, protocol, business reason and the data it carries. Ask the owning team to justify each flow in writing, and reject any flow that cannot be tied to a function. The output is an approved flow register that becomes the reference for all later rule work. The step is complete when the register has an entry for every flow in the diagram and each entry has an accountable owner.
Build a default-deny baseline on each NSC
On each network security control at the CDE boundary, set the base policy to deny all inbound and outbound traffic, and confirm that the final rule in the set denies anything not explicitly permitted. On OPNsense, for example, this means a stateful rule set with a closing block rule and logging enabled for matches that matter to review. Test the baseline in a non-production change window before it goes live. The output is an exported rule set for each NSC and a record of the deny-by-default test. The step is complete when traffic that no approved flow covers is blocked in that test.
Add scoped allow rules with owners and review dates
Translate each approved flow in the register into the narrowest allow rule possible, using specific source and destination addresses, required ports and named aliases for address groups. Attach the owner and the review date to each rule in the change record, and remove any rule that lacks a business purpose. Ask the team to confirm the review cadence that the organization's policy sets for these rules. The output is a rule inventory that maps each allow rule to a register entry. The step is complete when no allow rule exists without a matching register entry.
Place NSCs between wireless networks and the CDE
Identify every wireless network in the environment, whether or not it is itself part of the CDE, and place a network security control between each one and the CDE. Configure the rules so wireless traffic into the CDE is denied by default and only wireless traffic with an authorized business purpose is permitted. Record which wireless segments are in scope and which rules govern them. The output is a wireless segmentation rule record and a diagram showing each wireless network and its controlling NSC. The step is complete when a test from a wireless segment to a CDE address is blocked unless it matches an approved purpose.
Verify rules with rule-level testing
Test each NSC rule against the flow register, both by confirming that permitted traffic passes and that excluded traffic, including traffic from wireless segments, is denied. Use the firewall's rule-match logs and an independent scan from outside the boundary where the team can do so safely. Record the expected result, the actual result and the tester for each rule. The output is a rule-level test record and any defects logged against the change record. The step is complete when every rule has a passing test result or an open, owned remediation item.
Retain evidence for assessor review
Store the flow register, diagrams, exported rule sets, wireless test records and rule-level test results together under version control, with dates and approvers. Confirm with your assessor which evidence format they expect and how long they expect the records to span. Re-run the rule-level tests after any change to the boundary, and keep the change record that links each change to its approval. The output is an evidence package that an assessor can trace from a requirement to a specific rule and its test. The step is complete when a reviewer who did not build the rules can find the evidence for any rule within a short search.

Evidence that passes a 1.3 assessment and how to keep it current

An assessor testing Requirement 1.3 samples a small set of artifacts and checks that each one matches the live network on the audit date. The cards below cover the rule exports, flow register, diagrams, wireless evidence, change records and review sign-offs that connect the controls, along with how to keep each one current between assessments.

Exported NSC rule sets showing default-deny

Assessors look for a rule export from each network security control in the CDE path that ends in an explicit deny for inbound and outbound traffic, with allow rules limited to documented necessary flows. Export the live configuration rather than a design document, and confirm the export includes the final deny rule and the interface or zone it applies to. Schedule an export at least monthly and after every change, store it with a timestamp, and diff it against the previous version so unexpected allow rules are caught before an assessor finds them. For a firewall such as OPNsense, the rule list and aliases are the primary records to keep.

Approved flow register with owners

The flow register lists every permitted inbound and outbound connection into or out of the CDE, with its business purpose, source, destination, port, protocol, named owner and approval date. Assessors use it to test that each allow rule in the exported rule set traces back to an approved need, so any rule without a matching entry is a finding. Review the register whenever a new integration is requested, and remove flows that no longer have a live rule. Ask the owner of each flow to confirm the purpose at each periodic review rather than letting entries age silently.

Network and data-flow diagrams

Current network and data-flow diagrams show where the CDE boundary sits, which NSCs enforce it, and how cardholder data and connected systems move across segments. Assessors compare the diagrams with the rule exports and the flow register, so a segment that appears in a diagram but has no documented rule set is a gap to close. Update diagrams through the same change process as the rules, tag each revision with a date and approver, and walk the diagram against the live environment at least once a year and after any significant architecture change.

Wireless to CDE rule exports and tests

Requirement 1.3.3 requires network security controls between every wireless network and the CDE, and wireless traffic into the CDE is denied unless it has an authorized business purpose, whether or not the wireless network is itself in scope. Keep exports of the NSC rules that sit between each wireless segment and the CDE, and record test results showing that traffic from a wireless client is blocked where it should be. Repeat those tests after changes to access points, controllers or wireless VLAN settings, and retain the results with the rule exports for the same period.

Change records for rule additions

Every rule added, modified or removed should have a change record that states the business reason, the approved flow register entry it supports, the requester, the approver, the implementation date and the test that confirmed the change worked. Assessors often pick a recent rule and ask for this trail, so a rule that appears in an export with no change record is hard to defend. Tie the change ticket number to the rule description where the platform allows it, and reconcile the change log against the monthly rule export to confirm no changes were made outside the process.

Periodic review sign-offs

A periodic review sign-off records that a named owner checked the active rules against the flow register and confirmed each allow rule is still necessary, that the deny-by-default posture holds, and that wireless controls are still in place. The review should be dated, signed by someone with authority over the CDE, and list any rules removed or corrected. Assessors check that reviews happen on the schedule the entity set and that findings were acted on, so keep the review output alongside the change records it generated. Confirm the cadence with your QSA before you commit to it.

What meeting 1.3 costs in money and effort

This table breaks down the money and effort behind Requirement 1.3, showing who is paid for each component, whether it is one-time or recurring, and what pushes it up or down. Use it to build a written, itemized scope before comparing quotes, since no fixed figures apply to every environment.

Cost component	Who is paid, one-time or recurring	What drives it up	How to keep it down
NSC licenses or appliances	Vendor or reseller. Purchase is one-time, support and subscription renewals recur.	Number of NSCs needed at each CDE boundary, high availability pairs, throughput, and vendor feature tiers.	Count only the NSCs the flow register requires. Self-hosted open-source firewalls such as OPNsense can remove license spend, though hardware and support still apply.
Engineering time to build the baseline and flow register	Your team and any implementation partner. One-time, with updates when flows change.	Number of inbound and outbound flows, undocumented legacy connections, and third-party integrations.	Start from current diagrams and actual traffic logs. Ask the partner for a written list of deliverables tied to each flow.
Rule review and change control	Your internal network and security staff. Recurring.	Frequency of business changes, number of rules, and rules without owners or business justification.	Use named aliases, document the business purpose per rule, and tie each change to an approved ticket.
Wireless segmentation work and testing	Your network team, with a tester or partner for validation. One-time build, recurring retest.	Number of wireless networks, whether any are adjacent to the CDE, and guest or staff networks sharing hardware.	Separate wireless networks from the CDE by design. Confirm in the quote whether testing covers every wireless network or only those in scope.
External testing or independent review	Qualified testing firm or independent reviewer. Recurring at the cadence your scope requires.	Number of boundaries, rule complexity, and whether testing is repeated after each significant change.	Scope testing to the CDE boundary and wireless networks. Ask whether a single engagement covers both.
Assessor sampling time during the assessment	Your staff who produce evidence, plus the assessor who samples it. Recurring each assessment cycle.	Volume of rule sets, number of change records requested, and gaps in logs or approvals.	Keep rule reviews, approvals and log exports ready in one place. Ask the assessor to confirm its sampling approach in writing before fieldwork.

Which open-source tools support 1.3 evidence, and their limits

Requirement 1.3 is tested by looking at the rules that govern traffic into and out of the CDE, and at the proof that those rules hold over time. The four tools below can produce parts of that evidence, but each covers one layer, and none replaces the organization's own rule review or an assessor's judgment on whether the output is sufficient.

OPNsense packet filtering

OPNsense is a stateful packet filter licensed under BSD-2-Clause. Its rules pass, block or reject traffic by source, destination, port and protocol, and aliases let you group CDE addresses and approved service endpoints so the ruleset stays readable. Enable per-rule logging so each rule match appears in the live log view, which gives you a record that inbound and outbound CDE traffic is limited to what is authorized. Confirm with your assessor that rule exports, change history and log retention meet their sampling approach, and that the default deny sits at the end of each relevant rule set.

Coraza web application filtering

Coraza is a web application firewall licensed under Apache-2.0. It runs ModSecurity SecLang rulesets and the OWASP Core Rule Set, and integrates with Caddy, HAProxy, Traefik and Nginx. It filters HTTP attacks such as SQL injection, cross-site scripting and code injection, so it fits in front of payment web applications. It does not replace network security controls under 1.3. Its logs show blocked application requests, not the port and address policy that 1.3.1 and 1.3.2 require. Confirm which rule set version and exceptions your assessor expects to see documented.

Wazuh configuration assessment

Wazuh Security Configuration Assessment is licensed under GPL-2.0-only. It scans monitored endpoints against YAML policies, most of them based on CIS benchmarks, and checks files, directories, registry keys and running processes, with recommended remediation for each finding. For 1.3, it can show that hosts that sit on the CDE network boundary or act as jump points hold the configurations your rules assume. It does not read firewall rulesets, so pair it with exported NSC rules. Confirm which policies you run, whether you customize them, and how your assessor wants pass and fail results retained.

Fleet device policies

Fleet is licensed under MIT. Its policies ask yes or no questions of enrolled devices as osquery queries, and the policies page shows which devices in each fleet pass or fail. You can write policies that confirm a host has an approved local firewall enabled, or that it is not running unapproved network listeners, which supports the restriction of access around the CDE. Fleet covers devices you manage, not the network path itself. Confirm that your assessor accepts policy query results with timestamps as evidence, and decide who reviews failing devices and how fast they are remediated.

Who owns the CDE network rules, who prepares evidence, and who assesses

Requirement 1.3 asks for an answer to one question on every path into and out of the cardholder data environment: which traffic is necessary, and why. That answer is a business and risk decision, so it stays with your organization. Your team decides which services need to reach the CDE, which external parties may connect, and which outbound destinations are legitimate. It also approves each rule, records its business purpose, and signs off on changes when a payment application or vendor integration changes.

Business purpose per rule: every allowed flow has a named owner and a stated reason, not just a source, destination and port.
Deny-by-default position: your policy sets the default to deny, and each exception is an approved decision.
Wireless decisions: your team decides which wireless traffic has an authorized business purpose before it can reach the CDE.
Approval and change control: rule additions and removals go through an approval record that a reviewer can trace.
Accountability: a named role answers for the rule set, even when a partner or vendor operates the firewall.

Before any outside party is engaged, confirm that the rule owners and approvers are named in your own documents, because an assessor will ask who made each decision.

Where 1.3 implementations usually fall short, and how to close each gap

Most failures against Requirement 1.3 are not missing firewalls. They are rules that outlived their purpose, wireless paths that were never separated, and documentation that no longer matches the running rule set. The cards below cover the gaps assessors meet most often, the fix for each, and the artifact that shows it was closed.

Allow-any rules left from migrations

Temporary rules added during a cutover, a platform move or an incident often stay in place as permissive any-to-any or any-port entries. Under 1.3.1 and 1.3.2, inbound and outbound CDE traffic must be limited to what is necessary, with everything else specifically denied. Export the active rule base, sort by source, destination and port, and flag every rule whose source or destination is any. Replace each with named aliases and explicit ports, then remove the broad rule and confirm the deny-all default is the last rule. The artifact is the before and after rule export with change tickets for each removal.

Rules without a business purpose or owner

A rule that no one can justify is a rule no one reviews, and it becomes a path into the CDE. Require every allow rule to carry a description naming the business purpose, the system owner, the approving role and an expiry or review date. Where the firewall supports rule descriptions and aliases, use them consistently. Then check each allowed flow against the data-flow documentation and remove any rule with no current purpose. The artifact is a rule register that links each allow entry to an owner, a justification and an approval record.

Wireless networks bridged to the CDE

Under 1.3.3, network security controls must sit between every wireless network and the CDE, and wireless traffic into the CDE is denied unless it has an authorized business purpose, whether or not the wireless network is itself a CDE. Gaps appear when access points share a VLAN, a guest network routes to a payment subnet, or a management bridge is left enabled. Confirm the wireless segment terminates on a firewall interface, test from a wireless client that attempts to reach CDE addresses, and check that the rule set denies this traffic by default. The artifact is the segmentation test result and the firewall rule export for the wireless interface.

Diagrams that do not match the running rule set

Network diagrams drawn at project start drift from the firewall once rules are added by hand. An assessor who compares the diagram with the live configuration will find flows that the document does not show. Export the running configuration, generate a flow list from the enabled rules and compare it line by line with the network and data-flow diagrams. Resolve each difference by either updating the diagram or removing the rule, and record the reconciliation date. The artifact is a signed reconciliation record showing diagram and configuration matched at a stated point in time.

No evidence of periodic rule review

Teams often review rules after an audit finding but have no scheduled, repeatable check between assessments. Set a recurring review of the rule base against the approved flows, record who performed it, and capture any changes. Where a configuration monitoring tool is in place, use it to alert on rule changes outside change control, and confirm that the enabled rules still match the approved baseline. Ask your assessor which review cadence and evidence format they expect for your environment, since the requirement sets the frequency and your QSA will test against it. The artifact is a dated review log with reviewer, scope, findings and sign-off.

Common questions about 1.3 cost, effort and doing it in-house

How much effort does requirement 1.3 take for a small rule set versus a large one?

Effort scales with the number of inbound and outbound paths into the cardholder data environment, not with the size of the company. A small environment with one payment application, one database tier and a single internet entry point has a short list of allowed flows to document and justify. A large environment with many segments, third-party connections, management networks and cloud security groups has many more rules, each needing a stated business purpose, an explicit deny at the end of the rule base and evidence that the rules match what was approved. Ask any provider to break its estimate down by rule count, number of network zones, and number of third-party connections, and to state which of those items it has assumed.

Can an open-source firewall satisfy requirement 1.3?

Requirement 1.3 is technology neutral. It asks for network security controls that restrict traffic to what is necessary and deny everything else, plus controls between wireless networks and the CDE. Open-source options such as OPNsense, a stateful packet filter with rules that pass, block or reject traffic by source, destination, port and protocol, can meet that intent when they are configured with a default deny, documented rules and logging of rule matches. The assessor will test the configuration and the evidence, so the platform choice matters less than whether you can show the ruleset, its approvals and its review history. Confirm the specific features you need with the vendor and in your own test environment.

Can our own team do requirement 1.3 without outside help?

Yes, if your team can read the current ruleset, map each allowed flow to a business purpose, and produce evidence that the controls work as documented. Many organizations do this in-house for simple environments. The work becomes harder when no one can explain why a rule exists, when rules were added through informal change requests, or when the CDE boundary itself is unclear. An internal review of the ruleset against the CDE definition in the PCI SSC glossary is a useful first step before deciding whether to bring in help for the cleanup, the evidence or both.

What does the work need from our network and security teams?

Network engineers own the firewall configuration, the rule inventory and the change records. Security staff own the policy, the review of allowed traffic, the wireless segmentation decision and the evidence that rules are reviewed. Application and payments owners must confirm which flows are business necessary. Expect the network team to provide exports of current rules, network diagrams and data-flow information, and the security team to test deny behavior and check logs. Agree in advance who signs off each rule and who answers assessor questions, because delays usually come from waiting for those approvals.

How long do the baseline and evidence take, and what sets that duration?

The duration depends on scope, and the written scope sets it. The main drivers are the number of rules to review, how many environments or sites are involved, whether wireless networks touch the CDE, how much existing documentation is usable, and how quickly approvals come back. A fixed-scope engagement records the deliverables, the systems covered and the timeline before work starts, so ask for those items in writing rather than a generic duration. The assessor's own schedule also affects when validation can be completed.

Can a consultant sign the PCI DSS assessment for requirement 1.3?

No. A consultant or implementation partner can prepare the ruleset, the configuration, the documentation and the evidence, but only a Qualified Security Assessor can complete the Report on Compliance for a merchant or service provider, or the assessor-related attestation where it applies. The organization owns its controls and signs its Attestation of Compliance. Keep consulting and assessment work separate where possible, so the assessor can test an environment without relying on the same person who designed it. Ask any provider to state its role in writing.

What should we ask for in a quote for requirement 1.3 work?

Ask for a written scope that lists the firewalls, cloud security groups and wireless controls covered, the number of rules reviewed, the CDE boundary assumed, and the deliverables such as the ruleset standard, the rule inventory, the diagrams and the test evidence. Ask which tasks are one-time, such as the initial cleanup, and which recur, such as the six-monthly ruleset review and ongoing monitoring. Ask what the provider needs from your team, which items are excluded, how changes to scope are priced, and what happens if the assessor requests additional evidence. DeployOpen does not publish a price list, and a quote follows from the written scope.

How DeployOpen scopes, implements and prepares 1.3 evidence

DeployOpen works on 1.3 Restricting network access to the CDE as part of a written, fixed scope inside your own infrastructure. We prepare the inbound, outbound and wireless network security controls and the evidence that shows they work, while your organization owns the controls and an independent QSA issues the assessment.

How we scope

Map every inbound and outbound path into and out of the CDE, with each allowed flow and its business purpose recorded.
Identify every wireless network and confirm the network security controls required between it and the CDE.
Agree the scope, deliverables and timelines in writing before work starts, since engagements are fixed-scope.

How we build

Configure deny-by-default rulesets on the firewalls or equivalent controls you run, with only documented, necessary flows permitted.
Set up rule aliases, logging of each rule match and review workflows so every permitted flow traces to a business need.
Test the rules against the intended flows and confirm that unlisted traffic and unauthorized wireless traffic are blocked.

How we hand over

Deliver rule listings, network diagrams, test results and configuration exports that show how 1.3 is met on each control.
Document the procedures your team uses to review rules, approve new flows and retain the logs an assessor will request.
Confirm with your QSA, before testing begins, which evidence formats and sampling they expect for 1.3.

How we support

Provide ongoing support, upgrades and continuous testing of the controls as a retainer after the initial scope is complete.
Review rule changes and new wireless or connectivity requests against the 1.3 requirements before they reach production.
Keep the evidence current between assessments so your team can answer assessor questions without rebuilding records.