Safeguard 13.8 Network intrusion prevention

What CIS Safeguard 13.8 network intrusion prevention asks for

Safeguard 13.8 asks the enterprise to deploy a network intrusion prevention solution where appropriate, such as a Network Intrusion Prevention System (NIPS) or an equivalent cloud service provider service. It is an Implementation Group 3 Safeguard only, so it applies to enterprises with security specialists and regulated or sensitive assets facing sophisticated, targeted attacks. In v8.1 it sits in the Network asset class under the Protect security function. It is the prevention step that follows Safeguard 13.3, which asks for network intrusion detection. Detection reports matching traffic to people who then respond. Prevention is expected to act on that traffic at the boundary, dropping or blocking it as it crosses.

The risk is known attack traffic crossing network boundaries, such as exploit attempts, command and control callbacks and scanning, reaching assets that could have been protected automatically. The phrase "where appropriate" leaves the organization to decide which boundaries need prevention and to record why the others do not. An assessor will expect a documented rationale, not an assumption that every link needs inline blocking. Expect questions about internet egress, partner connections, data center perimeters and cloud virtual networks, and whether the decision reflects the data each boundary carries.

The work is usually harder than the product choice. Many organizations cannot show their network boundaries because diagrams and asset records are out of date, so prevention cannot be shown to cover them. Cloud and SaaS traffic often bypasses the data center path where a appliance sits, which leaves gaps the Coverage metric will expose. Finally, many intrusion prevention deployments run in detect mode for long periods, with alerts never tuned into blocking rules. Confirm your own boundary inventory first and compare it with the Navigator's mappings to NIST SP 800-53 Rev. 5 AC-4(4), SI-4 and SI-4(4), ISO/IEC 27001:2022 Annex A 8.8, SOC 2 CC6.6 and CC7.2, and PCI DSS v4.0 6.4.2, 11.5.1 and 12.10.5 before you rely on any of them.

Which network boundaries and teams fall under Safeguard 13.8 network intrusion prevention

Safeguard 13.8 is measured as coverage of the network boundaries you define, so the scope decision drives most of the work. The cards below cover the boundaries to list, the prerequisite records, the managed versus self-hosted choice, the teams that change the boundary, and the third parties that operate part of it.

Internet edge and perimeter ingress

Start with the boundaries where traffic enters or leaves the organization over the internet. Include every public address range, load balancer, firewall and gateway that accepts inbound connections, and every egress path to the internet. Because the assessment measures coverage against the boundaries you define, an unlisted internet edge is a gap an assessor will find. Confirm the list against routing tables and public DNS records, not only the firewall policy.

Data center and cloud VPC ingress

Internal and cloud network boundaries need the same treatment as the internet edge. List each data center core, each cloud VPC or VNet, and the ingress and egress points between them. Teams often protect the public edge and leave east-west or cloud-to-cloud paths uninspected. Record each boundary with its owner and the sensors or cloud services that cover it, so coverage can be calculated from that list.

Partner, VPN and remote access links

Partner connections, site-to-site VPNs and remote access concentrators carry traffic from networks you do not fully control. Treat each tunnel termination point as a boundary and decide whether it is in scope. Document the decision even when the answer is no, with the reason and the compensating control. Assessors ask why a link was excluded, and an undocumented exclusion looks like an oversight.

Asset inventory and architecture diagrams

The assessment lists Safeguard 1.1 (detailed enterprise asset inventory) and Safeguard 12.4 (architecture diagrams) as prerequisites for measuring 13.8. Without them, you cannot prove which boundaries exist or which hosts sit behind them. Use the inventory to confirm that every boundary device appears in it, and use the diagrams to show where traffic crosses each boundary. Confirm that both records are current before you calculate coverage.

Managed cloud services versus self-hosted sensors

A cloud provider's managed intrusion prevention service and a self-hosted sensor can both satisfy 13.8 where appropriate. Decide per boundary which one covers it, and record the choice with the reason, such as the traffic type or the logging the team needs. Ask a managed provider which boundaries its service inspects and whether it prevents or only alerts. For self-hosted options, confirm that the sensor can block traffic in the configuration you deploy.

Owners of firewall and routing changes

