03.03.04 Response to audit logging process failures

What 03.03.04 asks for when audit logging process failures happen

A CUI system that stops recording events, or quietly fills its log storage, is blind to whatever happens next, and 03.03.04 exists so that the organization hears about it in time to act. The requirement asks you to alert designated personnel or roles within a defined time period when an audit logging process fails, and to take further actions you define. Those two items are organization-defined parameters (ODPs). NIST does not set them for you. If your federal customer or contract does not specify values, you must assign them yourself to complete the requirement, so the first decision is writing down the alert window, the recipients and the response actions in your system security plan.

NIST's examples of audit logging process failures include software and hardware errors, failures of log capture mechanisms and reaching audit log storage capacity. NIST's discussion also lists possible responses: overwriting the oldest records, shutting down the system or stopping record generation. Each response is a trade-off. Overwriting keeps the system running but destroys evidence, and shutting down protects the record at the cost of availability. Your choice should follow from the CUI workload and your incident response plan, and it should be recorded so an assessor can see why you picked it. A failure that stops record generation is also a loss of evidence for 03.03.03, so the two requirements should be read together.

Three things usually make this requirement hard. The ODPs are left unset, so the system has no defined time window or action to test. Alerts are routed to a shared mailbox or a single engineer's inbox that nobody checks on a schedule. And failures are never tested, so the first real storage exhaustion becomes the first time anyone learns the alert path is broken. Ask your team to fill the ODP values, name the roles rather than individuals, and run a deliberate test, such as a stopped log shipper or a full test volume, with the alert reaching a person. Keep the test output, because an assessor will ask for it under the test method in SP 800-171A Rev. 3.

Which systems, logs and teams 03.03.04 covers in a CUI environment

The scope of 03.03.04 follows the system security plan boundary for the CUI environment. Every component that produces, carries or stores audit records inside that boundary, and every person or service that must hear about a failure, falls within what the organization must define and test.

Systems that generate audit records

Start with every system inside the CUI boundary that writes audit records: operating systems, directory services, applications, network devices and security tools. For each one, record what happens when its audit process fails, such as a write error, a stopped agent or a full disk. Confirm the list against the system security plan and the system design documentation, since assessors examine both when they test 03.03.04.

Log collectors and transport paths

Agents, forwarders and message queues move audit records from their source to storage. A failure here can silently stop records from arriving even when the source system keeps running. Map each collector and transport path, decide which failures count as audit logging process failures, and confirm that the alert logic covers a collector that stops sending as well as one that reports an error.

Central storage and capacity limits

Central log stores fail when they reach capacity, which NIST lists as an example of an audit logging process failure. Identify where records are stored, how much capacity remains, and which response the organization defines for the oldest records, such as overwriting them, shutting down the system or stopping record generation. Each choice has consequences for retention and availability, so document the decision before an assessor asks about it.

Security and on-call roles that receive alerts

The 03.03.04 parameters require the organization to name the personnel or roles that receive failure alerts and the time period in which they must be notified. Map these to named roles, not individuals, and confirm that the roles include people who can act outside business hours. Interview testing will check whether these people understand their responsibility and can describe the response.

Cloud and third-party logging services

Where audit records flow to a managed logging service, the organization still owns the requirement, but part of the failure detection may sit with the provider. Confirm which failures the provider reports, how and how fast it notifies the customer, and whether the customer can receive those alerts in its own alerting path. Contract terms and the provider's documentation should describe this, and the organization should verify it.

Parameter ownership under the contract

The values for the time period and the additional actions are organization-defined parameters. NIST does not assign them, and if the federal agency does not specify values, the nonfederal organization must set them. Confirm with the contracting agency or DoD contract context whether it has published values, because that decision determines which parameter values an assessor will check.

How an assessor tests audit logging process failure response

This table maps the SP 800-171A Rev. 3 assessment for 03.03.04 by determination statement, method, objects examined, interviewed or tested, and the evidence an assessor expects. Read it as a checklist of what to prepare before an assessment, and note that the two ODP checks are where undefined values most often cause findings.

