SI.L2-3.14.6 Monitor communications for attacks

What SI.L2-3.14.6 requires and why it cannot go on a POA&M

If a CMMC Level 2 assessment is on the calendar, SI.L2-3.14.6 is one of the requirements you cannot afford to leave open. It carries 5 points and must be MET before you can reach Conditional or Final Level 2 status. The requirement asks you to monitor your organizational systems, including inbound and outbound communications traffic, so that attacks and indicators of potential attack are detected. In plain terms, someone or something must be watching the doors and the traffic leaving the building, and you must be able to show that it works. NIST SP 800-171A, the assessment guide behind the Level 2 requirements, splits this into three objectives: monitor the system, monitor inbound traffic, and monitor outbound traffic to detect attacks and indicators of potential attacks. An assessor will test each one separately, so a sensor on the perimeter alone does not satisfy the internal monitoring objective.

The reason this cannot go on a plan of action and milestones (POA&M) is set by the scoring rules. Under 32 CFR 170.24, a 5-point requirement that is NOT MET is subtracted from the maximum score of 110, and 32 CFR 170.21(a)(2) does not allow requirements worth more than 1 point on a POA&M. Your compliance lead should treat this as a go or no-go item for the assessment, not a gap to document and defer. Phase I self-assessments, SPRS postings and annual affirmations remain in place while the Department of War has suspended Phase II, which had required C3PAO certification. That suspension changes when a third party reviews your evidence, not what your score must reflect, so plan as if the assessment could happen on short notice. Confirm the current status with the DoW CIO About CMMC page and with your contracting officer.

Monitoring programs usually fail in predictable ways. The first is unclear placement: the organization cannot show where its monitoring devices or agents sit, such as at the boundary, on internal segments, or on servers that handle CUI, and assessors use that layout as evidence. The second is logs no one reviews. An intrusion detection sensor that writes alerts nobody triages will be tested as a capability, and the assessor will ask for records of alerts, reviews and actions taken. The third is missing documentation: the continuous monitoring strategy and the tools and techniques description must match what the systems actually do. Before the assessment, confirm which sensors cover which zones, pull a sample of alerts with their review and disposition records, and test that an alert fires for a benign simulated event. If any of these checks fails, fix it now, because an unfinished monitoring control cannot be documented as complete later in the assessment window.

Which systems, traffic paths and teams fall under SI.L2-3.14.6

SI.L2-3.14.6 applies to the organizational systems that handle CUI and the communications that reach them, so scope starts with the system security plan. The cards below cover the systems, traffic paths, endpoints and teams that the monitoring must reach, and the decisions that change how much work the requirement creates.

CUI systems and their data flows

Start with every system that stores, processes or transmits CUI, then trace how that data moves in and out. Document each system in the system security plan, including file shares, collaboration tools, engineering applications and backup targets. Systems that only touch CUI indirectly, such as identity providers or management consoles, often fall in scope because they can affect the protected environment. Confirm that the monitoring boundary matches the boundary described in the plan, so an assessor does not find a system that handles CUI but is not watched.

Internet egress and boundary points

Internet gateways, VPN concentrators, email relays and any point where traffic crosses the boundary are the core places to watch inbound and outbound communications. Map each egress path, including paths that bypass the main firewall, such as direct cloud connections or vendor tunnels. Unmonitored egress is a common gap, because outbound traffic carrying CUI or command channels can leave without passing a sensor. Ask the network team to list every route out of the environment and confirm which ones have a monitoring point.

Cloud and remote access paths

Cloud tenants, virtual private clouds and remote access sessions create traffic that does not cross a traditional data center perimeter. Identify which cloud workloads hold CUI, which accounts can reach them, and how remote staff connect. Monitoring placed only at the office network misses these flows. Decide whether sensors run inside each cloud network, whether cloud provider logs feed the monitoring platform, and how remote endpoints report their traffic. Confirm these choices in the system security plan.

Endpoints that talk to external systems

Workstations, engineering laptops and servers that connect to outside services can carry malicious or unauthorized communications even when perimeter sensors are healthy. List endpoint groups that reach external systems, such as build servers, vendor portals and cloud sync clients. Decide where host-based monitoring agents are placed and which outbound destinations trigger review. Check that the agent deployment covers the same systems listed in the asset inventory, since agents missing from some hosts leave silent gaps.

Security operations, network, cloud and IT roles

