08 Network Protection: HITRUST requirements and evidence

What HITRUST network protection requires and why it trips up assessments

If an assessment is coming and your network is in scope, 08 Network Protection is the domain that asks whether you can show who controls every path into and across your environment. It covers controlled perimeter and internal networks, segmentation between zones with different risk, firewall rules that allow only what is needed, and oversight of the network service providers whose infrastructure carries your traffic. HITRUST scores this domain in e1, i1 and r2 reports alike, so it cannot be skipped by choosing a lighter assessment level.

The domain matters in practice because it fails often. In the HITRUST 2025 Trust Report, Network Protection accounted for 7.3% of failing domains in 2024, and the second most frequent corrective action plan that year concerned managing and monitoring network service providers. Those two findings point to the same weakness: organizations can usually describe their network design, but they struggle to prove that the design still holds and that someone reviews it. Confirm the current figures against the report before you cite them to a stakeholder.

Networks drift. A firewall rule added for a one-time vendor integration stays for years, a VLAN created for a project loses its owner, and an exception approved in a ticket never gets revisited. Rule sets grow faster than the people who understand them, and the evidence an assessor needs is scattered across firewall consoles, change tickets, cloud security group exports, provider reports and staff memory. Before the assessment window opens, assign an owner to each firewall policy and each network zone, export current rule sets with their justifications, and collect the contractual and operational records for every network service provider. Those three tasks surface most gaps early enough to fix them.

Which networks, providers and teams are in scope for network protection

Network protection is scoped by where traffic enters, moves and is administered, and by who operates each of those paths. The decisions below determine which requirement statements apply, which evidence an assessor will ask for, and how much of the domain a provider can carry on your behalf.

Assessed network boundaries

Start by drawing the perimeter of the assessed environment: which virtual networks, subnets, VPCs, on-premises segments and office links carry in-scope data or administer in-scope systems. Anything inside that boundary needs documented firewall rules, segmentation evidence and monitoring. Anything left outside should be justified in writing, because assessors will test whether the boundary matches the system description.

Internet ingress points

List every path from the internet into the environment, including load balancers, public IP addresses, API gateways, VPN concentrators and any web application firewall. Each ingress point needs a named owner, an allow list of ports and protocols, and logs of rule matches. Forgotten public endpoints are a common reason a boundary review turns up gaps late in fieldwork.

East-west traffic between zones

Decide which traffic between application tiers, databases, management networks and development zones is in scope. Lateral movement is where segmentation is tested hardest, so the assessed zones and the rules that separate them must be explicit. Confirm with your assessor how much east-west inspection and logging they expect for each zone pair.

Remote administration paths

Identify every route used to administer in-scope systems: bastion hosts, jump boxes, SSH and RDP access, cloud consoles, and vendor support tunnels. These paths often bypass normal ingress controls, so they belong in scope even when staff describe them as temporary. Document who can open each path, from where, and how sessions are recorded.

Third-party network service providers

Identify providers that operate network components you depend on, such as managed firewalls, DDoS mitigation, DNS, content delivery and managed security monitoring. Their responsibilities, your oversight of them and the evidence you can obtain from them must be set out before fieldwork. Reliance on a provider's report should be confirmed with your assessor, since the provider's controls rarely cover your rule sets.

Shared responsibility and inheritance

In HITRUST's OCI inheritance example, the provider secures backbone networking and DDoS protection, while the customer configures its own virtual networks, security groups and web application firewall. The domain is moderately inheritable, not fully inheritable. Confirm inheritance terms with your assessor, and document each carve-out in a shared responsibility matrix so that no network control falls between the two parties.

How an assessor tests network protection

This table compares six areas an assessor typically examines for the 08 Network Protection domain, what each one looks at, the evidence to have ready and where findings tend to appear. Read it as a preparation checklist: each row shows what the assessor will ask to see before fieldwork starts. Fieldwork runs at most 90 days, and only an Authorized HITRUST External Assessor performs the validated assessment, so use the table to prepare your evidence, not to predict a result.

