Self-hosted network security monitoring

Why network security monitoring needs its own layer and which open source stacks fit

Network security monitoring needs its own layer because endpoint agents and application logs do not see most of what crosses the wire. Traffic between workloads inside a data center or cloud VPC (east-west) and traffic entering or leaving it (north-south) can carry command-and-control, lateral movement and data staging that never touches a monitored host or generates a log line on the device that matters. A network sensor sees the packets themselves, so it can catch activity that a compromised or unmanaged system is hiding from its own logs. The practical decision is whether to assemble the detection and metadata engines yourself or adopt a bundled platform that already integrates them.

Suricata and Zeek do different jobs and are often run side by side. Suricata is the detection engine: it inspects traffic against signature rules, can raise alerts on known patterns, and is licensed under GPL-2.0 (Suricata 8.0.7 was published on September 15, 2026). Zeek is the protocol analysis framework: it writes structured metadata for connections, DNS, HTTP, TLS and file activity, which analysts use for hunting and investigation, and it is distributed under a BSD-style license (Zeek 9.0.0 was published on August 21, 2026). Confirm with your architects which sensor placements, rule sets and log formats your SIEM and analysts will consume before you choose either as the system of record for network evidence.

Security Onion is the bundled option. It packages Suricata, Zeek, osquery and the Elastic stack into one platform for monitoring, hunting and log management, and it is licensed under the Elastic License 2.0 (release 3.3.0-20260911 was published on September 11, 2026). Assembling the components yourself gives you direct control over versions, tuning and storage design, but it also makes you the integrator for upgrades, interoperability and documentation. A bundle reduces that integration work and shortens the path to a working sensor, while adding a license you must review against your own use and redistribution terms. Ask any partner which of these two paths they recommend for your sensor count, traffic volume and staffing, and what that choice commits you to after go-live.

What to agree on before you choose network security monitoring components

Network security monitoring projects stall when teams pick sensors before they agree on scope, purpose and ownership. The six decisions below shape sensor count, storage, privacy handling and staffing, so settle them in writing before comparing Suricata, Zeek or any packaged platform.

Traffic in scope

List every segment you intend to observe: data center east-west traffic, cloud VPCs, branch sites, remote access concentrators and any OT segments. Each segment needs a sensor position with visibility into the traffic you care about, which often means a span port, a network tap or a virtual sensor inside the cloud account. Document which segments are excluded and why, and confirm that each cloud provider and OT vendor allows traffic capture in your environment before you commit to a design.

Detection, investigation or both

Detection means Suricata signatures and alerts that page someone. Investigation means retaining Zeek logs and metadata so analysts can reconstruct an event days later. Most teams need both, but the balance changes sensor tuning, log volume and the skills you must hire for. Write the primary goal first, then the secondary one, so procurement and staffing questions have an answer.

Retention and packet storage location

Decide how long connection metadata, protocol logs and full packet captures are kept, and where they physically reside. Full packet capture grows quickly and often contains credentials, personal data or health information, so it may need a different location and access list than metadata. Confirm with legal and data protection staff whether packet data may leave a region or a cloud account, and size storage from your measured traffic rather than from a generic estimate.

Encryption and privacy limits on captured content

Much traffic is encrypted, so sensors see metadata such as server names, certificate details and flow timing rather than payloads. Where you do decrypt for inspection, you take on key management and privacy obligations. Decide whether TLS inspection is permitted, which systems are exempt, and how captured payloads are masked or access-logged. Confirm the rules with your privacy office before deployment, because they limit what Zeek and Suricata may record.

Alert triage model and ownership

Name the team that reviews each alert, the hours it covers, the severity levels that wake someone up, and the criteria for closing an alert as benign. Without this model, sensors generate volume that nobody reviews. Record the tuning owner too, since suppressions and rule changes need a change record. The triage model determines how many analysts you need and whether you can run the service with an outside partner for overnight coverage.

SIEM and ticketing integration

Decide which event stream goes to your SIEM, in what format, and which fields must be present for correlation with endpoint and identity logs. Define how a high-severity alert becomes a ticket, what fields the ticket carries and who receives it. Confirm that the platform you choose can forward to your SIEM and ticketing tools through supported outputs, and document the agreed field mapping so the integration can be tested before go-live.

Which open source network monitoring stack fits which team