Monitoring spans several teams. Security operations reviews alerts and records responses, the network team maintains sensors and firewall rules, the cloud team configures tenant logging, and IT manages endpoint agents and asset records. Assign a named owner for each monitoring point and document who reviews which alerts and how escalations reach incident response. Unclear ownership is one of the more common reasons evidence cannot show that monitoring is active and reviewed.

Third-party managed monitoring providers

Some organizations hand alert triage or sensor operation to a managed security provider. The organization still owns the requirement, so the contract must state which monitoring points the provider covers, how alerts reach internal staff, and what evidence the provider supplies. Check whether the provider handles CUI or its metadata, since that can bring the provider into scope. Ask for written responsibilities and confirm that the provider's records can be produced for an assessor.

How an assessor tests SI.L2-3.14.6 monitoring

This table compares the three SP 800-171A assessment objectives for SI.L2-3.14.6, showing what the assessor examines, the evidence requested and the findings that most often leave the requirement unmet. Read each row as one objective that must be satisfied with final evidence before the requirement can be scored as MET.

Objective	What the assessor examines	Evidence requested	Common findings
Monitoring the system	Whether the organization monitors its systems for attacks and indicators of potential attack, and how that monitoring is scoped and governed	Continuous monitoring strategy, system monitoring tools and techniques documentation, and the list of monitored assets	Monitoring strategy exists but does not name the systems in scope, or tools are documented without evidence they run
Monitoring inbound traffic	Whether monitoring covers traffic entering the boundary, including detection at points where external traffic reaches internal systems	Sensor or IDS placement diagrams, boundary sensor configuration, and sample alerts from inbound traffic	Sensors are deployed but rulesets are outdated, disabled or never tuned to the environment
Monitoring outbound traffic	Whether monitoring detects unauthorized data leaving the organization and communication with external systems	Egress monitoring configuration, alert records for outbound flows, and documented review of external destinations	Outbound traffic is not monitored at all, or only inbound traffic appears in the evidence
Intrusion detection testing	Whether intrusion detection and system monitoring actually detect what they are configured to detect	Test results, such as controlled test traffic or simulated indicators, with the resulting alerts and tickets	No test records exist, or tests were run once and never repeated after configuration changes
Indicator coverage	Whether monitoring can surface the indicators listed in the assessment guide, such as malicious code in internal traffic, activity outside business hours, and communication with external systems	Rule or detection content mapped to each indicator class, and records showing alerts generated and reviewed	Rules exist for malware signatures only, with no detection for off-hours activity or unusual external destinations
Monitoring placement	Whether monitoring devices or agents sit at strategic points that see the traffic the requirement covers	Network diagram showing sensor locations, facility or cloud layout, and asset coverage per location	Diagrams are out of date, or cloud and remote segments have no sensor coverage
Alert records and response	Whether alerts are reviewed and acted on, creating an audit trail that shows the monitoring works in practice	Alert logs, review records, tickets or incident entries linked to alerts, and retention settings for these records	Alerts are generated but no reviewer, timestamp or disposition is recorded

How to implement traffic monitoring that passes SI.L2-3.14.6

This sequence takes an organization from defining what traffic it must watch to a tested, documented monitoring capability that an assessor can check against the three SP 800-171A objectives for SI.L2-3.14.6. Each step names the artifact it produces so the final evidence set is built as the work proceeds.