Assessment element	What the assessor does	Objects and evidence expected	Common findings
Determination statements (two)	Examine the policy and procedures, then confirm the system alerts designated personnel or roles within the defined time period and takes the defined additional actions	Audit and accountability policy and procedures, procedures for responding to audit processing failures, system design documentation, system configuration settings	Procedures describe a response that was never written down, or the configured response does not match the documented one
Examine method	Read documents and settings to confirm the failure response is designed and configured	Alert rules or notification settings, configuration files for the logging component, design diagrams showing where failures are reported	Design documents are generic and do not name the failure conditions covered
Interview method	Ask the people who run logging and security what happens when logging fails and who acts	Personnel with audit and accountability responsibilities, personnel with information security responsibilities, named alert recipients and on-call roles	Staff cannot name the alert recipients or describe the follow-on action
Test method	Trigger or simulate a logging failure and observe whether the mechanism alerts and acts as defined	Mechanisms that implement the system response, such as alert rules, notification channels, storage capacity alarms and failure-handling settings, with test records	Alerts were configured but never tested, so no delivery or timing record exists
ODP check: time period	Confirm the time period for alerting personnel or roles is defined with a value	Documented alert timing requirement, configuration showing the value in use, approval record	Time period is described as prompt or immediate without a measurable value
ODP check: additional actions	Confirm the actions taken on a logging failure are defined with specific values	Documented follow-on actions, such as the approach used when storage is full or when the log capture mechanism stops	No documented follow-on action, or actions that conflict with availability needs and are never applied

Implementing the alert and response chain step by step

This sequence turns 03.03.04 from a policy statement into a working chain: documented parameter values, a complete inventory of logging processes and failure modes, alerts that reach named people in time, and a tested runbook for each failure path. Each step closes with an artifact an assessor can examine.

Set and document the two parameter values
Requirement 03.03.04 leaves two organization-defined parameters open: the time period within which personnel or roles must receive a failure alert, and the additional actions to take when a logging process fails. Confirm with the federal agency that holds the contract whether it has specified either value. If it has not, the organization must assign them, and the decision should be made by the system owner with the security lead and approved by the authority that accepts the system security plan. The output is a signed parameter record that names each value, its owner, its approval date and the review trigger. Confirm that the same values appear in the system security plan, so the assessor can trace them without interviews.
Inventory every audit logging process
List every process that generates, forwards, stores or rotates audit records across the system boundary. This includes application audit trails, operating system and directory logs, network and security device logs, and any collector or log shipper between them. For each process, record the component, the host, the destination, the storage it writes to and the owner. The output is a failure inventory that adds the failure modes NIST describes for this requirement: software and hardware errors, failures of log capture mechanisms and reaching audit log storage capacity. Mark which failures are detectable by the system itself and which are only visible when someone checks the destination, because the second group needs its own detection method.
Configure detection and alerting for each failure
For each inventoried process, define a signal that shows it has failed. Examples include error messages in the application log, a drop to zero records from a source over an expected interval, a failed write, an unreachable collector, and storage usage crossing a threshold the organization sets. Metrics and log-based queries can feed one alerting view, so the same rule set can cover both. Where a platform already writes its own audit trail, such as the admin audit logging in Nextcloud or the request logs that OpenBao audit devices produce, confirm which failures that trail reveals, since a device that stops writing will not log its own stop. The output is a set of alert rules, each with its query, threshold, routing target and the time it must fire, tested against a staged fault before go-live.
Assign receiving roles and coverage
Name the roles that receive each alert class, not only individuals, so the chain survives staff changes. Typical roles are the logging platform owner, the security operations lead and the incident responder on duty. Document how alerts reach them outside working hours, which backup receives an alert if the primary does not acknowledge it, and how the alert routing itself is protected, since a single notification channel is a common point of silent failure. The output is a roster and routing table tied to the time period in the parameter record. Confirm the roster with the people named, and check that the notification path works when the primary logging system is down.
Write the response runbook and its trade-offs
For each failure class, write the actions the responders take, in order. NIST lists possible responses such as overwriting the oldest records, shutting down the system or stopping record generation. Each carries a cost: overwriting destroys evidence that may be needed later, shutdown affects availability and business operations, and stopping generation creates an unlogged gap. The runbook should state which option applies to which failure, who may authorize it, and how the decision and any gap are recorded. It should also include steps to restore capture, verify that records are complete after recovery, and preserve the affected logs for review. The output is a runbook with a decision table, approved by the system owner and linked from the incident response plan.
Test each failure path end to end
Induce each failure class in a non-production or controlled environment and observe the full chain: detection, alert delivery to the named roles, acknowledgment, the runbook action and recovery. Measure the elapsed time against the parameter value, and record any path where the alert did not arrive or the action was not taken as written. Include a test of the storage threshold alert before the disk is actually full. Keep the test logs with the date, the operator, the injected fault, the observed alert time and the outcome. Repeat the tests after any change to the logging pipeline. The output is a set of signed test logs that show each path has been exercised, with corrective actions tracked to closure.
Hand the chain to assessors as evidence
Assemble the artifacts so an assessor can examine the policy and procedures, the system design documentation and the configuration settings, then interview the people who respond to failures. Map each artifact to the determination statements in SP 800-171A Rev. 3 for 03.03.04, which include two checks that the parameter values are defined. Confirm with the assessing body which evidence format it expects. The output is an evidence package with the parameter record, failure inventory, alert configurations, roster, runbook and test logs, indexed by requirement. Independent assessors, not the implementation partner, decide whether the evidence meets the requirement.