Test area	What the assessor examines	Evidence requested	Common findings
Network diagram and scope boundary	Whether the diagram matches the assessed environment, including ingress points, connections to third parties and cloud virtual networks	Current network diagrams, asset inventory for network devices, and a written scope boundary tied to the assessment	Diagrams that predate recent changes, or missing links to cloud accounts and remote access paths
Segmentation between zones	Whether systems that hold sensitive data are separated from general user and internet-facing zones, and whether that separation is enforced	VLAN and subnet lists, routing and access control configuration exports, and a record of tested paths between zones	Flat networks where the in-scope environment shares a broadcast domain or routing path with out-of-scope systems
Firewall rule review	How rules are approved, scoped by source, destination, port and protocol, reviewed periodically and removed when no longer needed	Rule base exports, change tickets linked to rule changes, periodic review records and rule owner sign-off	Any-any rules, undocumented exceptions, and rules with no owner or business justification
Network services and ingress exposure	Which services listen on externally reachable addresses, and whether unneeded services are disabled and exposed interfaces are limited	Port scan or external exposure reports, service baselines, and records of approved exceptions for each exposed service	Management interfaces reachable from the internet, and services enabled by default and never reviewed
Monitoring and logging of network traffic	Whether traffic and security events are recorded, retained, reviewed and tied to an owner who acts on alerts	Sample flow or firewall logs, alert review records, retention settings and evidence of who reviews them and how often	Logs collected but never reviewed, or alerts that go unanswered with no documented triage
Management of network service providers	How the organization oversees providers that run network services, such as hosting, DDoS protection or managed firewalls, and what those providers are responsible for	Responsibility matrix, provider contracts or service descriptions, provider assurance reports, and records of periodic reviews	No documented split of duties with the provider, or no review of provider results after onboarding

How to implement network protection in the assessed environment

This sequence turns network protection from an informal set of firewalls into documented boundaries, owned rules and reviewable logs that an assessor can trace back to the in-scope environment. Each step produces an artifact the next step depends on.

Confirm the scope boundary and draw current diagrams
Start by agreeing with the assessment team which systems, data flows, networks and administrative paths fall inside the assessed scope. Your network and security engineers then draw current diagrams showing every ingress point, internet-facing service, management path, cloud virtual network and connection to third parties that touches in-scope data. The step is complete when the diagrams match what is actually deployed, which you confirm by comparing them against live configuration exports rather than against the original design documents. Keep the diagrams under change control so later edits leave a record.
Define zones and segmentation rules
Group the in-scope assets into zones based on function and data sensitivity, such as public-facing services, application tiers, databases, management networks and corporate user networks. For each zone, write the segmentation rules that say which zones may talk to which, over which protocols, and in which direction. The output is a zone register that names each zone, its owner and its permitted flows. Assessors commonly test this register against the diagrams, so any flow that exists in one but not the other should be resolved before you move on.
Set default-deny firewall policy with named rule owners
Configure firewall policy so that traffic is blocked unless a rule explicitly permits it, and record each permitted flow as a rule with a stated business purpose, source, destination, port and protocol. Assign a named owner to every rule, responsible for justifying it and removing it when the purpose ends. Open-source firewalls such as OPNsense support this model through aliases for address groups and per-rule logging, so the rule set can be exported and compared with the rule register. The step is complete when every rule in the firewall maps to a register entry with an owner, and no entry exists without a live rule.
Place inspection and logging at ingress and east-west points
Add inspection and logging where traffic enters the environment and where it moves between zones. At internet-facing ingress, a web application firewall such as Coraza, which is compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, can inspect HTTP requests against common injection and scripting attacks. For east-west traffic, intrusion detection such as Suricata and network metadata capture such as Zeek can record alerts, protocol transactions and connection records, with each log stream forwarded to a central log platform. The output is a logging configuration document listing each sensor, the log types it produces, where they are stored and who can read them. Confirm the chosen tools' capabilities against current vendor documentation before you commit to them.
Document network service provider oversight
Record every network service provider that carries, secures or manages in-scope traffic, including internet carriers, managed firewall operators, DDoS protection services, content delivery networks and cloud providers. For each one, document what the provider controls, what your organization controls, the contractual evidence you hold, such as a current SOC 2 or HITRUST report where available, and how you monitor their service levels and incidents. This is a frequent area of corrective action in HITRUST assessments, so the output should be a provider register with a named owner and review date for each entry, and a shared responsibility statement that matches the cloud or hosting contract. Ask each provider for the exact evidence they can supply rather than assuming it exists.
Run a rule and log review cycle
Establish a recurring review in which rule owners confirm that each firewall rule is still needed, that no unused or overly broad rules remain, and that changes followed the approval process. In the same cycle, a reviewer examines logs from the inspection and monitoring tools for denied traffic patterns, alerts that were dismissed without action and gaps where expected logs stopped arriving. Each review should produce a dated record listing the rules checked, the findings, the decisions and the follow-up owner. Assessors look for evidence that reviews happened on the stated schedule, so the review record is the artifact that proves the control operates, not just that it was designed.