Define the monitored boundary and system scope
The organization owns this step and writes down which systems, enclaves and connections carry CUI and therefore fall inside the monitoring scope. Start from the system boundary already described in the system security plan, then list every point where traffic enters or leaves that boundary, including remote access, cloud connections, email and connections to external service providers. The output is a scope statement and a boundary diagram that the assessor can match against the asset inventory. The step is done when every CUI flow crosses a point on the list.
Place monitoring sensors at strategic points
Assign monitoring devices or agents to the boundary points and to internal segments where malicious traffic would first show up, such as the perimeter firewall, the segment edges and key server zones. Record the reason for each placement, because SP 800-171A treats the locations of monitoring devices as evidence in its own right. The output is a monitoring placement diagram with a short table listing each sensor, its location, the traffic it sees and the owner. The step is done when inbound and outbound paths are both covered.
Build the detection rule baseline
Select the detection content that matches the environment, such as intrusion detection signatures, Sigma rules or vendor rulesets, and document each ruleset source, version and update method. Tune the rules to remove noise that comes from normal business traffic, and add custom rules for indicators tied to the organization's own systems. The CMMC Assessment Guide gives internal traffic showing malicious code, anomalous activity outside business hours, unauthorized data leaving the organization and communication with external systems as examples of indicators to cover. The output is a rule baseline document that maps each rule family to one of these indicators.
Configure log forwarding and central collection
Configure each sensor to send its alerts and flow records to a central collection point so that events can be correlated and retained. Where the tools support it, use structured output such as EVE JSON from Suricata through OPNsense to syslog, and forward those records to an analytics platform such as OpenSearch Security Analytics or Wazuh. Confirm time synchronization across all sources so timestamps line up during review. The output is a data flow diagram and a test showing that a sample alert from each sensor arrives in the central platform. The step is done when each sensor's output is confirmed end to end.
Define alert triage and escalation procedure
Write the procedure that tells analysts how to sort alerts, decide which ones indicate a possible attack, and escalate them into the incident response process. Define who reviews alerts, what severity levels mean, which alerts need immediate action and how each triage decision is recorded. Link the procedure to the incident response capability so that confirmed events move into tracking and reporting. The output is a triage procedure with severity definitions, an escalation path and a record template. The step is done when a named role can follow it without further instruction.
Set the review cadence and monitoring strategy
Document the continuous monitoring strategy that explains how often sensors, rules and alert queues are reviewed, who signs off on the review and how changes to rules are approved. Set a cadence the organization can sustain and state it in the system security plan rather than in informal practice. The output is the monitoring strategy document plus a review log that records each review, its findings and any rule changes. The step is done when at least one review cycle has produced a complete log entry.
Test detection and record the results
Test the monitoring capability by generating controlled, clearly labeled test traffic that resembles the indicators in the rule baseline, then confirm that each sensor and rule raises the expected alert and that the alert reaches the analyst queue. Include a test for outbound traffic to an external destination, since SP 800-171A assesses inbound and outbound monitoring separately. The output is a test record listing each test, the expected result, the observed result, the tester and the date. Keep the record in final form, because assessors do not accept drafts as evidence of a MET result.
Assemble the evidence package for the assessor
Collect the scope statement, boundary and placement diagrams, rule baseline, log flow evidence, triage procedure, monitoring strategy, review log and test record into one evidence package indexed to the three assessment objectives of SI.L2-3.14.6. Check that each document is signed or approved by its owner and that the system security plan references the same sensors and processes. The output is an indexed evidence binder that the independent assessor can review. The step is done when every objective points to at least one final-form artifact.

Evidence that passes SI.L2-3.14.6 and how to keep it current

An assessor will not accept a description of monitoring as proof of monitoring. The artifacts below come from the potential evidence list in NIST SP 800-171A, and each one shows a different part of the 3-objective test: that the system, its inbound traffic and its outbound traffic are monitored for attacks. Every item must be in final form at assessment time, not a draft, and each needs a named owner and a review date.

Continuous monitoring strategy

This document states what is monitored, why, how often alerts are reviewed, who acts on them and how the strategy is updated after architecture or threat changes. The assessor checks that it covers the whole boundary and both traffic directions, not only the perimeter. Keep it current by revising it when the network boundary, monitoring tools or the organization's threat sources change, and record the approval date and approver on each version.

Monitoring tools and techniques documentation

Document each tool that inspects communications, such as an intrusion detection engine, a log analytics platform or a SIEM, with its version, rule sources, what it decodes and where its output goes. The assessor compares this against the system security plan and the tools actually running. Refresh it after each upgrade or ruleset change, and keep the change history so the assessor can see when detection content changed.

Record of monitoring device placement

A current diagram or table showing where sensors, agents and collectors sit, such as at the boundary, between internal segments and at egress points. Placement must match the traffic paths the organization claims to watch, including outbound traffic leaving the CUI environment. Verify placement against the live configuration during each review, since a sensor moved during a network change can silently stop seeing a path.

Network and facility layout

A logical network diagram and, where relevant, a physical layout showing the CUI boundary, the connections crossing it and the monitored chokepoints. The assessor uses it to confirm that the monitoring points cover every entry and exit path. Store it with the system security plan and reissue it whenever a connection to an external system, cloud service or remote access path is added or removed.

Audit records of alerts and dispositions

Exported alert logs paired with a record of what happened to each one: triaged, escalated, closed as benign or linked to an incident ticket. An assessor looks for proof that alerts were reviewed, not only generated. Sample a range of dates and confirm each sampled alert has a documented disposition. Retain these records under the organization's audit log retention rules and keep the review cadence visible.