Evidence that passes an audit logging failure review

An assessor testing 03.03.04 looks for a defined alert time, defined additional actions, and proof that both work in practice. The artifacts below connect the written design to observed behavior, and each one needs a refresh routine so it still matches the running system at assessment time.

Audit and accountability policy and procedures

The written policy and the procedure for handling audit processing failures are the first things an assessor examines. The procedure should name the roles that receive failure alerts, the time period in which they must be alerted, and the actions to take when logging stops or storage fills. Check that the document reflects the systems in the current boundary, carries an owner and a review date, and was approved by the person accountable for the system security plan. Review it at least when the logging architecture changes.

Documented ODP values

03.03.04 has two organization-defined parameters: the time period for alerting personnel or roles, and the additional actions taken on a failure. NIST does not assign these values, so the organization must set them and record them. Write each value as a specific statement, such as the alert window and the named action sequence, and tie it to the system security plan. An assessor will check that both values are defined before evaluating the determination statements, so an empty or vague parameter fails the check on its own.

Alert rule exports and configuration

Export the alert rules that detect logging failures, such as log capture errors, dropped events, and storage approaching capacity, along with their evaluation intervals, notification policies and recipients. Grafana Alerting can build rules from queries across data sources, so screenshots alone are weak evidence. Keep exported rule files or configuration snapshots in version control, and require change approval for any edit. Confirm the alert window in the rule matches the documented ODP value, since a mismatch is a common assessment finding.

Failure response runbook

The runbook turns the policy into steps that an on-call engineer can follow at night. It should cover how to confirm a logging failure, how to preserve existing records, which of the organization-defined actions to take first, and when to escalate. NIST's discussion lists responses such as overwriting the oldest records, shutting down the system, or stopping record generation, so the runbook must state which response applies to each system and why. Store it with a version and date, and rehearse it against the current architecture.

Failure test records

Assessors expect evidence that the alert and response work, not only that they exist. Run controlled tests such as filling a non-production log volume to capacity or stopping a log shipper, then record the time of the fault, the time the alert reached the designated role, and the action taken. Schedule these tests at a defined interval, retain each record with its ticket and screenshots, and repeat them after any logging change. Failed or late alerts should generate a corrective action with a closure date.

On-call and role assignment records

The alert must reach named people or roles, so keep current records of who holds each role, the rotation schedule, and the escalation path. Review these records whenever staff change, and confirm that notification channels still deliver to active accounts. Remove departed personnel promptly, because an alert sent to an inactive mailbox counts as no alert. Interviews with personnel holding audit and accountability responsibilities are part of the assessment, so staff should be able to explain the role and the response steps without reading from a document.

What meeting 03.03.04 costs in money and effort

This table breaks down the cost and effort of meeting 03.03.04 by component, showing who is paid, whether each cost is one-time or recurring, and what drives it up or down. Use it to build a written scope and to ask vendors and partners for line items that match. The main takeaway is that self-hosting removes license subscriptions but not the recurring work of alerting, on-call response and evidence upkeep.