Which self-hosted open-source tools produce network protection evidence

Network protection evidence usually comes from a few distinct layers: the firewall that sets the rules, the web application firewall that filters application traffic, and the sensors that record what actually crossed the network. The four tools below cover those layers, and each produces a different kind of record an assessor can sample. Confirm fit with your own architecture, licensing review and log retention needs before you commit.

Coraza web application firewall

Coraza is a web application firewall that can run ModSecurity SecLang rulesets and the OWASP Core Rule Set, aimed at attacks such as SQL injection, cross-site scripting and code injection. It integrates with Caddy, HAProxy, Traefik and Nginx, so the evidence depends on which proxy sits in front of your applications. Check that the rule set version is tracked under configuration management and that blocked-request logs reach your central log store. The license is Apache-2.0, which carries no copyleft obligation but still requires you to keep the license notice.

OPNsense firewall rules

OPNsense is a stateful packet filter whose rules pass, block or reject traffic by source, destination, port and protocol. Aliases group addresses, so one reviewed object can represent a segment or a service and the rule set stays readable for an assessor. Enable per-rule logging where a rule matters for segmentation, and review the live log view as part of a documented schedule. Its BSD-2-Clause license is permissive, so confirm the terms that apply to any plugins you add.

Suricata network intrusion detection

Suricata writes EVE JSON records for rule match alerts, anomalies, flows and protocol transactions such as HTTP, DNS, TLS, SSH and SMB. It can split these record types into separate files, which makes it easier to route alerts to a SIEM and retain flow data on a different schedule. Confirm which rule sets you run, who tunes them and how alert review is recorded, because an unreviewed alert feed is weak evidence. Suricata is licensed under GPL-2.0-only, so review how your distribution and any modifications are handled before you ship or host it for others.

Zeek network traffic analysis

Zeek writes dozens of logs by default, including conn.log for who talked to whom, for how long, how much and over which protocol, plus dns.log, http.log and weird.log for anomalous events. Each entry carries a unique connection identifier, so an assessor can trace one session across several logs. Decide retention for each log type and confirm that the sensor sees traffic at the points your segmentation claims to protect. Zeek is licensed under BSD-3-Clause, and you should confirm that your sensor placement and log storage meet your own data handling rules.

Which evidence passes a network protection test and how to keep it current

What network diagrams do assessors expect for the in-scope environment?

Assessors expect current network diagrams that show where the assessed scope begins and ends, every segment inside it, the connections to other networks, and the points where traffic crosses a trust boundary. The diagram must match the live environment, so it should be generated from or checked against the actual configuration rather than kept as a static drawing. To keep it current, store the diagram under version control, tie each change to the change ticket that altered the topology, and have the system owner sign off on the diagram at a review interval your own policy sets. Confirm with your assessor which level of detail they need before you finalize the boundary drawing.

How do firewall rule exports prove network access is controlled?

A rule export shows every permit and deny rule in force, with its source, destination, port and protocol, which lets an assessor test whether access is restricted to what the business needs. Each rule should have a named owner, a documented business reason and a link to the change ticket that approved it. In OPNsense, aliases group addresses so reviewers can read the intent of a rule, and per-rule logging lets you show that matches are recorded for review in the live log view. Export the rule set on a schedule, store each export with a timestamp, and record a periodic owner review that marks stale or unjustified rules for removal. Ask your assessor how they want exports presented, whether as raw configuration or as a reviewed listing.

What segmentation test results should be kept for an assessment?

