What DORA network security requires and who proves it
A supervisor, customer or board now expects a financial entity to show its DORA network controls are in place. Article 13 of Delegated Regulation (EU) 2024/1774 requires networks segmented by criticality, classification and risk profile, all network connections and data flows documented, and a separate dedicated network for administering ICT assets. It also requires a yearly review of network architecture and security design, and firewall rules verified at least every 6 months for systems supporting critical or important functions. The entity owns these controls. An implementation partner such as DeployOpen can prepare the segmentation design, firewall configuration, rule-review records and architecture documentation inside the entity's own infrastructure, but the partner does not decide whether the entity is compliant. The competent authority for the entity, and any independent assessor the entity engages, judges compliance. DORA also sets no certification scheme, so there is no certificate to buy. Ask any provider who claims otherwise to show which body issues it.
The effort depends on the entity's size, the number of systems it runs, how many of them support critical or important functions, and how far its networks already separate. A small firm with a flat network faces a different workload than a bank with a legacy core and many interconnected payment flows. Confirm with your supervisor or your own risk assessment which systems fall in scope before pricing any work. The regulation's text on proportionality and the simplified regime, read alongside the RTS, is the natural starting point (EUR-Lex text of Delegated Regulation (EU) 2024/1774). In a written scope, ask the provider to name the deliverables: a connection and data-flow inventory, a segmentation diagram tied to criticality classes, the administration network design, the firewall rule register with review dates, and the signed architecture review record. Each deliverable should map to a specific Article 13 requirement so an assessor can trace evidence to obligation.
How to segment networks by criticality, classification and risk profile
This sequence turns an inventory of ICT assets into a set of network zones and a register of permitted flows between them, so that each zone reflects how critical its systems are and access is limited to what approved activities need.
Map ICT assets to critical or important functions
Start from the financial entity's list of critical or important functions and trace which ICT assets support each one, including applications, databases, middleware, interfaces, cloud workloads and the supporting identity and logging services. The ICT risk owner and the business function owner should sign off the mapping together, since the business view decides what a function depends on. The step is complete when every asset in the inventory is linked to at least one function or explicitly marked as supporting none, and each link can be traced back to the risk assessment.
Classify assets by criticality and data sensitivity
Assign each asset a criticality level based on the functions it supports and the impact of its loss or compromise, and a data classification based on the most sensitive information it stores or processes. Record the risk profile that comes out of the existing ICT risk assessment alongside both labels. Where an asset supports several functions, the highest criticality governs its placement. The output is a classified asset register that the network design can reference, and the check is that no asset is left without both labels.
Group assets into network zones
Combine assets with similar classification and risk profile, and similar trust requirements, into named network zones such as a zone for systems supporting critical functions, a zone for less critical internal services, a zone for user endpoints and a zone for externally facing services. Keep management interfaces out of production zones by design, since they are handled in the separate administration network. The zone map, showing each zone, its members and its purpose, is the first deliverable. It should be reviewed by the architecture owner before any rules are written.
Document all connections and data flows
Record every connection between zones and every data flow that crosses a zone boundary, including the protocol, port, direction, data classification, the business purpose, the owner and whether the flow is automated or interactive. Include flows to and from external parties, cloud services and ICT providers. Flows that cannot be justified by a documented purpose are flagged for removal rather than carried over. The flow register is complete when the network diagram and the register agree, and when the register can be used to answer which systems can reach a given asset.
Set allowed flows and default deny between zones
Translate each documented flow into a firewall rule that permits only that source, destination, port and protocol, and set a default deny for everything else between zones. Use address aliases or groups for systems that share a role so that rules stay readable. Where the design supports it, add automated isolation of an affected asset as a documented response option, in line with the risk-based network management structure that Article 9(4) describes. The output is a rule set that maps line by line to the flow register, with no rule lacking a documented purpose.
Limit access to approved activities
Apply the policy requirement that physical and logical access be restricted to what legitimate, approved activities require. In practice this means reviewing which users, service accounts and administrators can reach each zone, removing standing access that no approved activity needs, and tying each remaining access path to an owner and an approval record. The evidence is an access map by zone that the information security function can show to an assessor alongside the information security policy.
Confirm the design can sever connections
Test that the network can be cut or segmented quickly for a given zone or connection without taking down unrelated services. Record the procedure, the people authorized to run it and the systems that depend on each connection so that the cut does not create a hidden outage. The check is a tested runbook with a dated record of the test, which supports the requirement that the infrastructure be designed for instantaneous severance to limit contagion. Confirm with the internal audit or testing function how often the test should repeat.
Dedicated administration networks by environment
In an on-premises data center, the administration network is usually a separate segment that carries management interfaces for hypervisors, storage controllers, switches, firewalls and out-of-band consoles. Administrators reach it through a hardened jump host placed on the boundary between the corporate network and the admin segment. Article 13 of the RTS asks for a separate network used to administer ICT assets, so the design decisions are where the separation is enforced and who is allowed to cross it.
- Management interfaces on their own VLAN: Baseboard controllers, hypervisor management addresses and switch management ports sit in a segment with no default route to user networks.
- Jump host as the only entry point: Administrators authenticate to a bastion, and the firewall allows SSH or RDP to the admin segment only from the bastion address.
- Out-of-band recovery access: Console servers or a separate management switch keep recovery possible when production links fail.
- Firewall evidence: Rule exports and logged rule matches show that admin ports are reachable only from the bastion. Confirm with your firewall vendor which logging options are available for each rule.
Check the network diagram against the live firewall rules, then compare a sample of bastion session logs with the admin segment's documented membership.
In a cloud account, the network is largely virtual: virtual private clouds or networks, subnets, route tables, security groups and the provider's control plane. A dedicated administration network is typically a separate subnet or account reached through a bastion, a session gateway or a private endpoint, with privileged identities kept apart from workload accounts. The provider's control plane is not a network segment you operate, so the evidence focuses on who can reach it, from where, and under which conditions.
- Separate account for administration: Management tooling and privileged roles live in a dedicated account, which limits the blast radius from workload accounts.
- Private admin subnet: The bastion or session gateway sits in a subnet whose security group accepts admin traffic only from documented sources.
- Control plane access restrictions: Use conditional access, network restrictions or private connectivity for console and API access where the provider supports it. Confirm the exact options with the provider.
- Flow and configuration logs: Enable flow logs for admin subnets and keep configuration change logs under the entity's logging policy.
Export the security group and route table configuration for each admin subnet and reconcile it with the documented architecture and data flows.
Hybrid environments split administration across two control planes and the connection between them. The highest exposure usually sits on the VPN or dedicated link, because a compromise there can bridge the data center and cloud admin segments. The design has to cover both sides and the path, and the documented connections must show every route that carries administrative traffic.
- One identity plane with tiered accounts: Use a single directory with separate privileged accounts for on-premises and cloud administration, so that revoking one access path does not depend on the other.
- Narrow interconnect: Permit only named admin subnets across the VPN or private link, and advertise routes for those prefixes only.
- Consistent bastion policy: Apply the same session recording, inactivity timeout and approval settings on both sides of the connection.
- Ability to sever the link: Article 9(4) expects connections to be severable, so confirm how the link can be shut down quickly while leaving a recovery path for the admin network.
From a workload subnet, test that admin ports are refused across the link, then confirm that the bastion path still works and that both results are recorded.
An air-gapped network has no routed connection to the internet or to corporate networks. Its administration network is often a separate physical network with its own switches, jump station and controlled transfer process. Controls shift from firewall rules toward physical access, transfer procedures and offline evidence. Because patches and monitoring data still have to cross the boundary, the transfer process becomes a control that must be documented and reviewed.
- Separate hardware for administration: Admin switches and jump stations are dedicated to the admin network and are not shared with the production network.
- Controlled transfer point: Patches and logs enter and leave through a defined media or one-way transfer process, with each transfer logged and scanned before import. Confirm the transfer device options with the vendor.
- Local session control: Enforce inactivity locks and session termination on jump stations, as Article 13 requires for sessions.
- Offline evidence store: Keep signed configuration baselines, port maps and access logs in a location the network team controls, with copies that survive a site failure.
Walk the boundary in person, reconcile the cabling and port inventory with the architecture document, and review the transfer log for the same period.
What a six-monthly firewall rule check must show
Article 13 of Delegated Regulation (EU) 2024/1774 asks for firewall rules to be reviewed regularly and verified at least every six months for systems supporting critical or important functions. The cards below describe what that verification should leave behind, so an assessor can trace each rule from its business reason to its last check.
Rule inventory with named owners
Every firewall rule needs a record that names the team or person accountable for it, the interface it sits on, and the source, destination, port and protocol it matches. Check that the inventory covers every rule set in scope, including rules inherited from earlier projects and rules on virtual or cloud firewalls that sit alongside appliances. An owner who cannot be reached during a review is a finding in its own right, because nobody can confirm the rule is still needed. In OPNsense, aliases and rule descriptions can carry much of this information, but the entity must confirm its own export or documentation process meets this need.
Written justification for each rule
Each rule should state the business or technical purpose it serves and the system it protects, linked to a documented data flow. A rule that allows "any to any" or permits a broad subnet without a stated reason fails the basic test of showing why it exists. Reviewers should be able to trace a rule to the connection inventory required by the same article. Where a rule supports a critical or important function, record the justification at the level of detail an assessor would need to test it.
Removal of stale and overly broad rules
The six-monthly check should produce a visible outcome: rules that no longer match a live system, expired temporary exceptions, and rules wider than their justification require are either narrowed or removed. Keep a record of what was removed, when, and who approved it, because a clean rule set with no history of change can look as though the review never happened. Ask the platform team for hit counts or last-match data to identify rules that have not been used, and treat that data as an input to the decision rather than the decision itself.
Verification evidence dated within six months
The review needs its own dated record: who performed it, which rule sets were examined, what was found, and what was changed. The record should fall within the six-month interval the Article sets for critical or important systems, so the entity should keep a calendar and a sign-off that an assessor can match to the rule export. Confirm whether the verification is performed by an internal reviewer, an independent party or a combination, and document that choice in the security policy.
Linkage to the change process
Every rule added, changed or deleted between reviews should trace back to an approved change record. This connects the firewall review to the change management procedure, so that the review confirms the live rule set matches what was approved rather than reconstructing history from memory. Look for unapproved rules that appeared through emergency fixes and check that they were either formalized or removed during the review. Mismatches between the change log and the exported rule set are among the most common points an assessor will probe.
Logging of rule matches for review
Rules that block or allow traffic must be logged in a way that lets the reviewer see what the rule did. In OPNsense, each rule can be set to log its matches, and the live log view shows them, but retention, access controls and export still need to be configured and confirmed by the entity. The review should check that logging is enabled on rules in scope, that logs cover the period since the last review, and that log storage meets the entity's own retention decision. Confirm these capabilities against the platform version in use before relying on them as evidence.
How connections are severed and sessions ended under Article 9(4)
The core requirement here is that network connection infrastructure must be designed so it can be instantaneously severed or segmented to minimise and prevent contagion, especially between interconnected financial processes. This sits in the second subparagraph of Article 9(4) of DORA, and the RTS on ICT risk management ties it to a risk-based network structure that may include automated isolation of affected assets during a cyber-attack. For an assessor, the design question is simple: if a segment is compromised, can you cut its links to the rest of the estate in a controlled way without taking down the critical or important functions that depend on it? The answer should be visible in the architecture, in the firewall policy and in the runbook, not only in a policy statement.
Expect the assessor to ask for a tested isolation procedure and proof that it has been exercised. Practical evidence includes the documented steps for quarantining a segment or host, the firewall or VLAN changes that implement it, the roles authorised to trigger it, and records from exercises or real events showing when it was used and how long the cut took to take effect. If automated isolation is part of the design, ask the team to show the trigger logic, the affected asset list it produces and the rollback path. Confirm the exact isolation mechanisms your platform supports with its vendor and test them in your own environment rather than assuming them.
Article 13 of the RTS adds the session side: sessions must be terminated or locked after a period of inactivity. Check that inactivity timeouts are configured on firewall management interfaces, jump hosts, hypervisor consoles and administrative sessions into the dedicated administration network, and that the values are set by your own risk assessment and documented. Assessors commonly sample these settings and compare them with the configuration baseline. Record the chosen timeout values, the systems they apply to and the exceptions approved by the management body, so that the evidence matches what the network actually enforces.
What makes network readiness cost more or less
The cost of meeting the DORA network requirements depends less on the tools than on how many zones, connections and outside parties the network carries, and whether anyone owns the rules. Each driver below changes the design work, the documentation load and the staff time the entity must commit.
Number of network zones
Each zone needs a criticality classification, a stated purpose and documented boundary rules before it can be segmented. Ten zones create far more rules to design, test and review than three, and each additional zone adds to every six-monthly rule check. Ask how zones are classified and who approves a new one.
External connections and data flows
Every connection to a provider, bank partner or data feed must be documented, including direction, protocol, data carried and the systems supporting critical or important functions. Entities with many external links spend more time mapping flows before any segmentation work can start. Confirm the flow inventory exists before requesting a design quote.
Legacy flat networks
A flat network where production, office and administrative traffic share one broadcast domain forces the most change. Separating it means re-addressing systems, moving applications and proving that nothing critical breaks during cutover. Legacy systems that cannot be moved may need compensating controls, which should be recorded as risk decisions.
Third parties with network access
Vendors that log in remotely, maintain equipment or exchange data over site-to-site links add access paths that must be segmented, logged and reviewed. Each one also needs contractual terms covering how its access is granted and removed. The count of such parties often matters more than the count of internal systems.
Cloud versus on-premises
Cloud networks are defined in software through virtual networks, security groups and route tables, which can be exported and reviewed as code, but they also multiply accounts and subscriptions. On-premises networks depend on physical switches and firewalls that need hands-on access for changes and evidence. Ask whether the design will be managed as code and how the administration network is provided in each environment.
Documentation maturity and rule ownership
Architecture diagrams, a current asset inventory and named owners for each firewall rule turn the annual architecture review and six-monthly rule checks into routine work. Without them, the first review often reconstructs the network from scratch. Whatever the build partner delivers, the entity must staff rule ownership internally, because only its own people can approve business need for each rule.
From gap analysis to evidence an assessor can test
This sequence turns the Article 13 and Article 9(4) network requirements into a documented, segmented and tested network design, with the evidence a competent authority or internal auditor can sample. Each phase closes with a named output that feeds the next. Durations depend on scope and are set out in the written plan.
Scope network assets and critical functions
The organization confirms which ICT systems support critical or important functions, which networks host them, and which external parties connect to them. DeployOpen works through the asset inventory with the owners of each system, so the scope reflects how the business actually runs. The step closes with a scoped asset list and a named owner for each network segment. The organization approves that list before design starts, because every later decision depends on it.
Run gap analysis against Article 13 and Article 9(4)
DeployOpen compares the current network against each requirement of Article 13 of the RTS and the Article 9(4) expectations on policy, risk-based network management, automated isolation and access limits. The gap analysis records what exists, what is missing, and what evidence each gap would produce. The output is a written gap register with a proposed remediation for each item. The organization decides which gaps to close, accept or defer, and records that decision in its risk documentation.
Design zones and the dedicated administration network
Working from the scoped assets, DeployOpen proposes network zones grouped by criticality, classification and risk profile, with a separate network for administering ICT assets. The design also covers how a connection to an affected zone can be severed quickly, which is the Article 9(4) expectation on instantaneous severing and segmentation. The architecture is reviewed by the organization's network and security owners. It is accepted when each zone has a stated purpose, an owner and an approved set of permitted paths.
Implement segmentation and firewall policy
DeployOpen configures the firewalls, routing, and access paths for the agreed zones, then writes rules that allow only the flows the design approves. In OPNsense, for example, rules pass, block or reject traffic by source, destination, port and protocol, and aliases group addresses so each rule stays readable. Rule match logging is enabled for the rules that matter most. The step closes when a test run shows that approved flows work, blocked flows fail, and the rule set matches the approved design.
Document connections, data flows and rules
DeployOpen produces the documentation that shows every network connection and data flow, the purpose of each, its owner, and the firewall rule that permits it. Documentation also covers the administration network, how administrative sessions are authenticated and terminated after inactivity, and the information security policy that governs network access. The output is a versioned network register that matches the live configuration. The organization approves it, and it becomes the baseline for the architecture review.
Perform the first architecture and firewall review
The organization runs its first review of network architecture and security design, which Article 13 requires once a year. The same cycle includes a verification of firewall rules, which must be verified at least every six months for systems supporting critical or important functions. DeployOpen can prepare the rule export, the change history and a comparison against the register, but the organization's reviewers make and sign the findings. The closing output is a dated review record with each finding, its owner and its remediation status.
Hand over the evidence pack
DeployOpen assembles the evidence pack: the approved scope, gap register, design, network register, rule exports, test results, and the review record, indexed so an assessor can trace each Article 13 and Article 9(4) requirement to its artifact. The organization owns the pack and keeps it under its own change control. Handover is complete when the internal control owner confirms they can locate each item and explain it. Independent auditors and competent authorities decide what evidence is sufficient; DeployOpen does not issue any assessment or attestation.
Who owns, who builds and who judges network controls
The financial entity remains accountable for its network security under DORA, whatever help it brings in. Its management body approves the ICT risk framework, and the people responsible for ICT risk decide which network segments are critical, which connections are acceptable and which residual risks the business will carry. The organization also owns the review cycle, so the yearly architecture review and the six-monthly firewall rule verification must be signed off by named people who can explain what changed and why.
- Policy ownership: Maintain the documented information security policy and the network management rules that the RTS expects, and keep them current when the architecture changes.
- Criticality decisions: Decide which systems support critical or important functions, since that classification drives segmentation depth and verification frequency.
- Risk acceptance: Record who accepts each residual network risk, such as a rule that cannot yet be removed, and the date by which it will be reviewed.
- Approvals and sign-off: Approve network changes through the change process and sign the annual architecture review and each firewall verification report.
- Evidence custody: Store the documented data flows, rule reviews and severance test results where assessors can reach them.
Before any engagement starts, confirm that a named owner exists for each of these items, because a partner cannot approve its own design.
An implementation partner such as DeployOpen prepares the technical side of network controls inside the client's own infrastructure. The partner can design the segmentation model, configure the firewalls and administration network, document connections and data flows, and collect the evidence that the organization reviews. The partner works to the scope agreed in writing and hands the results to the client. It does not decide risk acceptance, does not approve its own changes and does not issue reports or certificates. Only an independent auditor, assessor or the relevant authority can do that.
- Network design: Propose zones by criticality, the dedicated administration network and the rules that connect them, for the client to approve.
- Configuration and hardening: Build the rules in the firewall platform, for example OPNsense aliases and rules, and record the reasons for each rule.
- Documentation: Produce the connection inventory, data flow diagrams and architecture description that the yearly review depends on.
- Verification workflow: Run the six-monthly rule checks, flag unused or overly broad rules and deliver findings to the client's owners.
- Severance support: Build and test the means to cut or isolate connections quickly and report the results.
Ask any partner to name the deliverables it will produce, the evidence format and who on the client side receives each one.
The competent authority for the financial entity supervises DORA compliance using its supervisory powers, and an independent assessor may test controls where the entity or the authority asks for it. Both examine evidence, test whether controls work as described and raise findings where they do not. The Regulation does not create a certification scheme for ICT network controls, so no body certifies that a network meets Article 13. The assessor's output is a finding or an opinion on the evidence, and that output belongs to the assessor, not to the organization or its partner.
- Examination of design: Compare the architecture document with the actual segmentation and ask whether it matches the criticality assessment.
- Testing of rules: Sample firewall rules and check them against documented business need and review records.
- Review of records: Read the annual architecture review and the six-monthly verification to confirm they happened on time and were signed by the right people.
- Findings: Report gaps to the entity, which then owns the remediation plan and timeline.
- Independence: Keep the assessor separate from the team that built the network, so the findings carry weight.
Before engaging an assessor, confirm which authority supervises your entity and what evidence format it expects.
Questions buyers ask about DORA network requirements
Does a microenterprise get a lighter network review under DORA?
Yes, in one respect. Article 13 of Delegated Regulation (EU) 2024/1774 requires the network architecture and security design to be reviewed once a year, but for microenterprises that review is periodic instead of annual. The rest of the network duties still apply in full: segmentation by criticality, documented connections and data flows, a dedicated administration network for managing ICT assets, and the ability to sever connections. Size changes how often you review and how much documentation you keep, not whether the requirement exists. Confirm with your competent authority how it reads your entity type, because the regime depends on how microenterprise status is defined for your organization.
Must every system sit on a dedicated admin network?
The rule is written as a requirement on the network estate, not as a rule for each individual system. Article 13 of the RTS requires a separate, dedicated network to be used for administering ICT assets. In practice, most organizations place management interfaces for servers, hypervisors, firewalls and identity systems on that network, and they decide case by case where a legacy or specialist system fits. Your risk assessment and network documentation should show which assets are administered from it, and why any exception is justified. Confirm with your auditor how they expect exceptions to be recorded.
How does the six-month firewall check differ from the yearly architecture review?
They test different things at different intervals. The yearly review covers the overall network architecture and security design. The firewall check is narrower: Article 13 of the RTS requires firewall rules to be reviewed regularly and verified at least every six months for systems supporting critical or important functions. Rule verification means confirming that each rule still matches a business need and that no unneeded access remains. Firewall rule sets change often, so the six-month check is where drift is caught. Keep dated records of each verification, since an assessor will ask for them. Confirm the exact scope of "critical or important functions" with your own function mapping.
Can a cloud provider take over the network security duties?
A cloud provider can run parts of the network stack for you, but the duties remain with your organization. Under DORA, the financial entity owns its ICT risk management, including segmentation, firewall reviews and the administration network. A provider's shared responsibility model describes what the provider operates, and your contract and exit plans should state that split clearly. You still need to document your own data flows, perform the reviews and be able to sever connections. Ask the provider for evidence you can present to an assessor, and confirm how it will support the six-month verification and any audit requests.
How much internal staff time does this work need?
The effort depends on how complete your current documentation is and how many networks, firewalls and connections you run. The main drivers are the size of the estate, whether connection and data flow diagrams already exist, how many firewall rules need reviewing, and how many systems support critical or important functions. One-time work includes building the network inventory, mapping flows and designing segments. Recurring work includes the yearly architecture review, the six-monthly rule verification and change records. Ask any partner for a written breakdown of which tasks need your architects, your security team and your system owners. No fixed duration is set by the regulation, so treat any estimate you receive as a planning figure to test.
Can an external partner handle the network work alone?
An external partner can prepare much of the work, but it cannot own the outcome or issue the assurance. DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, and can prepare segmentation designs, firewall configurations, documentation and evidence. Your organization must still approve the design, make the risk decisions, run the reviews and accept residual risk. Independent auditors and assessors, not implementation partners, examine the results and issue any reports. Agree the split of responsibilities in writing before work starts, so each review and approval has a named owner.
What to confirm before you commit budget
Before you approve budget for the network work, confirm which functions your organization treats as critical or important. Article 13 of Delegated Regulation (EU) 2024/1774 ties the six-month firewall verification to systems that support those functions, so the scope of the verification depends on this classification. Ask your compliance lead or the competent authority contact for your entity type whether they expect the classification to be documented in a specific format, and confirm who approves it. A quote built on an unclear list of functions will either miss systems or inflate the segmentation and testing work.
Next, confirm the state of your existing firewall platforms with the people who run them. Check whether each platform can log rule matches, whether logs can be exported for review, and whether it supports address aliases or object groups for grouping systems by criticality. For OPNsense, the rule logging option and the live log view are documented in the vendor manual, but you should verify the version in your environment and any custom plugins before assuming the same behavior. If a platform cannot produce rule-level evidence, the six-month check becomes a manual exercise, and that changes the effort in any proposal.
Finally, decide who signs the yearly review of network architecture and security design and who accepts it on behalf of the management body. Confirm whether the architecture owner is internal, whether an external party will review it, and how the sign-off is recorded in your ICT risk management documentation. Ask any implementation partner to state in writing which parts of the review they prepare and which parts your staff or an independent assessor must perform. DeployOpen prepares systems, diagrams and evidence, but the organization owns its controls and the approval of its architecture.
How DeployOpen prepares network controls and evidence for assessment
DeployOpen plans and implements self-hosted open-source network controls inside the client's own infrastructure, then documents them so the organization can show how segmentation, firewall rules and the administration network work. DeployOpen prepares systems and evidence; the organization owns its controls and independent assessors decide whether they meet the requirement.
How we scope
- Engagements are fixed-scope, with the network estate, environments and systems covered agreed in writing before work starts.
- The written scope lists network segments, the criticality of systems each segment hosts, and the connections to be documented.
- Scope names the firewall platforms, administration paths and external parties whose connections the review will cover.
How we build
- Segmentation is designed around criticality, classification and risk profile, with a dedicated administration network kept separate from business traffic.
- Firewall rules are built with aliases for address groups, named purposes, and logging enabled on rules that need review evidence.
- Connections that must be cut quickly are designed for instant severance or isolation, and the procedure for doing so is tested before handover.
How we hand over
- Documentation covers the network architecture, every documented connection and data flow, and the ownership of each rule.
- Evidence packs include rule exports, change records, the yearly architecture review record and the six-monthly firewall rule verification results.
- The organization receives a handover of the configuration, runbooks and open items, and the independent assessor decides what the evidence proves.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers for keeping rule sets and segmentation current.
- Retainers can cover the recurring six-monthly rule checks and the annual architecture review, so the evidence stays dated and complete.
- Before any assessment, confirm with DeployOpen which evidence the client's own risk assessment and the competent authority will expect.