Intrusion prevention only works when the teams that change firewall rules, routing and tunnel configuration know it is in place. Name the owner of each boundary, the change process that alters it, and the team that tunes signatures and responds to blocked traffic. A change that reroutes traffic around a sensor can silently drop coverage. Include the owners in the scope document so each boundary has one accountable team.

How an assessor tests network intrusion prevention coverage

This table walks through the checks an assessor typically runs against Safeguard 13.8, from confirming the boundary list against the asset inventory and architecture diagrams to verifying that sensors block traffic. Read it as a sequence: the coverage score is only as reliable as the boundary list that feeds it.

Test step	What the assessor checks	Evidence requested	Common findings
Prerequisite check against 1.1	Whether the enterprise asset inventory covers the devices that sit behind each network boundary	Current asset inventory export, with network location for each device	Inventory omits cloud workloads, branch devices or segments added outside change control
Prerequisite check against 12.4	Whether the architecture diagrams show every network boundary, internet edge, and internal trust zone the organization relies on	Dated architecture diagrams, with boundaries and zones labeled	Diagrams are out of date or show only the perimeter, leaving cloud and partner links undocumented
Boundary list reconciliation	Whether the organization's list of network boundaries matches the inventory and diagrams, with no boundary missing	Boundary register that cross-references the inventory and diagram identifiers	Incomplete boundary list, which is the most common finding because the Coverage score is calculated from it
Coverage calculation	The share of listed network boundaries that have a network intrusion prevention solution in place	Mapping of each boundary to the sensor or cloud service protecting it, with the numerator and denominator	Boundaries counted as covered when the sensor is only deployed on a subset of traffic or links
Sensor placement check	Whether each covered boundary sees the traffic that crosses it, including encrypted and east-west paths where they are in scope	Sensor placement records, network diagrams showing tap or inline points, and interface configuration	Sensors sit on a mirror or a monitoring port that misses some flows, so prevention never sees them
Prevention mode check	Whether the sensors are configured to block or drop matching traffic, not only to alert	Configuration export showing the action set for enabled rules, plus sample blocked events	Sensors run in detection mode on every boundary, so 13.8 is met only in name and 13.3 is what is actually in place
Rule currency and tuning	Whether the signature or threat feeds are updated on a documented schedule and whether blocking rules have been reviewed for false positives	Update logs, rule set versions, and records of tuning decisions	Feeds are enabled but stale, or blocking is disabled after an outage and never re-enabled
Alert and block review	Whether blocked events reach the monitoring process and are reviewed by people who can act on them	Sample of block events forwarded to the central alerting platform, with review tickets	Block events are logged locally but never forwarded or reviewed

How to deploy network intrusion prevention across boundaries

This sequence moves Safeguard 13.8 from an inventory of network boundaries to a prevention deployment that is tuned, monitored and measured with the Coverage metric the CIS assessment specification uses.

Confirm asset inventory and architecture diagrams
Before choosing any product, the network, security and platform teams confirm that the detailed enterprise asset inventory (Safeguard 1.1) and the architecture diagrams (Safeguard 12.4) are current. The assessment specification lists both as prerequisites for measuring 13.8, and a boundary missing from these records is easy to miss later. The output is a signed-off inventory extract and diagram set, with a named owner and a last-reviewed date for each.
Define and record network boundaries in scope
Using the architecture diagrams, the team lists every network boundary where traffic enters or leaves a trust zone, including internet edges, cloud virtual network perimeters, partner connections, and links between data center segments. Each boundary receives an identifier, an owner, the assets behind it and a note on whether it is in scope for prevention. The output is a boundary register. Its total count becomes the denominator for the Coverage metric, so the register should be approved by the people who own those networks.
Choose a NIPS or cloud service per boundary
For each boundary in the register, the team selects an appropriate network intrusion prevention solution. The options include a dedicated NIPS appliance, an open-source engine such as Suricata running on a firewall platform, or an equivalent cloud provider service for cloud boundaries. The selection records the throughput needs, encrypted traffic handling, logging format and the team that operates it. Ask each vendor or platform owner to confirm in writing which detection and blocking capabilities the product actually provides, because capabilities differ by product and license tier. The output is a decision record per boundary.
Deploy in detection mode to baseline noise
The chosen solution is installed on each in-scope boundary with alerting enabled but blocking disabled. Running in detection mode lets the team see which rules fire on legitimate traffic, such as scanners, backup jobs and business applications, before any traffic is dropped. The team records the rulesets loaded, the interfaces monitored and the placement relative to firewalls and NAT. The output is a deployment record for each boundary showing the mode, version and sensor placement, plus a baseline of alert volume and false positive candidates.
Tune rules and enable blocking by category
Working from the baseline, the security engineers suppress or adjust rules that are proven false positives and document why each change was made. They then enable blocking only for rule categories the organization has approved, starting with those that have low false positive rates and clear business risk, and keep others in alert mode. Each change needs an approver who is not the person making it. The output is a tuning change log that lists rule identifiers, the reason, the approver and the date, which an assessor can follow from baseline to enforcement.
Route alerts and logs to the central platform
The solution's alerts and event records are sent to the central alerting and log platform used for Safeguard 13.1 and Control 8. Where the engine supports it, the team configures structured output, such as Suricata's EVE JSON, and splits record types into the streams the log tools need. The team then tests the path by generating a known benign alert and confirming it appears, with the expected fields, in the central platform. The output is a test record showing end-to-end delivery and the list of log sources connected.
Document the coverage calculation
The team calculates the Coverage metric the assessment specification uses for 13.8: the share of network boundaries in the register that have a network intrusion prevention solution in enforcement or approved state. The calculation is repeated on a set schedule and whenever the boundary register changes, with any boundary that is out of scope or excluded carrying a documented reason. The output is a coverage report that shows numerator, denominator, date, exceptions and the owner who signed it off, which is the evidence an independent assessor will ask to see.

