Safeguard 13.10 application layer filtering requirements

What application layer filtering under 13.10 asks an enterprise to do

Safeguard 13.10 asks an enterprise to filter traffic at the application layer, using a filtering proxy, an application layer firewall or a gateway, so that requests to its applications are inspected for malicious content before they reach the application. It is an IG3 safeguard, so it applies only once an enterprise has the security staff and the regulated, sensitive applications that CIS expects at that level. The organization owns this control. An implementation partner can build and document the filtering layer and collect its evidence, but the enterprise decides what is in scope, what the rules block, and who reviews the results. The CIS Controls also do not replace any regulatory scheme, so an assessor will test this safeguard against the enterprise's own risk picture and the frameworks that apply to it.

Segment filtering under 13.4 works at the network and transport layers, deciding which hosts and ports may talk to each other. That is necessary, but it cannot tell a legitimate login request from a crafted one sent to the same port. Application layer filtering closes that gap for web and API traffic. It targets attack classes such as SQL injection, cross-site scripting and code injection, which ride on allowed ports and look like ordinary requests at the packet level. A web application filter, for example a rule set following the OWASP Core Rule Set, is one way to address them, and the enterprise should confirm which attack classes its chosen product covers and how it handles encrypted traffic, since inspection often depends on where TLS is terminated. The hard part is usually scope and tuning rather than installation. A filter can only protect applications it knows about, so the detailed asset and software inventories in Safeguards 1.1 and 2.1, which the CIS Assessment Specification lists as prerequisites, must be complete first. Each application then needs its own rule baseline, and the rules need ongoing review, because false positives can break business transactions and loosened rules quietly remove protection. Before committing to a product, ask the vendor or implementation partner to confirm its rule compatibility, logging format and how its alerts feed the centralized alerting in 13.1 and the threshold reviews in 13.11.

Which applications, traffic paths and teams fall inside Safeguard 13.10

Safeguard 13.10 is scoped by which web and API applications sit behind a filtering point, not by the network diagram alone. The cards below cover the application inventory, the traffic paths that reach it, the asset classes and teams involved, and the inventories that decide whether the scope is complete.

Internet-facing web and API applications

Start with every application that accepts HTTP or HTTPS traffic from outside the organization, including public websites, customer portals, partner APIs and administrative consoles published to the internet. Each one is a candidate for a filtering proxy, application layer firewall or gateway. Check whether the filtering point sits in front of every public hostname, including test and legacy endpoints that teams sometimes forget to publish through the same path.

Internal applications and east-west paths

13.10 is not limited to the internet edge. Internal web services, admin tools and API calls between segments can carry the same injection and abuse risks. Decide which internal application paths cross a boundary worth filtering, such as a user segment reaching a sensitive application zone. Document those paths so the filtering point has a clear, reviewable role rather than an undefined one.

Asset classes: Network, Software and Devices

In v8.1, Safeguard 13.10 is assigned to the Network asset class, so the filtering devices and gateways are the primary in-scope assets. The applications behind them belong to the Software asset class, and any appliance or virtual host running the filter may fall under Devices. Confirm that each asset class has an owner for its part of the filtering chain, since a gap between network and software ownership is a common reason the scope looks complete on paper but is not.

Teams that own the filtering chain

Filtering rules touch network engineering, application owners, security operations and platform teams. Network teams usually own the proxy or gateway hosts, application teams know which paths and parameters are legitimate, and security teams own the rule set and the review of blocked requests. Write down who approves a rule change and who receives alerts from the filter, because an unowned rule set tends to drift from the applications it protects.

Asset and software inventories as prerequisites

The CIS assessment specification lists Safeguards 1.1 (detailed enterprise asset inventory) and 2.1 (software inventory) as prerequisites for measuring 13.10. If an application is missing from the software inventory, it will likely be missing from the filter too, so the scope is only as complete as those inventories. Reconcile the application list against DNS records, load balancer configurations and certificate records to catch hosts that bypass the filtering point.

Confirming IG3 applicability

Safeguard 13.10 sits in Implementation Group 3 only, one of the 23 safeguards reserved for IG3. Organizations below IG3 should confirm with their chosen Implementation Group whether the safeguard applies to them before building it into scope, and record that decision in the scope statement. Where it does not apply, the record should still explain how application traffic is otherwise protected, so an assessor can follow the reasoning.

