Network security monitoring for public sector: why agency constraints change the design
An agency that must show monitoring coverage to assessors while feeding a central SOC needs sensors placed to see traffic at every enclave boundary, not just at the internet edge. Start by mapping each enclave, its data classification and the control baseline that governs it, then decide where a sensor can see the traffic it must record. Federal systems typically select a baseline from NIST SP 800-53B, where the moderate baseline selects 287 controls and enhancements and the high baseline selects 370, so the monitoring design must answer to SI-4 (system monitoring) and related audit controls in each system's own security plan. State and local bodies work from their own frameworks, such as the FBI CJIS Security Policy where criminal justice information is involved, and the sensor design has to honor the same classification boundaries. Packet capture is the hard part: it can contain sensitive content, so storage location, access and retention must be decided before the first sensor is racked.
Security Onion is the packaged option most agencies evaluate first. It is a Linux distribution that combines the Security Onion Console, Elasticsearch, Suricata, Zeek, Elastic Fleet agents and Suricata full packet capture, so Suricata and Zeek remain the detection and metadata engines underneath and the Elastic stack provides search and storage. The distribution is licensed under the Elastic License 2.0, which is source-available rather than an OSI-approved open-source license. For procurement, that means the agency's legal and acquisition staff should review the license terms against its open-source policy before adoption, and should not assume that a public repository equals an open-source license. Suricata is licensed under GPL-2.0 and Zeek under a BSD-style license, so an agency that wants to avoid the Elastic dependency can assemble the engines directly, at the cost of more integration work.
Before selecting a design, confirm three things with the agency's authorizing official and assessor: which enclaves need their own sensors, which supported operating system and hardware the agency's standards allow (Security Onion 3.x supports only Oracle Linux 9 and x86-64 processors), and whether the sensors must run with no internet access, in which case the airgap workflow and rule updates must be planned from the start. Ask the central SOC team which fields and alerts it needs from each sensor, so that the forwarding path to the SOC is part of the architecture rather than an afterthought. Document these decisions in the monitoring plan, because they are the evidence an assessor will ask to see first.
Which public sector requirements shape the monitoring build
This table compares the federal and public sector requirements that most affect where sensors go, how long data is kept and who can reach it. Read each row for the decision it forces on the build, then confirm the exact obligations with your authorizing official, counsel or assessor. The main takeaway is that the control baseline and the data classification of captured traffic usually matter more than the choice of sensor software.
| Requirement | What it asks for | What it means for sensors, storage and access |
|---|---|---|
| NIST SP 800-53 Rev. 5 baselines and SI-4 | SP 800-53B baselines select 149 (low), 287 (moderate) and 370 (high) controls and enhancements. SI-4 covers system monitoring, including network monitoring for attacks and unauthorized use. | Sensor coverage must be traceable to SI-4 and the baseline your system is authorized under. Keep sensor inventories, rule sources and alert records as the evidence an assessor will request. |
| FISMA and OMB Circular A-130 | FISMA requires agencies to secure their information systems, and Inspectors General independently assess that security and report to OMB. | Expect the monitoring design to be reviewed by an IG or external assessor. Document monitoring scope, roles and review cadence so they can be tested against your system security plan. |
| FedRAMP scope under OMB M-24-15 | Cloud products that create, collect, process, store or maintain federal information on behalf of an agency fall within FedRAMP. Systems used only for one agency's operations on cloud infrastructure, not offered as a shared service, are out of scope. | A hosted sensor, cloud SIEM or managed NDR service that handles agency traffic or logs may need FedRAMP authorization. Confirm the service's status with the vendor and your authorizing official before routing captures to it. |
| CJIS Security Policy v6.1 (effective 26 June 2026) | For criminal justice information, requires FIPS 140-3 certified modules or FIPS 197 AES with 256-bit keys for CJI in transit and at rest outside physically secure locations, and vulnerability scanning at least monthly. | Packet captures and logs that contain CJI need encryption that meets the stated module and key rules. Sensor and storage hardware must support validated cryptography, and scan schedules must cover the monitoring stack itself. |
| 32 CFR 2002.14(h)(2) and NIST SP 800-171 | Federal agencies use NIST SP 800-171 when setting requirements to protect CUI on non-federal information systems, unless the CUI category prescribes other safeguards. | Contractor-run or off-site sensors and SOCs that touch CUI inherit these safeguards. Confirm which CUI categories are in the traffic and whether the NSM host sits on a non-federal system. |
| NIS2 scope for public administration | Covers central government entities regardless of size and lists public administration as a high-criticality sector. Member States may extend it to local administration. It does not apply to entities working in national security, public security, defense or law enforcement. | EU agencies must first confirm whether they fall in scope and under which national transposition. Monitoring obligations and incident reporting timelines should be checked with the national authority, not assumed from this table. |
| OMB M-21-31 packet capture retention | Not stated here. The retention period for full packet capture must be taken from the memo itself. | Confirm the retention rule in M-21-31 with counsel or your assessor before sizing storage. Retention drives disk capacity, backup scope and how long captured traffic must be protected. |
Where agency sensors go by environment
The core is where most east-west and north-south agency traffic converges, so it is usually the first place to put sensors. Placement here gives the broadest view for the fewest devices, but it also concentrates load, so the sensor design has to account for peak throughput.
- Aggregation and core uplinks: Place taps or span ports on links between distribution switches and the data center core, where traffic from many segments is visible at once.
- Data center east-west paths: Add visibility on server-to-server traffic inside the data center, since lateral movement often stays off the perimeter.
- Sensor count: Each sensor needs at least 4 cores, 12 GB RAM and 2 NICs, and Security Onion sensors support only x86-64 processors. Count sensors by link speed and number of monitored segments, not by building.
- Dedicated monitoring path: Use a tap or network packet broker so that span sessions do not compete with production traffic on the switch.
Before finalizing, ask the agency network team to confirm which links carry the most traffic and where encryption terminates, because encrypted flows limit what Suricata and Zeek can inspect at each point.
Branch and field offices are smaller, geographically spread and often connected over WAN links. The priority is usually the traffic that enters and leaves each site, along with any local segments that hold agency systems. Sensor count grows with the number of sites, so the per-site design should be repeatable and cheap to operate.
- WAN edge tap: Monitor the link between each office and the agency backbone or internet breakout, since this captures traffic entering and leaving the site.
- Local user segment: Where a site has a user LAN that reaches agency applications directly, add a span or tap on that segment if the design calls for it.
- Sensor count: Plan one sensor per site as a baseline, then confirm whether a site with high throughput needs a second sensor. The per-site hardware minimums still apply.
- Remote management: Confirm that the sensor can be installed, updated and rebuilt by central staff without site visits, and that the management path is itself monitored.
- Failure behavior: Decide what happens to alerts when a WAN link fails, and whether logs buffer locally until connectivity returns.
Ask the agency to confirm the number of sites, their uplink types and whether any site hosts systems that handle regulated data, since those sites may need the enclave design described in another tab.
Cloud workloads cannot be tapped in the way physical networks can. Visibility usually depends on virtual network mirroring, a sensor running as a virtual machine inside the workload's virtual network, or traffic routed through a monitored gateway. The provider's features determine which option is possible, so the design starts with what the cloud platform exposes.
- Virtual mirroring or gateway routing: Confirm whether the provider offers traffic mirroring for the chosen services and whether mirrored traffic can reach a sensor in the same region.
- Sensor as a virtual machine: A Security Onion sensor running on a virtual machine must meet the same hardware minimums and x86-64 requirement as a physical sensor, so check instance types before sizing.
- Scope check: Cloud services that store, process or transmit federal information on behalf of an agency fall within FedRAMP scope, and a monitoring service that handles that data may need to be assessed as part of it. Confirm the scope determination with the agency's authorizing official before deployment.
- Log and metadata handling: Decide where Zeek and Suricata output is stored, and confirm that the storage location meets the agency's cloud authorization terms.
- Ephemeral workloads: Plan how sensors follow autoscaling or short-lived workloads, since a fixed sensor count may miss traffic on instances that appear and disappear.
Before deployment, confirm with the agency's cloud security office how the FedRAMP scope rules apply to the specific cloud services and monitoring components in use.
Enclaves that handle criminal justice information (CJI) or controlled unclassified information (CUI) are often isolated from the general agency network. Packets inside these zones may contain regulated data, so sensors belong inside the boundary and the design must limit what leaves it. Only metadata and alerts should typically cross to the central SOC, and the agency should confirm that rule with its security authority.
- Sensor inside the boundary: Place a tap or span on enclave links so the sensor captures traffic at the enclave edge and between enclave segments, without sending raw packets outside.
- Metadata forwarding: Forward Zeek logs, Suricata alerts and selected Security Onion events through a controlled path, such as a filtered or unidirectional transfer, so the central SOC receives analysis outputs but not packet payloads.
- Local packet storage: Keep full packet capture on the sensor, encrypted at rest. For CJI outside physically secure locations, the CJIS Security Policy requires FIPS 140-3 certified modules or FIPS 197 AES with 256-bit keys.
- Manager dependency: If the manager node goes down, search nodes stop indexing, so plan a local buffer or a secondary path for enclave logs.
- Sensor count: Each enclave may need its own sensor, so count sensors per boundary, not only per site.
Ask the agency's information security officer to confirm which fields may leave the enclave and to approve the forwarding design in writing before the sensor is connected.
Which open source platforms fit a public sector NSM build
A public sector network monitoring build usually combines a packaged sensor stack, a detection engine, a metadata framework and a sharing or correlation layer. Each platform below fits a different role, and the license, support lifecycle and deployment model matter as much as the detection features when an agency reviews options.
Security Onion as the packaged stack
Security Onion bundles Suricata, Zeek, Elasticsearch and Elastic Fleet, so an agency gets sensors, search and console in one Linux distribution instead of integrating them separately. Its Distributed deployment, with a manager, sensor nodes and search nodes, is the recommended production design. Its license is the Elastic License 2.0, which is source-available rather than OSI-approved, so counsel should review the terms against agency procurement rules. The Pro edition adds OIDC single sign-on, LUKS encryption, FIPS mode and OS STIG compliance, which many agencies will need to evaluate. Security Onion 2.4 reached end of life on October 1, 2026, so new builds should target 3.x on Oracle Linux 9.
Suricata for signature-based detection
Suricata is a GPL-2.0 engine for network intrusion detection, prevention and security monitoring, and it generates the alerts and full packet capture that analysts pivot from. Agencies should confirm which rule sources they are permitted to use, how rules are updated in segmented zones, and who approves suppressions and thresholds. Its GPL-2.0 license is widely accepted in procurement, but the operational work of tuning and rule governance remains in-house or with a partner. Plan a versioned rule change process so the detection baseline can be shown to an assessor.
Zeek for protocol metadata
Zeek is a network analysis framework under a BSD-style license that turns traffic into structured logs for DNS, HTTP, TLS, SMB and other protocols. Those logs support investigations and hunting when a signature does not exist, and they are usually far smaller than full packet capture. Agencies should decide which protocol logs to retain, how long, and where they are stored, since metadata may still reveal sensitive activity. Confirm which Zeek version and scripts your chosen Security Onion release carries before writing the design.
Wazuh for correlation with network data
Wazuh is a GPL-2.0 XDR and SIEM platform that can correlate network alerts with host events, authentication logs and file integrity data. It is useful where an agency already runs endpoint agents and wants one place to correlate network detections with host activity. The decision is architectural: a separate SIEM adds another system to accredit and secure, while Security Onion already includes search and dashboards. Confirm the integration path with the SOC, the log retention obligations and where Wazuh components will be hosted.
MISP for threat intelligence sharing
MISP is an AGPL-3.0 threat intelligence platform used to store indicators and share them with trusted communities. For an agency, it can carry indicators from national or sector sharing groups into Suricata and Zeek detections. AGPL-3.0 requires attention if the agency modifies and offers the software over a network, so legal review is needed. Agencies should confirm the sharing agreements, classification handling and which indicators may leave the agency before connecting MISP to the sensors.
Shuffle for SOC automation
Shuffle is an AGPL-3.0 SOAR platform that can automate triage, enrichment and ticket creation for alerts from the sensor stack. Public sector teams often rely on it to meet internal response timelines with small analyst groups. The main decisions are which playbooks touch production systems, how approvals are recorded, and where automation logs are retained for incident reviews. Because it is a general purpose platform, plan the playbook library and testing as deliberate work rather than a default setup.
How an agency NSM rollout moves from scoping to SOC handover
The sequence turns an agency's control baseline into placed, tuned and documented sensors that feed the central SOC, with each phase closing on a named artifact the agency can review and keep. It is written for agencies planning an NSM rollout with a partner, and the outputs are the same whether the sensors run in a cloud account or on agency premises.
Scope enclaves and map controls to the baseline
The agency and DeployOpen list every network enclave in scope, the system boundary each one belongs to, and the NIST SP 800-53 Rev. 5 baseline that applies (low, moderate or high, as defined in SP 800-53B). The team maps which monitoring requirements, including the SI-4 family, each enclave must satisfy and which owner signs for each mapping. The output is a signed scoping design that names every enclave, its boundary, its control owners and the evidence each control will need. Confirm with the agency's authorizing official whether any overlay or agency-specific parameter changes the baseline before design begins.
Design sensor and tap placement per enclave
For each enclave, the team identifies the points where traffic can be observed without disrupting production, such as span ports, network taps at boundary and east-west choke points, and virtual taps in cloud segments. The design records which segments must be visible for full packet capture and metadata, and where encrypted traffic is decrypted, if at all, under the agency's own policy. The output is a placement diagram per enclave showing each sensor, its feed, its management path and the segments it does not see. Ask the agency to confirm change-control approval for each tap or span change before any cabling work starts.
Size hardware and storage for capture and retention
The team sizes each sensor and each Security Onion node against peak link utilization, the packet capture retention period set in the scoping design, and the metadata volume that Zeek and Suricata will produce. Security Onion supports only x86-64 processors, and the published minimums for standalone, manager, search and sensor roles set the floor for the bill of materials. The output is a sizing worksheet with assumed peak throughput, retention math and a hardware list that the agency can verify against procurement rules. Ask the partner to show how packet loss at peak is measured during the pilot rather than assumed.
Pilot in one enclave and tune rules
The team deploys sensors and a Security Onion node in a single enclave and runs them alongside normal operations long enough to observe real traffic patterns. Rule sets are loaded and reviewed in the Detections interface, where NIDS rules are modified, suppressed or thresholded, and each change is recorded with a reason and an approver. The output is a tuning log that lists every suppressed or modified rule, the traffic that triggered it and the agency owner who accepted the change. Done means the agency signs off that the alert volume is reviewable by the SOC and that known false positives have a documented basis.
Build the production Distributed deployment
The team moves from the pilot to the Distributed deployment type recommended for production, with a manager node, sensor nodes and search nodes, and receiver nodes where the design needs pipeline redundancy. The architecture docs note that search nodes stop indexing if they lose the manager, so the team documents that dependency and the recovery steps for it. The output is an as-built configuration record, network and access diagram, and a tested restore procedure. Confirm with the agency whether sensors and nodes must run without internet access, which determines whether the ISO and airgap update path applies.
Integrate alert routing with the central SOC
Suricata and Zeek data from each enclave is forwarded to the central SOC through the agreed path, and alert routing rules are set for severity, enclave and asset owner. The team tests the routes end to end with known test traffic and confirms that analysts can pivot from an alert to the related packet capture under the agency's access controls. The output is a routing matrix, a runbook for triage handoff and a test record showing each alert path delivered. The SOC lead should confirm the escalation paths and that the agency's SOAR or ticketing integration, if any, receives the same fields.
Assemble the SI-4 evidence pack
The team collects the artifacts that show the monitoring operated as designed: the signed scoping design, placement diagrams, sizing worksheet, tuning log, configuration baselines, alert samples, routing tests and access reviews. Each artifact is mapped to the SI-4 requirement and the enclave it supports so an assessor can trace a control to its evidence. The output is an evidence pack indexed by control and enclave. DeployOpen prepares this evidence for the agency's assessment, but independent auditors and the agency's authorizing official make the determination. Ask the partner to show how the pack is versioned and how packet capture handling is documented under the agency's data rules.
Run recurring upgrade windows and rule reviews
After handover, the team schedules recurring upgrade windows for Security Onion, Suricata, Zeek and the operating system, each tested first in a non-production copy where the agency allows it. Rule sets and tuning entries are reviewed on the agency's cadence, and every change updates the tuning log and the evidence pack. The output is an operations calendar, a change record for each upgrade and a refreshed SI-4 evidence set. Security Onion 2.4 reached end of life on October 1, 2026, so agencies running older releases should confirm their upgrade path against the current end-of-life documentation before scoping the first window.
What auditors and inspectors general ask to see from NSM
This table lists the evidence an agency assessor or Inspector General team typically asks for from a network security monitoring program, the component that produces each item, and what to confirm before the assessment. Use it to build an evidence folder before fieldwork rather than assembling records under deadline. The main takeaway is that sensor and rule records are only persuasive when they show change history and who approved each change.
| Evidence item | Produced by | What to confirm with the assessor |
|---|---|---|
| Sensor placement diagrams | Network design documents and sensor inventory maintained by the agency and partner | Which network boundaries, enclaves and span or tap points the assessor treats as in scope for monitoring |
| Suricata and Zeek configuration | Deployed configuration files on manager and sensor nodes, under version control | Whether the assessor expects the configuration baseline, change approvals or both, and the retention period for prior versions |
| Rule source and update records | Security Onion Detections and the update tool (soup) logs, plus the rule source list | Which rule sources are approved, how offline updates are verified in airgap mode, and the update cadence expected |
| Detections tuning history (modify, suppress, threshold) | Security Onion Console Detections interface audit trail for NIDS rule changes | Whether each suppression or threshold change needs a documented justification, reviewer and expiry date |
| Packet capture retention settings and access logs | Suricata full packet capture configuration and Security Onion access records | The minimum retention period required under the agency's policy and OMB M-21-31, and who may access captured traffic |
| Alert triage tickets | Case management or ticketing system linked to Security Onion alerts | Required fields, closure criteria and the sampling method the assessor will use |
| SOC handover records | Shift logs and handover notes from the agency SOC and any partner staff | Whether the assessor expects evidence of 24-hour coverage, escalation paths and role assignments |
| Vulnerability scan results for sensors | Scanner output for sensor and manager nodes (for example, Greenbone or the agency's scanner) | Scan frequency, remediation deadlines and how accepted risks are documented for the sensors |
| FIPS and encryption settings | Security Onion Pro FIPS mode and LUKS settings if licensed, plus OS and TLS configuration | Whether the agency requires FIPS 140-3 validated modules for data in transit and at rest, and how the validation status is shown |
Questions agencies ask before choosing an NSM partner
What drives the total cost of network security monitoring for an agency?
The total cost is driven by sensor hardware and taps at each site, storage for full packet capture and metadata, analyst and tuning time, and any partner fee. Security Onion is free and open, but the repository is licensed under the Elastic License 2.0, so the license terms should be reviewed with counsel. Hardware is the first cost to size: Security Onion requires x86-64 processors, and the documented minimums are 4 cores and 12 GB RAM for a sensor, 4 cores and 16 GB RAM for a manager or search node, and 4 cores and 24 GB RAM for a standalone node. Packet capture storage grows with traffic and retention period, which the agency's retention rule sets. One-time costs include hardware, installation and tuning. Recurring costs include storage, staff time, and any Security Onion Pro subscription, which is sold on 1 to 5 year terms. Ask for each component as a separate line in a written quote.
How long does a network security monitoring rollout take in an agency?
The timeline depends on the number of sites, the change windows the agency allows, the approval path for network access, and how much tuning the enclave needs before alerts reach the SOC. No duration is set by a researched fact, so the timeline must come from a written scope. A sound scope usually separates the phases: discovery of tap and span points, hardware delivery, installation of a Distributed deployment with a manager, sensors and search nodes, rule loading, tuning, and handoff of alerts to the central SOC. Each phase depends on approvals from the agency, so the agency's own review cycles often set the critical path. Ask the partner to list every dependency and who owns it.
What must the agency provide before a monitoring partner starts work?
The agency must provide accurate network diagrams for each enclave, a list of tap and span points that are physically available, approved change windows for any cabling or sensor work, and named access to enclave staff who can confirm asset ownership and traffic patterns. The agency should also provide its retention requirements for packet capture and metadata, its authentication method for the console, and the rules for any system that holds CJI or controlled data. Without these inputs, sensor placement and tuning become guesswork. Ask the partner to write the list of required inputs into the scope so that delays have a named owner.
Can an agency run network security monitoring without an outside partner?
An agency with trained network and security engineers can run a Security Onion deployment itself, because the platform is free to use and documented for Import, Evaluation, Standalone and Distributed deployments. The harder work is sustained: sensor placement, rule management in the Console Detections interface, suppression and threshold tuning, upgrades and the review of alerts every day. Security Onion 2.4 reached end of life on October 1, 2026, and 2.3 reached end of life on April 6, 2024, so upgrade planning is an ongoing duty. An agency that lacks staff for these tasks should weigh a partner for implementation, hardening and documentation, with a retainer covering upgrades and tuning. DeployOpen delivers these services under written, fixed-scope agreements and ongoing support retainers.
How do FedRAMP and CJIS requirements affect cloud and hosting choices for monitoring data?
FedRAMP scope covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. Systems used only for one agency's operations on cloud infrastructure and not offered as a shared service fall outside that scope, so the agency should confirm with its authorizing official whether its own monitoring stack needs a FedRAMP authorization. CJIS Security Policy version 6.1 took effect on June 26, 2026 and requires FIPS 140-3 certified modules, or FIPS 197 AES with keys of at least 256 bits, for CJI in transit and at rest outside physically secure locations, along with vulnerability scanning at least monthly. Packet capture can contain CJI, so the hosting decision and the encryption method must be settled before sensors are placed. Ask the partner to show where each data store sits and how encryption is configured.
How do airgapped Security Onion upgrades work with soup and ISO media?
Security Onion supports full installs on networks without internet access. The ISO carries packages and NIDS, YARA and Sigma rules, and the soup update tool updates an airgapped node from newer ISO media. The process is to bring the new ISO across the gap through the agency's approved media transfer process, verify it, and then run soup in airgap mode on each node in a planned order. Because the manager must be reachable for search nodes to keep indexing, upgrades should be scheduled in change windows with a rollback plan and a test on a non-production node first. Confirm the agency's cross-domain transfer rules before the first update, and ask the partner to document each step as evidence for the change record.
What should an agency ask a partner to put in the written scope?
A written scope should list the sites and enclaves in scope, the sensor count and placement for each, the hardware specification and who supplies it, the Security Onion deployment type, the rule sources and tuning workflow, the SOC handoff method, the upgrade and support model, and the deliverables such as diagrams, runbooks and evidence for monitoring controls. It should also state what is excluded, such as third-party sensor feeds or Pro features, and name the agency's dependencies. Ask the partner to state how it will evaluate packet loss at peak traffic and how it will document the monitoring evidence that an assessor later reviews. DeployOpen provides these items under fixed-scope agreements, and the quote follows from the written scope.
What to ask an NSM partner before signing a public sector scope
Start with the boundary. Ask the partner to show, in writing, how each sensor location maps to the agency's chosen baseline and to each enclave in scope, and which enclaves they will not cover. Under the NIST SP 800-53B baselines, the low, moderate and high baselines select 149, 287 and 370 controls and enhancements, so the same sensor design can satisfy one agency's SI-4 expectations and leave gaps in another's. Ask who decides sensor placement at enclave edges, which agency system owner signs off on it, and how a sensor moved or added during the engagement is recorded in the system security plan. Ask to see a sample placement diagram for a segmented network before you sign.
Next, ask how sensors are sized and how packet loss is measured. Request the sizing worksheet, the assumed peak throughput per link, and the drop counters the partner will report each month. Ask whether the design uses the Distributed deployment type with manager, sensor and search nodes, and what happens to indexing when the manager is unavailable, since the Security Onion architecture docs say search nodes stop indexing without a reachable Redis. For SI-4 evidence and retention, ask which artifacts are generated, where they are stored, how long they are kept, and who can alter them. Ask the partner to confirm how full packet capture retention is set for each sensor, because that figure is an agency decision that the partner should document rather than assume.
Upgrades deserve a direct question. Security Onion 2.4 reached end of life on October 1, 2026, and the partner should state in writing which version each sensor runs, how each segmented or airgapped zone will move to a supported release, and whether the 2.4 to 3 path applies to the distribution in use or needs a fresh install. Ask how soup updates are staged from newer ISO media in airgap mode, who verifies rule sets after the move, and what rollback looks like. Finally, ask how the partner supports Inspector General and external auditor requests: who answers, within what agreed timeline, and what evidence packages they can produce in the format the assessor uses. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue audit reports or attestations, so the agency should confirm that independent assessors and its own compliance staff remain the decision makers.
