What Safeguard 10.7 behavior-based anti-malware asks for
Safeguard 10.7 asks an IG2 or IG3 enterprise to use anti-malware software that detects threats from how software behaves, not only from known signatures. If you already run anti-malware on your endpoints, the question is whether that product watches for suspicious behavior such as unexpected process injection, scripts launching other tools, or ransomware-like file changes, and whether you can show it is installed and configured on the assets that matter. CIS places the Safeguard in the Devices asset class and the Detect security function, and in Implementation Group 2, so it does not apply to IG1 enterprises but does apply to every IG2 and IG3 enterprise. Signature matching alone misses new or modified malware that has no known pattern yet, which is why assessors expect behavior analysis to sit on top of signature protection rather than replace it.
The CIS Controls Assessment Specification scores the Safeguard with a Coverage metric: the share of assets that have properly configured, authorized behavior-based anti-malware installed. Coverage is only as accurate as your denominator. The specification lists Safeguards 1.1 (detailed enterprise asset inventory), 2.1 (software inventory) and 4.1 (secure configuration process) as prerequisites, because you cannot count covered devices without knowing which devices exist, cannot confirm the agent is authorized without a software inventory, and cannot call a configuration proper without a documented baseline. Organizations that struggle usually have incomplete asset inventories, endpoints that report to no console, and no named owner for tuning exclusions and responding to behavioral alerts. Decide those owners before you start, and confirm with your assessor which evidence they will accept for the denominator.
Start by reconciling the endpoint list from your anti-malware console against your asset inventory, then record the behavior detection setting, policy version and exclusion list for each group. Ask your vendor to confirm which behavioral detection features are included in your license tier, because many products separate them from basic signature scanning. Treat unexplained gaps, such as servers outside the console or agents disabled by users, as findings to close before measuring Coverage. Where you need to show detection activity over time, open-source tools such as osquery can report running processes and loaded modules from the fleet, and Wazuh can collect and alert on endpoint events. Confirm with your assessor whether those outputs satisfy the evidence they expect, since the choice of evidence is theirs.
Which devices, teams and tools fall under Safeguard 10.7
Scoping decides how large the Safeguard 10.7 effort becomes. The cards below cover the enterprise assets, operating systems, workloads and third-party devices that must be counted, along with the inventories that make the count defensible. Each card names a decision the team must make before measuring Coverage.
Confirm the Implementation Group first
Safeguard 10.7 sits in Implementation Group 2, so it applies to IG2 and IG3 enterprises but not to IG1-only enterprises. Confirm your Implementation Group before scoping, because an IG1 enterprise may treat behavior-based detection as a planned upgrade rather than an assessed requirement. If you are unsure which group fits, document the reasoning so an assessor can follow it.
Start from the detailed asset inventory
Safeguard 1.1 requires a detailed enterprise asset inventory, and the Assessment Specification lists it as a prerequisite for measuring 10.7. Every endpoint and server in that inventory is a candidate for Coverage, so gaps in the inventory become gaps in the denominator. Ask whether the inventory includes devices that are powered off for long periods, laptops that connect rarely, and retired hosts still listed as active.
Use the software inventory to define the tool set
Safeguard 2.1 requires a software inventory, which shows which anti-malware products are installed, which versions are in use and which are unauthorized. Without it, you cannot tell whether a device runs an authorized behavior-based product or a legacy signature-only agent. Reconcile the software inventory against the asset inventory so that every in-scope device maps to a named, approved product.
Cover servers, virtual machines and cloud workloads
Scope the Coverage denominator to include servers, virtual machines, containers host nodes and cloud compute instances that run enterprise workloads, not only user laptops. Confirm whether each platform supports the chosen behavior-based agent, and document alternative controls where it does not. Ephemeral instances that exist only briefly still need a defined rule for when they join scope.
Decide how to treat unmanaged and contractor devices
Devices owned by contractors, guest systems and bring-your-own equipment often sit outside central management. Decide whether they are in scope if they connect to enterprise assets, and if so, how the agent is enforced or access is restricted. Document exceptions with an owner and an expiry date, because an unexplained exception will appear as a coverage gap during assessment.
Align scope with central management in 10.6
Safeguard 10.6 covers central management of anti-malware software, so the scope of 10.7 should match the population the central console can see and configure. An endpoint that runs an agent but reports to no console cannot be shown as properly configured. Check that the console reports on every in-scope asset, and record which team owns policy for behavior-based detection.
How an assessor tests Safeguard 10.7
This table maps each test an assessor is likely to run against Safeguard 10.7 to the evidence it requests and the findings that commonly appear. The Coverage metric in the CIS Controls Assessment Specification is the anchor, so read each row as a step toward proving that authorized behavior-based anti-malware is installed and configured on the share of assets in scope. The assessment specification defines what to measure but not how to sample, so confirm the sample method with your assessor before fieldwork.
| Assessment step | What the assessor checks | Evidence requested | Common finding |
|---|---|---|---|
| Inventory reconciliation | Whether the asset population in scope matches the enterprise asset inventory under Safeguard 1.1 | Asset inventory export, scope statement and reconciliation to endpoint console counts | Endpoints appear in the console but not in the inventory, or the reverse |
| Software inventory check | Whether each installed anti-malware product is on the authorized software list from Safeguard 2.1 | Software inventory, approval records and console product list | Unauthorized or unlisted anti-malware product running on some hosts |
| Sampling of endpoints | Whether a sample of assets from the scope actually runs behavior-based anti-malware | Sample selection record, per-asset agent status and product version output | Sampled endpoints with agent missing, stopped or out of date |
| Configuration review | Whether behavior-based detection is enabled, not only signature scanning | Policy export showing behavior, heuristic or real-time protection settings and exclusions | Signature-only configuration, or behavior features disabled by policy |
| Secure configuration baseline | Whether the configuration follows the documented process from Safeguard 4.1 | Hardening baseline, change records and policy version history | Settings drift from the approved baseline with no change record |
| Detection reporting | Whether behavioral detections reach the console and are reviewed | Sample alerts, detection logs and ticket or review records for those detections | Detections recorded locally on endpoints but never forwarded for review |
| Coverage calculation | Whether the share of assets with properly configured authorized behavior-based anti-malware is measured and reported | Coverage report with numerator, denominator and date of calculation | No coverage figure exists, or the denominator excludes known assets |
How to implement behavior-based detection step by step
This sequence takes Safeguard 10.7 from prerequisites to continuous evidence, so the behavior-based anti-malware on in-scope devices is authorized, configured, verified and measured. Each step closes with an artifact an assessor can review.
Confirm inventories and secure configuration process
Before choosing or changing software, confirm that the detailed asset inventory (Safeguard 1.1), the software inventory (Safeguard 2.1) and the secure configuration process (Safeguard 4.1) exist and are current. The assessment specification treats these as prerequisites, because you cannot measure coverage on assets you have not listed. Your IT or security operations lead owns this step. It is done when you can export a device list for the in-scope population and a documented configuration baseline that the anti-malware policy will reference.
Select or confirm an authorized behavior-based product
Identify the anti-malware product that will run behavior-based detection on Devices in scope, or confirm the product already in use. Check that the product actually provides behavior-based or heuristic detection in addition to signatures, and confirm the capability with the vendor in writing, because product names and feature sets vary. Record the software in your authorized software list so it is inventoried under Control 2. The output is an approval record naming the product, its version, the owner and the devices it covers.
Define a baseline policy with behavior detection enabled
Write the anti-malware policy that turns behavior-based detection on for every in-scope device class, and link it to the secure configuration baseline from Safeguard 4.1. The policy should state the detection settings, who may change them, and how changes are requested and recorded. Security engineering drafts it and the accountable security owner approves it. The output is a signed policy document and an exported configuration showing the behavior detection setting enabled.
Deploy and verify coverage on every in-scope asset
Push the agent and policy to every in-scope device, then compare the console's managed device list against the asset inventory from the first step. Investigate each gap: devices that are offline, unmanaged, or running an outdated agent. Coverage is the share of assets with a properly configured, authorized behavior-based product installed, so the reconciled list is the numerator and denominator your assessor will check. The output is a dated coverage report with every exception listed and an owner for each.
Tune exclusions under documented approval
Behavior engines generate false positives on legitimate administrative tools and build pipelines, and teams often respond by adding broad exclusions. Require each exclusion to name the path, process or hash, the business reason, the approver and an review date, and reject exclusions that cover whole drives or user profiles without justification. Keep the exclusion log under change control. The output is an exclusion register that matches what the console actually enforces, which you can compare against the register on a sample of devices.
Set up continuous coverage reporting
Configure the console or a connected reporting pipeline so that device coverage, detection policy state and exclusion counts are produced on a schedule and retained. Confirm that the report shows behavior detection as enabled rather than only that the agent is installed. Security operations owns the report and reviews exceptions with the asset owners. The output is a recurring report with retained history, which lets you show coverage over time rather than a single snapshot.
Route detections into monitoring and response
Confirm that behavior-based detections reach the people and tools that act on them, such as a security information and event management platform, a SIEM or an open-source alerting stack. Test the path with a benign, controlled detection event, which is an illustrative check rather than a required test, and record the alert, the ticket and the response. This connects Safeguard 10.7 to Control 8 log management and Control 17 incident handling. The output is a test record showing an alert travelled from endpoint to a reviewed queue.
Which evidence shows behavior-based anti-malware is active
An assessor testing Safeguard 10.7 wants to see that behavior-based detection is installed, configured and watched on the right assets. The six artifacts below connect to each other: the product list defines what counts, the policy and coverage records prove it is on, and the alert and exception records show it is working and managed. Refresh the coverage reconciliation on a recurring schedule rather than assembling it before an audit.
Authorized product list
This is the list of anti-malware products the organization has approved, with the version, vendor and the asset groups each product may cover. For Safeguard 10.7, the list should show which products provide behavior-based detection, not only signature matching. Assessors compare installed products against this list, so any product found on an endpoint but absent here is an immediate finding. Confirm the list with the product owner and record the approval date and approver.
Policy export with behavior detection enabled
Export the central policy or per-device configuration showing that behavior monitoring, heuristic analysis or the vendor's equivalent setting is turned on. A passing artifact names the setting, the policy it belongs to, and the device groups it applies to, and it can be read without vendor-specific interpretation. Take a dated export each quarter and after any policy change, and keep the previous export so the change history is visible. Ask the vendor which exact setting name corresponds to behavior-based detection in your product.
Coverage report matching the asset inventory
The Coverage metric in the assessment specification is the share of assets with properly configured, authorized behavior-based anti-malware installed. The coverage report should count the same assets as the enterprise asset inventory under Safeguard 1.1, and the two totals must reconcile, with each gap named. Reconcile monthly or on a schedule the organization sets, and document any asset that is excluded along with the reason. Without this reconciliation, the coverage figure cannot be trusted.
Sample endpoint configuration records
Assessors usually sample a selection of endpoints and check that each one shows the product installed, running, enrolled in the right policy and reporting to the console. A passing record includes the agent version, the policy name, the last check-in time and the state of the behavior module. Pull the samples from different device types and operating systems, so the evidence covers the whole fleet rather than a single image. Use the software inventory under Safeguard 2.1 to confirm that the agent is recorded as installed on each sampled host.
Detection and alert logs with review records
Behavior-based detections are only useful if someone reviews them. Keep exported detection logs for the review period, and attach records showing who triaged each alert, what action was taken and how it was closed. The Safeguard 8 logging evidence and any SIEM forwarding, such as OpenSearch Security Analytics or Wazuh alerts, can show that behavioral events reached a central place. Confirm the retention period for these logs with the organization's own policy, since no default is assumed here.
Exception approvals and compensating controls
Some assets cannot run the product, such as legacy systems, specialized equipment or hosts with vendor restrictions. Each exception should name the asset, the reason, the compensating control, the risk owner and an expiry or review date. Assessors check that exceptions are approved by someone with authority to accept the risk and that they are reviewed, not left open indefinitely. Count exceptions in the coverage report so the percentage reflects the real state of the fleet.
What meeting Safeguard 10.7 costs in money and effort
This table breaks down the cost of meeting Safeguard 10.7 into its components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to shape a quote request, and note that no price is given because none is supplied for this safeguard.
| Cost component | Who is paid or who spends effort | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Behavior-based anti-malware licenses | Software vendor or reseller, if a commercial product is chosen | Recurring, usually per endpoint or per term | Fleet size, operating system mix and whether the product is bundled with existing endpoint tooling; ask whether the quote covers every OS in scope |
| Open-source alternatives and tooling | Internal staff or an implementation partner for setup, with no license fee for the tools themselves | One-time setup, then recurring upkeep | Staff skill with query and rule languages, hosting for central components, and how many detections must be written in-house |
| Policy design and deployment engineering | Internal engineers or a partner under a fixed-scope agreement | One-time, with occasional repeats after major changes | Number of distinct device classes, legacy systems that cannot run the agent, and how much the Devices asset class inventory is already reliable |
| Tuning and exclusion review | Security engineers who review false positives and approve exclusions | Recurring | Software change rate, developer tooling that triggers behavioral rules, and how documented each exclusion must be for assessors |
| Coverage reconciliation | Asset management or security operations staff comparing agent status with the asset inventory (Safeguards 1.1 and 2.1) | Recurring, often on a fixed cycle | Accuracy of the asset and software inventories, number of unmanaged or intermittently connected devices, and how often the Coverage metric is reported |
| Alert review and staffing | Security operations analysts, internal or contracted | Recurring, usually the largest ongoing cost | Alert volume, severity thresholds, after-hours coverage expectations and whether alerts feed a central log platform |
| Log retention and storage | Infrastructure team or cloud provider | Recurring, scales with data volume | Retention period chosen, event volume per endpoint and whether behavior logs are forwarded to a SIEM or stored locally |
| External review or testing | Independent testing firm or assessor, for example a penetration test that checks whether detections fire | Periodic | Scope of the test, number of OS builds tested and whether the test is repeated after major platform changes |
| Auditor sampling time | Independent auditor or assessor, billed under the audit engagement | Periodic, tied to each assessment cycle | Quality of the evidence pack, whether the Coverage calculation is documented and how many assets the auditor samples |
How open-source tools can produce detection and coverage evidence
Open-source tools can generate much of the evidence an assessor will ask for under Safeguard 10.7, but they do not satisfy the Safeguard on their own. The Safeguard asks for behavior-based anti-malware, and the assessment specification scores it as a coverage share: assets with a properly configured, authorized behavior-based product installed. The organization still needs that product, and the self-hosted tools below help show that it is deployed, active and producing detections. Before relying on any of them, confirm each capability against your own environment and against the product's own documentation, particularly whether the behavior-detection feature you rely on is provided by the anti-malware product itself or by a separate telemetry layer.
osquery is the most direct source of endpoint-state evidence. Its osqueryd daemon can schedule SQL queries across a fleet, for example against the running processes, loaded kernel modules, open network connections and file hashes tables. Scheduled results can show whether suspicious process behavior is visible on each Devices asset and whether the anti-malware agent process is present and running. Velociraptor complements this with artifact collection and hunts across groups of systems. Its ability to schedule collection on machines that were offline and collect them when they reconnect helps close coverage gaps on laptops that are not always on the network. Velociraptor is licensed under AGPL-3.0-only, so review what that license requires if you modify and distribute it or offer it to others over a network.
OpenSearch Security Analytics and Wazuh are the detection and review layers. OpenSearch Security Analytics runs detectors that match ingested logs against Sigma rules, records matches as findings with severity and log type, and sends alerts to channels such as Slack or email. Wazuh decodes collected events, compares them against its ruleset, writes matches to alerts.json, maps alerts to MITRE ATT&CK and forwards them to its indexer for dashboard review. Together they give an assessor a dated record of detections and their handling. Note the licenses: OpenSearch is Apache-2.0 and Wazuh is GPL-2.0-only. Confirm the rule coverage you need, since the ruleset is only as useful as the rules that match your hosts.
Who owns Safeguard 10.7 and what can be outsourced
The organization owns Safeguard 10.7. That means it decides that behavior-based anti-malware is required on in-scope Devices, approves the product and configuration, sets the exception process, and answers for the result. Because the Assessment Specification scores the Safeguard with a Coverage metric (the share of assets with properly configured, authorized behavior-based anti-malware installed), the internal team must be able to produce that number on demand and explain every gap.
- Policy and scope: Write the anti-malware standard, define which asset classes are in scope, and approve the behavior-based product and its settings.
- Exception approvals: Decide which assets may run without the agent, for how long, and who signs off on each exception.
- Alert review: Triage detections, decide on containment, and record outcomes in the incident process.
- Coverage metric: Own the calculation of authorized, properly configured coverage and reconcile it against the asset inventory (Safeguard 1.1) and software inventory (Safeguard 2.1).
- Prerequisite control: Keep the secure configuration process (Safeguard 4.1) current, since the Assessment Specification treats it as a prerequisite.
Before engaging any outside party, confirm that someone internal can name the owner of each item above and produce the coverage figure without help.
An implementation partner can prepare the systems and evidence that show Safeguard 10.7 is working. The partner does not own the control, does not decide which assets are exempt, and does not sign off that the control passes. Its work is technical and documentary, and it should be scoped and priced in writing before work starts.
- Deployment and configuration: Install and configure the behavior-based agent, apply the approved policy, and verify the agent on sample hosts.
- Coverage reporting: Build the reports or queries that count authorized, properly configured installations against the inventory, so the internal team can review them.
- Tooling: Set up open-source collection and detection, for example osquery for fleet queries or Wazuh for alert handling, inside the client's own environment.
- Evidence packs: Assemble configuration exports, screenshots, query outputs and change records in a structure the assessor can follow.
- Handover: Document runbooks and train the internal team so it can operate and re-run the evidence without the partner.
Check that the statement of work names the deliverables, the environments touched and who approves each change, and that the partner will not be listed as the owner of the control.
An independent auditor, assessor or certification body tests whether Safeguard 10.7 is implemented and issues any report or certificate. Independence is the point of the role, so the assessor must test evidence it did not design or set up. An assessor that builds the coverage report it then tests has a conflict, and most engagements avoid that by separating the two activities.
- Testing: Select samples of assets, compare the agent inventory with the asset inventory, and check the configuration against the approved policy.
- Evidence review: Judge whether the logs, query outputs and exception records are complete, consistent and traceable to source systems.
- Independence limits: An assessor may explain what evidence is expected but should not design the evidence it later tests.
- Reporting: Issue the report or attestation under the assessor's own name, based on its procedures and professional standards.
- Mapping questions: Confirm which framework the client is being assessed against, since CIS Controls mappings to other frameworks are informational unless the assessor's scheme requires them.
Ask early whether the assessor will accept evidence prepared by a partner and how it wants the coverage calculation documented.
Outsourcing works best for labor-heavy, repeatable setup, while decisions and accountability stay in-house. The split below is a common pattern rather than a fixed rule, and the boundary should be written into the scope for each engagement.
- Usually outsourced: Initial agent rollout, configuration hardening, fleet query and collection setup, evidence pack assembly and runbook drafting.
- Usually kept in-house: Product selection, exception approval, alert triage decisions, the coverage metric sign-off and the policy itself.
- Shared: Testing the agent on pilot groups, where the partner executes and the internal team reviews results.
- One-time versus recurring: Deployment and tooling setup are typically one-time, while coverage reporting, alert review and exception renewal recur and need an owner after the project ends.
- Cost drivers: Asset count, number of operating systems, existing tooling and how many exceptions exist all change effort. Ask any partner to itemize these in a quote.
Ask each party to confirm in writing who signs each evidence item before the first assessment.
Questions buyers ask about Safeguard 10.7 cost, effort and help
Does an IG1-only enterprise need Safeguard 10.7 behavior-based anti-malware?
No. CIS places Safeguard 10.7 in Implementation Group 2, so it applies to IG2 and IG3 enterprises but not to IG1. IG1 is the essential cyber hygiene baseline that every enterprise should meet, and it already asks for anti-malware deployment (10.1) and automatic signature updates (10.2). If you are unsure which group you fall into, compare your enterprise against the descriptions on the CIS Implementation Groups page. Many organizations that start at IG1 adopt behavior-based detection early because it can catch threats that signatures miss, but adopting it early is a choice, not a requirement for IG1 alone. Confirm your group in writing with whoever sets your control baseline, including any contract or regulator that names the CIS Controls.
How much effort does it take to meet Safeguard 10.7?
Effort depends mostly on how many enterprise assets you run, how many already have anti-malware, and how well your inventories are maintained. The CIS Controls Assessment Specification measures 10.7 with a Coverage metric: the share of assets with a properly configured, authorized behavior-based anti-malware product installed. Your cost therefore has four parts: the product license, which usually recurs; deployment labor across the fleet; configuration and tuning of detection policies and exclusions; and ongoing review of detections and coverage reports. Deployment and tuning are mostly one-time work, while licensing, monitoring and reporting recur. Costs rise with device diversity, legacy operating systems, unmanaged endpoints and strict change control. Ask any quote to list the license separately from services, state the asset count it assumes, and separate initial rollout from annual operation.
Can our team meet Safeguard 10.7 without an outside partner?
Yes, if your team has the skills and capacity. The organization owns its controls, so internal staff can select the product, deploy it, set policies, collect coverage data and document the process. Teams usually find installation the easiest part. The harder work surrounds it: keeping the asset inventory (1.1) and software inventory (2.1) current, maintaining the secure configuration process (4.1), handling exclusions and false positives, and producing evidence in a form an assessor will accept. Outside help is most useful where those gaps exist or where staff lack the time to hold a fixed scope to completion. Before deciding, count your endpoints, check whether your current anti-malware already offers behavior-based detection, and ask whether one named person can own the work through to coverage reporting.
What does Safeguard 10.7 require from our staff day to day?
Plan for several roles to share the work. Endpoint administrators push packages and policy to devices. A security engineer sets detection and exclusion policy. Asset and software owners confirm that inventories are accurate. Change managers approve policy changes on production systems, and an analyst reviews detections and alerts. The skills needed include understanding how process behavior is flagged, reading detection events, and testing false positives before policies are enforced widely. The time commitment is highest during rollout and falls to periodic review once coverage is stable. Ask for named owners in writing. Staff who run the product should also know how to export coverage and detection records, because an assessor will ask to see them.
How long does Safeguard 10.7 take, and what must come first?
The material supplied for this page does not give a duration, and the honest answer depends on your starting position. The sequence is fixed, though. The Assessment Specification lists Safeguards 1.1, 2.1 and 4.1 as prerequisites for measuring 10.7, so an accurate asset inventory, a software inventory and a documented secure configuration process should exist before coverage can be measured properly. After that, deploy the authorized product to assets, configure behavior-based detection under a written policy, verify coverage against the inventory, and collect records of configuration and detections. Organizations with mature inventories and central management usually have less to build. Ask any provider for a dated plan built from the agreed scope, with milestones for prerequisites, rollout, verification and evidence handover.
What does an implementation partner deliver for Safeguard 10.7, and what does the auditor do?
A partner prepares systems and evidence. It does not decide whether the controls pass. For 10.7, DeployOpen would plan the rollout, implement and configure the approved behavior-based product inside your environment, connect its telemetry to your logging, document the process, and assemble the evidence an assessor will review. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies test the implementation and issue the reports. Work is fixed-scope: scope, deliverables and timelines are agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from that written scope. Ongoing support, upgrades and continuous testing are available as retainers. Ask any partner to label each deliverable as either evidence or advice.
How do open-source tools show that behavior-based detection is active?
Open-source tools can produce telemetry that supports the Coverage claim and the detection side of 10.7, but they do not replace the behavior-based anti-malware product itself. osquery can run scheduled queries across a fleet to report running processes, loaded kernel modules, open network connections and file hashes, which helps show coverage and spot unexpected activity. Velociraptor hunts collect artifacts across groups of systems and queue offline machines until they reconnect. Wazuh writes matching alerts to alerts.log and alerts.json and maps them to MITRE ATT&CK, while OpenSearch Security Analytics runs Sigma-based detectors and sends alerts to channels such as Slack or email. Confirm with your anti-malware vendor that the product detects by behavior, and keep its configuration and detection exports as primary evidence.
How DeployOpen scopes and prepares Safeguard 10.7 evidence
DeployOpen plans and implements the self-hosted open-source platforms that can produce Safeguard 10.7 evidence inside your own infrastructure, and prepares that evidence for review. Your organization owns the control and its decisions, and only an independent assessor issues any report or certificate.
How we scope
- The written scope lists which Devices assets fall under Safeguard 10.7 and which are excluded, with reasons.
- It confirms IG2 applicability and records the prerequisite inventories from Safeguards 1.1, 2.1 and 4.1.
- It names the behavior-based anti-malware product your organization already uses or has approved, or states that selection is out of scope.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.
How we build
- We configure detection telemetry and behavior monitoring within your own cloud accounts, data centers or air-gapped networks.
- We set up osquery queries that report running processes, loaded kernel modules and open network connections across hosts.
- We connect alerts from endpoints into a log platform such as OpenSearch Security Analytics or Wazuh for review and tuning.
- We test detections against controlled, benign behaviors in a lab or cyber range to confirm alerts fire as the configuration intends.
How we hand over
- We produce a coverage report that shows the share of in-scope assets with the authorized behavior-based tool installed and configured.
- We document the configuration baseline, exception process and the owner for each coverage gap.
- We deliver the evidence set: configuration exports, query results, alert samples and detection test records, mapped to the assessor's request.
- Your staff receive runbooks so the evidence can be regenerated without DeployOpen involvement.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial scope closes.
- Retainers can cover coverage reporting, tuning of detections and refreshing evidence before each assessment cycle.
- Assessment decisions and any report or attestation remain with your organization and the independent assessor you choose.