Evidence that passes a network intrusion prevention review

An assessor testing Safeguard 13.8 will follow the chain from the network boundaries you claim to cover, through the sensors enforcing prevention, to the blocked events those sensors produced. Each artifact below supports one link in that chain, and each needs a refresh routine so it still matches the environment on the day of the audit.

Boundary register with coverage calculation

This register lists every network boundary in scope and marks which ones have a network intrusion prevention solution in front of them. The Coverage metric in the CIS Controls Assessment Specification is the share of boundaries covered, so the register must give the numerator and denominator explicitly. Keep it current by updating it in the same change ticket that adds or removes a firewall, routed segment or cloud VPC. Check that the asset inventory from Safeguard 1.1 agrees with the boundary list.

Architecture diagrams tied to boundaries

The assessment specification names the architecture diagram from Safeguard 12.4 as a prerequisite, so an assessor will check that each boundary in the register appears on a diagram and that the sensor sits where the diagram says it does. Diagrams that show the sensor on the wrong side of a NAT or outside a critical egress path undermine the coverage claim. Regenerate or review the diagram whenever routing or firewall policy changes, and date each revision.

Configuration exports showing prevention mode

Detection and prevention can run side by side on the same sensor, so an assessor needs evidence that each sensor in the register is actually dropping traffic, not only alerting. Export the running configuration from each device, such as the IPS settings in OPNsense or the equivalent cloud service policy, and confirm the action is set to block for the rule categories you rely on. Schedule these exports and store them with timestamps, so the file from the audit period is available on request.

Enabled rule sets and their change history

Assessors ask which rule sets are active, who chose them, and how changes were approved. Record the enabled rulesets, such as the Emerging Threats and Abuse.ch sets in OPNsense, along with the version or update date of each. Keep a change log that ties each ruleset addition, disablement or suppression to a reason and an approver. Disabled rules without a documented reason are a common finding, so make the log the single place where those decisions are recorded.

Blocked event samples with central alerts

Assessors look for proof that prevention produces results that reach the central platform. Pull a sample of blocked events from the sensor, then show the matching alerts in the SIEM or log platform that Safeguard 13.1 requires. If you forward Suricata EVE JSON, confirm that drop and alert records arrive with the source, destination, signature and action fields intact. Take the samples across the audit period rather than from a single day, and keep the query used to produce each sample.

Tuning review cadence and decisions

Prevention rules that block legitimate business traffic get disabled quickly, so assessors expect a scheduled review of tuning decisions. Document the review frequency, the people attending, and the outcome of each review, including rules tightened, suppressed or left alone with a reason. Connect these reviews to the alert threshold tuning in Safeguard 13.11, which carries its own fixed review frequency at IG3. Retain the minutes and the tuning changes so each review can be traced to a specific rule or threshold.

Which open-source tools can produce network intrusion prevention evidence