How an assessor tests application layer filtering

The table sets out the assessment steps an assessor is likely to take for Safeguard 13.10, from confirming the application inventory to sampling rule-match logs. Read each row as a question the assessor will ask and the evidence you should have ready, and confirm the exact method with your assessor because the CIS Controls Assessment Specification defines what to measure, not how to test it.

Assessment area	What the assessor checks	Evidence to prepare	Where it usually fails
Application inventory	Confirms the application inventory that 13.10 depends on, drawing on the asset and software inventories in Safeguards 1.1 and 2.1 as prerequisites.	Current asset and software inventories, with internet-facing and business-critical web applications marked.	Inventory lists applications that have no owner, or omits applications hosted in cloud or on internal subnets.
In-scope application paths	Traces each in-scope application path from the user or external client to the server to confirm a filter sits in front of it.	Network and data flow diagrams, DNS records, load balancer and reverse proxy configuration for each application.	A secondary hostname, legacy port or direct IP route reaches the application without passing through the filter.
Filter placement and bypass	Tests whether traffic can reach the application server directly, outside the filtering proxy, firewall or gateway.	Firewall rules that restrict inbound access to the filter only, and results of a reachability test from outside the filter path.	Application servers accept traffic from any internal subnet, so a compromised internal host bypasses the filter.
Rule set review	Reviews the rule sets, signatures and configuration to confirm they cover the attack classes the organization has chosen to block.	Exported rule set with version, change history, and a record of the rule sets enabled for each application.	Rules were installed at a default setting and never tuned, or exclusions were added without a documented reason.
Detect-only mode	Checks whether the filter is blocking or only logging, and whether that choice was approved for each application.	Configuration showing the enforcement mode for each rule set, plus the approval record for any detect-only setting.	Rule sets were placed in detect-only mode during rollout and remained there with no review date.
Rule-match logs	Samples rule-match and block events to confirm they are recorded, retained and reach the central alerting platform from Safeguard 13.1.	Log samples for a sample period, log forwarding configuration, and retention settings.	Logs stay on the filter appliance, or they are sent to a destination nobody monitors.
Alert handling	Follows sampled alerts from the filter to a documented triage and response outcome.	Tickets or case records for sampled alerts, with the analyst decision and any rule change made afterward.	Alerts are generated but closed without investigation, or no ticket exists for a blocked attack.
Review and tuning records	Confirms that the rule sets are reviewed on a defined schedule and that changes are approved and traceable.	Review schedule, meeting or sign-off records, and change tickets for rule and exclusion changes.	No evidence of review after the initial deployment, or changes made directly on the device without a record.
Scope of the assessment	Confirms the assessment boundary matches the applications the organization declared in scope and the way the safeguard was applied.	Written scope statement signed by the owner, with any applications excluded and the reason for each exclusion.	Scope is narrower than the application inventory, and excluded applications carry sensitive data or public exposure.

Evidence that shows application layer filtering is operating

An assessor testing Safeguard 13.10 looks for proof that the filter exists, that it is configured as documented, and that it is the only way into the application. The cards below are artifacts that answer those questions, and most of them need to be refreshed on a schedule rather than assembled once before an audit.

In-scope application and route inventory

This is the list of every application, host name and route that the filter is supposed to protect, built from the asset inventory in Safeguard 1.1 and the software inventory in Safeguard 2.1, which the CIS assessment specification names as prerequisites for measuring 13.10. Keep it tied to owners and exposure, such as internet-facing, partner-facing or internal-only. Check it against DNS records and load balancer targets each month, because a new route that bypasses the filter is the most common gap. An application missing from this inventory is one an assessor can treat as unfiltered.

Configuration exports of the filtering proxy

Export the running configuration of the filtering proxy, application layer firewall or gateway on a fixed schedule and store it outside the device. For a Coraza-based deployment this means the web server or proxy directives that load the engine and rule files, and for an OPNsense perimeter it means the filter rules and aliases. Compare each export with the previous one to show no unreviewed change occurred. Confirm with your platform team which export format the chosen product supports and whether secrets are redacted.

Active rule set and version history

The assessor needs to see which rules were in force on a given date, not only the current ones. Keep the rule set in version control, with each change linked to a change ticket that names the requester, the reason and the approver. For Coraza, this means the OWASP Core Rule Set and any local rules, pinned to the versions you tested. Record the rule-set version alongside each production deployment so you can show what was active during any audit period.

