What NIS2 network security requires before an assessor arrives
Point 6.7 of the Annex to Implementing Regulation (EU) 2024/2690 asks an entity to protect its network and information systems from cyber threats, starting with a comprehensible and up-to-date network architecture document. On top of that document, the entity must block network communication that operations do not need, control remote access (including access by service providers), deactivate unneeded connections and services, and where appropriate admit only authorized devices. It must also hold implementation plans for newer network layer protocols and modern email security standards, and apply best practices for DNS security and internet routing security. A national authority will test whether these controls exist, whether someone owns them, and whether the documents match the live environment. The risk is that the network drifts away from what is written down. Legacy paths that nobody documented keep working after a project ends, and vendor access is added one ticket at a time until no one can list every remote session. Some devices, such as industrial controllers, older appliances or embedded units, cannot receive security patches, so they need compensating controls and a recorded list. Before an assessor arrives, compare the architecture document against the firewall and router rulesets, switch VLAN and ACL configurations, and a traceable inventory of devices. Confirm with your own network team which exposure points exist today, because no generic count of them can stand in for that check.
Start with the supplier path, because it changes most often. Point 6.7.2(h) allows a service provider connection only after an authorization request and for a set period, such as the duration of a maintenance operation. Decide who approves these requests, how long each window lasts, how the connection is opened and closed, and where the session is recorded. A firewall rule that stays open for a former contractor is the finding assessors look for first. Logging the connection in a tool such as OPNsense, which can record each rule match for review, gives you evidence that the window was used as approved. The protocol, email and DNS items are plans, not one-time fixes. Your evidence should show a dated implementation plan for moving to latest generation network layer protocols, a plan for modern email security standards, and a stated approach to DNS and routing security. Owners, milestones and the decisions you have made are what a reviewer reads. Treat these plans as living documents that a named person updates after each architecture change, and confirm the standards and timing that apply to your sector with your competent authority and your own risk assessment.
Which networks, devices and suppliers fall under point 6.7
Point 6.7 applies to the network and information systems of entities covered by Implementing Regulation (EU) 2024/2690, and the boundary you draw determines how much of the network you must document, restrict and evidence. Scope should follow your own risk assessment, so the cards below set out the decisions that most often change the work and the checks to make before you commit to a boundary.
In-scope network segments
Start from the systems that support your operations and services, then trace which network segments carry their traffic, including management, backup and monitoring paths. A segment that only carries a supporting service still counts if compromise of it could reach an in-scope system. Confirm the boundary against your asset inventory and architecture document, and record the reasoning for segments you exclude. Assessors will look for that reasoning as much as the list itself.
Remote access as a separate scope
Remote access paths, including VPN concentrators, bastion hosts and jump servers, are where point 6.7 expects remote access to be controlled, so include them in scope even when they sit on a shared network. Count every route in, whether used by staff, contractors or automated tools. A remote access path you cannot list in your architecture document is a finding waiting to happen.
Service provider connections
Supplier connections for maintenance, monitoring or support are in scope because point 6.7.2(h) allows them only after an authorization request and for a set period. Identify each connection, its owner, the systems it reaches and its end date. Connections that are open-ended or undocumented belong in scope and should be closed or reauthorized before the next review.
Devices that cannot be patched
ENISA's June 2025 guidance lists a register of network devices that cannot receive security patches as evidence, so these devices belong in scope even when they are old, embedded or vendor-managed. Each one should be isolated, monitored and listed with its reason for remaining unpatched. Confirm with each vendor whether firmware updates exist before you accept a device as permanently unpatchable.
Cloud and data center networks
Networks run by a cloud provider or colocation data center are usually split between the provider's responsibility and yours. Your scope normally covers your virtual networks, security groups, firewall policies, routing and the connections you configure, while the provider's physical network sits with the provider under its own obligations. Ask each provider for its security documentation and map its responsibilities against your architecture before you draw the line.
Suppliers and managed services
Managed network or security services often operate firewalls, routers or monitoring on your behalf. Decide whether their management paths and tooling fall within your documented architecture, and whether their access is counted as a service provider connection. Contract terms should state what they control, what you control and how changes are approved, so the boundary is written down rather than assumed.
How an assessor tests network security under point 6.7
The assessor starts with the network architecture document required by point 6.7. The test is whether the document is comprehensible to someone who did not build the network, and whether it matches the systems running today. The assessor usually walks a sample of zones, links and trust boundaries from the document into the live environment and asks who approved the last change and when the document was last reviewed.
- Current diagrams: Expect a request for network diagrams showing zones, segments, internet edges and connections to third-party networks, with a revision date and owner.
- Coverage of the estate: Cloud VPCs, data center links, remote sites and management networks should appear, not only the production core.
- Common finding, stale diagrams: Diagrams that still show decommissioned firewalls or omit a cloud account added later are among the most frequent gaps.
- Change linkage: The assessor may compare the change log against the document to see whether architecture changes trigger an update.
- Ownership: A named owner who can explain each zone is stronger evidence than a diagram produced for the audit.
Before the assessment, reconcile the diagrams with a discovery scan of the environment and record the discrepancies and their closure dates.
This test checks that communication not needed for operations is blocked, and that the rules that do this can be read and reviewed. The assessor typically requests firewall and router rulesets, switch VLAN and access control list configurations, and a sample of the logs that show rule matches. They look for default-deny postures, rules with broad sources or any-any ports, and rules that no one can justify.
- Exported rulesets: Current configurations for each firewall, router and switch with a version or export date, as ENISA's June 2025 guidance lists as evidence.
- Justification: Each permit rule should map to a business purpose, with an owner and a review date.
- Common finding, overly permissive rules: Legacy any-any rules kept after a project ended, or aliases that grew beyond their original purpose.
- Logging of rule matches: Evidence that denied and permitted traffic is logged and reviewed in some form.
- Sample testing: The assessor may pick a service, attempt the connection from an unexpected source and check whether the rule blocks it.
Before the assessment, run a rule review that removes unused rules and records the justification for every remaining broad rule.
Point 6.7.2 requires control of remote access, including access by service providers, and allows supplier connections only after an authorization request and for a set period, such as the length of a maintenance operation. The assessor tests whether each remote path is known, whether it is authorized, and whether it closes when the work ends. Standing vendor access is the finding assessors look for first.
- Connection register: A list of all remote and supplier paths, including VPNs, jump hosts, vendor tunnels and cloud console access, with the owning party.
- Authorization records: Requests, approvals and the approved time window for each supplier session.
- Device restrictions: Evidence that access is allowed only from authorized devices where this is appropriate.
- Common finding, standing vendor access: Tunnels left open after a project, or accounts that remain active with no end date.
- Closure evidence: Logs or tickets showing the connection was disabled at the end of the window.
Before the assessment, sample recent supplier sessions and confirm that each has a request, an approval and a recorded closure.
Point 6.7.2 asks entities to deactivate unneeded connections and services. The assessor checks that listening services, open ports and unused connections have been reviewed and turned off, and that devices which cannot receive security patches are identified and handled. Scans and configuration exports are the usual evidence.
- Service baseline: A documented list of services each system needs, compared with what a port scan or host inventory shows.
- Unsupported devices: A list of network devices that cannot receive security patches, which ENISA's guidance names as evidence, with compensating controls such as isolation.
- Common finding, unneeded management services: Web administration interfaces, legacy protocols or default ports left enabled on appliances.
- Scan evidence: Internal scan results compared against the baseline, with exceptions recorded.
- Retirement records: Evidence that decommissioned connections were removed from firewalls and routing, not only from documents.
Before the assessment, scan the internal network against the service baseline and document each exception with an owner and a date.
The last part of point 6.7 asks for implementation plans for the transition to the latest generation of network layer protocols and for modern email security standards, and for best practices in DNS security and internet routing security. Assessors look for dated, owned plans with progress against them, not statements of intent. Plans are often the weakest evidence in this area.
- Plan documents: Written plans for network layer protocol transition and email security, with scope, owners, milestones and status.
- Email records: Current configuration of the sending domain's authentication and policy records, checked from outside the organization.
- DNS controls: Evidence of DNS resolver security practices and control over authoritative zones, including change control on records.
- Routing practices: Documented practices for internet routing security, such as route filtering and prefix monitoring, where the organization announces its own routes.
- Common finding, plans without progress: A plan dated years earlier with no milestones met and no revision.
Before the assessment, confirm the actual email and DNS configuration from outside the network and update each plan with current status.
How to implement network security controls step by step
This sequence turns point 6.7 from a set of network settings into a documented, reviewable state: an architecture baseline, a reduced ruleset, controlled supplier access, a list of devices that cannot be patched, and dated plans for newer protocols. Each step produces an artifact an assessor or supervisor can inspect.
Confirm the architecture baseline from discovered devices and flows
Start by building an accurate picture of what is actually connected. Network discovery, switch and router configuration exports, firewall rule exports and traffic flow records from sensors or firewall logs show which devices talk to each other, over which protocols and across which zones. The network or platform team owns this work, and an implementation partner can run the discovery and reconcile results with the asset inventory. The step is complete when every discovered device and observed flow is either matched to a known system or flagged for investigation. Ask your team to confirm whether any devices or links sit outside the existing inventory before moving on.
Document the network architecture
Turn the baseline into a comprehensible, up-to-date architecture document. It should show network zones, segments, the demilitarized zone, the administration network, links to third-party networks, and the location of firewalls and routers. Pair the diagrams with the current firewall and router rulesets and switch VLAN and ACL configurations, since ENISA's June 2025 guidance lists these as examples of evidence. The output is a versioned document with an owner, a review date and a change log, approved by the person accountable for network security. Confirm that a reviewer outside the team who drew the diagrams can trace a path from an internet entry point to a production system.
Reduce rulesets to what operations require
Compare each firewall and router rule against the documented flows from step one and the business reasons for them. Remove rules for services no longer in use, block communication that operations do not need, and deactivate unneeded connections and services on devices. Where the platform supports it, restrict remote access, including access by service providers, to specific authorized devices. A firewall such as OPNsense can group addresses into aliases and log each rule match, which helps the reviewer see which rules are actually hit. The output is a before and after ruleset with a documented justification for each retained rule, plus a record of removed rules and the change ticket that approved each removal.
Implement time-limited supplier access with an authorization workflow
Replace standing vendor access with a request-and-approval process. A supplier submits a request naming the system, the purpose and the period needed, such as the duration of a specific maintenance operation. The approver authorizes the access, the network team opens a time-limited path, and the session is logged and closed when the window ends. Monitoring tools such as Zeek, which records connection logs linked by a unique identifier, or Suricata's EVE output can show what the supplier connected to and for how long. The output is a sample set of completed requests showing approval, the defined access window, the logged session and the confirmed closure. Confirm with suppliers that their contracts accept this model before rollout.
Inventory devices that cannot receive security patches
List every network device that cannot receive security patches, such as end-of-support hardware, appliances whose vendor no longer publishes updates, or systems where patching would break a required function. For each one, record the model, firmware version, location, business owner, the compensating controls in place (segmentation, restricted access, monitoring) and the review date. This list feeds the patch management and vulnerability handling processes so that exceptions are documented rather than forgotten. The output is a register that is linked to the asset inventory and reviewed on a set cycle. Ask the vendor or the owner to confirm the support status in writing for each device.
Write dated plans for modern protocols, email security and DNS and routing security
Draft implementation plans covering the transition to latest-generation network layer protocols, the adoption of modern email security standards, and best practices for DNS security and internet routing security. Each plan should list the current state, the target state, the owner, the dependencies (such as device support for newer protocols or DNS resolver changes), and the milestones with dates set by the entity. Keep the plans in the same governance system as the architecture document so they are reviewed together. The output is a set of approved, dated plans with a status record that is updated at each review. Confirm which of these items your vendors support before setting dates, and avoid committing to targets that your current hardware cannot meet.
Which evidence satisfies point 6.7 and how to keep it current
ENISA's June 2025 guidance names concrete artifacts for network security, and supervisors will ask for them as they stand on the day of inspection. The cards below cover the core network records, the access and supplier authorization trail, and the implementation plans, along with how each one stays accurate between audits.
Up-to-date network diagrams
The architecture document required by point 6.7 needs diagrams that show every network zone, connection to third-party networks, the demilitarized zone and the administration network. Assign an owner to each diagram and tie updates to the change process so that a new firewall, VLAN or cloud peering link cannot go live without a matching diagram revision. Check the diagram against a live discovery scan or the asset inventory at least once per review cycle, and record the date and approver on the diagram itself.
Firewall and router rulesets
Rulesets show which traffic the entity blocks, which it allows and why, and they are the main proof that unneeded communication is stopped. Keep each rule tied to a business owner and a ticket reference, and remove rules that no longer have a purpose. Schedule exports of the active configuration to a protected repository, then compare each export to the previous one so that unapproved changes surface quickly. Firewall platforms such as OPNsense keep rules with aliases and per-rule logging, which helps reviewers trace a rule to its use.
Switch VLAN and ACL configurations
VLAN assignments and access control lists on switches and routers show whether the segmentation described in point 6.8 is enforced at layer 2 and layer 3, not just drawn on the diagram. Export these configurations on a schedule and store them with the diagrams so reviewers can match a VLAN to its zone. Confirm that production, development and test segments, and the separate administration network, appear as distinct VLANs with explicit ACLs between them. Ask your network vendor which export formats and audit logs the platform supports before you design the export job.
List of unpatchable network devices
ENISA lists a register of network devices that cannot receive security patches as evidence. Such devices, often older appliances, embedded controllers or unsupported firmware, need a named compensating control, such as isolation in a restricted segment or tighter ACLs, and a review date. Keep the list in the same repository as the diagrams so it is reviewed whenever the asset inventory changes. Cross-check each entry with the patch management exception record so the two documents agree.
Supplier access authorization records
Point 6.7.2(h) allows service provider connections only after an authorization request and only for a set period, such as the length of a maintenance window. Each record should state who requested access, the business reason, the systems reachable, the approver, the start and end times, and the evidence that the connection closed on schedule. Review the remote access logs against these records each month. Remote access gateways and session recording tools can produce much of this trail, but confirm that they capture supplier sessions separately from staff sessions.
Network security implementation plans
Point 6.7.2(j) to (l) requires implementation plans for the move to latest generation network layer protocols, for modern email security standards, and for DNS and routing security practices. These plans are documents, so they need a scope, named owners, dated milestones and a status that is updated at each review. Record where the entity stands today, which legacy protocols remain, and the risk accepted for any delay. Supervisors look for a plan that is current and followed, so schedule a periodic check of progress against the stated milestones.
How self-hosted tools produce network evidence
A self-hosted firewall, intrusion detection system and network metadata logger can each produce records that an assessor can read against point 6.7. The most direct of these is the rule export. OPNsense (BSD-2-Clause) is a stateful packet filter whose rules pass, block or reject traffic by source, destination, port and protocol, and its aliases group addresses so that the rule set stays readable. Exporting the ruleset and the log of rule matches gives evidence that unneeded communication is blocked and that service provider access is limited to the windows the entity authorized. Confirm in your own environment that the export format, log retention and per-rule logging meet what your assessor will ask to see.
Suricata and Zeek provide a different kind of evidence. Suricata's EVE output writes JSON records for alerts, flows and protocol transactions such as DNS, TLS and SSH, and it can split these into separate files for a log management tool. Zeek writes conn.log, which records who talked to whom, for how long, how much and over which protocol, along with dns.log and weird.log for anomalous events, all linked by a unique connection identifier. Together these show what was actually communicating on the network, which is useful when checking whether the documented architecture matches observed traffic. Confirm that your sensors see the segments you claim to monitor, because a log only proves what passed the sensor.
None of these tools write the network architecture document, decide which remote suppliers may connect, or set the policy that governs them. The entity owns those artifacts. The architecture document must be current and comprehensible, the authorization request for each service provider connection must be approved by a named person, and the policy must say which access is allowed and why. The tools supply the records that show those decisions were followed. A practical first step is to ask your implementation partner to map each tool output to a specific artifact, then to confirm with your security team which outputs they will rely on during an assessment.
What meeting point 6.7 costs in money and effort
This table breaks down the cost components of meeting point 6.7 on network security, showing who is paid, whether each cost is one-time or recurring, and what drives it up. Use it to structure a written scope and to compare quotes line by line. No prices or durations are stated because none are supplied, so each row names what to ask for instead.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives the cost |
|---|---|---|---|
| Architecture documentation | Internal staff time, plus an implementation partner if engaged to produce diagrams | One-time, then recurring upkeep | Number of sites, cloud accounts, zones and third-party links that must appear in the document |
| Ruleset cleanup and firewall review | Network engineers, or a partner preparing rule exports and change records | One-time, then recurring review | Age of existing rules, number of aliases and undocumented exceptions, and whether rules carry owners |
| Firewall, IDS and logging software | Open-source tools carry no license fee, but hosting, storage and staff time still apply | Recurring (hosting and operations) | Traffic volume, log retention period, number of sensors and whether logs feed a central tool |
| Supplier access workflow | Internal IT and service desk, sometimes a partner building the approval and time-limited access process | One-time setup, then recurring approvals | Number of service providers, frequency of maintenance windows and how many people approve requests |
| Device authorization controls | Internal endpoint or network teams | One-time setup, then recurring maintenance | Number of managed devices, device types and whether certificates or device registries already exist |
| Unpatchable device list | Internal asset and security owners | Recurring | Number of legacy or embedded devices and how often the list changes |
| Modern protocol and email transition plans | Internal architects and security leads, sometimes a partner drafting the plan | One-time plan, with recurring progress reviews | Breadth of legacy protocols in use and the number of mail domains and DNS zones |
| Evidence upkeep | Internal compliance and operations staff | Recurring | Frequency of configuration changes, number of evidence items and whether exports are automated |
| External testing or review | Independent testing firm or partner, paid per written scope | Recurring if repeated, one-time for a baseline | Scope size, number of segments tested and whether the review covers configuration or live testing |
| Assessor sampling | Independent auditor or assessor, paid by the organization | Recurring at each assessment cycle | Number of samples requested, depth of change history and how well evidence is indexed |
Who owns network security and who can help
The organization owns its network architecture, its risk decisions and its supplier relationships. Point 6.7 of the Annex to Implementing Regulation (EU) 2024/2690 expects a network architecture document that is comprehensible and kept up to date, and that document has to reflect decisions the organization actually made. Management, through the body accountable under Article 20 of NIS2, approves the risk acceptance for any exception, such as a device that cannot receive security patches. The network team decides which traffic is blocked, which remote access paths exist and which service provider connections are authorized, and it answers for them.
- Architecture document: Owns the network diagram, zone design and the rationale for each connection to the outside world.
- Risk acceptance: Management signs off on residual risk, including unpatchable devices and any exception to the segmentation or remote access rules.
- Supplier authorization: The network team approves each time-limited service provider connection, its duration and the work it covers.
- Rule ownership: Named staff own firewall and router rulesets, switch configurations and their change approvals.
- Operational follow-up: Staff review logs, respond to alerts and close out connections that are no longer needed.
Before engaging any partner, confirm that these owners are named in writing and that their decisions are recorded where a supervisor could request them.
An implementation partner such as DeployOpen can plan, build and document the network controls inside the organization's own infrastructure. Typical work includes setting up stateful packet filtering with reviewable rules, configuring intrusion detection and network logging, drafting diagrams, and assembling the configuration exports that show what is in force. The partner prepares the systems and the evidence, but the organization decides what the rules should say. Scope, deliverables and timelines are normally agreed in writing before work starts, so the handover is clear.
- Rulesets and aliases: Builds firewall rules and address groups from the approved architecture, with change history kept.
- Diagrams and inventories: Produces current network diagrams and device lists for review by the owners.
- Logging and monitoring: Configures tools such as Suricata and Zeek so that connection and alert records exist and can be retained.
- Evidence packs: Exports rulesets, VLAN and ACL configurations and access approvals in a form an assessor can read.
- Knowledge transfer: Trains internal staff so the organization can run and change the controls after handover.
Ask the partner to state in the scope which artifacts it will hand over and which decisions it will not make on the organization's behalf.
Testing and reporting belong to parties independent of both the organization and its implementation partner. NIS2 creates no certificate of compliance. National competent authorities supervise through inspections, security audits, security scans and information requests, and an organization may also commission an independent assessor for its own assurance or for a customer. Whoever tests the network must be able to reach the systems without relying on the partner's own summaries, and the partner cannot write or sign that conclusion.
- Authority supervision: National authorities test the network directly or request evidence under their powers in Articles 32 to 34.
- Independent assessment: An external assessor can test the rules, the diagrams and the logs against point 6.7 and report its findings.
- Partner limits: The implementation partner may explain its configuration and answer questions but does not issue audit reports or attestations.
- Retesting: Findings from tests feed back to the owners, who fix them and keep the record of closure.
- Independence: A tester that designed the same rules has a conflict and should not be the only check.
Confirm with the supervisor or assessor which evidence format and scope they expect before preparing anything.
Some network work is commonly delegated and some must stay with the organization. Building and maintaining rules, configuring monitoring and producing diagrams are routinely outsourced to a partner or managed provider. Deciding what the architecture is, accepting risk, authorizing supplier access and answering to a supervisor are not. Outsourcing does not move liability for the Article 21 measures away from the entity, so the contract should say who does what and how changes are approved.
- Typically outsourced: Ruleset builds, log pipeline setup, diagram drafting and periodic configuration reviews.
- Kept in-house: Architecture decisions, risk acceptance, supplier authorization and final sign-off on changes.
- Shared: Ongoing monitoring and alert triage, where the provider works within agreed escalation rules.
- Contract points: Access to configurations, evidence retention periods and the process for emergency changes.
- Exit terms: Ownership of configurations and documentation if the relationship ends.
Check that the partner's written scope lists each item above and names the internal role that accepts it.
Where organizations fall short on network security
Most network security gaps under point 6.7 are not missing products. They are documents and rules that drifted from the live network, and access that was granted once and never revisited. Each card names a gap an assessor is likely to find and the action that closes it.
Diagrams that no longer match the network
The architecture document must be comprehensible and up to date. Many organizations draw the network once for an audit and then let it drift as subnets, cloud accounts and firewall zones change. Check the diagram against the live configuration: routing tables, firewall interfaces and VLAN assignments. Assign an owner and tie diagram updates to change tickets so every new segment, gateway or peering link triggers a revision. ENISA's guidance expects up-to-date network diagrams as evidence, so a diagram dated before the last major change is a finding in itself.
Permissive any-to-any firewall rules
Rules that allow any source to reach any destination on any port defeat the requirement to block network communication that operations do not need. These rules often survive from commissioning, when someone opened traffic to get a project working. Export the active ruleset, sort it by source, destination and port, and flag every rule that lacks a documented business reason. Remove or narrow each one, and log rule matches on the boundary so that the remaining allowances can be reviewed against actual traffic. The closing action is a rule-by-rule justification that an owner signs.
Standing vendor VPN accounts
Service provider access is a common route into operational networks. A maintenance vendor with a VPN account that stays enabled year round holds access the business no longer needs. Point 6.7.2(h) allows provider connections only after an authorization request and for a set period, such as the length of a maintenance window. Inventory every vendor account, map it to a contract or ticket, and disable it by default. Require a request, a named approver, an end time and session logging for each connection. Ask the vendor to confirm who holds credentials on their side.
Unpatchable devices without a list
Some devices, such as legacy controllers, embedded appliances and medical or industrial equipment, cannot receive security patches. ENISA's guidance lists a register of these devices as evidence. Many organizations know these devices exist but keep no list, so an assessor cannot confirm that compensating controls exist. Build the register from the asset inventory, record the reason each device cannot be patched, and document isolation or monitoring measures for it. Review the list when the device is replaced or when vendor support ends.
Email and DNS standards without a plan
Point 6.7.2(j) to (l) asks for implementation plans for latest generation network layer protocols, modern email security standards and best practices for DNS security and routing security. Organizations often have partial answers: mail authentication configured for one domain, DNS resolvers left on defaults, or no route validation policy at all. Document the current state of each standard, the target state, the owner and the date of the next review. Confirm the specific standards with your own technical team and your ENISA-mapped evidence before you commit to them, because a plan that names standards the environment does not use will not pass review.
Flat networks that blur segmentation
Point 6.8 requires risk-based segmentation, a demilitarized zone, a separate administration network and separation of production from development and test systems. A flat network, where a workstation, a vendor laptop and a production server share one broadcast domain, fails that test even if the firewall has rules. Map each zone against the risk assessment, confirm that administration traffic travels on its own network, and confirm that test copies of production data do not reach production segments. An assessor will check the VLAN and ACL configuration against the diagram, so the two must agree.
Questions buyers ask about IR 2024/2690 6.7
How much effort does meeting point 6.7 take, and what drives it?
Effort depends mostly on how well the network is already documented and how many connections, zones and remote paths exist. No fixed effort figure is supplied for this work, so ask for one in a written scope. The main drivers are the number of firewalls, routers and switches to review, the count of third-party and remote access paths, whether a current architecture diagram exists, and how many devices cannot receive security patches. Costs fall into two groups. One-time work covers the baseline architecture document, rule and VLAN reviews, and removing unneeded services. Recurring work covers rule changes, supplier access approvals and periodic reviews. A quote should separate these and state which items the client's staff must supply, such as device access and change records.
How long does preparation for point 6.7 usually take?
The duration depends on the size of the network, the state of its documentation and how quickly the client can approve changes. No duration is supplied for this work, so confirm a timeline in the written scope rather than relying on general estimates. Preparation usually moves faster when current diagrams, firewall and router rulesets, and a device inventory already exist. It slows down when remote access runs through undocumented tools, when service provider connections lack owners, or when change windows are scarce in production. Ask for milestones tied to evidence: a verified architecture document, a reviewed ruleset, a tested remote access path and an approved list of supplier connections.
What must our team provide before work starts?
Your team must provide access, authority and accurate source material. The core inputs are the current network topology, device lists, firewall and router configurations, VLAN and access control lists, remote access methods, and a list of every service provider that connects to your systems. Your team also needs to name owners for each connection and approve changes to production rules. Decisions that belong to the organization include which traffic is needed for operations, which supplier connections are authorized, and which devices are exempt from patching with a documented reason. An implementation partner can prepare configurations and records, but management keeps ownership of these decisions.
Can our internal team handle point 6.7 without an outside partner?
Yes, an internal team can do this work if it has the network skills, time and authority to change production systems. Many organizations keep the architecture document, the ruleset review and the supplier access process in-house and bring in help only for specific gaps. The decision depends on whether staff can produce evidence consistently, not just configure devices once. Check whether your team can maintain up-to-date diagrams, review rule changes against documented needs, and run time-limited access for suppliers. If one of these areas is weak, an outside partner can fill it under a fixed scope while your staff keep ownership of the network and its decisions.
Can an implementation partner issue the compliance evidence for point 6.7?
No. An implementation partner prepares the network, configurations and records, but only the national competent authority or an independent assessor can judge compliance. NIS2 does not create a certificate of compliance. Authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. The evidence you present, such as an architecture document, firewall rulesets, VLAN and ACL configurations and a list of unpatchable devices, is your organization's own record. Confirm with your competent authority and any assessor you engage which formats and levels of detail they expect before you finalize the evidence set.
How does point 6.7 relate to point 6.8 on segmentation?
Point 6.7 covers how network access is controlled and documented, while point 6.8 covers how the network is divided into separate zones. The two work together. Point 6.7 asks you to block communication that operations do not need, control remote access, including by service providers, and keep an accurate architecture document. Point 6.8 requires risk-based segmentation, separation from third-party networks, a demilitarized zone, a separate administration network and separation of production from development and test systems. Segments define the boundaries, and the 6.7 rulesets enforce what crosses them. Evidence for one usually supports the other, so plan the architecture document, diagrams and rulesets together.
Which open-source tools can produce network evidence for point 6.7?
Several self-hosted open-source tools can produce records that support point 6.7, but none of them makes the organization compliant on its own. OPNsense is a stateful packet filter whose rules pass, block or reject traffic by source, destination, port and protocol, and it can log each rule match for review. Suricata writes EVE JSON records for alerts, flows and protocol transactions such as DNS and TLS, which can be split into separate files for log management tools. Zeek writes conn.log, dns.log and other logs linked by a unique connection identifier, which helps show who communicated and over which protocol. Confirm with each vendor how logs are retained and protected in your environment before you rely on them as evidence.
How DeployOpen scopes and prepares network security evidence
DeployOpen works on IR 2024/2690 6.7 Network security as a fixed-scope engagement inside your own infrastructure. We prepare the network architecture document, access controls and supplier connection records that an assessor or national authority would ask to see, while your organization keeps ownership of its controls and decisions.
How we scope
- Agree in writing which network segments, firewalls, routers and remote access paths fall under the engagement.
- Inventory the service provider connections that need authorization requests and time-limited access windows.
- Define which deliverables, such as diagrams, rulesets and device lists, will be produced and handed over.
How we build
- Configure default-deny firewall rules and aliases in your own environment, including logging of each rule match.
- Deploy network monitoring sensors where the agreed scope requires them, with protocol logs linked for review.
- Document remote access controls, including device authorization rules for administrative and supplier sessions.
How we hand over
- Deliver an up-to-date network architecture document with diagrams that match the running configuration.
- Export firewall rulesets, switch VLAN and ACL configurations, and the list of devices that cannot receive security patches.
- Provide a written record of supplier connection approvals and the implementation plan items you asked us to cover.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Re-verify rulesets and diagrams when your network changes so the evidence stays current.
- Confirm with your auditor or competent authority which evidence formats they accept before the work closes.