OPNsense is the most direct open-source option for producing evidence against Safeguard 13.8, because its built-in intrusion detection and prevention system runs Suricata and can be set to alert on or block matching traffic. The rulesets named in the supplied documentation include Emerging Threats and Abuse.ch, and the platform can send alerts to syslog in EVE JSON format. For an assessor, the evidence to collect is the configuration that shows which interfaces the IPS is enabled on, the action set for each ruleset (alert or drop), and a dated record of blocked events. Confirm with the OPNsense project, in its current release documentation, which interfaces and virtual segments the IPS can inspect in your deployment, since coverage is what the Coverage metric measures. OPNsense is published under the BSD-2-Clause license, which your legal team should confirm against the version you deploy.

Suricata's EVE output is the record set that turns a running IPS into something an assessor can sample. The EVE JSON file can carry rule match alerts, anomalies, flow records, protocol transactions for HTTP, DNS, TLS, SSH and SMB, file information, dropped packet records and engine statistics. Those records can be split into separate files, so alert events can go to your SIEM or log analytics platform while flow and protocol records go to a retention store. Map the alert and dropped-packet records to the prevention actions you claim, and keep engine statistics to show the sensor was running during the review period. Suricata is licensed under GPL-2.0-only, so confirm with counsel what that license means if you modify or redistribute the engine, and check the current EVE field definitions in the project documentation before you build parsing rules around them.

Coraza is an Apache-2.0 web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, with integrations for Caddy, HAProxy, Traefik and Nginx. It is useful for blocking attacks such as SQL injection, cross-site scripting and code injection on HTTP application traffic, but it sits at specific application entry points. It does not, by itself, show that every network boundary is covered by an intrusion prevention solution, so do not cite it as the evidence for the Coverage metric. Use it as a complement to a network-level IPS and document where it sits in your architecture. Before adoption, confirm the Apache-2.0 terms, the supported integrations and the current rule set compatibility with the Coraza project, and verify each platform's current capabilities against its own documentation rather than relying on this summary.

What meeting Safeguard 13.8 network intrusion prevention costs

This table compares the cost components of meeting Safeguard 13.8, showing who is paid for each, whether it is one-time or recurring, what drives it up and how to keep it down. Read it as a checklist for a quote: each row should map to a written list of network boundaries. The main takeaway is that open-source sensors can remove license spend, but tuning, evidence upkeep and validation testing still carry recurring effort.

Cost component	One-time or recurring	What drives it	How to keep it down
NIPS or cloud provider service licensing and subscriptions	Recurring (subscription or support renewal); a one-time purchase is possible for some appliances	Number of network boundaries covered, throughput, and whether support and threat intelligence feeds are included	Cover only the boundaries in the written list, confirm feed and support terms, and compare open-source sensors that carry no license fee but still need operating effort
Engineering time for deployment and boundary mapping	One-time, with periodic rework when the network changes	Quality of the asset inventory (1.1) and architecture diagrams (12.4), number of segments, and placement of sensors inline or out of band	Start from current inventory and diagrams, document each boundary once, and reuse the boundary list in later reviews
Rule tuning and false-positive review	Recurring	Volume of alerts, custom rules, the number of business applications with unusual traffic, and how often rulesets update	Limit enabled rulesets to those that match the environment, record each suppression with a reason, and schedule regular review rather than ad hoc changes
Evidence upkeep	Recurring	Number of boundaries to evidence each review period, export and retention requirements, and how many teams hold configuration records	Automate exports of configuration and alert logs, keep one owner for the coverage record, and store evidence in a single location
External testing that validates blocking	Recurring, usually per test cycle	Scope of boundaries tested, whether prevention is tested in production or a staging copy, and the depth of the test	Test the same boundary list each cycle, agree the rules of engagement in writing, and retest only the boundaries that changed
Auditor sampling time	Recurring at each assessment or audit	Number of boundaries sampled, the depth of evidence requested, and gaps found in earlier cycles	Prepare a coverage record that shows every boundary and its prevention status, so samples can be pulled quickly

Who owns network intrusion prevention, who can implement it and what the auditor checks

The organization owns Safeguard 13.8. Its security and network teams decide where network boundaries exist, which of them need intrusion prevention, and whether a given rule set may block traffic or should only alert for a period. Those decisions are accountable business and risk decisions, so they stay with the organization even when an outside partner does the technical work. The assessment specification also expects the organization to supply its asset inventory (Safeguard 1.1) and architecture diagrams (Safeguard 12.4), because the Coverage measure depends on knowing where the boundaries are.