Intrusion detection test results

Test results showing that detection works, such as a documented test that triggers a known signature or a controlled simulated attack, with the alert produced and the response recorded. Assessment objectives include testing the intrusion detection and monitoring capabilities, so a configuration screenshot alone is weak evidence. Repeat the tests after rule or sensor changes and keep the results with dates, the tester and the observed outcome.

What meeting SI.L2-3.14.6 costs in money and effort

This table breaks down the cost components of monitoring communications for attacks, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to build a quote request, since no price is published for any component and the figures depend on your own traffic, sites and staffing. The main takeaway is that self-hosted open-source tools can remove license spend, but sensor placement, tuning and alert review remain paid effort.

Cost component	One-time or recurring	What drives it	What to ask for in a quote
Sensor hardware or virtual appliances	One-time, with refresh	Number of internet edges, segments and sites where monitoring devices sit; throughput of inbound and outbound traffic	Bill of materials, sizing basis, and who buys and supports the hardware
Detection and log platform licenses	Recurring if commercial; none for most open-source options	Ingest volume, number of endpoints and network devices, and vendor licensing model	Whether the quote includes license fees, support tiers and the cost of any paid rule feeds
Self-hosted operation of open-source platforms	Recurring staff and infrastructure time	Storage for alert and flow records, retention period, and the hosting environment	Hosting assumptions, storage sizing, backup scope and who patches the platform
Engineering time to deploy and tune rules	One-time, with periodic tuning	Number of log sources, custom rules needed, and how much baseline traffic must be learned before alerts are trusted	Deliverables for sensor placement, rule sets, tuning cycles and documented test results
Analyst time for alert review	Recurring	Alert volume after tuning, hours of coverage, and escalation procedures tied to incident response	Expected review model, escalation path and how false positives are handled over time
Evidence upkeep	Recurring	Frequency of monitoring reviews, changes to monitored systems, and how often diagrams and tool documentation change	Who maintains the monitoring strategy, device location records and sample alert records
External testing or review	Periodic	Scope of detection testing, such as whether intrusion detection is exercised with simulated attacks	Test scope, method, reporting format and whether retesting is included
Auditor sampling	Per assessment	Number of monitored boundaries and the assessment method chosen by the independent assessor	Confirmation with the assessor of the evidence they will sample before engagement

Which open-source tools can produce this evidence

SI.L2-3.14.6 asks for proof that traffic and systems are watched for attacks, and assessors look for the sensor, the detection logic and the alert trail. The four tools below cover different parts of that chain: network sensing at the boundary, raw event formats, rule-based correlation, and host and log alerting. Confirm with your assessor which combination matches your system boundary.

OPNsense built-in IPS

OPNsense includes an intrusion detection and prevention system that runs Suricata, with rulesets such as Emerging Threats and Abuse.ch. It can alert on or block matching traffic at the boundary, which is where assessors expect to see inbound and outbound monitoring placed. Check that the rulesets you enable match your threat profile, that alerting is enabled rather than only blocking, and that syslog export in EVE JSON format reaches a system you control. Confirm the license terms (BSD-2-Clause) with your counsel.

Suricata EVE JSON output

Suricata's EVE output writes structured JSON records for rule alerts, anomalies, flows, and protocol transactions such as HTTP, DNS, TLS, SSH and SMB. These records give you evidence of traffic the sensor saw, not only what it blocked, which helps when an assessor asks about outbound communication with external systems. Records can be split into separate files for log management tools. Confirm retention, file permissions and how records are protected from alteration, since those controls are assessed under the audit requirements. Suricata is licensed under GPL-2.0-only.

OpenSearch Security Analytics

Security Analytics runs detectors that match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules. Each match is recorded as a finding with its rule, log type and severity, and alerts can go to channels such as Slack or email. The correlation graph links findings across log types, which helps show indicators that span network and host activity. Your team must tune detectors, define who reviews findings, and document response actions. The project is licensed under Apache-2.0.

Wazuh rules and alert trail

Wazuh decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders, plus any custom rules you write. Matching alerts are written to alerts.log and alerts.json, mapped to MITRE ATT&CK, and forwarded to the Wazuh indexer for dashboard review. Keep the local alert files as part of your audit trail and confirm that alert handling is documented. Assessors will ask whether the rules you rely on were reviewed for your environment, so record your rule selection. Wazuh is licensed under GPL-2.0-only.