Cost component	One-time or recurring	What drives it	What to ask for in a quote
Tooling and licenses	Recurring if using commercial alerting or log platforms; the named open-source tools carry their own license terms (AGPL-3.0-only, MPL-2.0, Apache-2.0)	Number of log sources, whether alerting is bundled with a paid tier, and hosting footprint	Itemized list of every component, its license terms, and any paid add-ons required for alerting
Engineering time to configure failure detection	One-time, with periodic rework after upgrades	Number of systems emitting audit logs, heterogeneity of log pipelines, and whether metrics and logs are alerted from one place	Named tasks for detecting write errors, capture failures and storage capacity thresholds, plus the systems covered
Organization-defined parameter and runbook work	One-time, revisited when the alert window or response actions change	Whether the organization already has a defined alert time period and response actions, and how many roles must be notified	Written deliverable setting the alert time period, notified roles, and the additional actions, approved by the organization
Failure testing and simulation	Recurring at the frequency the organization sets	Number of log pipelines, change rate, and whether tests are run in production or a staging copy	Test plan, test frequency, evidence captured per test, and who signs off results
Evidence upkeep	Recurring	Assessment cycle, number of systems in scope, and how often configurations change	Format of evidence packages, retention location, and how records are kept current after each change
On-call and response staff time	Recurring	Alert volume, number of responders, hours covered, and how often logging failures occur	Escalation matrix, staffing model, and whether response is internal, outsourced or shared
External testing or review	Periodic, scoped per engagement	Depth of independent review, whether tests are performed by a separate team, and the size of the environment	Fixed scope, deliverables, retest terms, and whether findings include remediation support
Assessor sampling and effort	Recurring at each assessment	Number of alerts and failure events the assessor samples, and how well records are organized	Confirm with the assessing body what sample evidence it expects before the assessment begins

Which self-hosted open-source tools produce failure alerts and evidence

Under 03.03.04, the organization must alert the right people within a defined time when audit logging fails, then take the actions it has defined. The tools below can each contribute a piece of that chain: a log that records administrative activity, an audit device that records secrets access, an alerting layer that routes notifications, and a metrics store that can show whether logging is still producing data. None of them replaces the organization's own failure definition, alert routing or response procedure.

Nextcloud admin_audit app

The admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit. For 03.03.04, the useful question is whether the audit log keeps growing as expected and whether the log path has stayed writable. A file that stops receiving entries after a configuration change or disk issue is a candidate failure signal. Confirm in your own Nextcloud version and configuration whether the app itself reports write errors or stopped capture, because that behavior is not something to assume from the logging setting alone.

OpenBao audit devices

OpenBao audit devices keep a detailed JSON log of every API request and response, including errors, with most sensitive values hashed using HMAC-SHA256. Errors in this log are evidence of request handling, and a gap in entries can indicate an audit path problem. The key point for 03.03.04 is that OpenBao's documented behavior around an audit device that cannot write is a configuration question, so the team should confirm how failures in an audit device are handled in its deployed version and whether requests are blocked when logging fails.

Grafana Alerting rules

Grafana Alerting builds alert rules from queries and expressions across multiple data sources, and it can alert on metrics and logs together from a single view. For 03.03.04, this is the layer that turns a failure signal into a notification to a defined role. Rules can cover both a log-storage metric and a log-pipeline error count. The team must define the time window the requirement expects, set contact routing to the named personnel or role, and test the notification path, since an alert that reaches no one does not meet the requirement.

Prometheus metrics and PromQL

Prometheus collects metrics from instrumented jobs through a pull model over HTTP, stores them as time series identified by metric name and labels on local storage, and queries them with PromQL. Teams can expose log pipeline health, such as error counters or storage usage, and write PromQL expressions that detect a flat line where entries should appear. Because Prometheus stores data locally, the team should plan how long series are kept and whether the monitoring host is itself covered by the same failure alerts. Confirm the metric names exposed by each logging component in its own version before writing rules against them.

Who does what: your team, an implementation partner and the auditor

Your organization owns the control. The requirement asks you to alert designated personnel or roles within a time period you define when audit logging fails, and to take further actions you define. Those two choices are organization-defined parameters (ODPs), and NIST does not set their values, so if the federal agency that holds your contract does not specify them, you must. Only your leadership can accept the residual risk of a logging gap and decide how quickly someone must act.

ODP decisions: Set the alerting time period and the additional response actions, such as whether the system keeps accepting activity, stops, or overwrites the oldest records, and record the rationale.
On-call roles: Name the roles or people who receive failure alerts, with backups for nights, weekends and leave.
Runbook approval: Approve the response procedure, including who decides to halt processing and who notifies the contracting agency.
Accountability: Keep ownership of the outcome in house, even when a partner builds the tooling.
Recurring work: Review the alert list, the on-call roster and the runbook on a schedule you set, and after each test or real failure.