Boundary decisions: Define which network boundaries are in scope and record why any boundary is excluded.
Blocking policy approval: Approve which signatures or categories may block traffic, and who signs off changes that could interrupt business services.
Source records: Maintain the asset inventory and architecture diagrams that the Coverage metric is measured against.
Evidence ownership: Keep alert records, change approvals and review notes, and be able to show them to an assessor on request.
Operational response: Staff the team that reviews blocked events and escalates them under the incident response process.

Check that a named owner signs the boundary list and the blocking policy, and that the owner can explain both to an assessor without the vendor present.

Where network intrusion prevention programs fall short

Most gaps in Safeguard 13.8 are not about the product. They come from boundaries nobody recorded, sensors that never left detection mode, and changes that cannot be traced. Each card below names one gap and a step the team can take this quarter to close it.

Boundaries missing from the register

Coverage in 13.8 is measured against network boundaries, so a boundary absent from the asset inventory and architecture diagrams cannot be counted as covered. Cloud workloads, SaaS egress paths and branch links are the usual omissions because they are created by teams outside the data center. Compare the inventory from Safeguard 1.1 and the diagrams from Safeguard 12.4 against cloud accounts, SaaS tenant settings and internet breakout points. Record every egress path you find, including those with no prevention in front of them.

Sensors left in detection mode

A sensor configured to alert without blocking can look like a working prevention control on a dashboard while stopping nothing. This often happens because an alert-only rollout was meant to be temporary and no one set an end date. Pull the running configuration from each sensor and list which rule sets are in alert mode and which are in drop mode. Assign an owner and a date to every boundary that is still in detection only, and record the reason if a boundary is intentionally left there.

Rules enabled without tuning

Enabling broad signature sets in blocking mode without tuning tends to block legitimate business traffic, such as internal scanners, backup jobs or API clients that resemble attack patterns. The first outage usually leads to a rollback that removes prevention from the boundary altogether. Start with alert-only runs on each boundary, review the top-firing signatures against known traffic, and suppress or adjust false positives before enabling blocking. Keep a written tuning baseline so a rollback does not become the default response.

Prevention changes without tickets

Rule changes, bypass entries and exceptions made on a prevention platform are security-relevant configuration changes. When they are made without a linked change record, an assessor cannot tell whether an exception was approved, who made it, or when it expires. Pull the last quarter of configuration changes from the sensor or firewall management console and match each one to a change ticket with an approver. Flag any change without a ticket for review, and add a rule to the change process that exceptions carry an expiry date.

Coverage claims without configuration evidence

Teams sometimes report that a boundary is covered on the basis of a diagram, a purchase order or a verbal assurance. An assessor measuring the Coverage metric will ask for the configuration that shows prevention is active on that boundary. Choose a sample of boundaries and export the sensor interface assignments, the enabled rule sets and the mode of each. Where the export does not show prevention on a boundary, correct the coverage figure before reporting it.

Stale inventory and diagrams

Safeguard 13.8 depends on Safeguards 1.1 and 12.4 being current. When the asset inventory lags behind new subnets, cloud VPCs or retired firewalls, the coverage calculation is built on an incomplete list. Compare the last inventory update and the date on the architecture diagrams with the most recent network change. Schedule a review of both documents against live network data, and name an owner who signs off after each significant change to the boundary design.

Questions buyers ask about Safeguard 13.8 network intrusion prevention

How much effort does it take to deploy a network intrusion prevention system at each boundary?

Effort depends on how many network boundaries the organization has and how much each one differs from the others. Each boundary needs a sensor or inline device, a placement decision, a rule set, a decision on which alerts may block traffic, and a feed of logs to the monitoring platform. The biggest drivers are the number of internet egress points, the volume of traffic each one carries, whether traffic is encrypted and needs inspection support, and whether the boundary sits in a cloud account, a data center or an air-gapped network. Ask any partner or vendor for a quote built from a written list of boundaries, traffic assumptions and blocking policy, not from a single headline figure. Rollout cost is largely one-time, while licensing, rule updates and tuning recur.

Does a cloud provider intrusion prevention service count as equivalent to a NIPS?