Sample logs of blocked and allowed requests

Keep representative logs showing requests the filter blocked and requests it allowed, with timestamps, rule identifiers and the matched application. Blocked samples show the rules work. Allowed samples show that legitimate traffic still reaches the application and that exceptions are visible. Forward these logs to the SIEM from Safeguard 13.1 so that centralized alerting can correlate them with other events. Without that link, the log samples are harder to tie to an alert that someone reviewed.

Tuning and exception approval records

Filters generate false positives, and teams add exclusions to keep applications working. Each exclusion needs a record that states the rule, the request pattern, the business reason, the risk accepted, the approver and an expiry date. Review open exceptions at the same cadence as the alert threshold review in Safeguard 13.11. An exception without an owner or expiry date is a finding waiting to be written, so check the list for stale entries before each assessment.

Proof the filter is the only path

Show that the application cannot be reached except through the filter. Evidence includes firewall rules that allow inbound traffic only from the filter address, security group or network path, plus flow records from Safeguard 13.6 showing that no direct connections reached the application server. Test this by attempting a direct connection from outside the filter's path and saving the failed attempt. Keep a dated record of each test, because a single passing test does not show the path stayed closed between audits.

How to implement application layer filtering in six steps

This sequence moves application layer filtering from an inventory-based design to enforced rules that generate alerts, so the organization can show Safeguard 13.10 is designed, configured, tuned and monitored. Each step closes with a record that an assessor can inspect.

Confirm application and asset inventories
Start by checking that the enterprise asset inventory from Safeguard 1.1 and the software inventory from Safeguard 2.1 are current, because the Assessment Specification treats both as prerequisites for measuring 13.10. The network or platform team lists every application that accepts traffic from users, partners or the internet, and maps each one to its hosts, ports and network paths. The step is complete when every in-scope application has an owner and a documented traffic path that matches the inventories.
Select the filtering point for each path
For each application path, the architecture owner chooses where filtering happens: a filtering proxy, an application layer firewall or a gateway in front of the application. The choice depends on protocol, whether TLS is terminated at that point, and whether the application is web-based. The output is an approved architecture diagram that names the filter for each path, the segment it sits in and the traffic it inspects, signed off by the security and application owners.
Build a hardened configuration baseline
The platform engineering team deploys the chosen filter from a version-controlled configuration. For web traffic, an open-source option such as Coraza, which supports ModSecurity SecLang rulesets and the OWASP Core Rule Set, can run behind Caddy, HAProxy, Traefik or Nginx. Packet-level allow and deny rules for the path can be defined in OPNsense, which logs rule matches. Confirm the vendor or project documentation for each component's supported features before relying on them. The output is a configuration baseline with rule sets, exception placeholders and change history.
Deploy in detect mode
Enable the filter in a mode that logs matching requests without blocking them, so legitimate business traffic is not interrupted while rules are evaluated. The operations team routes these logs to a staging location and confirms that every in-scope application path produces entries. The step is complete when the team can show detection events for each path and a test request that the filter recorded as expected.
Tune rules against observed traffic
Review detect-mode logs against real application behavior, then disable or adjust rules that flag legitimate requests and keep those that match attack patterns for the application. Each change is recorded with the rule identifier, the reason, the approver and the date. Tuning ends with a short test plan that confirms known malicious payloads are still caught and normal workflows still pass. The output is a tuning record that an assessor can trace from each rule change to its justification.
Move to block mode with documented exceptions
Switch the tuned rules to block mode in a planned change window, starting with the paths that have the clearest evidence of good tuning. Each exception that must remain, such as a rule disabled for a specific API, is documented with its business reason, compensating control and review owner. The step is complete when block events are visible in the logs and the exception register is approved by the control owner.
Route filter logs into central alerting
Forward filter and firewall logs to the centralized alerting platform that Safeguard 13.1 describes, so blocked and suspicious requests feed correlation rules and responders see them. Alert thresholds for the filter are then reviewed on the schedule set under Safeguard 13.11. The step closes when a test event generates an alert that reaches the on-call queue, and the alert path, owner and review schedule are written into the Control 13 runbook.

Open-source tools that can support application layer filtering evidence

