What SI-6 security function verification asks for and why assessors care
When an audit or FedRAMP assessment is coming and SI-6 is on the list, the assessor wants proof that your security functions still work, not just that they were turned on once. SI-6 requires you to verify that defined security and privacy functions operate correctly at defined times or on command, to alert defined personnel when a verification test fails, and to take defined action such as shutting down, restarting or taking another step you have specified when an anomaly is found. The control is a base control in the System and Information Integrity family, it sits in the high security control baseline under SP 800-53B, and FedRAMP requires it at Classes C and D.
The risk behind the control is silent failure. A firewall rule set gets overwritten by a change, a logging agent stops shipping events, or an endpoint protection service is disabled on a subset of hosts, and nobody notices until an incident shows the gap. SI-6 forces the organization to test those functions on a schedule or after defined transitions, such as restarts, patches or configuration changes, and to know immediately when a test fails. Assessors care because a control that worked at the time of the last review tells them little about today.
The difficulty lies in three definitions the organization must make itself. First, which security and privacy functions are in scope, since the control does not list them for you. Second, how often each function is verified, and which system transitions trigger a verification. Third, what evidence proves each run: a test log, an alert record, a ticket showing who responded and what action was taken. Confirm these decisions with your assessor and your System Security Plan before you build tests, because an assessor will check the defined parameters against the actual operation of the system.
Which systems and functions SI-6 covers and the scoping choices that change the work
SI-6 has no baseline enhancements, so the organization-defined parameters decide how much verification the work carries. The cards below cover the decisions that set that scope and the controls that bound it.
Choosing which security functions to verify
SI-6 applies to the security and privacy functions the organization defines, so the first decision is the list itself. Typical candidates include audit logging, malware protection, access enforcement, encryption and key handling, configuration baseline checks and integrity checks. Each function in the list needs a test that shows it still works, not only that it is installed. Ask the assessor to confirm which functions the system design documentation says must be verified, because the assessment examines that documentation directly.
Defining the verification schedule
The parameters also set when verification runs, either at defined intervals or on command. A schedule that runs daily against a function that changes weekly leaves gaps, and a schedule that runs only on demand leaves no record that checks happened. Record the chosen frequency in the security plan and tie each function to its test and its owner so the assessor can trace the schedule to results.
Identifying transition states that trigger checks
SA-6 assessment objects include a list of system transition states that require security functionality verification. Typical transitions are boot, restart, software or firmware updates, failover, and changes to access control or logging settings. Each transition on the list should have a documented check that runs after it completes. Confirm with the assessor whether your list covers the transitions your operations team performs routinely, not only the ones in the design.
Bringing privacy functions into scope
The control covers privacy functions as well as security functions, so any mechanism that enforces privacy requirements can fall within the parameters. Examples include masking or redaction of personal data, consent flag enforcement and retention deletion jobs. Agree with the privacy office which of these the organization defines, since a privacy function that silently fails can be as serious as a failed security control.
Setting alerting and response for failed tests
When a verification test fails, SI-6 requires alerting defined personnel and taking a defined action, such as shutting down, restarting or isolating the component. The alert route, recipients and response steps are organization-defined, so each must be written down and tested. Confirm the escalation path with the incident response team so a failed test does not sit in a queue unnoticed.
Setting the boundaries with CA-7, CM-4, CM-6 and SI-7
SI-6 sits alongside four related controls. CA-7 covers continuous monitoring, CM-4 covers impact analysis of changes, CM-6 covers configuration settings and SI-7 covers integrity checking. Verification results feed CA-7 reporting, changes that alter a function trigger CM-4 analysis, and CM-6 settings define what each function should look like. Drawing these boundaries early prevents duplicate testing and shows the assessor which control owns each result.
How an assessor tests SI-6 under SP 800-53A
This table walks through how SP 800-53A structures its assessment of SI-6, from the determination statements to the examine, interview and test methods that produce evidence. Read it as a checklist of what to prepare before an assessor arrives, because each row names an artifact or behavior the assessor will look for.
| Assessment element | What the assessor does | What to have ready |
|---|---|---|
| Determination statements | Tests seven statements covering whether verification is performed at defined times or on command, whether failures alert personnel, and whether defined responses follow anomalies | A written mapping from each statement to the system component and the responsible owner |
| Examine: alerts and notifications | Reviews records of failed security verification tests and the notifications sent when they occurred | Alert logs, notification history and the recipient list for each verification function |
| Examine: transition states | Checks the list of system transition states that require security functionality verification, such as startup, restart and failover | A documented list of transition states with the verification performed at each one |
| Examine: design documentation | Reads system design documentation to confirm which security functions are verified and how the verification is designed | Current architecture and design documents that name each verified function |
| Examine: configuration settings | Reviews configuration settings for verification schedules, alert routing and defined responses, along with the related documentation | Exported configuration for the self-test schedule, alert rules and response actions, with change history |
| Interview targets | Asks system administrators, security operations staff and system owners how failures are detected, who responds and what actions follow | Staff who can explain the alert path and the response steps without relying on a single document |
| Test: triggering a failure | Induces or simulates a failed verification test in a controlled environment and watches whether the defined action runs | A test plan, a non-production environment and a record of the simulated failure and the result |
| Test: confirming the alert | Verifies that the failed test generates an alert to the defined personnel within the expected path | Evidence that the alert reached the named recipients, such as a notification log or ticket |
| Common finding: undefined parameters | Notes when the organization has not set the times, triggers or responses that SI-6 leaves to the organization | Completed organization-defined parameter values in the system security plan |
| Common finding: silent tests | Flags verification tests that run on schedule but produce no alert or record when they fail | Proof that a deliberately failed test generates a visible alert and a stored record |
| Common finding: no response evidence | Finds alerts with no documented response action, such as shutdown, restart or escalation | Tickets or runbook records that show the defined action was taken after a failure |
How to implement SI-6 in six steps
The sequence turns SI-6 from a policy statement into a verification program: named security functions, defined test triggers, automated checks, routed alerts, defined responses and a recurring review of results and coverage. Each step produces an artifact an assessor can examine.
Inventory the security and privacy functions
Start by listing the security and privacy functions the system relies on, such as logging, malware protection, access enforcement, encryption settings, time synchronization and the monitoring agents themselves. The system owner, security engineering and the privacy office should agree on the list and map each function to the component that performs it. The output is a function inventory that names each function, its owner and the component it runs on. The step is done when every function that an assessor would expect to see verified appears on the list, with an owner for each.
Set the organization-defined parameters
SI-6 leaves several values for the organization to define, including how often each function is verified, which events trigger an on-command check and which system transition states require verification, such as startup, restart and after a security-relevant change. Record each value against the function it governs and tie it to the system's documented design. The output is a parameter record that lists frequency, triggers and transition states for each function. Ask your assessor to confirm the values are specific enough to test, because vague frequencies are hard to show as met.
Build automated verification tests
For each function, write a test that proves the function works, not only that the component is running. Examples include a policy check that confirms a hardening setting is still in place, a query that confirms an agent is reporting, or a controlled test event that confirms an alert fires. Open-source tools such as Wazuh Security Configuration Assessment, Fleet policies and Prometheus queries can carry many of these checks, and each check should be scheduled according to the parameters from the previous step. The output is a test specification that gives the test, the expected result, the schedule and the tool that runs it.
Route failed tests to named personnel
Connect each test to an alerting path so that a failed verification reaches a named role, not a shared inbox that nobody reads. Grafana Alerting can build rules from metrics and logs across data sources, so a failed check can notify the on-call engineer and open a ticket. Document the routing rules, escalation steps and the people or roles who receive each alert. The output is an alert routing record that shows which test notifies which person or role and how escalation works. Confirm that the routing still works after staff changes, because a stale recipient list is a common gap.
Define the response to each failure
SI-6 requires a defined action when an anomaly is found, which may be a shutdown, a restart, isolation of the component or another action the organization chooses. Write a runbook for each function that states the immediate action, who may authorize it and how the event is documented for later review. Keep responses proportionate, since an automatic shutdown of a production service can create its own availability problem, and record the decision where the organization made it. The output is a response runbook that links each failure type to a defined action and an authorizing role.
Run, record and review results and coverage
Run the tests on the defined schedule and on the defined triggers, and keep each result with a timestamp, the component tested and the outcome. Review the results on a recurring basis, check that every function in the inventory has a test and that every test has run within its parameter, and record any failures, the response taken and the time to resolution. Coverage gaps should feed back into the function inventory. The outputs are a test log, a coverage review and a list of corrective actions. An assessor will usually ask to examine the alert records and the configuration documents alongside these results, so keep them together.
How automated verification tests and alerting fit together
SI-6 asks whether a security function still works, and an assessor will test that with evidence rather than a product list. The chain runs from a defined function, such as endpoint policy checks, log forwarding or alert routing, through a scheduled or on-command verification test, to a recorded pass or fail result, then to an alert sent to defined personnel and a defined action such as isolating a host, restarting a collector or stopping a pipeline. The organization must define each link: which functions are in scope, how often each runs (or what event triggers it, such as a configuration change or a system transition state), who receives the alert, and what response is required. Those definitions belong in the system design documentation and configuration settings that an assessor will examine.
In an open-source stack, the test layer is often a compliance query engine. Fleet policies, for example, are yes or no questions about devices, and the policies page shows which devices pass or fail each policy. Wazuh Security Configuration Assessment scans endpoints against YAML policies and can be extended with custom checks. Prometheus collects metrics that can show whether a collector is still emitting, and Grafana Alerting can route rule-based alerts from metrics and logs to the people named in the response plan. Confirm with each vendor how a failed test is represented, how long results are retained and whether results can be exported in a form your assessor accepts, because the failure history is the evidence that the response actually happened.
Stress one point in your design: a green dashboard or an installed agent does not satisfy SI-6 on its own. Assessors will ask for alert records of failed verification tests, evidence of the response, and proof that the test ran at the defined times or after the defined transitions. Plan a deliberate failure test, such as disabling a logging agent in a non-production environment, and keep the alert, the response ticket and the restored result together. Ask your implementation partner to show that chain end to end before the assessment window opens, and confirm the exact frequencies and recipients with your authorizing official or compliance lead.
Evidence that passes an SI-6 assessment and how to keep it current
An assessor testing SI-6 looks for proof that the defined verification tests run, that failures reach people who act on them, and that the design documents match what is actually configured. The cards below cover each artifact type and the routine that keeps it current between assessments.
Defined functions and parameters list
Start with a written list of the security and privacy functions in scope and the organization-defined parameters that set when and how each is verified. SI-6 has 9 organization-defined parameters in Release 5.2.0, so the list should show the value chosen for each one, such as the verification frequency or the trigger for an on-command test. An assessor will compare this list against the system's security functions, so anything omitted needs a documented reason. Review it whenever a security function is added, removed or changed.
Test definitions and schedules
Keep each verification test as a versioned definition that names the function it checks, the expected result, the method, the owner and the schedule or trigger. The schedule should match the parameter values declared in the function list, and any on-command or transition-state test should point to the event that starts it. Assessors use these definitions to confirm that a test which passed actually checked the function it claims to cover. Store them in version control so changes carry an author and a date.
Timestamped test run logs
Run logs show that each defined test executed at the defined times, with a timestamp, the system or component tested, the result and any error output. Gaps in the sequence are the first thing an assessor checks, so confirm that the scheduler records skipped or failed runs rather than dropping them. Retain the full run history for the period your assessment cycle covers, not only the most recent results. A dashboard showing current status is useful for operators but does not replace the underlying log.
Alert records and notification evidence
SI-6 requires that personnel receive an alert when a verification test fails. Keep the alert rule, the recipient list, and a record of each alert that fired and each notification delivered, with timestamps and acknowledgment where the tool supports it. Examine objects in SP 800-53A include the alerts and notifications for failed verification tests, so an assessor will ask to see a real failure and its trail. Test the alert path on a schedule, because a rule that silently stopped routing is a common finding.
Response records and tickets
The control also requires a defined action when an anomaly is found, such as shutting down, restarting or another action the organization specifies. Each failed test should produce a ticket or incident record that names the responder, the action taken, the time it was taken and the outcome, including whether the function was confirmed working afterward. Link these tickets to the run log entry that triggered them. Assessors often sample a failure and follow it end to end, so the chain from alert to action to verification should be traceable in one place.
System design and configuration documentation
Design documents and configuration settings show which functions exist, how they are verified and what state the system is expected to be in. SP 800-53A examines system design documentation and configuration settings with their associated documentation, so keep the two aligned. Record the configuration baseline for each verification tool, including its policies and the component inventory it covers. Where a verification tool relies on a policy set such as a CIS-based benchmark, note the version used and any local changes.
Transition-state lists
SP 800-53A examines a list of system transition states that require security functionality verification, such as startup, restart, failover, patch application or a major configuration change. Maintain this list as a controlled document and tie each state to the test that runs when it occurs. Review it after each significant architecture change, because new transition paths such as a new replication step or an added service often go unlisted. An assessor will test whether verification happened at each listed state.
Keeping evidence current between audits
Between assessments, run a short routine: confirm the run history is complete for the period, review whether test coverage still matches the function list after each change, and check that alert and response records close the loop. Link verification results to CA-7 continuous monitoring output so that failures appear in the same reporting cycle as other monitoring findings. Record each coverage review with a date and a reviewer, since that record shows the control is maintained rather than set once. Confirm with your assessor which review frequency they expect for your environment.
What meeting SI-6 costs in money and effort
This table breaks down the cost components of meeting SI-6 Security and privacy function verification, who is paid for each, and whether it is one-time or recurring. Read it as a list of what to ask for in a quote, because NIST does not estimate compliance costs and no figures are supplied here.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Defining the security functions in scope | Internal security and engineering staff, or an implementation partner | One-time, revisited on change | Number of defined functions and how many systems share them |
| Building self-test scripts and checks | Platform engineers or an implementation partner | One-time build, then recurring upkeep | Count of functions, test complexity and reuse of templates across systems |
| Tooling and licenses | Vendor or open-source operators (self-hosted tools carry no license fee but need hosting and staff) | Mostly recurring | Self-hosting versus subscription, data volume and number of monitored endpoints |
| Alert routing and response runbooks | Security operations staff and on-call engineers | One-time setup, recurring review | Number of alert paths, escalation tiers and defined responses such as restart or shutdown |
| Evidence collection and upkeep | Compliance lead and system owners | Recurring | Frequency of test runs, retention of alert records and number of systems in the boundary |
| FedRAMP annual assessment at Classes C and D | Independent assessor, paid by the cloud service provider | Recurring every year | Assessor scope, sample size and how well evidence is already organized |
| External testing or assessment support | Independent assessor or testing firm | Recurring or per engagement | Depth of review of the test design and whether assessors sample transitions and configurations |
| Auditor sampling and follow-up questions | Auditor, billed per engagement terms | Recurring with each assessment | Clarity of design documentation and completeness of failed-test alert records |
Open-source tools that produce SI-6 evidence and their limits
Wazuh's Security Configuration Assessment is the most direct source of SI-6 run results among the tools covered here, because it repeatedly checks monitored endpoints against a set of configuration rules and records the outcome. Its policies are written in YAML and are shipped mostly based on CIS benchmarks. Each policy checks files, directories, registry keys and running processes, and the result includes remediation recommendations. The tool is licensed under GPL-2.0-only, so the organization should have its counsel confirm how that license applies to any modifications it distributes.
- Scan output as verification records: Each scan result shows which checks passed or failed on each endpoint, which can serve as dated records of a security function being verified.
- Custom policies: Teams can write their own YAML policies for organization-defined settings, so the checks match the functions named in the SI-6 parameters rather than only generic benchmark items.
- Alerting on failures: Failed checks can feed the organization's alerting path, which is the part of SI-6 that requires notifying defined personnel.
- Coverage limits: A policy only tests what it was written to test. A passing scan does not prove that a self-test of a security function ran at the defined times or on command.
- Transition states: Configuration checks do not detect when a system enters a transition state that the organization has listed for re-verification.
Confirm the scan schedule, the policies in use and the alert destinations against the organization's own SI-6 procedure before citing Wazuh output as evidence.
Fleet policies are yes or no questions asked of devices as osquery queries, such as whether disk encryption is enabled or a required agent is running. The policies page shows which devices in each fleet pass or fail each policy. Fleet is licensed under MIT, which is a permissive license, but the organization still needs to review the terms of any bundled components and its own deployment. Fleet's output is closest to a per-device status record, which makes it useful when an assessor asks which devices met a verification check at a given time.
- Per-device pass or fail: The policies page gives a current status for every device in a fleet, which supports population-level evidence.
- Osquery-based queries: Policies are written as queries, so the organization can express the security function under test in its own terms.
- Scheduled evaluation: Policies run on a recurring basis, which can align with a defined verification frequency if the organization configures it that way. Confirm the evaluation interval in your Fleet version.
- Point-in-time limits: The page shows the latest status, not a full history. Export or retain results separately if the assessor will sample past dates.
- Not a response procedure: A failing policy does not shut down, restart or reconfigure anything unless a separate process does so. SI-6 requires defined actions, and those must be documented and tested outside the tool.
Ask the platform team how long policy results are retained and whether exports can be stored with the rest of the SI-6 evidence set.
Grafana Alerting builds alert rules from queries and expressions across multiple data sources, so it can alert on metrics and logs together and manage those alerts from a single view. For SI-6, it is the most natural place to route notifications when a verification test fails, provided the failing signal is first exported to a data source it can query. Grafana is licensed under AGPL-3.0-only. Organizations that modify Grafana and make it available to users over a network should review the obligations of that license with counsel before deployment.
- Multi-source rules: A rule can combine a metric from one source with a log event from another, which helps when a verification failure appears in both places.
- Notification routing: Alert rules can notify defined personnel, which maps to the requirement to alert defined people about failed verification tests.
- Single management view: Teams can create, manage and act on alerts from one place, which simplifies showing an assessor how alerts were configured and handled.
- Dependency on upstream signals: Grafana does not run verification tests itself. It only alerts on what other tools report.
- Alert history: Retain alert rule definitions and firing history under change control so the organization can show alerts existed during the review period.
Confirm the AGPL-3.0 obligations for your deployment, and document which data sources and rules cover each defined security function.
Prometheus collects metrics from instrumented jobs using a pull model over HTTP. It stores the samples as time series identified by a metric name and labels, on autonomous local storage, and queries them with PromQL. Prometheus is licensed under Apache-2.0. For SI-6, its value is in recording numeric signals over time, such as the result of a self-test exposed as a gauge, the time of the last successful check, or the count of failures per function. Those series give an assessor a timeline rather than a single snapshot.
- Time series history: Stored samples let the team show when a verification check last succeeded and how often it has failed.
- PromQL expressions: Queries can compare the age of the last successful test against the organization's defined interval, which helps detect a missed verification.
- Pull model dependency: Targets must be reachable and instrumented. A function that is not exposed as a metric cannot be evidenced here.
- Local storage limits: Local storage is autonomous, so retention, backup and capacity planning are the organization's responsibility. Confirm the retention period and how the data is protected.
- Self-tests must be written: Prometheus records what a self-test reports. The self-test itself, its triggers and its failure responses must be designed and documented by the organization.
Before relying on Prometheus series as SI-6 evidence, confirm the retention setting and document which exposed metrics correspond to each verified function.
Where SI-6 programs usually fall short and how to close each gap
SI-6 programs tend to fail in the handoffs between a working test and a useful outcome: the parameters are never set, the test runs but nobody is told, or the alert lands with no owner. The cards below take five gaps an assessor is likely to find under the 7 determination statements in SP 800-53A and describe a practical fix for each.
Undefined organization-defined parameters
SI-6 has 9 organization-defined parameters, covering which security and privacy functions get verified, how often or when, who gets alerted and what action follows. When these stay blank, the control cannot be tested against anything. Write a parameter table for the system that names each function, its verification frequency, the trigger events such as reboot or policy change, and the responsible role. Ask the assessor to confirm the values match the system security and privacy plan before testing begins.
Tests that run but never alert
A self-test that passes or fails silently gives the organization no signal when a security function breaks. SI-6 requires alerting defined personnel when verification fails, and SP 800-53A asks the assessor to examine the alerts or notifications generated by failed tests. Route failed results from the check into a monitored channel, such as a dashboard alert rule or ticket queue, and keep a sample alert in the evidence folder. Confirm that a deliberately failed test produces a notification.
Alerts with no named owner
An alert that goes to a shared mailbox often gets acknowledged by nobody. SI-6 expects defined personnel to receive the failure alert, so the assessor will look for a named role, a backup and an escalation path. Map each verification function to an accountable owner in the on-call roster, define the response window in writing, and record acknowledgments. Review the roster when staff change, because stale ownership is one of the most common findings in interviews.
No evidence of response actions
SI-6 requires the system to shut down, restart or take another defined action when a verification fails, and the assessor will ask for proof that this happened. Many programs document the intended response but keep no record of what occurred after a real or simulated failure. Define the response for each function, such as restarting a logging agent or isolating a host, and capture the ticket, command output or configuration diff that shows the action. Run a controlled failure test once a year to produce this evidence.
Coverage limited to endpoints
Teams often verify endpoint security tools, such as configuration checks on servers and laptops, and assume that covers SI-6. The control applies to the defined security and privacy functions of the system, which can include audit logging, access enforcement, encryption settings and privacy controls. The list of transition states and design documentation in SP 800-53A should drive scope. Build the function inventory from the system design documents and check whether each function has a verification test, including the privacy functions the system relies on.
No re-verification after changes
A verification run at deployment does not show that a function still works after a patch, a configuration change or a platform upgrade. SI-6 ties verification to defined times or events, so the assessor will compare the transition states in your list against your change records. Add a re-verification step to the change process for each listed transition, such as a fleet policy check after a rebuild, and log the result against the change ticket. Confirm which change types require re-testing before the assessment.
SI-6 questions buyers ask before bringing in help
How much effort does SI-6 take, and what drives it?
SI-6 takes effort in proportion to how many security and privacy functions the organization must verify, how often it verifies them, and how many system transitions trigger a check. The control asks the organization to define which functions are tested, the times or triggers for testing, the personnel alerted to failed tests, and the action taken on an anomaly. Most of the work sits in those definitions and in building the self-tests themselves, then in keeping alert routing and response steps current as the system changes. A larger, more heterogeneous environment with many transition states raises the effort, and so does a missing baseline of what the security functions are supposed to do. Ask any provider to size the work from your system design documentation rather than from a generic template.
Can our team implement SI-6 without an outside partner?
Yes, an internal team can implement SI-6 if it has the skills to write automated checks against its own security functions, route alerts to named people, and document the response to each failure. The control does not require an external party. Teams usually struggle with three things: deciding which functions count as security functions for the system, proving that the tests themselves run at the defined times, and keeping the evidence trail current across changes. An implementation partner can prepare the tests, monitoring and documentation, which is often faster when staff are already committed to other work. Either way, the organization owns the control and its decisions.
What does SI-6 need from our internal staff?
SI-6 needs named owners who can make decisions that only the organization can make. Those include the security administrator who defines which functions are verified and how often, the operations lead who owns the alert path and the on-call response, and the system owner who approves the defined actions such as shutting down or restarting a component. Staff also need to review failed test results, confirm the tests still match the system design after changes, and sign off on the documentation that an assessor will examine. Ask your provider to name the internal roles needed before work starts, so that approvals do not become the schedule's hidden bottleneck.
How long does SI-6 take to implement?
No researched timeline is available for this control, so treat any duration you hear as unverified. The time depends on the number of functions to verify, the state of existing monitoring tools, the number of internal approvals, and how much design documentation already exists. Ask the provider for a written schedule tied to a written scope, with milestones for definitions, test build, alert routing, response procedures and evidence capture. A fixed-scope agreement makes the schedule easier to hold the provider to, and it lets your team plan its own review time.
Does FedRAMP Class C or D change the SI-6 work?
Yes, the FedRAMP Rev5 baselines require SI-6 at Classes C and D, while the NIST SP 800-53B high baseline also assigns it. The FedRAMP annual assessment rule requires SI-6 to be part of an independent assessment every year at those classes. That means the control must stay operational and evidenced year after year, not only at the initial authorization. Confirm the current class requirements and assessment rules in the FedRAMP rules repository before scoping, because the rules are updated over time. Plan for recurring evidence collection, including alert records and failed-test responses, as part of routine operations.
Can an implementation partner issue the SI-6 assessment result?
No. An implementation partner prepares the systems, self-tests, alert routing and documentation that show SI-6 is in place, but it cannot issue an assessment report, attestation or certification. Under FedRAMP, an independent assessor performs the annual assessment, and under other programs an independent auditor or certification body issues the result. The organization remains responsible for its controls and for the accuracy of what it presents to the assessor. Ask any provider to state its role in writing so that the assessor's independence is preserved.
What should we ask a provider for in a fixed-scope quote?
Ask for a written scope that names the security and privacy functions to be verified, the systems and environments covered, and the transition states that trigger tests. Also ask for the deliverables: test definitions, the automated check configuration, alert routing and escalation records, documented responses for each failure type, and an evidence package mapped to the SP 800-53A examine objects. Request the assumptions behind the price, the internal roles the provider expects you to fill, the acceptance criteria, and what is excluded, such as the independent assessment itself. Finally, ask how changes to scope will be priced and approved in writing, and whether ongoing testing or support is quoted separately as a retainer.
How DeployOpen prepares SI-6 systems and evidence
DeployOpen scopes SI-6 in writing before any work starts. The agreed scope names which security and privacy functions are verified (for example, logging pipeline health, endpoint configuration checks, alert delivery and access controls), the defined times or on-command triggers for each verification, the personnel who receive failed-test alerts, and the transition states that require verification. Because SI-6 asks the organization to define these parameters, the organization owns the decisions, and DeployOpen documents them so the assessor can compare the stated design with what the system actually does. The engagement is fixed-scope, so deliverables and timelines are settled in the written agreement rather than discovered during the work.
On the tooling side, DeployOpen plans, implements and documents self-hosted open-source components inside the client's own cloud accounts, data centers or air-gapped networks. Wazuh Security Configuration Assessment can run recurring checks against endpoints, and Fleet policies can show which devices pass or fail each yes or no check. Prometheus and Grafana Alerting can carry verification signals from the monitored functions into alert rules and notification routes. DeployOpen configures these tools, sets up alert routing to the personnel the client defined, and writes response runbooks that state what happens on a failed test, including any shutdown, restart or other defined action. Whether a given tool covers a specific function should be confirmed against the client's environment during scoping.
The output is an evidence pack organized around the SI-6 assessment objects in SP 800-53A: alert and notification records for failed verification tests, the list of transition states, system design documentation, and configuration settings with their supporting documentation. DeployOpen prepares these artifacts for the client's assessor, but DeployOpen does not issue audit reports, attestations or certifications. Only an independent assessor or certification body does that. Ongoing testing, tool upgrades and support after go-live are available as retainers, which matters for SI-6 because FedRAMP Classes C and D require the control in an independent assessment every year. Ask any partner to confirm in writing who maintains the verification logic after handover.