Safeguard 13.8 names a cloud service provider service as an example alongside a Network Intrusion Prevention System, so it can count, but the decision belongs to the assessor. The coverage metric measures the share of network boundaries covered by intrusion prevention solutions, so the question is whether the cloud service sits in front of every boundary in scope and can block traffic, not whether it carries a particular brand name. Document the service's placement, its blocking mode, its log export and any traffic it cannot inspect. Confirm with the assessor, before work starts, how they will count the cloud service in the coverage calculation and what evidence they expect.

Can our own team deploy network intrusion prevention without an outside partner?

Yes, if the team has the specialists that Implementation Group 3 assumes. IG3 is aimed at enterprises with dedicated security staff facing sophisticated, targeted threats, so the team needs people who can design boundary placement, write and test rules, handle false positives and run incident response from the blocking alerts. Teams without that depth often use an implementation partner to prepare the sensors, document the configuration and build the evidence, while keeping ownership of blocking decisions in-house. Under any model, the organization owns its controls. An implementation partner prepares systems and evidence, and only an independent assessor or certification body issues any report.

How long does intrusion prevention tuning take, and why does it never end?

Initial tuning usually runs in detection mode first so the team can see which rules fire on normal business traffic before any traffic is blocked. The length of that period depends on traffic volume, the number of applications and how many false positives appear. Tuning does not stop after go-live because the threat landscape changes, rule sets are updated, applications change and new services are added. Safeguard 13.11 requires alerting thresholds to be tuned at least monthly, and the same discipline should cover prevention rules. Plan for a recurring review cycle with a named owner, and ask any partner to state how tuning is scoped in the written agreement.

What does the team need in place before intrusion prevention can be measured?

The assessment specification lists Safeguard 1.1, a detailed enterprise asset inventory, and Safeguard 12.4, architecture diagrams, as prerequisites for measuring Safeguard 13.8. Without them, the organization cannot show which network boundaries exist. The team also needs a documented change control process so rule and mode changes are approved and recorded, and a named owner who makes blocking decisions and can explain a blocked business transaction at short notice. Confirm these prerequisites and the owner's authority in writing before deployment begins.

Do IG1 or IG2 organizations need network intrusion prevention?

Safeguard 13.8 is an IG3 Safeguard, so it is not part of the essential cyber hygiene set (IG1) or the additional set for organizations with more operational complexity (IG2). Confirm the implementation group that applies to your own scope, because it depends on your sensitivity profile, your security staffing and the threats you face. IG1 and IG2 organizations still benefit from network intrusion detection under Safeguard 13.3 and from centralized alerting. The CIS Controls do not replace any regulatory, compliance or authorization scheme, so a regulator, contract or assessor may require prevention even where the Safeguard does not apply to your implementation group.

How DeployOpen scopes and implements Safeguard 13.8 network intrusion prevention

DeployOpen works on Safeguard 13.8 as an implementation partner inside your own infrastructure. We prepare the prevention layer, its inputs and the evidence an assessor will ask for, while your organization keeps ownership of the control and its decisions. Only an independent auditor or certification body issues reports or certificates.

How we scope

Confirm which network boundaries exist and which ones need inline prevention, with the asset inventory and architecture diagrams as starting inputs.
Record the chosen platform, such as a NIPS or a cloud provider service, and the reasons it fits your boundaries.
Agree the written, fixed scope, deliverables and timeline before any work starts, with the coverage measure defined up front.

How we build

Deploy the prevention engine at each agreed boundary, for example OPNsense with its Suricata-based intrusion prevention, inside your cloud accounts, data centers or air-gapped networks.
Tune rulesets and block actions so legitimate business traffic is not disrupted, and test blocking behavior in a staging path first.
Route prevention alerts and EVE JSON output to your centralized logging so the detections feed Safeguards 13.1 and 13.6.

How we hand over

Document each boundary, the enforcement policy, the change process for rulesets and the owner for every block decision.
Produce coverage evidence showing which network boundaries are protected, mapped to the Coverage measure in the assessment specification.
Provide runbooks for reviewing blocked traffic, handling false positives and escalating events to your incident response process.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, so rulesets and platform versions stay current after handover.
Re-verify coverage when network boundaries change, such as new segments, cloud accounts or remote access paths.
Run security testing of the protected boundaries when your organization asks for it, and report findings for remediation.