Who owns SI.L2-3.14.6, who can help and where the auditor stops

Your organization owns SI.L2-3.14.6. Monitoring the system and its inbound and outbound communications is a operational duty that must be performed, decided and recorded by your people, and no outside firm can accept that accountability on your behalf. Your team decides what counts as an attack indicator for your environment, who reviews alerts, how quickly they are triaged, and when an alert becomes an incident under your incident response process.

Monitoring decisions: Define which systems, network boundaries and cloud accounts are monitored, and where sensors sit at strategic points such as the internet edge, internal segments and egress paths.
Alert review: Assign named staff or a monitored service to review alerts, with documented triage steps and escalation criteria.
Rule ownership: Approve and maintain detection rules, including tuning decisions and the reasons for suppressing any signature.
Records: Keep the monitoring strategy, tool documentation, deployment locations, review logs and tickets in final form.
Ongoing operation: Confirm that sensors keep running, logs keep arriving and reviews keep happening between assessments.

Before any assessment, confirm that someone on your side can explain each of these items from your own records without relying on a consultant.

Where organizations fall short on SI.L2-3.14.6

Most shortfalls on SI.L2-3.14.6 are not missing tools. They are sensors that cover too little of the environment, alerts nobody closes out, and monitoring that cannot be demonstrated to an assessor. Each card below names one gap, the fix, and the evidence that closes it.

Sensors only at the perimeter

Many environments place an intrusion detection sensor at the internet edge and nowhere else. The requirement covers inbound and outbound communications, so an assessor will ask what sees east-west traffic between internal segments and what sees egress toward external systems. Check that monitoring points cover the boundary, the segments holding CUI, and the outbound path. Document where each device sits, using a current network diagram that matches the deployed reality.

Alerts generated but never dispositioned

A detection engine that writes alerts to a dashboard nobody reviews does not show monitoring of attacks. Assessors look for a defined triage path: who reviews alerts, how often, what counts as a true or false positive, and when an alert becomes an incident under the incident response process. Keep a disposition record for each alert class, including the reviewer, the decision, and the follow-up. Without those records, the monitoring is hard to distinguish from logging.

No documented monitoring strategy

Assessment objectives for this requirement expect the organization to show how it monitors its systems, not just that it does. SP 800-171A lists a continuous monitoring strategy and system monitoring tools and techniques documentation as potential evidence. Write down what is monitored, which tools cover which zones, which indicators of attack the team looks for, and how the strategy is reviewed. The strategy should match the system security plan and the actual sensor inventory.

Log retention that cannot be shown

Teams often run detection successfully but cannot produce the logs from a specific date range when an assessor asks. Set a retention period in writing, confirm that network and detection logs from sensors, firewalls and SIEM are retained for that period, and test a retrieval. Record where logs are stored, who can access them, and how integrity is protected. Ask the platform vendor to confirm how its log output can be exported and retained in your environment.

Detection rules never tested

Rulesets from open-source engines are only useful if they fire on the traffic they are meant to catch. SP 800-171A expects tests of the intrusion detection and monitoring capabilities. Run controlled test traffic, such as a benign simulated scan or a known signature from a lab, and record that the alert was generated, routed and reviewed. Repeat the test after rule updates. Keep the test plan and results, because an untested rule is hard to defend as a control.

How much effort, time and outside help SI.L2-3.14.6 needs

What does it cost to meet SI.L2-3.14.6 and what drives the price?

The cost is set by the size and complexity of the environment being monitored, not by the requirement itself, and no public price figure applies to it. Costs fall into three groups: internal staff time to design monitoring, tune alerts and keep records, software and hosting for sensors, log storage and dashboards, and any outside help you buy. The biggest drivers are the number of network boundaries that need sensors, the volume of traffic and logs retained, how many systems in scope feed events into the monitoring stack, and how much of the alert review you staff internally. Ask any partner for a quote built from a written scope that lists the boundaries, sensor locations, log sources, retention period and the deliverables, including the documented monitoring strategy and test records.

How long does it take to put SI.L2-3.14.6 monitoring in place before evidence exists?