This table compares Suricata, Zeek, Security Onion and Wazuh by license, latest researched release, fit and operating effort. Read it as a shortlist, not a verdict: the right choice depends on whether your team wants a detection engine, an analysis framework, a bundled sensor and analyst platform, or a host and log-centric XDR. Confirm each product's network sensor capabilities in your own environment before deciding.

Option	License and latest researched release	Best fit	Operating effort
Suricata	GPL-2.0. Version 8.0.7, published September 15, 2026	Teams with an existing SIEM or log platform that need signature and rule-based network detection at sensors	Moderate. Rule selection, tuning, sensor performance checks and updates are ongoing, and you must supply the logging and analyst workflow around it
Zeek	BSD-style license from the Regents of the University of California. Version 9.0.0, published August 21, 2026	Teams that want structured network logs (connections, files, protocols) for hunting, investigation and custom detection scripts	Moderate to high. Scripting, log schema decisions and storage planning fall to your team, and detection content is largely self-authored
Security Onion	Elastic License 2.0. Version 3.3.0-20260911, published September 11, 2026	Teams without a full SOC stack that want Suricata, Zeek, osquery and the Elastic stack delivered as one platform for monitoring and hunting	Moderate to high. Expect ongoing work on sensor sizing, Elastic storage, retention and upgrades, plus analyst training on the bundled tools
Wazuh	Core repository under GPL version 2. Release v4.14.9, published October 15, 2026	Teams that want unified XDR and SIEM with host agents and log analytics, and may pair it with network sensors such as Suricata or Zeek	Moderate. Agent rollout, rule tuning and dashboards are the main recurring tasks; network visibility depends on the sensors you add

How sensor placement and packet capture sizing decide what you can see

Sensor placement decides what Suricata and Zeek can see before any rule is written. A sensor only observes the packets that cross its tap or SPAN port, so the placement list should come from your trust boundaries: the internet edge, the links between security zones, the segments in front of critical databases and identity systems, and the east-west paths between application tiers. Each point should be recorded with the traffic it carries, who owns the switch or firewall, and whether the tap is passive or inline. Cloud workloads need a separate decision. Many cloud networks do not offer a physical tap, so you will need to confirm which mirroring or flow-log features your provider exposes, what they capture, and whether they add cost or latency. Confirm these details with your network team and provider before you commit to a design.

Capture sizing has to come from measured traffic, not a generic rule. Four inputs drive the storage and compute requirement: sustained throughput, peak bursts (such as backups, batch jobs or a flood of failed logins), the retention window you need for investigations, and whether you keep full packet capture or only headers and Zeek logs. Full capture multiplies storage cost by the traffic volume and the retention period, while header-only capture or Zeek metadata costs far less and answers most triage questions. Ask the partner to run a baseline period at each sensor point, record throughput at the busiest hour, and model storage tiers (hot disk for recent days, cheaper object or archive storage for older data). Treat the output as a measured estimate that you re-check after the first quarter of operation.

Encryption limits what payload inspection can prove, but metadata still has value. As more sessions use TLS, Suricata signatures that look inside payloads will see less, and full capture of encrypted traffic adds storage without adding readable content. Zeek still records connection metadata, server names, certificate details, and in many cases JA3 or JA4-style fingerprints, which support detection of unusual destinations, beaconing and certificate anomalies. *Illustrative example:* a server suddenly opens connections to an unfamiliar host every few minutes, with a new certificate issuer. The payload is unreadable, but Zeek connection and certificate logs still show the pattern. Ask your partner which encrypted-traffic indicators they will enable and how they will be validated against your baseline.

Reference architecture: sensors, analysis, storage and the alert path

A network security monitoring deployment is a chain: taps or mirrored ports feed sensors, sensors ship metadata and alerts through a transport layer, and analysts triage in a SIEM or console enriched with threat intelligence. Each link sits behind its own trust boundary, and each needs access controls sized to what it can see.

Network taps and mirrored ports

Taps or switch mirror (SPAN) ports copy traffic to the sensor without the sensor sitting in the forwarding path. Decide per segment which traffic you need: north-south at the internet edge, east-west between data center zones, and traffic to identity and database tiers. Confirm whether mirrored ports drop packets under load, since a silent drop creates blind spots that look like clean traffic. Restrict who can reconfigure switch mirror sessions, because changing a mirror is a quiet way to stop collection.

Sensor hosts running Suricata and Zeek

