SI-4 system monitoring requirements: what the control asks for and why it is hard
SI-4 requires the organization to monitor its system to detect attacks, indicators of attack and unauthorized connections, and to identify unauthorized use. It is a base control in the System and Information Integrity family of NIST SP 800-53 Rev. 5, and SP 800-53B assigns it to the low, moderate and high baselines. If your organization faces an audit, a FedRAMP requirement or a customer contract that cites SI-4, or if your system has no monitoring plan at all, the first job is to show who watches what, with which sensors, and what happens when something fires. The control asks for several distinct things: placing monitoring capabilities strategically and ad hoc, analyzing the events those capabilities detect, adjusting monitoring as risk changes, obtaining a legal opinion on monitoring, and giving monitoring information to defined personnel. Each of these needs a named owner and a record.
The risk SI-4 addresses is simple to state and hard to meet. An attacker who moves laterally, exfiltrates data or uses a stolen credential often leaves traces, but those traces only matter if a sensor captured them and someone acted. Organizations struggle because three things are rarely documented together: which log sources and network segments are monitored, which detection rules or sensors cover them, and who owns each alert queue and its response. A firewall may log to a SIEM that nobody reviews, or a cloud account may produce audit events that never reach the monitoring platform. Before any tool decision, build a single inventory that links each in-scope component to its log source, its detection content and its alert owner, then have the continuous monitoring strategy and the monitoring tool documentation point to the same list. Confirm the legal opinion requirement with your counsel early, because it can hold up a deployment that technically works.
Which systems, sensors and teams fall under SI-4 monitoring
SI-4 scope is set by three inputs: the impact baseline that selects the control and its enhancements, the FedRAMP class if one applies, and the system boundary that determines where sensors must sit. Each card below is a scoping decision that changes the monitoring work, and the owners you name for each one determine who acts on the alerts.
Baseline selection drives enhancements
SI-4 is selected in the low, moderate and high SP 800-53B baselines, but the enhancements change with impact level. The moderate baseline selects SI-4(2), (4) and (5). The high baseline adds SI-4(10), (12), (14), (20) and (22), which bring in more specific detection, automated tooling and outbound traffic expectations. Confirm the system's security categorization before you size the sensor estate, because moving from moderate to high changes the work, not just the paperwork.
FedRAMP class adds a fixed enhancement set
If the system is authorized under FedRAMP Rev5, SI-4 applies at Classes B, C and D, with 7 enhancements at Class C and 14 at Class D. Class D also brings the annual independent assessment expectation for SI-4(1), (2), (10), (16), (19), (20) and (23). Treat the class as a scoping input that can exceed the SP 800-53B baseline, and check the current FedRAMP rules before you design the monitoring layer.
Network segments and boundary points
Place sensors at every point where traffic crosses the authorization boundary, including internet egress, partner connections, VPN concentrators and links between enclaves of different sensitivity. SI-4 expects monitoring devices to be deployed in deliberate locations, so the assessor will ask for a current facility or network diagram that shows where each sensor sits. Record any segment left unmonitored and the reason, because assessors test the gap as well as the coverage.
Hosts, workloads and endpoints
Decide which hosts and containers generate logs that a detection pipeline must ingest. Production servers, bastion hosts, database servers and administrative workstations usually come first. Agents or log forwarders must cover every operating system in the boundary, and the team should confirm that log volume and retention on each host support the detection rules written for it. Ephemeral workloads need forwarding at creation time, because they may disappear before a periodic collector reaches them.
Cloud accounts and control plane logs
Each cloud account, subscription or project inside the boundary needs its control plane activity, configuration changes and network flow records routed to the monitoring platform. Identify every account that can change security settings, including accounts used by automation and break-glass access. Confirm with the cloud provider which log categories are available in your tier, since gaps in control plane logging are a common finding when reviewers test SI-4 coverage.
Identity systems and third-party services
Directory services, single sign-on providers, privileged access tools and any external service that handles authentication or stores boundary data are monitoring sources. Failed logins, role changes and token issuance are the events that reveal unauthorized connections and misuse. Third-party services often hold their own logs, so the agreement with each provider should state how logs reach your platform and who can request them during an investigation.
Alert triage ownership and escalation
Name the team that reviews each alert queue, the on-call owner who can act at night and the criteria for escalating to incident response. Security operations usually owns triage, while platform engineering owns sensor health and the detection rules are signed off by the security lead. Document these roles in the monitoring plan so an assessor can trace an alert from detection through to a recorded decision.
How an assessor tests SI-4 and what they ask to see
This table compares the three SP 800-53A assessment methods (examine, interview and test) for SI-4 and shows what an assessor looks at, what they ask you to produce and where findings usually arise. Read each row as a question the assessor will ask, then check that your monitoring records answer it before fieldwork starts.
| Test method | What the assessor looks at | Evidence requested | Common findings |
|---|---|---|---|
| Examine: continuous monitoring strategy | Whether the strategy states monitoring objectives, what is monitored and how changes in risk adjust monitoring | Approved monitoring strategy with version history and the date of the last review | Strategy names objectives but does not list the log sources or cloud accounts actually monitored |
| Examine: facility diagram or layout and system diagrams | Where monitoring sensors sit relative to boundaries, network segments and administrative paths | Current network and data flow diagrams marking IDS, log collectors and monitoring points | Diagrams are older than the last infrastructure change, so new subnets have no sensor coverage |
| Examine: monitoring tools and techniques documentation | Which detection tools are deployed, what they ingest and which rulesets or signatures are active | Tool inventory, configuration files, enabled rulesets and log source lists with owners | Rulesets were installed but never updated, or disabled rules are not recorded with a reason |
| Examine: locations where monitoring devices are deployed | Physical or virtual placement of sensors at boundaries, internal segments and high-value assets | Sensor deployment register with hostnames, network locations and collection scope | Undocumented sensor coverage, with some segments or hosts not feeding any monitoring tool |
| Examine: alert configuration and records | How detections are turned into alerts, severity levels, and where alerts are routed | Alert routing rules, severity mapping and sample alert records showing timestamps and source | Alerts go to a shared mailbox or dashboard with no named owner or escalation path |
| Interview: system and security operations staff | Whether operators can explain what is monitored, how they triage alerts and when they escalate | Named roles, on-call schedules and documented triage steps confirmed in discussion | Staff describe monitoring differently from the documented strategy, or no one owns tuning |
| Interview: personnel who adjust monitoring after risk changes | How new threats, system changes or incidents change monitoring scope and detection content | Change tickets or risk review minutes that show monitoring was adjusted | Monitoring changes are made informally with no record linking them to a risk decision |
| Test: triggered or sampled event traced end to end | Whether a controlled, detectable event produces an alert that reaches a person who acts on it | Event time, alert record, ticket or case entry and closure note for the same event (illustrative test scenario) | Alert fires but no response record exists, or the response is logged in a tool the assessor cannot access |
| Test: sample of historical alerts | Whether a sample of past alerts shows triage, disposition and analysis as the strategy describes | Random sample of alerts with triage notes, disposition and any escalation records | Alerts are closed without a documented reason, or many alerts show no analyst action |
Evidence that passes SI-4 and how to keep it current
SI-4 is tested through documents, configurations and records that show monitoring was designed, deployed, operated and reviewed. The cards below describe six artifacts an assessor will usually ask to see, and how to keep each one accurate between assessments. No single artifact demonstrates compliance on its own; the assessor decides whether the set supports the control.
Continuous monitoring strategy
This is the document that sets out what the system monitors, why, how often and who acts on the results. SI-4 assessment procedures examine the continuous monitoring strategy, so it must name the monitoring objectives, the attack indicators in scope and the parameters your organization defined for SI-4. Keep it current by tying each revision to a dated change record, and review it whenever the threat assessment or system boundary changes. Confirm the version your assessor received matches the version your teams follow.
Sensor placement and coverage record
SI-4 assessments examine the locations where monitoring devices are deployed, usually against a facility diagram or system layout. Your record should map each sensor, collector or detection point to the network segment, host group or cloud account it watches, and show gaps as well as coverage. Keep it current by reviewing coverage whenever a system, subnet or cloud account is added, retired or moved. Ask the assessor which diagram version they will compare against.
Monitoring tool configuration and rule sets
Detection tools are only as good as the rules they run, so assessors look for exported configurations and rule sets with version history. For open-source platforms such as Wazuh, OPNsense with Suricata, or OpenSearch Security Analytics, this means the active detectors, rule files, decoders and alert destinations. Export configurations on every change and store them under version control with the change ticket that caused them. Confirm that the exported set reflects what was running on the audit date.
Sample alert and triage records
Assessors commonly sample alerts and follow each one from detection through analysis to disposition. Each record should carry a timestamp, the source event, the rule that fired, the analyst's assessment and the action taken, including closure as a false positive. Keep records in a case system or ticketing tool, and retain enough alert history to cover the assessment period. Ask the assessor how many samples they expect and which time window they will draw from.
Legal review of monitoring
SI-4 requires that the organization obtain legal advice on monitoring activity, so keep a dated memorandum or approval that covers what is collected, which employees or users are affected, retention and any notice obligations. Revisit it when monitoring scope changes, when new data sources such as endpoint telemetry are added, or when applicable law changes. Confirm with your counsel which jurisdictions and data protection rules apply to your monitored population.
Distribution records for monitoring information
SI-4 requires that monitoring information reach defined personnel, so assessors look for evidence of who received reports, dashboards or alerts and how. Keep distribution lists, on-call rosters, dashboard access records and periodic summary reports with dates. Review the recipient list when roles change, staff leave or a new team takes ownership of a system. Confirm that the defined personnel in your SI-4 parameters match the people actually receiving the information.
How to implement SI-4 monitoring step by step
This sequence turns SI-4 from a policy statement into a working monitoring capability, with each step producing a record an assessor can examine, interview staff about and test.
Confirm the baseline and enhancements in scope
Start by confirming which SI-4 enhancements apply. SP 800-53B selects SI-4(2), (4) and (5) at the moderate baseline and adds SI-4(10), (12), (14), (20) and (22) at high, and FedRAMP's Rev5 rules add further enhancements for its classes. The system owner and compliance lead should record the impact level, the baseline and any tailoring decisions in the system security plan. Done means a signed scope statement that lists each enhancement and the reason it applies or is excluded.
Write monitoring objectives tied to system risk
Write objectives that state what the monitoring must detect, such as attacks, indicators of attack, unauthorized connections and unauthorized use, and link each objective to a risk in the organization's risk assessment. The security team drafts them and the system owner approves them. Done means a monitoring objectives document where every objective traces to a named risk and to an SI-4 requirement, which gives the assessor a clear test of whether monitoring matches what the organization said it needed.
Map log and traffic sources and sensor placement
Inventory every source that can show an attack or unauthorized connection: hosts, network devices, identity systems, cloud control planes and application logs. For each source, record where the sensor sits, such as a network segment, host agent or cloud log stream, and what gap remains. Assessors examine documentation of monitoring tools and of the locations where devices are deployed, so the facility or architecture diagrams should match this map. Done means a coverage map showing every source, its sensor location and any unmonitored segment with a documented reason.
Deploy collection and detection
Install collectors and detection engines in the client's own environment and configure them to receive the sources from the coverage map. Open-source options include OpenSearch Security Analytics, which runs detectors against ingested logs using Sigma rules and records findings, Wazuh, which decodes events against its ruleset and writes alerts, and Suricata with OPNsense for network intrusion detection. Confirm each product's current capabilities and supported log types in its documentation before committing. Done means a running deployment with a configuration record and a test showing that each mapped source reaches the detection platform.
Build and inventory the detection rules
Turn the monitoring objectives into a rule inventory. Each rule should name the objective it serves, the log source it reads, the severity it assigns and the response it expects. Track custom rules separately from vendor rules, and record who approved each change and when it was reviewed. Where a rule maps to an ATT&CK technique, note that mapping so coverage can be shown. Done means a versioned rule inventory in which every objective has at least one rule, or a documented reason it has none.
Set alert routing and triage ownership
Define where alerts go, who receives them and what the triage steps are. Alert channels such as email or chat should route to a named on-call role, and the escalation path should connect to the incident response plan. Record which person owns triage for each source and what happens when no one responds. Done means a routing table and an escalation procedure, plus a list of named roles that the system owner has confirmed. The assessor will ask staff to explain this path, so the roles must match what people actually do.
Run an end-to-end test event and record the result
Generate a controlled test event, such as a simulated failed login or a test connection to a blocked destination, and follow it from source to sensor, through detection, alert and triage. Record the timestamps and the person who handled it. Repeat the test for each major source group and for each enhancement in scope. Done means a signed test record for each path that shows detection, alert delivery and documented triage. Failed tests should generate a finding in the plan of action and milestones rather than being quietly fixed.
Obtain the legal opinion and set the review cycle
Obtain a written legal opinion confirming that the monitoring complies with applicable law and employee agreements, because SI-4 requires it. Then set a review cycle in which the objectives, coverage map and rule inventory are checked as the risk assessment changes, and record each review and its changes. Ask counsel to confirm the scope in writing, and keep the opinion with the authorization documentation. Done means a dated legal opinion on file and a review schedule that names owners, with each review leaving a record of what changed and why.
Open-source monitoring tools that produce SI-4 evidence
SI-4 asks for evidence that monitoring exists, is placed deliberately, and produces analyzed events. The four tools below each generate a different kind of record, so an assessor can trace a detection from sensor to alert to review. None of them satisfies SI-4 alone. The organization still defines its monitoring objectives, owns the alert review process and decides what to retain.
OpenSearch Security Analytics
Security Analytics under the Apache-2.0 license 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 go to channels such as Slack or email. A correlation engine links findings across log types in a correlation graph. Confirm which log sources, rule packs and correlation features your OpenSearch version and configuration actually enable before you cite them in the SI-4 evidence package.
Wazuh alerts and dashboard review
Wazuh, licensed under GPL-2.0-only, decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders plus any custom rules you add. Matches are written to alerts.log and alerts.json, mapped to MITRE ATT&CK, and forwarded to the Wazuh indexer for review in the dashboard. The assessor will look for proof that someone reviews these alerts and acts on them, so keep the dashboard review records alongside the files. Confirm the ruleset version and any custom rule changes are under configuration control.
OPNsense intrusion detection and syslog
OPNsense ships an intrusion detection and prevention system, licensed under BSD-2-Clause, that runs Suricata against rulesets such as Emerging Threats and Abuse.ch. It can alert on or block matching traffic at the network boundary and send those alerts to syslog in EVE JSON format. This gives you boundary monitoring evidence that is separate from host logs. Confirm which rulesets are enabled, whether blocking mode is on or alert-only, and how the syslog destination is configured and retained.
Suricata EVE records
Suricata, licensed under GPL-2.0-only, writes EVE JSON records for rule match alerts, anomalies, flows, and protocol transactions such as HTTP, DNS, TLS, SSH and SMB. It also records file information, dropped packets and engine statistics. The output can be split into separate files for log management tools, which lets you keep alerts, flows and engine health distinct for review. Confirm which EVE event types are enabled in your configuration, since flow and protocol logging add volume and retention cost.
What meeting SI-4 costs in money and effort
This table compares the main cost components of running SI-4 monitoring, who is paid for each, whether it is one-time or recurring, and what moves it up or down. NIST does not estimate compliance costs, so use the table to shape your own written scope and quote rather than as a price guide.
| Cost component | One-time or recurring | What drives it | How to keep it down |
|---|---|---|---|
| Tooling or licenses | Recurring where commercial | Log volume, number of monitored sources, and whether SIEM or IDS features are licensed per unit | Self-hosted open-source platforms such as Wazuh, OpenSearch and Suricata remove license spend, but hosting, storage and support still apply |
| Engineering time for sensor deployment | One-time, with later changes | Number of hosts, network segments, cloud accounts and sensor placement decisions documented for SI-4 | Agree a written list of sensors and systems in scope before work starts, and reuse configuration templates |
| Rule tuning and detection content | One-time, then recurring | Number of custom rules, false positive rates, and changes in threat or system risk | Start from the built-in rulesets, then tune only for in-scope systems and document each change |
| Storage and retention for log data | Recurring | Event volume, retention periods set by policy, and whether logs are kept in hot or archive tiers | Define retention per log type in the monitoring objectives and archive older data to cheaper storage |
| Alert triage staffing | Recurring | Alert volume, number of on-call analysts, and hours needed to analyze detected events | Tune rules to reduce noise, map alerts to defined response steps, and review trends each cycle |
| Evidence upkeep | Recurring | Frequency of monitoring reviews, records of legal opinion on monitoring, and sensor placement documentation | Generate evidence from the platform where possible and keep one owner for each record |
| External testing or review | Periodic | Scope of independent review and whether monitoring coverage is tested as part of wider security testing | Limit external work to the systems and detections named in the written scope |
| Independent assessor sampling | Periodic | Number of systems and sampled events the assessor selects, and how well records are organized | Prepare sample-ready records for each sensor and alert type before the assessment starts |
Who runs SI-4 monitoring: your team, a partner and the auditor
Your organization owns SI-4. The control asks for monitoring that is tied to defined objectives, so the people who set those objectives, decide what happens when an alert fires and accept the residual risk must be your employees or accountable officers. A partner or vendor can build the tooling, but it cannot decide what your monitoring is for or what your risk tolerance is. Assessors look for this ownership in the documents and in the records of day-to-day decisions.
- Monitoring objectives: Define what the system must detect, such as attacks, indicators of attack and unauthorized connections, and document how those objectives change as risk changes.
- Alert triage and response: Staff a queue, set severity rules and record the disposition of each alert, including false positives and suppressed rules.
- Legal opinion: Obtain and file the legal review that SI-4 requires for monitoring activity, especially where employee or user activity is captured.
- Risk-driven adjustments: Review sensor coverage and rules when the threat picture, system boundary or data sensitivity changes, and record the decision.
- Risk acceptance: Decide which detection gaps are accepted, by whom and for how long.
Before engaging anyone, confirm that a named owner exists for each of these items and that the owner has the authority to make the decision.
An implementation partner such as DeployOpen prepares and deploys the self-hosted monitoring stack inside your infrastructure and assembles the evidence your team and assessor will use. This work is usually outsourced because sensor placement, log pipelines and rule engineering take specialist time. The partner does not decide whether your monitoring is adequate and does not issue an assessment conclusion. Only an independent auditor or assessor does that.
- Sensor deployment: Install and configure network sensors, host agents and log collectors, and document where each device sits in the system.
- Rule engineering: Build, tune and version detection content, for example Suricata rulesets or Sigma-based detectors in OpenSearch, and record the change history.
- Coverage documentation: Produce diagrams and inventories that show monitoring locations and the event sources they cover.
- Evidence assembly: Collect configuration exports, alert samples and review records in a form your team can present to an assessor.
- Handover and runbooks: Train your staff so triage and tuning stay in-house after go-live.
Price these services against a written scope. Ask the partner which artifacts it will hand over, and confirm that your team, not the partner, signs off on the monitoring objectives.
The independent auditor or assessor tests SI-4 against the assessment procedures in SP 800-53A, samples evidence, interviews staff and examines the monitoring design, then issues findings. Independence is what gives the result weight. An assessor who designed the monitoring they are testing cannot judge it objectively, so the partner that builds the stack generally should not also be the assessor for the same control.
- Examine: Review the continuous monitoring strategy, system monitoring documentation and deployment locations against the SI-4 determination statements.
- Interview: Ask triage staff and system owners how alerts are handled and how monitoring changes after a risk event.
- Test: Sample alerts and tickets, check that detections fire for test activity your team authorizes, and verify that logs reach the monitoring platform.
- Findings: Record deficiencies and the basis for each conclusion in the assessment report.
- Scope of role: The assessor reports conclusions. It does not write your objectives or tune your rules.
Before hiring an assessor, confirm its qualifications for your framework, the assessment method it will use and how it handles conflicts of interest with the partner that built your monitoring.
Where SI-4 programs usually fall short and how to close each gap
SI-4 programs rarely fail because a tool is missing. They fail where sensors, owners, rules and scope drift apart from the system as it actually runs. The six gaps below are the ones assessors most often find, and each one closes with a specific artifact or routine that an independent assessor can examine.
Sensors not mapped to the boundary
Monitoring devices are often deployed where someone remembered to install them, not where the system boundary runs. SI-4 assessment objects include the locations within the system where monitoring devices are deployed, and a facility or architecture diagram that shows them. Build a sensor placement register that lists each log source, collector and network tap against a boundary diagram, then check it against the asset inventory each quarter. Confirm with your assessor which diagrams they will accept as the placement record.
Alerts without owners or responses
An alert that reaches a shared mailbox with no named responder is monitoring in name only. Assign each alert source and severity to a documented owner, with the response expected and the escalation path to incident response. Keep the routing matrix in the continuous monitoring strategy so an assessor can trace an alert from detection to a named person and a recorded action. Ask who is on call for each channel and whether that answer is written down.
Detection rules never tuned or reviewed
Rulesets shipped with a platform reflect generic threats, and noisy rules train teams to ignore alerts. Review enabled rules on a set cadence, record which were disabled or modified and why, and track false positive rates per rule. Wazuh, for example, ships a ruleset of over 3,000 built-in rules and decoders, so enabling everything is not a monitoring decision. Keep a change log for rule tuning that ties each change to a documented risk decision.
No end-to-end alert test
Teams often assume a rule fires because it is enabled, but a collector failure, parser error or broken notification channel can silence it without anyone noticing. Run a scheduled test event that travels from the source through the collector, detector, alert channel and ticket queue, and record the result. Keep the test record as dated evidence, and include what happens when a test fails. Ask whether the test covers network sensors as well as host logs.
Monitoring not updated after change
SI-4 expects monitoring to be adjusted as risk changes, so a new cloud account, new application or reclassified data set that lacks coverage is a finding. Tie monitoring scope to the change management process so every significant change triggers a check on sensor placement, log sources and rules. Record the review in the change ticket and reflect it in the continuous monitoring strategy. Ask how a new system gets monitoring before it receives production traffic.
Missing legal review of monitoring
SI-4 requires obtaining legal opinion on monitoring activity, which many programs skip because monitoring is treated as a technical matter. Obtain and file a written legal review that covers employee notice, data protection duties, retention limits and any cross-border transfer of logs. Revisit the review when monitoring scope expands or the governing law changes. Confirm with counsel, not the security team alone, what the review must cover in your jurisdiction.
SI-4 monitoring questions buyers ask before hiring help
How much effort does SI-4 system monitoring take?
The effort depends mostly on how many systems feed the monitoring, how many of the SI-4 enhancements your baseline selects, and whether logs and alerting already exist. SI-4 is in the low, moderate and high SP 800-53B baselines, and the moderate baseline selects SI-4(2), (4) and (5), while the high baseline adds SI-4(10), (12), (14), (20) and (22). Each selected item needs a documented design, working telemetry, tested alerts and evidence that someone responds. Ask any partner for a quote built from your system boundary, your current sensor and log coverage, and the enhancements your authorization requires. Confirm the exact selections against your baseline and your agency or contract requirements before you estimate.
How long does SI-4 implementation take?
The timeline is set by scope, not by the control itself. A single system with existing log collection and an established SOC needs far less time than a multi-enclave environment that must deploy sensors, normalize logs from several sources and write monitoring objectives for each. The work also includes legal review of monitoring, which SI-4 requires as a separate item, so approvals can run in parallel with technical work. Ask for a written schedule with milestones, the systems in scope, and the dependencies on your change windows, procurement and staff availability. Treat any duration given without a written scope as an assumption to challenge.
Can a small team implement SI-4 in-house with open-source tools?
Often yes for a bounded environment, as long as the team can run the tools and maintain them. OpenSearch Security Analytics (Apache-2.0) matches ingested logs against Sigma rules and raises findings and alerts, Wazuh (GPL-2.0-only) ships over 3,000 built-in rules and decoders and maps alerts to MITRE ATT&CK, and OPNsense (BSD-2-Clause) runs Suricata for network intrusion detection with EVE JSON output. Gaps usually sit in sensor placement documentation, tuning and the response process, not in the software itself. Check the licenses, support model and feature set of each product against your own requirements before you commit to a design.
What does SI-4 require from our own staff?
Your staff must own the decisions that an implementation partner cannot make for you. These include setting monitoring objectives, approving where sensors are placed, deciding which events are analyzed and by whom, defining how monitoring changes as risk changes, and obtaining the legal opinion on monitoring that SI-4 calls for. Someone must also run the alert queue, review false positives and keep the rules current. Name an accountable owner for SI-4 and a backup for alert triage before the work starts, because the assessor will ask who acts on a finding and how that person is trained to do it.
Can an implementation partner issue a compliance result for SI-4?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Under FISMA, assessment of agency systems is performed by independent parties, and FedRAMP requires an independent assessment at least once a year for the relevant SI-4 enhancements at Classes C and D. Your organization owns its controls. An independent assessor or certification body decides whether SI-4 is met and issues the report. Ask any partner to state this role in the written scope, and ask your assessor which evidence they expect to examine.
How does SI-4 differ from SI-3 and SI-5 in the SI family?
SI-4 covers monitoring the system itself: detecting attacks, indicators of attack and unauthorized connections, then analyzing the events and alerting on them. SI-3 covers malicious code protection, which is anti-malware at endpoints and at network entry and exit points, with update cadence, scan configuration and response actions. SI-5 covers security alerts, advisories and directives, which is subscribing to external sources such as CISA, distributing those alerts internally and acting on binding directives within required timeframes. SI-3 and SI-4 often share telemetry, but they have different evidence. SI-3 evidence shows scanner coverage and signatures, SI-4 evidence shows sensor placement, monitoring objectives and analyzed events, and SI-5 evidence shows advisory intake and actions taken.
What should a written scope for SI-4 include?
A useful scope names the system boundary and the SI-4 items selected from your baseline, then lists each deliverable with its owner and acceptance criteria. It should cover the monitoring objectives, a sensor placement diagram tied to the system and facility layout, the monitoring tools and their configuration, the rule set and alert routing, a sample of analyzed events with response records, and the process for adjusting monitoring as risk changes. It should also state what the partner will not do, including issuing any assessment result, and it should list your responsibilities, such as access, change approvals and legal review. Ask for the scope to be agreed in writing before work starts, and for pricing to follow from that document.
What evidence will an assessor ask for to test SI-4?
Assessors follow the SP 800-53A procedures for SI-4, which include examining the continuous monitoring strategy, system monitoring tools and techniques documentation, and the locations where monitoring devices are deployed, along with interviews and tests. In practice, expect to show the monitoring strategy, a facility or system diagram with sensor locations, tool configuration exports, rule sets, sample alerts with their disposition, and records that show the monitoring was adjusted after changes in risk. Confirm the exact evidence list with your assessor before you build it, because they decide what is sufficient for your environment.
How DeployOpen scopes and prepares SI-4 monitoring evidence
This sequence takes an SI-4 monitoring requirement from a written scope to an evidence set an independent assessor can test. DeployOpen prepares the systems and documentation, while the organization owns its controls and the assessor issues any report.
Confirm the baseline and enhancements in scope
DeployOpen and the client agree which SP 800-53B baseline applies to the system, then list the SI-4 enhancements that baseline selects, along with any FedRAMP or other overlay requirements that add to them. The client confirms system boundaries, data types and the organization-defined parameters for SI-4, such as the monitoring objectives. Output: a written scope listing each SI-4 item, its owner and the assessor's expected evidence, which becomes the basis for the quote.
Map monitoring sources to the system boundary
Using the agreed scope, DeployOpen inventories the hosts, network devices, cloud services and applications that produce logs or network traffic inside the boundary. The team records where monitoring sensors sit, which mirrors the SP 800-53A examine objects for monitoring device locations and the system monitoring documentation. Output: a monitoring coverage map that the client reviews and signs off before any deployment begins.
Deploy self-hosted monitoring in the client environment
DeployOpen installs the agreed open-source components inside the client's own cloud accounts, data centers or air-gapped network. Typical components include a SIEM and detection layer such as Wazuh or OpenSearch Security Analytics, and network intrusion detection such as Suricata on OPNsense where that fits the boundary. Access, retention and backup settings are configured to the client's policies. Output: running sensors and detection content, with configuration files kept under version control.
Tune detection rules and alert routing
The team loads prepackaged rules, adds custom rules for the client's systems, and sets severity levels and alert channels such as email or chat. Testing uses known benign and simulated suspicious events to confirm that detections fire and that alerts reach the right people. Tuning decisions and false positive handling are logged. Output: a documented ruleset, a test record showing alerts were generated and delivered, and a list of open tuning items.
Document triage ownership and monitoring changes
DeployOpen works with the client to write who reviews alerts, who escalates them, how often monitoring objectives are reviewed, and how monitoring changes when risk changes. The client confirms the legal review of monitoring activity and the distribution of monitoring information to defined personnel. Output: approved procedures and a responsibilities table that the client's control owners sign, so that each SI-4 requirement has a named owner.
Assemble the evidence set for the assessor
DeployOpen collects the artifacts that map to the SP 800-53A assessment objects for SI-4: monitoring strategy, system monitoring tool documentation, diagrams of sensor placement, sample alerts with their triage records, and configuration exports. Each item is indexed to a determination statement and dated. Output: an evidence binder and a gap list. DeployOpen does not judge whether the evidence passes; the independent assessor makes that determination.
Hand over and agree ongoing support
The client receives the operating documentation, admin access records, and a walkthrough of alert handling for its own staff. Any open gaps are listed with proposed owners. Ongoing support, upgrades and continuous testing can be added through a retainer, priced from the written scope. Output: a signed handover record and, where chosen, a retainer agreement. A quote follows from the written scope, and DeployOpen does not publish a price list.
