PR.IR-01 network protection and segmentation: what the requirement asks
If a CSF 2.0 profile or a customer questionnaire asks how you segment your networks, it is almost certainly asking about PR.IR-01. This Subcategory of the PROTECT Function's Technology Infrastructure Resilience Category expects that networks and environments are protected from unauthorized logical access and use. NIST does not certify this outcome or any product that claims to meet it. Your organization owns the control, and an independent assessor only reviews what you can show. NIST publishes four Implementation Examples: segment networks and cloud platforms by trust boundary and platform type (IT, IoT, OT, mobile and guest); allow only necessary traffic from external networks; implement zero trust architectures; and check endpoint health before granting access. Read together, they ask for clear zones, default-deny rules between them, and a decision point that considers the device as well as the user.
PR.IR-01 absorbs parts of CSF 1.1 PR.AC-5 (network integrity), PR.PT-4 (communications and control networks protected), PR.AC-3 (remote access managed) and PR.DS-7 (development and testing separated from production). If your earlier assessment mapped those items, check whether the evidence you already hold still answers the new identifier, and confirm the exact crosswalk in NIST's CSF 1.1 to 2.0 Core transition spreadsheet before you reuse it.
The requirement is hard in practice because most environments were not designed for it. Flat legacy networks let a compromised workstation reach payment, clinical or industrial systems. Cloud sprawl creates accounts, VPCs and peering links that no one inventoried. Shadow connections, such as vendor VPNs, unmanaged Wi-Fi access points and engineering laptops bridged to plant networks, bypass the boundary you documented. Start by asking for a current network and data flow map, then test whether each trust boundary has an enforced rule set rather than only a diagram. Assessors will ask for rule exports, change records and sample log reviews, so confirm early which of those your team can produce.
Which networks, platforms and parties fall under PR.IR-01
PR.IR-01 applies wherever the organization's networks, cloud environments and connected parties can reach technology assets. The decisions below determine how many boundaries must be drawn, which traffic must be filtered and which parties must be brought inside the evidence set.
Trust boundaries between network types
Decide which networks are separated from one another: IT corporate networks, OT control networks, IoT devices, mobile devices and guest Wi-Fi. NIST's Implementation Examples name these platform types as segmentation candidates. Each boundary you add needs a documented purpose, a filtering rule set and a test that shows traffic is blocked. Flat networks where OT and guest devices share a broadcast domain with corporate systems usually produce the largest remediation effort, because every system on the flat segment inherits the exposure. Ask which networks currently share routing, DNS or authentication services, since those shared services often defeat the separation on paper.
Cloud accounts and virtual networks
Each cloud account, subscription, project and virtual network is a separate boundary that must be inventoried and segmented. Scope usually grows through forgotten test accounts, peering links and development environments that connect to production databases. Count every account and VPC or VNet that holds regulated data or controls production systems, and document how traffic moves between them. Confirm which team owns each account, because segmentation decisions made in one account can be undone by an administrator in another. Treat cloud security groups and network policies as part of the segmentation evidence, not as a separate exercise.
Remote access paths
Remote access is a boundary crossing that many organizations overlook. VPN concentrators, remote desktop gateways, jump hosts and vendor support tunnels each open a path from outside into a protected network. Scope every ingress point, including ones installed for a single project and never removed. For each path, record who can use it, which destinations it reaches and whether the connecting device is checked for health before access is granted. The PR.IR-01 Implementation Examples call for that health check, so a remote access path without one is a finding even when the network design is otherwise sound.
Third-party and supplier connections
Site-to-site VPNs, API integrations, managed service provider consoles and vendor maintenance accounts bring outside parties into your logical boundary. Each connection should appear in the network diagram with its owner, its permitted destinations and its ports. Contracts often describe what a supplier may access, but the firewall rules are what actually enforce it. Ask each supplier for the connection method they use and whether they share credentials with other customers. Connections that are inventoried only in procurement files tend to be missed during segmentation testing.
Data flows that cross boundaries
The effort rises sharply once you map where data moves between segments. A database that feeds a reporting tool in another zone, a file transfer from OT historians to a corporate analytics platform, or a backup job that reaches a cloud region each needs an explicit allow rule with a stated business reason. Build the data flow map first, then mark each crossing as allowed, restricted or removed. Flows that no one can justify are the cheapest to remove and the most useful to report as improvements. Confirm that logging is enabled on every crossing so that rule matches can be reviewed later.
Inbound web traffic to applications
Applications published to external users sit on the boundary between the internet and internal networks, so they belong in PR.IR-01 scope even when the application team considers them a separate concern. Identify each published hostname, its reverse proxy or load balancer and the rules that filter requests before they reach the application. Open-source web application firewalls such as Coraza, which is Apache-2.0 licensed and compatible with the OWASP Core Rule Set, can sit in this path. Confirm which applications bypass these controls, because a single exposed backend can undo the filtering applied everywhere else.
How an assessor tests PR.IR-01 segmentation and filtering
This table compares the four testable elements behind PR.IR-01: segmentation design, external traffic filtering, zero trust access and endpoint health checks. Read each row as the assessor's plan for that element, the evidence to have ready and the gaps that usually surface. The assessor is independent and tests the organization's own controls, not the implementation partner's documentation.
| Testable element | Test approach and evidence requested | Common findings |
|---|---|---|
| Segmentation design | Document review of the network and trust boundary diagrams, data flow maps and the rationale for each zone (IT, IoT, OT, mobile, guest). Assessor checks that zones match the asset inventory and that cloud accounts and virtual networks are included. | Diagrams older than the current network, cloud subnets missing from the design, and OT or IoT devices placed on corporate segments without a documented reason. |
| External traffic filtering | Configuration inspection of firewall and web application firewall rule sets, with a sample of rules traced back to a documented business need. Assessor confirms default deny for inbound traffic and reviews logging settings for rule matches. | Broad 'any' source rules left from temporary changes, unused rules never removed, and rule matches not logged or reviewed. |
| Zero trust access | Review of the access architecture and policy records, then sampled tests in which the assessor attempts access from outside the trusted zone and checks that identity and device conditions are enforced before access is granted. | Trust still based on network location alone, policies that exempt administrators or service accounts, and no evidence that policy decisions are logged. |
| Endpoint health checks | Sampled review of posture policies (patch level, endpoint protection status, encryption) and tests showing that a noncompliant device is denied or quarantined. Assessor asks for the check results for a set period. | Health checks defined but not enforced, exceptions with no expiry, and unmanaged devices that reach resources through an unchecked path. |
| Boundary crossing tests | Assessor selects flows between zones and tests whether unauthorized traffic is blocked, using agreed test traffic from a permitted and a non-permitted source. Results are compared with the documented rules. | Permitted flows that are wider than documented, return traffic allowed without a stated rule, and tests run only against a staging copy that differs from production. |
How to implement PR.IR-01 in a sequence that produces evidence
This sequence moves from knowing what networks and platforms exist to proving that traffic between them is limited, filtered, logged and tested. Each step leaves a record an assessor can sample, so the evidence builds as the work proceeds.
Inventory networks and platform types
The infrastructure owner, with the network and cloud teams, lists every network segment, cloud account, VPC or VNet, data center zone, guest or IoT network, and OT or mobile environment in scope. Each entry records the platform type, the owning team and the systems it hosts. The step is complete when the inventory reconciles against the asset register used for ID.AM and a named owner signs off on each line. The output is a network inventory that becomes the starting point for every later record.
Define trust boundaries and zones
Group the inventoried networks into zones based on trust level and platform type, such as internet-facing, corporate IT, production, management, IoT, OT and guest. Document the boundary controls at each edge, including which firewall, cloud security group or gateway enforces it. The step closes when every in-scope network belongs to exactly one zone and each boundary has an enforcing device. The output is a zone diagram with a short table of zone definitions and boundary owners.
Document allowed flows between zones
For each pair of zones, record the business reason, source, destination, protocol, port and direction of every flow that must cross the boundary. Anything not listed is denied by default, and the owner of each flow confirms it in writing. The step is done when the flow register covers all permitted paths and reviewers can trace each one to a system owner. The output is a flow register, which also supplies the justification assessors ask for when they test PR.IR-01.
Enforce external filtering and logging
Translate the flow register into rule sets on the edge firewalls and web-facing gateways, starting with a default deny posture and adding only the listed flows. For web applications, a web application firewall such as Coraza can be deployed alongside a rule set compatible with the OWASP Core Rule Set, and its configuration should be tested before it is put into blocking mode. Enable logging for each rule so matches can be reviewed. The step closes when each rule set has a named owner, a change record and a log sample from the live environment. The output is versioned rule sets, change tickets and log exports. Confirm the logging options and retention periods against the platform documentation and your own log policy.
Add zero trust access and endpoint health gates
Where internal access still relies on network location, add identity-based access checks for the flows that matter most, so that a connection is authorized by who or what is requesting it. Define the health attributes a device must present, such as patch level, disk encryption or endpoint protection status, and configure the policy engine to deny access when they are missing. Each gate needs a documented exception process. The step is complete when test accounts and test devices show both allowed and denied outcomes. The output is access policy definitions, device health criteria and the test results that show each gate working. Confirm which health signals your endpoint tooling can supply before writing the policy.
Validate, review and retain test records
Test each boundary by attempting the flows that should be blocked and confirming that the permitted flows still work. Review the rule sets and the flow register on a schedule set by the control owner, and after any material network change, recording findings and their closure. The step is done when test results, review minutes and remediation tickets are stored where an independent assessor can sample them. The output is a validation report, dated review records and a change history linking each rule to its flow and owner. These records are what an assessor reviews, but the assessor, not DeployOpen or the organization alone, decides whether the evidence meets the requirement.
Which evidence satisfies PR.IR-01 and how to keep it current
An assessor testing PR.IR-01 looks for records that show where trust boundaries sit, how traffic is filtered across them, and whether those controls changed under review. The cards below cover the artifacts that usually carry that proof, with guidance on keeping each one current between formal assessments. Confirm with your assessor which formats and review cycles they accept before you build the evidence set.
Zone and trust boundary register
This register lists each network zone, such as corporate IT, guest, IoT, OT, mobile and cloud accounts, with its trust level, owner and the controls that separate it from neighboring zones. It is the starting point for showing that segmentation follows trust boundaries and platform types, as the PR.IR-01 Implementation Examples describe. Keep it current by requiring a register entry before any new subnet, VPC or VLAN goes live, and by reconciling it against the asset inventory each quarter. Confirm the review interval your assessor expects.
Network and data flow diagrams
Diagrams show how traffic moves between zones, which services talk to each other and where external connections enter. They let an assessor compare the documented design with the firewall rules and cloud security groups that enforce it. Store diagrams under version control, tie each revision to a change ticket, and redraw any zone that changed during the period. A diagram that no longer matches the running environment is weaker evidence than no diagram, so spot-check it against live configuration.
Firewall rule sets with owners and review dates
Each rule set should show the source, destination, port and protocol that each rule permits, along with a named business owner and the date the rule was last reviewed. Unowned or expired rules are a common finding because they allow traffic nobody can justify. With OPNsense, rules can use aliases for address groups, which keeps the export readable for reviewers. Export the rule set on a schedule, record who approved each change, and remove rules that no longer serve a documented purpose.
Rule-match logs and their review
Logs of rule matches show that filtering actually runs and that blocked traffic is visible to the team. OPNsense can log each rule match, and the live log view supports review, but logs are only evidence if someone reviews them and records what they found. Define which rules are logged, where logs are retained and who reviews blocked attempts from external networks. Keep a short review record for each period, including follow-up on unexpected denies, so the assessor can see the review happened.
Remote access and zero trust policy records
Policies for remote access, administrative paths and zero trust controls show how access is granted per session and per resource rather than by network location alone. Pair the written policy with configuration exports from the access gateway or identity provider, and with a list of accounts and groups allowed through each path. Review the list when staff change roles or leave, and confirm that exceptions carry an approver and an expiry date. Record the approval of each policy version so the assessor can see which rules applied at a given time.
Endpoint health check configuration and results
Endpoint health checks confirm that a device meets baseline requirements, such as current patches, disk encryption and an active agent, before it reaches protected resources. Evidence has two parts: the check configuration, which states what is tested and what happens on failure, and the results, which show pass and fail outcomes over time. Keep the configuration under change control, and sample results regularly to confirm that failing devices were blocked or remediated. Ask your assessor whether point-in-time results or continuous logs carry more weight for them.
Change records for network controls
Change records link each firewall, routing or segmentation modification to a request, a risk assessment, an approver and a test result. They show that network controls are not changed informally and that rollbacks are possible. Require a change record for every rule addition, zone change and gateway update, and compare the change log against the configuration export at the end of each review period. Gaps between the two are the first thing an assessor will question, so reconcile them before the assessment starts.
What meeting PR.IR-01 costs in money and effort
This table lists the cost components of meeting PR.IR-01 for a self-hosted environment, who is paid for each, whether it is one-time or recurring, what pushes it up or down, and what to request in a quote. Open-source firewalls and web application firewalls remove license spend, but the engineering effort for segmentation design, rule sets and evidence stays.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives cost up or down | What to ask for in a quote |
|---|---|---|---|---|
| Tooling or licenses | Software vendor or subscription provider, if any. Open-source options such as OPNsense (BSD-2-Clause) and Coraza (Apache-2.0) carry no license fee | Recurring if commercial support or a paid subscription is chosen, otherwise none | Number of firewalls and clusters, need for vendor support, commercial add-ons, log storage volume | Itemized list of license and support lines, renewal terms, and whether support is optional |
| Segmentation design and rule engineering | Internal network or platform engineers, or an implementation partner paid on a fixed scope | One-time for the initial design, recurring when new segments or platform types are added | Number of trust boundaries and platform types (IT, IoT, OT, mobile, guest), cloud footprint, legacy OT constraints, count of allowed flows | Written scope listing zones, flows to be allowed, and the rule set deliverable, with the staff roles named |
| Zero trust and endpoint health checks | Identity and endpoint engineers, plus any agent or posture tooling the organization selects | One-time for integration, recurring for policy tuning and device onboarding | Number of managed device classes, identity provider integration, degree of legacy device support | Deliverables for posture criteria, enforcement points, and a test plan covering exception handling |
| Web application filtering | Application or platform engineers for rule tuning, false positive review and deployment | Recurring, because rule sets need tuning as applications change | Number of public applications, custom application logic, OWASP Core Rule Set tuning effort | Rule tuning schedule, logging and review process, and who approves rule exceptions |
| Evidence upkeep | Internal compliance or security staff, or a partner preparing evidence packs | Recurring, usually per review cycle | Frequency of rule changes, whether firewall logs are retained centrally, size of the change record set | Evidence list mapped to each implementation example, export format, and retention period the organization sets |
| External penetration or configuration testing | Independent testing firm or internal testers, paid per engagement | Recurring, typically per test cycle or after significant network change | Size of the attack surface, number of segments tested, whether cloud and OT zones are in scope | Scope statement, test methods, retest terms, and the report format the assessor will receive |
| Assessor sampling | Independent auditor or assessor, paid for the assessment itself. DeployOpen prepares systems and evidence but does not issue reports | Recurring with each assessment cycle | Number of segments and firewall configurations sampled, quality of change records, number of exceptions found | Sampling approach, expected evidence requests, and what the assessor needs from the organization before fieldwork |
| Internal oversight and staff time | Organization's own staff, who own the controls | Recurring | Number of firewall administrators, change approval steps, frequency of network and cloud changes | Confirm named owners for each segment and a review cadence agreed before work starts |
Which self-hosted open-source tools support PR.IR-01 evidence
OPNsense is a firewall platform built on a stateful packet filter, and its rules are the most direct evidence for the parts of PR.IR-01 that concern unauthorized logical access between networks. Each rule passes, blocks or rejects traffic by source, destination, port and protocol, so the rule set can be read as a written statement of which trust boundaries are open and which are closed.
- Rule inventory: An exported rule set shows which IT, IoT, OT, mobile and guest networks may reach each other and where external traffic is allowed in.
- Aliases: Address groups defined once and reused make it easier to show that segment membership matches the documented trust boundary.
- Per-rule logging: Enabling logging on a rule records each match, and the live log view lets reviewers inspect denied or unexpected flows.
- Change history: Configuration backups kept under version control give dated evidence of when a boundary changed. Confirm the export options available in your release.
What it does not cover: the packet filter does not decide what a trust boundary should be, does not prove that segments were designed by platform type, and does not inspect application requests for attacks such as injection. Those points need a documented architecture, the zero trust and endpoint health checks handled under other controls, and the web application firewall described in the next tab.
Confirm the logging, alias and export behavior against the OPNsense rules documentation for your version, and have your legal team check the BSD-2-Clause terms if you redistribute modified builds.
Coraza is a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, aimed at attacks such as SQL injection, cross-site scripting and code injection. It supports PR.IR-01 at the application boundary by showing which requests reached an application and which were blocked before they arrived.
- Blocking records: Audit logs record the rules that matched and the requests that were blocked for a given application path, which evidences filtering of external traffic at the web layer.
- Rule set version control: Keeping the SecLang rules and the Core Rule Set version in source control shows which rules were active on a given date.
- Proxy integrations: Documented integrations with Caddy, HAProxy, Traefik and Nginx let you place the filter where your existing traffic path already terminates.
- Tuning records: Rule exclusions and tuning decisions, with their approvals, show that false positives were reviewed rather than silently allowed. Confirm the setting names in the current documentation.
What it does not cover: Coraza does not segment networks, does not control non-HTTP protocols, and cannot show that the deployed rules match the approved set unless you keep those records yourself. The OWASP Core Rule Set is a separate project with its own license, so record its version and terms alongside Coraza's Apache-2.0 license.
Before writing these records into an evidence file, read the Coraza introduction and confirm which rule formats and proxy integrations your deployed version supports.
No single tool proves PR.IR-01. An assessor looks for a coherent chain: the boundary design, the enforcing configuration, the logs that show enforcement, and the records of approved change. The two tools above each produce part of that chain, and the evidence file should tie each record to the informative references that NIST publishes for PR.IR-01, including SP 800-53 Rev. 5.2.0 controls AC-3, AC-4, SC-4, SC-5 and SC-7, ISO/IEC 27001:2022 Annex A controls 8.20 to 8.23, and SP 800-171 Rev. 3 requirements 03.01.02, 03.01.03, 03.13.01, 03.13.04 and 03.13.06.
- Boundary design record: A dated document that lists trust boundaries by platform type. The rule inventory and aliases should match it.
- Enforcement configuration: Exports of the packet filter rules and the web application firewall configuration, each labeled with the software version and export date.
- Activity logs: Samples of denied flows and blocked requests, kept for the retention period your policy sets.
- Change approvals: Tickets that link each rule or rule set change to a named approver and a reason.
- Crosswalk table: A table that maps each record to the referenced controls, so an assessor can trace a requirement to a file without searching.
Illustrative example: a guest network may be allowed to reach only the internet gateway. The rule export, the alias membership list, a sample of denied guest-to-internal flows and the approval ticket for the rule form one traceable set.
Ask your auditor which evidence format and sampling method they will use before you build the file. The organization owns the control, and the independent auditor decides what evidence is sufficient.
Where organizations fall short on PR.IR-01 and how to close each gap
PR.IR-01 asks whether networks and environments are protected from unauthorized logical access, and most shortfalls trace back to paths that were never mapped, owned or reviewed. The cards below cover the gaps assessors most often find in segmentation, filtering, zero trust and monitoring, with a fix for each.
Flat networks with undocumented OT and IoT links
Operational technology, IoT devices and building systems often sit on the same broad network as corporate IT, or connect through a vendor gateway nobody inventoried. PR.IR-01 expects segmentation by trust boundary and platform type, so a flat network is the first thing an assessor will test. Start by listing every connection between IT, OT, IoT, mobile and guest networks, then place a documented boundary at each one. Confirm that each boundary has an owner and a stated purpose.
Filtering rules without owners or review dates
Firewall rules accumulate faster than anyone reviews them, and a rule without a business owner cannot be justified during an assessment. For each rule, record the owner, the business reason, the source and destination aliases, and the date of the next review. In OPNsense, aliases for address groups keep these rules readable enough to review. Ask the operations team to show who approved the last rule change and when it was last recertified.
Allow-any rules left from migrations
Temporary rules created during a cutover, vendor test or cloud migration often stay in place long after the project ends. An allow-any rule between segments defeats the purpose of segmentation, even if the rest of the policy looks sound. Search the rule base for broad source, destination or port values and for rules with no recent hits. Each match should either be narrowed to the required traffic or removed with a change record. Keep the change record as evidence that the cleanup happened.
Zero trust claimed without enforced endpoint checks
Many architecture documents describe zero trust access, yet the access decision still depends only on network location or a password. PR.IR-01 includes checking endpoint health before granting access, so the check must run in the access path and block a failing device, not merely produce a report. Confirm which applications enforce device posture, what happens when a check fails, and whether that decision is logged. Ask for a test device that fails a check and records the denial.
Remote third-party access without boundary records
Vendors, managed service providers and support engineers often reach internal systems through VPN accounts or remote tools that bypass the documented segmentation. Each remote path is a logical access route that PR.IR-01 expects you to protect and record. Maintain a register of every third-party connection, the systems it reaches, the approved window and the named sponsor. Disable accounts that have no active sponsor, and verify that vendor traffic is restricted to the same boundaries as internal traffic.
Logs collected but never reviewed
Firewalls and access gateways can record every rule match, yet many organizations never look at those records until an incident. An assessor will ask for evidence that the logs are reviewed, not only that they exist. Define which denied connections, rule changes and new paths trigger a review, and assign someone to check them on a set schedule. Keep dated review records, because a log archive with no review history is weak evidence for PR.IR-01.
Who owns PR.IR-01, who can help, and where the auditor stops
Your organization owns PR.IR-01. Someone with authority must approve the trust boundaries, decide which traffic from external networks is necessary, accept the residual risk and sign off on how zero trust access decisions are made. A vendor or assessor can advise on these choices, but they cannot make them on your behalf, and any evidence you present will be judged by whether an accountable owner made and recorded the decisions.
- Trust boundary decisions: Name each zone, such as IT, IoT, OT, mobile and guest, and record which flows cross each boundary and why.
- Rule ownership: Approve firewall rule sets, set a review cycle and define who may request a change and who approves it.
- Endpoint health policy: Decide which device health signals must be present before access is granted and what happens when a device fails the check.
- Log governance: Decide which rule match logs are kept, for how long, where they are stored and who reviews them.
Before engaging anyone, confirm that a named owner can explain every allowed path from an external network into your environment and that the decisions are documented in a form an assessor can sample.
Your engineers build and operate the segments day to day. They configure the packet filter, the web application firewall, the access gateway and the cloud network controls, and they handle the change requests that keep those rules aligned with the approved design. Their work produces most of the configuration evidence an assessor will examine, so it should be traceable from request to approval to deployment.
- Packet filter configuration: In OPNsense, rules pass, block or reject traffic by source, destination, port and protocol, and aliases group addresses. Confirm the rule logging option and where matches appear in the live log view before relying on it.
- Web traffic filtering: Coraza is a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. Confirm which integration your proxy uses, such as Caddy, HAProxy, Traefik or Nginx, before planning the rollout.
- Version-controlled configuration: Store rule sets and gateway settings in a repository so each change has an author, a reviewer and a timestamp.
- Change records: Link each rule change to a ticket that cites the trust boundary it affects.
For more on the packet filter, read the OPNsense documentation on rules. Your engineers should confirm that the documented behavior matches the version they run.
An implementation partner can take on the technical work that is hardest to staff internally: reviewing the segmentation design, cleaning up accumulated rules, setting up logging and testing whether segments hold. DeployOpen works this way inside the client's own cloud accounts, data centers or air-gapped networks. The partner prepares systems and evidence. It does not own the control, decide the risk or issue a conclusion on whether PR.IR-01 is met.
- Network design review: An outside reviewer can test the trust boundaries against your threat model and flag flows that cross zones without a documented reason.
- Rule cleanup: Partners often remove unused, overlapping or overly broad rules and document each change so the owner can approve it.
- Logging setup: The partner can configure rule match logging and route it to your retention platform, then test that events arrive.
- Segmentation testing: Testing confirms that traffic blocked by design is actually blocked, and the results go to your owner for remediation decisions.
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask for the scope to name each item above, whether ongoing testing is included, and which work recurs under a retainer rather than being a one-time build.
Only an independent auditor, assessor or certification body issues reports or conclusions. NIST states that it does not offer certifications or endorsements of CSF-related implementations or services and has no plans for a conformity assessment program. Any CSF 2.0 assessment against PR.IR-01 is therefore a contracted engagement, and its value depends on how the assessor defines its method and how independent it is from the work it reviews.
- Design and operation testing: The assessor checks whether the segmentation design fits the outcome of PR.IR-01 and whether rules operate as documented.
- Sampling of evidence: Expect sampling of rule changes, approvals, log extracts and test results across the period under review.
- Independence limits: An assessor who designed or cleaned up the rules may be unable to report on them. Ask how the assessor handles work its affiliates performed.
- Reference points: The NIST CSWP 29 PDF defines the Core outcomes, and your customers or regulators may name their own criteria.
Before signing, ask the assessor which evidence it will accept from a partner, how it documents its sampling and whether its independence policy covers the partner you have chosen.
Questions buyers ask about PR.IR-01 cost, time and effort
Can we implement PR.IR-01 in-house without an outside partner?
Yes, the organization can implement PR.IR-01 with its own staff, because CSF 2.0 is a voluntary framework and the outcome is owned by the organization, not by a consultant. The work is mostly network design and configuration: deciding trust boundaries, writing segmentation and filtering rules, and proving they work. Teams that already run firewalls, segmentation and identity controls usually need less outside help than teams building those skills from scratch. A partner is most useful when staff lack capacity, when several platforms need consistent segmentation, or when the organization wants evidence prepared for an independent assessment. Confirm internal skills against the four Implementation Examples before deciding.
What does PR.IR-01 require from our internal staff?
PR.IR-01 needs people who can make network decisions and keep them current. In practice that means:
- Network engineers who can map trust boundaries and approve traffic flows
- Security staff who define zero trust access rules and endpoint health checks
- Platform or cloud owners who confirm segmentation in their environments
- A records owner who keeps diagrams, rule reviews and change tickets current for auditors
The time commitment depends on how many networks, cloud accounts and OT or IoT segments are in scope. Ask a partner to name which roles it expects your staff to fill and for how long.
What drives the cost and effort of PR.IR-01?
The main drivers are the number of trust boundaries, the number of platform types (IT, IoT, OT, mobile and guest), the state of existing segmentation, and how much evidence must be produced. An environment with flat networks and undocumented flows takes far more work than one with existing zones and rule sets. Other drivers include the number of cloud accounts, the need for zero trust controls on remote access, and whether logs must be reviewed on a schedule. Costs fall into one-time design and build work, and recurring rule reviews, monitoring and changes. NIST does not publish cost figures for this Subcategory, so request estimates from the people doing the work.
Does an assessor certify PR.IR-01 compliance?
No. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. A PR.IR-01 alignment statement is the organization's own claim, which can be checked by an independent assessor who reviews the evidence. Any firm offering a PR.IR-01 certificate under the CSF is not offering a NIST product, so ask what the document actually is and who issues it. Where a customer or regulator requires a formal certificate, that requirement usually points to a different standard.
How does PR.IR-01 relate to CSF 1.1 PR.AC-5 and PR.PT-4?
PR.IR-01 takes over CSF 1.1 PR.AC-5 (network integrity) and PR.PT-4 (communications and control networks protection) under a new identifier. According to NIST's CSF 1.1 to 2.0 Core Transition Changes spreadsheet, it also absorbs part or all of CSF 1.1 PR.AC-3 and PR.DS-7. For teams that tracked the 1.1 identifiers, the practical step is to re-map existing evidence to PR.IR-01 and check whether the absorbed parts are fully covered. Use the spreadsheet as the authoritative source for the exact mapping.
What should we ask a partner for in a fixed-scope quote?
A fixed-scope quote should state exactly what is in and out of scope before work starts. Ask the partner to list:
- The networks, cloud accounts, OT or IoT segments and platforms covered
- The segmentation design, filtering rules and zero trust controls to be delivered
- The evidence set, such as diagrams, rule exports, change records and test results
- Who performs each task and what the organization must provide
- Deliverables, milestones and the acceptance criteria for each
- How ongoing rule reviews and support are priced separately
DeployOpen works from a written scope, so quotes follow from the agreed scope, and DeployOpen does not publish a price list.
How long does PR.IR-01 work usually take?
No researched duration is available for PR.IR-01, so the timeline depends on the environment. Work typically moves faster when trust boundaries are already documented and the team has rule sets to adapt, and slower when flat networks must be redesigned or when OT systems need careful change windows. Ask any partner for a timeline tied to specific deliverables, and confirm which dependencies (access, change approvals, maintenance windows) sit with your organization.
How DeployOpen scopes, implements and prepares PR.IR-01 evidence
DeployOpen treats PR.IR-01 as an engineering and evidence problem inside your own environment. We plan segmentation, filtering and access checks for your networks and cloud platforms, implement them on self-hosted open-source platforms, and document what an assessor will need to see. Your organization owns the control decisions, and an independent auditor issues any report.
How we scope
- We agree a written scope listing the networks, cloud accounts and trust boundaries covered before work starts.
- We map existing IT, IoT, OT, mobile and guest network zones and record which ones need segmentation.
- We confirm which external traffic paths need filtering and which zero trust or endpoint health checks apply.
How we build
- We configure stateful packet filtering with explicit pass, block and reject rules by source, destination, port and protocol.
- We deploy web application filtering using Coraza with OWASP Core Rule Set rules where public web services need it.
- We test each boundary against the intended rules and log rule matches so the behavior can be reviewed later.
How we hand over
- We deliver rule sets, network diagrams and configuration records that show how each PR.IR-01 requirement is met.
- We document the evidence sources, such as rule exports and log review records, and who in your team owns each one.
- We walk your team through the handover so they can run, change and review the controls without us.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We can prepare updated evidence packages for your assessor when segmentation or rules change.
- Your organization remains responsible for operating the controls and for any readiness or certification decisions.