Two open-source components can generate evidence for Safeguard 13.10, but they sit at different layers. Coraza inspects HTTP application traffic, while OPNsense filters at the network and transport layer that supports 13.4. Confirm the scope of each tool before mapping it to the Safeguard.

Coraza web application firewall

Coraza is an Apache-2.0 web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It inspects HTTP requests and responses and can run alongside Caddy, HAProxy, Traefik or Nginx. For 13.10, the evidence is the rule set version, the deployed configuration and the block logs showing requests stopped at the application layer. Confirm which proxy integration your environment uses and who maintains the rule set.

OWASP Core Rule Set tuning

The OWASP Core Rule Set supplies detection rules for attacks such as SQL injection, cross-site scripting and code injection. Rules are only useful once they are tuned to the applications they protect, because false positives can break legitimate traffic and false negatives leave gaps. Keep a record of each rule exclusion, its owner and its justification, since an assessor will ask why a rule was disabled. Confirm the rule set release you run against the current OWASP publication.

OPNsense packet filter rules

OPNsense is a BSD-2-Clause stateful packet filter. Its rules pass, block or reject traffic by source, destination, port and protocol, and aliases group addresses so one rule can cover a set of hosts. Per-rule logging records each match for review in the live log view. This supports the segment-level filtering in 13.4, but it does not inspect application content, so confirm with the vendor whether any available add-on provides application inspection before citing it for 13.10.

Version and support status

Open-source licenses let you use the software without a license fee, but they do not provide vendor support, security patches on a schedule or assessor-ready documentation. Record the exact version of each tool, the date you last reviewed its security advisories and who on your team owns patching. Ask whether a commercial support contract or an internal support process covers each component before an assessor asks for it.

Evidence from the asset inventory

Safeguards 1.1 and 2.1 are prerequisites for measuring 13.10, so every proxy and firewall instance must appear in the asset inventory and every software component in the software inventory. Without those records, an assessor cannot confirm that all application entry points pass through the filter. Keep the inventory export, the list of protected applications and the proxy configuration together as one evidence set.

What meeting Safeguard 13.10 costs in money and effort

This table breaks the cost of meeting Safeguard 13.10 into its components, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. No prices are given here, so use the table to build the questions you put to a provider in a written, scope-based quote.

Cost component	One-time or recurring, and who is paid	What drives it up	How to keep it down
Filtering software or appliance licenses	Zero for self-hosted open-source tools such as Coraza or OPNsense. Optional vendor support or subscriptions are recurring and paid to the vendor.	Support tier chosen, number of appliances or nodes, and any commercial add-on modules you decide to buy.	Use open-source components where they meet your requirements, and price support only if your team cannot maintain them in-house.
Application inventory work	One-time to start, then recurring as applications change. Paid to your staff or a partner preparing the inventory.	Number of internet-facing and internal applications, shadow applications, and how often teams change hostnames or routes.	Build the inventory from Safeguards 1.1 and 2.1 once, and tie new application onboarding to a review step so it stays current.
Engineering time for deployment and rule tuning	One-time for initial deployment, then recurring for tuning. Paid to internal engineers or an implementation partner under a fixed scope.	Number of applications behind the filter, complexity of routing, and the volume of false positives from rule sets such as the OWASP Core Rule Set.	Start in detection-only mode, tune per application, and document each exception so later changes are small.
Rule tuning frequency	Recurring. Paid to the team that owns the rules, internal or external.	How often applications change, how often new threats prompt rule updates, and the review cadence you set.	Set a fixed review interval, track blocked and allowed events, and limit changes to reviewed, logged updates.
Evidence upkeep	Recurring. Paid to internal staff, or to a partner that keeps configuration exports and change records current.	Number of rule sets, frequency of changes, and how many systems feed the logs that show filtering in operation.	Automate configuration exports and log retention, and keep one change record per rule change.
External testing or review	Recurring or periodic. Paid to an independent tester or reviewer, not to the auditor.	Scope of applications tested, depth of testing, and whether testing covers bypass of the filter as well as the rules.	Align tests with Control 16 and Control 18 cycles and reuse findings in the next review.
Auditor sampling time	Per assessment cycle. Paid to the independent auditor or assessor, who alone issues any report.	Number of applications and filter points sampled, and how quickly evidence can be produced on request.	Prepare a sample-ready evidence set covering inventory, rules, change logs and blocked-event reviews before the assessment starts.