Keep documented test results showing that systems in the assessed scope cannot reach other segments except through approved paths. Useful evidence includes the test plan, the source and destination pairs tested, the expected result for each pair, the observed result, and the remediation ticket for any unexpected path. Run segmentation tests after firewall or routing changes and whenever the scope boundary moves, then file the results with the diagram they validate. Testing can be performed by your internal team or by a security testing provider, but the results must reflect the environment as it stands on the test date. Confirm with your assessor how recent test results must be for the assessment period you are preparing for.

What WAF and IDS evidence shows detection is working?

Assessors look for proof that the web application firewall and intrusion detection system are configured, enabled and producing alerts that someone reviews. Preserve the active configuration and rule set versions, along with sample alerts that show detection and the follow-up action taken. Coraza, which is compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, can provide rule configuration and logs for web traffic, while Suricata's EVE output records rule match alerts that can be split into separate files for log management tools. To keep evidence current, export configuration snapshots on a schedule, keep rule update records, and file a periodic sample of triaged alerts with the reviewer's name. Note that a WAF on a customer-managed network is a customer control even when the provider secures the backbone.

Which network metadata logs satisfy retention and review expectations?

Network metadata logs record who communicated with whom, when, for how long, how much data moved and over which protocol, which lets investigators reconstruct events. Zeek produces conn.log for TCP and UDP connections, protocol logs such as dns.log and http.log, and weird.log for anomalous events, all linked by a unique connection identifier. Document where logs are sent, how they are protected from alteration, who reviews them and how often, and what retention period applies. Retention settings should be written into your logging standard and checked against the retention period your own policies and contracts require, since that period is set by your organization rather than by a fixed figure in this page. Verify that log shipping is working by sampling records on a schedule and recording the check.

What due diligence and monitoring records cover network service providers?

Assessors look for records showing that each network service provider, such as an ISP, managed firewall operator, DDoS mitigation provider or colocation network team, was vetted before use and is monitored afterward. Keep the due diligence file (security questionnaire responses, contract clauses on network security and incident notification, and any independent assurance reports you reviewed), along with a register of the services each provider runs for you. Monitoring records include periodic service reviews, tickets raised for provider incidents or misconfigurations, and evidence that you followed up. HITRUST's 2025 Trust Report notes that managing and monitoring network service providers was the second most frequent corrective action plan in 2024, so this is where assessments often stall. Set your own review cadence, record each review with a sign-off, and ask your assessor whether they accept inherited provider assurance for these items.

What meeting network protection costs in money and effort

This table breaks down the cost components of meeting the 08 Network Protection domain, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to build a written quote request, since most of the spend depends on how many network zones, systems and log sources are named in scope. The main takeaway is that licence spend is often the smallest line, while design, log review and third-party oversight usually drive the total.

Cost component	One-time or recurring	What drives it	How to keep it down
Tooling or licences	Recurring	Commercial firewall, IDS/IPS and WAF subscriptions, plus per-device or per-throughput fees	Self-hosted open-source options such as OPNsense, Suricata, Zeek and Coraza remove most licence spend, though support contracts may still apply
Engineering time to design and configure zones and rules	One-time, with recurring rule changes	Number of network zones, flows that cross zone boundaries, and the number of rules the assessor must trace to a requirement	Keep the zone model simple, use aliases for address groups, and document each rule against its purpose before go-live
Logging storage and review effort	Recurring	Volume of connection, protocol and alert logs, retention period, and how often a named person reviews them	Limit log sources to those in scope, split output into separate files for log management tools, and automate alert triage where possible
External penetration or segmentation testing	Recurring, usually annually or after significant change	Number of segments to test, depth of the test, and whether the test covers the boundary, internal segments or both	Define segment boundaries clearly, test against a written scope, and retest only the segments that changed
Provider oversight work	Recurring	Number of network service providers in scope, the depth of their evidence, and how often their reports are reviewed	Use inherited results where a provider's report covers the backbone and DDoS controls, and record your own configuration responsibilities separately
Assessor fieldwork	Recurring, per assessment cycle	Number of sampled rules, configurations and logs the assessor examines, and the readiness of evidence at the start of fieldwork	Prepare evidence before the assessor arrives, keep configuration exports current, and agree the sample approach in advance. The validated assessment fieldwork window is at most 90 days (HITRUST Assessment Handbook v1.1)