Check that every ODP value appears in your system security plan and that a named role can be reached within the time you chose.

Where organizations fail 03.03.04 and how to close each gap

Requirement 03.03.04 is easy to satisfy on paper and hard to prove in practice. The gaps below cluster around three questions: whether the organization has actually set its two parameters, whether failure alerts reach someone who acts on them, and whether the response has ever been exercised. Each card names one gap and a concrete step to close it.

Organization-defined parameters left blank

03.03.04 has two organization-defined parameters: the time period within which personnel or roles receive a failure alert, and the additional actions taken when a logging failure occurs. Assessors check that both values are defined, so a requirement without them is incomplete regardless of how well the tooling behaves. Close this by writing the alert window and the specific failure actions into the audit and accountability procedures, then confirming the same values appear in the system security plan. If a federal agency or contract specifies values, record those instead and note the source.

Alerts routed to an unmonitored channel

Many teams configure a failure alert that lands in a shared mailbox, a low-priority channel or a dashboard nobody opens outside business hours. The alert exists, but no designated role acts on it within the defined time. Test the full path by triggering a controlled failure and timing when the named role actually receives and acknowledges it. Record the result as evidence, and name a primary and backup recipient so the requirement does not depend on one person.

Failure response never tested

Assessors look for evidence that the response works, not only that it is described. An organization that has never simulated a full log storage condition or a stopped log collector cannot show that its alerting and actions function. Plan a tabletop or technical test that stops a log shipper or fills a test volume, then record detection time, notification, and the action taken. Repeat the test after significant changes to the logging stack, and keep the results with the change record.

Storage exhaustion with no early warning

NIST's discussion of 03.03.04 lists reaching audit log storage capacity as a典型 logging process failure. The risk is silent: once the volume fills, new records are lost and the gap may not be noticed until someone searches for an event that is missing. Set a warning threshold well below capacity, so the alert fires while there is still time to expand storage or offload records. Check that the threshold alert is separate from the failure alert and reaches the same designated role.

Undocumented choice of further action

The second parameter asks the organization to decide what happens after a failure. NIST's discussion names options such as overwriting the oldest records, shutting down the system or stopping record generation. Each option has a different security effect: overwriting can destroy evidence, while shutdown can stop a business service. Document the chosen action, the approver who accepted the trade-off, and the conditions that would trigger it. An unrecorded choice made during an outage is hard to defend afterward.

Failure response disconnected from incident response

A logging failure can hide an attack, so it belongs in the incident response process. Organizations often have a logging runbook and a separate incident plan that never reference each other. Add an explicit entry point in the incident response plan for audit logging failures, define who declares an incident when logs are lost during a security event, and state how gaps are reported in the plan of action records. Confirm that the roles named in the logging alert are also trained for the incident response role.

Questions buyers ask about 03.03.04 audit logging failure response

What does it cost to implement 03.03.04 and what drives the price?

No public price applies to this requirement, and DeployOpen does not publish a price list, so the cost comes from a written scope. The main cost drivers are the number of logging sources, whether alerting already exists in a monitoring stack, how many systems fall inside the CUI boundary, and how much policy and procedure documentation must be written from scratch. Some work is one-time, such as designing failure detection, writing the response procedure and testing it. Other work recurs, such as reviewing alert rules, rehearsing responses and keeping evidence current. When requesting a quote, ask the provider to separate these two groups and to state which systems, logs and ODP decisions are included.

How long does it take to get 03.03.04 working and what sets the pace?

The pace depends on how many audit logging pipelines exist, how mature the current monitoring is, and how quickly the organization can make decisions about its own parameters. No duration is supplied for this work, so confirm the timeline in the written scope. Delays usually come from waiting on the alert time period and the additional actions to be taken on failure, from getting access to log storage and collectors, and from testing failure conditions on production-like systems without disrupting operations. Plan for a test cycle in which a deliberately induced failure is detected, alerted and handled as the procedure says.

What does the organization need to provide for this work?

The organization must name the owners of the requirement, grant access to the logging systems, and make the decisions that only it can make. Three roles matter most: an accountable owner for audit logging, a named recipient or role for failure alerts, and someone who can approve the response actions, such as whether a system stops generating records or overwrites the oldest entries. The organization also needs to set the two organization-defined parameters for 03.03.04 itself, because NIST does not assign those values. Read-only access to log collectors, storage consoles and alerting tools is usually needed to build and test the controls.