Who does what for 13.10: your team, a partner and the auditor

Your organization owns Safeguard 13.10. Application layer filtering is a decision about which application traffic may reach which services, and that decision belongs to the people accountable for those services. No partner or auditor can make it for you, and an auditor will ask who approved each rule and when.

Application inventory: Maintain the list of internet-facing and internal web applications and APIs the filter protects. The assessment specification treats the asset and software inventories in Safeguards 1.1 and 2.1 as prerequisites, so build this list from those records and keep it current.
Rule ownership: Assign a named owner to each protected application and to the filter policy as a whole. Owners approve rule changes, exceptions and allowlist entries.
Block decisions: Decide which detections block traffic and which only alert. Record the reason for each blocking rule and the condition that triggers it.
Change records: Keep tickets or change logs showing who requested, approved and deployed each rule change.
Review cadence: Set a recurring review of rules and false positives, and record its outcomes.

Before your next audit cycle, confirm that every protected application has an owner and that you can produce an approval record for the most recent rule change.

Where organizations usually fall short on application layer filtering

Application layer filtering fails in predictable ways: the filter does not see every application, runs in the wrong mode, or cannot prove what it blocked. Each card below names one gap, why it matters for Safeguard 13.10, and the closing action an assessor will expect to see in place.

Applications missing from the inventory

A filter can only protect applications it knows about. Internal tools, legacy web apps and SaaS front ends added outside change control often sit behind a route that never passes the proxy or gateway. Safeguard 13.10 depends on the asset and software inventories in Safeguards 1.1 and 2.1, so a gap there becomes a gap in filtering. Close it by reconciling the published application list against DNS records, load balancer configurations and the software inventory every quarter, and treating any unlisted hostname as a finding.

Filters left in detect-only mode

Teams often deploy a web application firewall or gateway in detection mode to avoid breaking traffic, then never switch to blocking. Logs look busy, but nothing is stopped, and the control does not match what the Safeguard describes. Check the enforcement setting on every production route, not only on the platform's default configuration. Close it by setting a dated go-live criterion for each application, moving it to blocking after a tuning window, and recording the change in the change ticket.

Rule sets never reviewed or updated

Coraza with the OWASP Core Rule Set, or any ModSecurity-compatible ruleset, only defends against the attack patterns it contains. Rule sets that were installed once and left alone miss new payloads, and rules disabled to stop false positives are rarely revisited. An assessor will ask for version history and review records. Close it by pinning the ruleset version in configuration, documenting each disabled rule with a reason, and reviewing the set on a fixed schedule and after major application changes.

Exceptions granted without records

Developers frequently ask for a path to bypass the filter, a source address to be allowlisted, or a rule to be removed for one endpoint. When these approvals live in chat or memory, nobody can later explain why traffic was allowed. Each exception changes the filtering posture that 13.10 describes. Close it by requiring a written request with owner, business reason, scope, compensating control and expiry date, then reviewing every open exception at the same cadence as the ruleset.

Filter logs not reaching central alerting

Blocked requests that stay on the proxy host cannot support detection or response. Safeguard 13.1 expects security events to be centralized for correlation, and the filter is one of the richest sources of web attack signals. Logs that are rotated locally, unparsed or sent to a dashboard nobody watches fail in practice. Close it by forwarding filter logs to the SIEM or log platform, confirming that a test attack generates an alert, and naming an owner for each correlation rule.

No evidence of the user-to-application path

Assessors test whether traffic to a protected application actually passes through the filter. Many teams can describe the design but cannot show it, especially after cloud load balancers, CDNs or service meshes were added. Without a diagram tied to real configuration, the claim cannot be verified. Close it by producing a current data-flow diagram for each protected application, capturing the request path from the browser to the origin, and keeping a dated configuration export that shows the filter in that path.

Questions buyers ask about the cost, time and effort of Safeguard 13.10

How much effort does Safeguard 13.10 application layer filtering take?

The effort depends mostly on how many internet-facing and internal applications need filtering, how much of their traffic is already routed through a proxy or gateway, and how many rule sets must be written and tuned. Safeguard 13.10 is an Implementation Group 3 safeguard, so it is usually scoped for enterprises with security specialists and sensitive assets. Work falls into four parts: choosing the enforcement point, building and testing rules, tuning them against real traffic, and producing evidence. Ask any quote to break effort down by application, environment and rule set, and to separate one-time build work from recurring tuning and review.