Who owns network protection, who prepares evidence and who issues the opinion

Your organization owns network protection. Segmentation, firewall rule sets and oversight of network service providers remain decisions and accountabilities of your security and platform teams, and no partner or assessor can take them over. Your team decides what each network boundary is for, who may change it and how changes are approved. It also decides which controls rely on a provider, which is where inheritance enters the picture.

Control ownership: name an accountable owner for each network boundary and approve the segmentation design.
Rule approval: sign off firewall and access changes through your normal change process so every rule has a traceable reason.
Log review: assign people to review network alerts and set the review cadence the assessor will test.
Provider oversight: manage network service providers, their contracts and their assessed results.
Inheritance boundaries: a cloud provider's controls can be inherited only when that provider has its own assessed results covering them. In HITRUST's Oracle Cloud Infrastructure example, the provider secures backbone networking and DDoS protection while the customer configures its own virtual networks, security groups and web application firewall.

Before the assessment, confirm that each network requirement has a named owner who can show current evidence without outside help.

Where network protection assessments usually fail and how to close each gap

Network protection findings tend to share a root cause: the network is changing faster than the records that describe it. The cards below cover the gaps assessors most often raise, what closes each one, and the evidence to have ready before fieldwork starts.

No owner for firewall rules

Firewall rule sets often grow through urgent changes that nobody later reviews, so rules with no business reason stay in place. Assign a named owner to each rule group or alias, record the justification and expiry date in the change ticket, and review allow rules on a fixed schedule. Check whether every rule can be traced to an approved request. OPNsense can log each rule match, so confirm that logging is on for the rules you rely on as evidence. Stale allow rules are the finding most often traced back to missing ownership.

Undocumented network service providers

Network service providers such as carriers, managed firewall operators, DNS hosts and DDoS mitigation services often sit outside the internal asset inventory. HITRUST's 2025 Trust Report lists managing and monitoring network service providers as the second most frequent corrective action plan for Network Protection. Build a register of every provider that touches in-scope traffic, with its contract, service scope, security reporting and review date. Evidence includes signed agreements, the most recent provider assurance report, and a record of who reviewed it and what changed as a result.

Diagrams that drift from the live network

Network diagrams are often drawn for an audit or a design review and then not updated after the environment changes. Assessors compare the diagram against live configuration, so a missing subnet, an unlisted VPN path or an outdated firewall zone creates an immediate question about scope. Tie each diagram to a change process, export current routing and firewall configuration on a set schedule, and reconcile the two. Ask your team to confirm that the version in the evidence folder matches the configuration that was in place during the assessed period.

Logs collected but never reviewed

Many organizations forward firewall and intrusion detection logs to a central store but cannot show that anyone reviews them. Define which network events matter, such as denied flows to sensitive segments, unusual protocol use and failed connections to administrative ports, and assign a reviewer and cadence. Suricata's EVE output and Zeek's conn.log and weird.log can supply that material, linked by connection identifier. Keep the review records alongside the logs, since a log with no documented review will not satisfy a reviewer.

Inheritance claimed without provider evidence

Teams often mark network controls as inherited from a cloud provider without holding the provider's own evidence. HITRUST's inheritance example splits Network Protection: the provider secures backbone networking and DDoS protection, while the customer configures virtual networks, security groups and the web application firewall. Obtain the provider's current assessment report and shared responsibility matrix, map each claimed control to the specific provider statement, and list customer-side controls that stay with your team. Confirm the inheritance scope with your assessor before fieldwork.

East-west traffic left unsegmented

Perimeter firewalls are usually well documented, but traffic between servers in the same zone often passes freely. An attacker who gets into one system can then reach databases, management interfaces and backups without crossing any control. Group systems by data sensitivity and function, restrict flows between groups to the ports they need, and document each permitted path. Evidence includes the segmentation design, the rule set for internal zones, and test results that show blocked paths are actually blocked. Inspect internal flows with Suricata or Zeek where a firewall alone cannot see them.

Common questions about network protection cost, effort and outsourcing

How much effort does network protection take in a HITRUST assessment?