Duration depends on how much of the monitoring design already exists and how quickly you can deploy sensors and get logs flowing. Evidence cannot be produced until monitoring has run long enough to show detections, alert handling and documented tuning, so a project that looks finished on the day sensors go live may still lack records an assessor would accept. Plan for time to design the strategy, deploy sensors at the boundary and internal points, connect log sources, test that detections fire, and keep records of reviews. Ask for a timeline with milestones in the written scope rather than relying on a general estimate, and confirm with your assessor or C3PAO what evidence period they expect before you schedule an assessment.

Can our own team meet SI.L2-3.14.6 without an outside partner?

Yes, a capable internal team can meet this requirement if it has the skills and time to build and run the monitoring, and nothing in the rule requires a partner. The work is ongoing, not a one-time install. Your team needs network and security engineering skills to place sensors correctly, write or tune detection rules, review alerts, investigate indicators of attack and document each step. Teams with small staffs often struggle with alert review and proving that monitoring operated consistently. A partner can shorten the build, but the organization still owns the controls and the people who operate them after handover.

What staff time and skills does SI.L2-3.14.6 require from our team?

Ongoing work falls to several roles, and each needs defined time in your plan. Network engineers place and maintain monitoring points at the boundary and at strategic internal locations. Security analysts review alerts, triage indicators such as unusual outbound data flows or activity outside business hours, and escalate under the incident response process. System owners confirm which systems and log sources are in scope. Compliance staff keep the monitoring strategy, tool documentation, deployment locations and audit records current. Expect recurring work for tuning rules to cut false positives, patching the monitoring tools, and reviewing records before each assessment. Document these responsibilities in the system security plan so an assessor can trace them to named roles.

Are open-source tools like Suricata, Wazuh and OpenSearch enough for SI.L2-3.14.6?

Open-source tools can supply much of the technical capability, but they do not satisfy the requirement on their own. An assessor tests whether the system is monitored, whether inbound and outbound traffic is monitored, and whether attacks and indicators are detected, then looks for the documentation and records behind it. OPNsense can run Suricata intrusion detection with rulesets and write EVE JSON alerts to syslog. Suricata's EVE output can split records into separate files for log management. OpenSearch Security Analytics can run detectors against ingested logs using Sigma rules, and Wazuh can compare events against its ruleset and write alerts. Confirm that each tool meets your environment's needs, that its configuration is documented, and that the records it produces are retained and protected.

What can a partner do for SI.L2-3.14.6, and what can it not do?

A partner can plan the monitoring design, deploy and configure the tools in your own infrastructure, integrate log sources, document the monitoring strategy and tool configuration, test detections, and prepare evidence for your assessment. DeployOpen works this way for self-hosted open-source platforms inside a client's cloud accounts, data centers or air-gapped networks, and most engagements are fixed-scope with written deliverables. A partner cannot own your controls, issue an assessment result, or stand in for the assessor. Only an independent assessor, such as a C3PAO for Level 2 certification assessments, can assess and certify. Your organization remains responsible for operating the monitoring after handover, so agree in writing who will run it and how records are kept.

How DeployOpen scopes, implements and prepares SI.L2-3.14.6 evidence

DeployOpen treats SI.L2-3.14.6 as a monitoring design problem: which systems, inbound paths and outbound paths need sensors, and which logs prove that detection works. We plan and deploy self-hosted open-source monitoring inside your own environment, then prepare the configuration, test records and documentation an assessor will review. The organization owns the requirement, and only an independent assessor can judge whether it is met.

How we scope

Confirm the systems inside the CUI boundary and where monitoring sensors must sit to see inbound and outbound traffic.
Document the agreed monitoring coverage, detection sources and alert paths in the written scope before work starts.
Agree in writing which evidence is in scope, such as continuous monitoring strategy, tool documentation and deployment locations.

How we build

Deploy and configure self-hosted network intrusion detection in your infrastructure, with rulesets and alert actions defined in the design.
Connect sensor output and host logs to a self-hosted analytics platform with detection rules and alert routing to named recipients.
Test that detections fire on known malicious and anomalous traffic patterns, and record the results for later review.

How we hand over

Deliver configuration files, deployment diagrams and monitoring tool documentation mapped to the three 3.14.6 assessment objectives.
Provide test records, alert samples and review procedures in final form, so your team can show evidence rather than drafts.
Hand over operating runbooks so your staff can run, review and tune the monitoring without ongoing dependency on us.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, agreed in writing.
Review rule tuning, sensor health and alert volumes at a cadence set in the retainer scope.
Re-test monitoring after system changes, so the evidence stays current between assessments.