Can an internal team implement 03.03.04 without outside help?

Yes, an internal team can implement 03.03.04 if it has engineers who understand the logging pipeline and staff who can write and approve policy. The work is not especially large in isolation, but it touches logging, monitoring, incident response and documentation at the same time, which is where gaps often appear. Outside help is most useful when the team lacks experience with alerting on logging health, when many heterogeneous systems feed one audit store, or when the evidence must be organized for an assessor. An implementation partner can prepare systems and evidence, but the organization still owns the control and an independent assessor still performs the assessment.

How does 03.03.04 differ from 03.03.03 and 03.03.05?

03.03.04 covers what happens when audit logging itself breaks, such as a software error, a failed log capture mechanism or full storage, and requires alerting within a defined time plus further organization-defined actions. 03.03.03 covers generating and retaining audit records for the selected events. 03.03.05 covers reviewing and analyzing the records for inappropriate or unusual activity and correlating them across repositories. In practice, 03.03.03 creates the records, 03.03.04 makes sure you know when creating them has stopped, and 03.03.05 examines what the records say. An assessor will test each separately, so each needs its own evidence, such as alert rules and response logs for 03.03.04.

Does moving from Rev. 2 to Rev. 3 change the assessment for CMMC Level 2?

For CMMC Level 2 assessments, the requirement is still assessed against the Rev. 2 requirements, so the relevant practice is AU.L2-3.3.4 rather than the Rev. 3 wording. Under 32 CFR 170.14(c)(3), the CMMC Level 2 requirements are identical to Rev. 2, and NIST's change analysis classifies the Rev. 2 to Rev. 3 change for this requirement as significant, with more detail and foundational tasks. Contracts may reference different revisions, and a DoW class deviation names Rev. 2 explicitly. Confirm with the contracting officer which revision governs your contract before scoping the evidence.

Who sets the ODP values for 03.03.04 when the federal agency does not?

If the federal agency does not specify the values, the nonfederal organization must assign them to complete the requirement, because NIST does not assign ODP values. For 03.03.04, the two parameters are the time period within which personnel receive failure alerts and the additional actions to take when logging fails. A pending FAR overhaul proposal would instead have contractors use ODP values published by the DoW CIO, but that rule was not final as of October 2026. Ask the contracting officer whether values have been published, and record your chosen values in the system security plan so an assessor can verify them.

What can a partner not do for 03.03.04 assessment?

A partner cannot issue the assessment result. An implementation partner can design the alerting, configure the logging tools, write the response procedure, run failure tests and organize the evidence. Only the independent assessor or the authority that the contract names can score the requirement and issue the result that goes into the Supplier Performance Risk System. The organization remains responsible for its own controls and for the accuracy of its self-reported score. DeployOpen prepares systems, controls and evidence for compliance assessments, and it does not issue audit reports, attestations or certifications.

How DeployOpen scopes and prepares audit logging failure evidence

DeployOpen works on 03.03.04 by preparing the logging pipeline, failure alerts and response procedures inside your own infrastructure, so your organization can show how it detects and responds to audit logging failures. The organization owns the requirement and its organization-defined parameters, and an independent assessor reviews the result.

How we scope

Written scope names the systems that generate and store audit records and the logging tools in use
Scope records who must receive failure alerts and the time period you choose for alerting
Scope lists the additional actions your organization defines for logging failures, such as preserving the oldest records or halting record generation
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts

How we build

Configure audit sources such as the Nextcloud admin_audit app and OpenBao audit devices to write logs that alerting can see
Build Grafana Alerting rules and Prometheus queries that fire on capture errors, storage thresholds and stopped log flow
Test failure scenarios such as full log storage and failed log capture, then record how alerts and actions behaved

How we hand over

Document the logging failure procedure, alert routing, defined time period and the organization-defined actions in your own policy language
Provide configuration records and test results that map to the examine, interview and test objects in SP 800-171A Rev. 3
Confirm with your assessor which evidence formats they accept, since only an independent assessor issues assessment results

How we support

Ongoing support, upgrades and continuous testing are available as a retainer for alerting rules and logging configuration
Retainer work can review alert routing after staff or system changes and retest failure scenarios on a defined schedule
Confirm with DeployOpen during scoping which support terms apply, since quotes follow from the written scope