Effort depends mainly on how many network paths, segments and third-party network services fall inside the assessed scope, and on whether the evidence already exists in a form an assessor can sample. Network Protection is one of 19 assessment domains, so it is scored alongside every other domain rather than in isolation. Teams usually spend the most time on undocumented segmentation, firewall rule sets nobody has reviewed in a while, and missing records of who manages each network service provider. Ask any partner to size the work from a written inventory of in-scope network components, not from a percentage of the total project.

Can we do network protection work in-house?

Yes, if your team has the skills to configure and document network controls and the time to collect evidence in the form an assessor expects. Organizations often keep ownership of firewall policy, segmentation design and log review in-house, and bring in outside help for readiness reviews, gap analysis and evidence packaging. Only an Authorized HITRUST External Assessor organization may perform the validated assessment submitted for certification, so an internal team can prepare for the assessment but cannot issue the result. Confirm internally who will answer assessor questions about each network control before you commit to a plan.

What does the internal team need to provide for network protection?

The internal team must own the network design and be able to show it working over time. In practice this means:

A current diagram and inventory of in-scope networks, segments and boundaries
Firewall and web application firewall rule sets, with change records and review history
Logs that show allowed and blocked traffic, retained and reviewed on a defined schedule
Documented management and monitoring of network service providers, including their contracts and reviews

Assessors sample evidence across the assessment period, so a rule set that was correct once but never reviewed will not show a sustained control. Plan for the evidence to exist before the fieldwork window opens.

How does inheritance from a cloud provider change the network protection work?

Inheritance reduces the customer's share of the work, but it does not remove it. HITRUST's Oracle Cloud Infrastructure example describes Network Protection as moderately inheritable: the provider secures backbone networking and DDoS protection, while the customer configures its own virtual networks, security groups and web application firewall. The customer must therefore document its side of the shared responsibility split and show evidence for it. Confirm with the provider exactly which network controls are covered by their assessment before you claim inheritance in your own scope.

Which parts of network protection are worth outsourcing?

Outsourcing pays off most where specialist skill or independent testing adds confidence, and least where the organization must make its own design decisions. Common candidates are a readiness review of segmentation and firewall policy, security testing of the exposed perimeter and web applications, and help building monitoring that produces the logs an assessor will sample. Keep ownership of network policy decisions, approvals and the network service provider relationship with your own staff, because those are the records an assessor will ask about. DeployOpen plans, implements, hardens and documents self-hosted network controls inside the client's own infrastructure, and runs security testing, but it does not issue assessment results.

How does assessor independence affect who can prepare the network evidence?

Independence separates preparation from certification. An implementation partner may build the controls, configure the logs and assemble the evidence, but the independent assessor must test that evidence and reach its own conclusions. The assessor cannot be the same party that designed the controls it tests in a way that compromises objectivity, so confirm with your assessor which preparation work they will accept. Keep a record of who configured each network control, who approved changes and who reviewed the logs, since that separation is what the assessor will examine.

How DeployOpen scopes, implements and prepares network protection evidence

DeployOpen plans, implements and documents self-hosted open-source network controls inside your own cloud accounts, data centers or air-gapped networks. We prepare the systems and evidence for the 08 Network Protection domain, while your organization owns the controls and an independent HITRUST External Assessor performs the validated assessment.

How we scope

Confirm which networks, segments, firewalls and inspection points fall inside the assessed environment and which sit with an inheriting provider.
Agree in writing which network service providers and third-party connections need monitoring and documented oversight.
Record the shared responsibility split with your cloud provider for backbone networking, DDoS protection and web application firewall duties.

How we build

Deploy OPNsense rule sets that pass, block or reject traffic by source, destination, port and protocol, with aliases for address groups.
Configure Coraza as a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, integrated with your existing proxy.
Set up Suricata and Zeek so network alerts, flow records and protocol logs reach your log management tools with linked connection identifiers.

How we hand over

Deliver firewall rule inventories with documented business justification, owner and review date for each rule and alias.
Provide a network diagram, segmentation design and configuration baseline that your assessor can trace to each requirement statement.
Hand over sample log extracts, alert records and runbooks showing how network events are reviewed and escalated.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope engagement closes.
Re-verify rule sets and monitoring coverage when your environment changes, so evidence stays current for the next assessment window.
Confirm with your team and the assessor which artifacts and sampling periods apply before each validated assessment begins.

08 Network Protection