Suricata inspects traffic against signatures and emits alerts, while Zeek writes structured connection, DNS, HTTP and file logs that support hunting. Run both on dedicated sensor hosts in the monitored zone, with capture NICs separated from the management interface. Sensors hold a copy of sensitive traffic, so they belong in the most restricted monitoring zone, with administrator access through a bastion, signed or pinned rule and package sources, and host logs forwarded off the box.

Log transport layer

Sensors forward Eve JSON and Zeek logs to collectors over an encrypted channel, usually through a message queue or log shipper. Size the queue for burst conditions, since a stalled SIEM should not stall sensor capture. Authenticate each sensor with its own credential, so a compromised sensor can be revoked without touching the rest. Confirm that the transport survives a collector outage without dropping metadata that investigators will need later.

Storage and search tier

Alerts and Zeek metadata land in an indexed store that analysts query during triage and hunts. Full packet capture is a separate, much larger decision: it needs disk sized to traffic rate and a retention window set by investigations and legal hold, not by convenience. Separate retention for metadata and PCAP, and confirm who may export packets, since capture files often contain credentials and personal data. Keep the store behind the SOC network with role-based access and audit logging of queries.

SIEM and analyst console

This is where alerts are correlated, prioritized and assigned, typically through Security Onion, Wazuh or a commercial SIEM that already ingests your logs. The console is the tool analysts use daily, so it needs the strongest authentication in the stack, including MFA and role separation between tier 1 triage and tier 2 tuning. Confirm whether the platform can accept Suricata and Zeek data from your sensors without custom parsers, and who owns rule changes after go-live.

Threat intelligence enrichment

MISP or OpenCTI supplies indicators that the sensors and SIEM check against, such as domains, IP addresses and file hashes, and enrichment adds context to alerts. Treat feed quality as a risk: a noisy or stale feed produces false positives that analysts learn to ignore. Confirm which feeds may be shared outside your organization, and limit the platform's write access so that sharing decisions stay with named reviewers.

Build in-house, work with a partner or buy SaaS for network monitoring

This table compares three ways to get network detection running: an in-house team assembling Suricata and Zeek, an open source deployment run with an implementation partner, and a commercial SaaS or managed detection service. Read each row as a question to answer for your own environment, since the right model depends on who must control sensors and data, how many analysts you can staff, and how your budget splits between one-time build work and recurring operation. DeployOpen does not publish prices, so commercial pricing must come from the vendor or service provider.

Decision factor	In-house on open source	Open source with a partner	Commercial SaaS or managed service
Control over data and sensors	Full control. Your team chooses sensor location, retention and where traffic metadata is stored	Full control retained by you. The partner works inside your cloud accounts, data centers or air-gapped network	Shared control. Traffic metadata is typically processed in the provider's environment, so confirm data residency and retention terms in writing
Staffing to tune and triage	Dedicated analysts and engineers must learn Suricata rule tuning, Zeek scripts and sensor health monitoring	Your analysts still triage. The partner supplies build, tuning baseline and handover, and can offer ongoing support as a retainer	Provider analysts may triage alerts, but you still need staff to act on escalations and to tune for your own assets
Who pays for licenses	Suricata and Zeek are open source, so license cost is usually nil; confirm any commercial add-ons or vendor support you choose	Same open source license position. You pay the partner for scoped services, not for the software itself	Subscription or usage fees set by the provider. Ask for the pricing unit (sensors, throughput, endpoints or events)
Who pays for hardware and capture storage	You buy or allocate sensor hardware and packet or metadata storage, sized to your traffic	You still pay for hardware and storage. The partner's scope should state sizing assumptions and who owns procurement	Usually bundled or metered by the provider. Ask what happens to capture storage when traffic grows
Who pays for staff time	Internal engineering and analyst time for design, build, tuning and on-call coverage	Partner time for scoped build and handover, plus internal analyst time for triage and tuning after go-live	Lower internal engineering effort, but analyst time for escalations and environment-specific tuning remains
One-time versus recurring costs	One-time: design, build, initial tuning. Recurring: staff, hardware refresh, rule and signature maintenance, storage growth	One-time: scoped design and deployment. Recurring: your analysts, any retainer for upgrades and tuning, hardware refresh	Largely recurring subscription or service fees, plus internal triage time and any integration work
Upgrades and rule maintenance	Your team tracks Suricata and Zeek releases and tests changes before rollout	Agreed in the retainer or scope. Confirm test environments and change windows	Handled by the provider, with release timing and detection content changes set by their roadmap
Evidence for audit and assessment	You produce sensor configuration, retention and alert records yourself	The partner can prepare documentation and evidence for your assessor. Independent auditors issue any attestation	Provider reports may help, but confirm what logs and records you can export for your own assessor