How long does it take to deploy application layer filtering?

Duration is driven by the number of applications in scope, the state of the asset and software inventories, whether a filtering point already exists, and how much change control the environment requires. Two prerequisites affect the schedule most: an enterprise asset inventory (Safeguard 1.1) and a software inventory (Safeguard 2.1), both of which the CIS Controls Assessment Specification lists as prerequisites for measuring 13.10. Organizations with incomplete inventories should expect discovery to come first. Ask for a timeline that is tied to the written scope, with milestones for pilot applications, production cutover and tuning.

Can our team implement application layer filtering in-house?

Many teams can, provided they have people who understand HTTP traffic, reverse proxies, rule syntax and their own applications. The harder part is usually not installing a filter but deciding what it should block, keeping false positives from breaking business workflows, and documenting the result. A team without a web application security background, or without time for tuning, often underestimates the work. A useful check is whether the team can name each in-scope application, its normal request patterns, its owner and the rule changes made in the last quarter. If not, a scoping engagement may be worth the cost before committing to a build.

What does the internal team need to provide during the work?

The internal team supplies knowledge the filter cannot infer. That includes application owners who can explain legitimate traffic, change approvers who will sign off rule changes, network staff who control routing to the proxy or gateway, and an operations contact who receives alerts. The team also needs access to logs and test environments, and time for review meetings. Plan for named individuals with defined hours during deployment and for a recurring review owner afterward. Without these roles, rules tend to be disabled under pressure, which weakens the control and the evidence behind it.

Are open-source filters acceptable evidence for an assessment?

It depends on the assessor and on the documented configuration, not on the license. An assessor generally looks for evidence that a filtering point exists for the in-scope applications, that rules are defined, justified and version-controlled, that changes are approved, and that blocked events are logged and reviewed. Open-source components such as Coraza, which is Apache-2.0 licensed and compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, or OPNsense rule sets with per-rule logging, can produce that evidence. Confirm acceptance with your assessor before the engagement, and keep configuration exports, change records and log samples.

Can a partner help with scoping, tuning and evidence while we keep ownership?

Yes. A partner can scope the work, implement and harden the open-source filtering platform in your environment, tune rules against agreed test traffic, and prepare the configuration and log evidence an assessor will request. Under this model your organization still owns Safeguard 13.10, approves rule changes and decides its risk acceptance. DeployOpen prepares systems and evidence and does not issue audit reports or certifications; an independent auditor or certification body does that. Most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and ongoing tuning can be handled through a retainer.

How DeployOpen scopes, deploys and prepares evidence for 13.10

DeployOpen plans, implements and documents application layer filtering for Safeguard 13.10 inside your own cloud accounts, data centers or air-gapped networks. We prepare the systems and evidence an assessor will examine, while your organization owns the control and an independent auditor issues any report or certificate.

How we scope

Engagements are fixed-scope, with the covered applications, filtering points and deliverables agreed in writing before work starts.
The written scope confirms the Safeguard 1.1 asset inventory and 2.1 software inventory that the assessment specification expects as prerequisites.
We confirm which web applications and APIs sit behind a filtering proxy, gateway or application firewall, and which traffic paths remain out of scope.

How we build

We deploy a filtering layer such as Coraza, which is compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, in front of in-scope services.
We integrate the filter with your reverse proxy or gateway, such as Caddy, HAProxy, Traefik or Nginx, and test rule behavior against known attack patterns.
Where network-level allow rules are also needed, we configure OPNsense aliases, pass and block rules, and rule-match logging for review.

How we hand over

You receive configuration records, rule sets, change logs and test results that show filtering is operating as documented for each in-scope service.
We document the filtering process, ownership, review cadence and exception handling so your team can run and explain the control.
Evidence is delivered in your environment so your auditor can sample it directly, and we do not issue any attestation or certification.

How we support

Ongoing support, rule upgrades and continuous testing are available as a retainer after handover.
Support can cover rule set updates, new application onboarding and periodic review of filter logs for tuning and false positives.
Confirm with DeployOpen during scoping which support levels, response arrangements and testing frequencies apply to your engagement.