Who tunes and triages network alerts after go-live

An in-house team owns every alert from the Suricata and Zeek sensors, from first triage through tuning and escalation. Analysts need working knowledge of TCP, TLS, DNS and HTTP behavior, because most false positives come from normal traffic that a rule does not expect. They also need rule-tuning skill to decide when to suppress, threshold or rewrite a signature, and incident handling skill to decide when a detection becomes a case.

Protocol knowledge: analysts read Zeek logs such as conn.log, dns.log and http.log directly, not only the summary alerts.
Rule tuning: the team reviews upstream rule updates from the Suricata and Zeek projects in a staging sensor before they reach production.
Suppression and threshold work: every suppression needs an owner, a reason and an expiry date, so noise reduction does not hide real activity.
New sensor onboarding: the team adds monitored segments, validates capture coverage and updates the sensor inventory.
Handover documents: a tuning log, a suppression register, sensor runbooks and an escalation matrix that a new analyst can follow without the project team.

Before committing to this model, confirm with the platform vendor and your own environment how many analysts are needed for your alert volume and hours of coverage.

How a network security monitoring rollout runs, phase by phase

The sequence moves from an agreed scope to a monitored network that analysts can run without the implementation team. Each phase ends with a written artifact, so the client can check progress before the next phase starts. The timeline follows from the written scope, not from a fixed template.

Agree requirements and scope in writing
The client and DeployOpen confirm which network segments, cloud accounts, and data centers are in scope, which threats and compliance obligations the monitoring must support, who consumes alerts, and what retention is expected. DeployOpen drafts the scope and the client's security and network leads sign it. Done when the signed scope lists in-scope segments, exclusions, owners, and the decisions still open, such as whether Suricata runs in detection only mode or inline prevention.
Survey traffic and map sensor placement
Engineers review network diagrams, routing, VLAN layouts, and cloud flow paths, then identify where mirrored or tapped traffic can reach a sensor. They note encrypted segments, east-west flows, and places where traffic is asymmetric or invisible. Done when the placement map shows each sensor location, the traffic it will see, the gaps it will not see, and the switch or cloud mirror configuration each one depends on.
Size sensors and design packet capture
Using measured or estimated throughput from the survey, the team sizes CPU, memory, disk, and network interfaces for Suricata and Zeek on each sensor. They set how long full packet capture is kept, how metadata logs are retained, and what ingest volume the downstream SIEM must handle. Ask the partner to show the sizing assumptions and the peak traffic figure they used. Done when the sizing record states the hardware profile, capture retention, and storage growth per day under those assumptions.
Build and harden the sensors
Engineers build sensors on the agreed platform, which may be a Security Onion deployment or separately managed Suricata and Zeek hosts. They apply operating system hardening, restrict management access to a separate network, configure time synchronization, enable integrity and update controls, and set up capture permissions. Done when a build record lists versions, configuration files, access paths, and a hardening checklist signed off by the client's infrastructure team.
Establish detection baseline and tune alerts
The team enables the rule sets and Zeek scripts agreed in scope, observes normal traffic for a defined period the client approves, and suppresses or adjusts rules that fire on known benign activity. They record each change with the reason and the analyst who approved it. Done when the tuning log shows every suppressed or modified rule, the justification, and the alert volume before and after tuning.
Integrate with the SIEM and ticketing
Sensor logs and alerts are forwarded to the SIEM, and high-severity alerts create tickets in the client's ticketing system with the fields analysts need. The team tests parsing, timestamps, and field mapping with sample traffic and confirms that alert IDs trace back to packets or flow records. Done when an integration test record shows a set of test alerts arriving in the SIEM and creating tickets with the expected fields.
Onboard analysts and write runbooks
DeployOpen walks the security operations team through the console, alert queues, pivoting from alerts to Zeek logs and packet captures, and escalation paths. They write runbooks for common alert types, triage steps, capture requests, and sensor health checks. Done when the runbook set is approved by the operations lead and each analyst has completed a supervised triage exercise on live or replayed alerts.
Hand over operations and ownership
The team delivers the full documentation package, transfers administrator access, and agrees who owns rule updates, sensor upgrades, capacity reviews, and tuning after go-live. Open items move to a backlog with owners. If the client has chosen a retainer for upgrades or continuous testing, the support boundary is written into the handover. Done when the handover record lists owners, open items, and the signed acceptance of the operating model.

How network monitoring evidence supports HIPAA and FTC Safeguards obligations

Network security monitoring produces records that map to two common US obligations: audit controls over systems that hold ePHI under the HIPAA Security Rule, and monitoring of authorized user activity under the FTC Safeguards Rule. DeployOpen prepares the systems, retention settings and evidence packages, but the auditor or assessor decides whether that evidence is sufficient.

Audit controls for ePHI networks

The HIPAA Security Rule at 45 CFR 164.312 calls for audit controls that record and examine activity in systems containing ePHI. Suricata and Zeek logs of sessions, DNS and file transfers to and from ePHI segments can support that requirement when sensors cover those segments. Check with your compliance lead which systems count as in scope, and confirm that sensor coverage matches that scope before you rely on the logs.

Sensor coverage of in-scope segments

Evidence is only as complete as the traffic it sees. Map each sensor to the network segments that carry ePHI, customer data or administrative access, and record where traffic is not visible, such as encrypted east-west flows or cloud services without a tap. Gaps documented in advance are easier to defend than gaps an auditor finds. Ask your partner for a coverage diagram that the compliance team signs off.

Retention and integrity of records

Auditors look at whether logs are kept long enough and protected from alteration. Define retention periods for raw Zeek logs, Suricata alerts and packet captures separately, since captures are far larger and often need shorter retention. Store logs on write-restricted storage with access logging. Confirm your own retention obligations with counsel and your records policy before setting values in the platform.

Monitoring of authorized user activity

The FTC Safeguards Rule at 16 CFR 314.4(c) calls for monitoring and logging of authorized users. Network metadata shows which hosts connect to which services, including administrative protocols such as SSH and RDP, and when. Pair these records with identity and endpoint logs so that a reviewer can tie a session to a user. Confirm with the assessor whether network metadata alone meets the expectation for your environment.

Encryption in transit evidence

Both rules expect transmission to be protected. NSM can show which sessions run in clear text, such as legacy HTTP, FTP or unencrypted database connections, and which use current TLS. Zeek's SSL and X.509 records can document protocol versions and certificate details. Use these findings to build a remediation list, and record the date each exception was accepted or closed, because auditors ask how exceptions were handled.

Limits of what NSM proves

Network monitoring shows what crossed the wire, not what a user did on a host or whether a control was configured correctly. Packet metadata does not replace access reviews, change records or endpoint logs. State these limits in your evidence package so the auditor sees where NSM ends and other controls begin. Ask the partner to document the mapping of each NSM output to a specific control requirement.

What buyers ask before hiring help for network security monitoring

What drives the cost of a network security monitoring deployment?

Cost is driven mainly by the number and type of sensor locations, the traffic volume each sensor must inspect, how long you retain packet capture and metadata, and how much detection tuning the rollout requires. Software licenses are usually zero for Suricata and Zeek, so most spend is labor: architecture and sensor placement, installation, integration with your SIEM, tuning, and handover. Ask for a quote that separates one-time build work from recurring items such as storage growth, platform upgrades, rule maintenance and staff time for triage. The Security Onion project bundles Suricata and Zeek with a monitoring stack, which can change the component list you need to price.

How long does a network security monitoring deployment take?

The timeline depends on how many network segments need sensors, whether cloud, data center or air-gapped networks are involved, how quickly change approvals move, and how much tuning is expected before alerts are trusted. A small pilot on one segment can move faster than a multi-site rollout with packet capture and storage sizing still open. The rollout phases section explains how these stages are sequenced. Ask any partner to show the written scope, the dependencies on your network team, and the acceptance criteria for each phase before agreeing a schedule.

What does the work need from our internal team?

You need named owners for network access, change approval, switch and tap configuration, and the security staff who will receive alerts. Someone must confirm which subnets matter, where traffic is visible, and which encrypted or sensitive segments may be excluded from capture. Your team also owns retention decisions, access to stored packet data and sign-off on alert handling. Agree these responsibilities in the statement of work so that sensor placement and tuning do not stall while approvals are sought.

Can our team run Suricata and Zeek without outside help?

A capable network or security engineering team can deploy and run Suricata and Zeek, provided it has time for sensor design, rule management, log pipeline work and continuous tuning. The harder parts are usually not installation but deciding where sensors belong, sizing capture for peak throughput, keeping rulesets current without flooding analysts, and wiring output into a SIEM. If those skills or hours are not available, a fixed-scope implementation followed by a support retainer is one option. Compare the build versus partner versus SaaS section before deciding.

How many analysts do we need to triage network alerts?

The answer depends on sensor coverage, how aggressively rules are tuned, and whether alerts are enriched and deduplicated before they reach an analyst. Untuned Suricata rulesets on busy links can generate far more alerts than a small team can review, so tuning and suppression work comes before staffing decisions. Ask the partner to show the expected alert workflow, the severity model and the escalation path, then size the team against your own pilot data rather than a generic benchmark. No reliable headcount figure can be given without observed alert volume from your environment.

How does network security monitoring differ from a SIEM project?

Network security monitoring records and analyzes traffic on the wire, producing detection alerts and protocol metadata from tools such as Suricata and Zeek. A SIEM collects and correlates logs from many sources, including endpoints, identity systems and applications, and handles alerting, search and retention for that data. The two are complementary: NSM provides evidence of network behavior that logs may miss, and the SIEM provides the correlation and case workflow. Projects often fail when they are scoped as one effort, so plan them as linked workstreams. The open source SIEM and log management page covers the SIEM side in more depth.

Does encrypted traffic make network security monitoring useless?

No, but encryption limits what sensors can inspect. Encrypted payloads cannot be read by default, so NSM relies more on metadata such as connection records, TLS handshake details, certificate information, DNS and timing patterns. Zeek is well suited to producing this kind of metadata, and Suricata can still match signatures on unencrypted protocols and some handshake fields. Where decryption is considered, it raises legal, privacy and key-management questions that should be decided before deployment. Ask a partner how they will document visibility gaps so your risk owners understand what the sensors cannot see.

What should we ask a partner before signing?

Ask for a written scope that lists sensor locations, traffic assumptions, packet capture and retention targets, integrations and the acceptance tests for each phase. Request a clear split of one-time and recurring costs, and confirm who maintains rules, upgrades and storage after handover. Ask how the partner documents evidence for your compliance team, such as configuration records, access controls on stored data and monitoring logs, and whether they prepare that evidence without issuing any audit opinion. DeployOpen plans, implements, tests and supports self-hosted platforms in your own environment, and most work is fixed-scope, agreed in writing before it starts. Verify each claim against your environment before you sign.

How DeployOpen scopes, builds, hands over and supports network security monitoring

DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including network detection and traffic analysis. Each engagement starts with a written scope covering sensor placement, capture sizing, integration with existing log and endpoint data, and the staffing model for alert tuning and triage.

How we scope

Written scope covers which network segments get sensors, and where each sensor sits relative to the traffic it must see
Capture sizing is agreed against your stated traffic volumes, retention period and storage location before any hardware or cloud resources are provisioned
The scope names which log sources, such as the SIEM and endpoint telemetry, Suricata and Zeek output will feed into
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts; ongoing support is available as a retainer

How we build

Deploy Suricata and Zeek sensors inside your cloud accounts, data centers or air-gapped networks, with configuration kept under version control
Tune detection rules and Zeek scripts against traffic you have approved, and document every suppression with its reason and owner
Test sensor coverage, packet loss and alert delivery to the SIEM before the monitoring is declared operational
Harden sensor hosts, restrict management access and confirm that captured traffic is stored with the access controls you specify

How we hand over

Deliver architecture diagrams, sensor inventory, rule change logs and runbooks written for your own operations and security staff
Walk your analysts through alert triage, rule tuning requests and how to handle a sensor outage, using your own alert samples
Provide documented evidence of configuration and monitoring coverage that your compliance team can use in an assessment, without claiming audit outcomes
Agree a handover checklist in the written scope so acceptance criteria are clear to both parties

How we support

Retainer support can cover sensor health checks, Suricata and Zeek version upgrades, and rule set maintenance after go-live
Testing services can include network-level security testing to check whether your sensors detect the activity your scope says they should
Backups of sensor configuration and detection content are maintained as part of the operating documentation
Ask any partner to confirm response expectations, upgrade cadence and who on their side is accountable for sensor availability in writing