%201.png)
%201.png)
The Audit and Accountability (AU) domain is the "black box flight recorder" of your system. It provides evidence that things are going right and forensics when something goes wrong. The AU controls focus on tracking user and system activity. It requires your organization to decide what events are important enough to record. A policy should define log creation, logging protections, and log reviews.
Implementing these controls turns your network into a monitored environment. When users know the system records their actions, they are less likely to break the rules. Individual accountability means you can tie a specific action to a specific person. Logs can also reveal system errors before they crash your entire network. Several regulatory requirements mandate organizations to keep logs. These controls ensure you meet relevant legal standards and support incident response capabilities.
Domain level policies address the controls implemented within systems and organizations. Policies are the perfect home to define control parameters, such as frequencies. Procedures describe the implementation of policies or controls. Organizations may document procedures within the system security plan or within separate documents. Here are some of the principles that guided this audit and accountability policy:
A cover page tracks specific details regarding the policy, including:
NIST SP 800-53 defines specific objectives for domain-level policies. From this guidance we incorporate the following major sections into our policy:
The purpose statement should identify why the policy exists and what it aims to achieve.
The scope should identify who it applies to and under what circumstances.
The policy governance section covers most of the organization defined parameters. These subsections cover the following details:
The fourth section includes our policy statements. Subsection headings group related Policy statements together. Each policy statement has a unique number for traceability to other documents. A policy statement number consists of the section, subsection, and policy statement order.
The fifth section identifies the relevant roles and responsibilities identified in the policy. A single, short paragraph describes the responsibilities for each role. The sixth section identifies the supporting procedures. We opted to align our subsection headings with the names of supporting procedures. The seventh section identifies related documents, to include relevant policies. The eighth section documents a revision history. This table captures policy changes, including: version, effective date, approver(s), change summaries. The ninth section captures a formal authorization of the policy by the policy owner.
NIST identified a named set of procedures for each practice within NIST SP 800-171. The assessment guide (SP 800-171A) contains the original mappings. The CMMC assessment guides include this mapping as well. The potential assessment methods and objects section contains a subsection called examine. Within each practice, NIST identified relevant policies, procedures and other artifacts. We used the relevant procedures to organize the section headings within each policy.
This section requires systems that handle sensitive data to record important security events. These events include logins and attempts, system setting changes, and privileged user actions. Systems must send logs in real-time to a central monitoring server. Log entries must show who took the action, the device used, when it happened, and whether the action worked. Staff must review logging settings once a year or after major system changes.
CMMC Objectives Covered in This Section:
Active monitoring requires systems to alert the right people if logging processes fail. This section defines these triggers for alerts and automated actions. Triggers may include full storage or loss of connectivity to a data source. In our policy, if the storage space runs, the system will notify the team and overwrite the oldest data. This ensures the system keeps running while protecting the most recent information. This approach falls in line with the moderate baseline of NIST SP 800-53. Less tolerant organizations may opt to shut the system down when audit storage is full.
CMMC Objectives Covered in This Section:
Designated staff must check audit records for sensitive systems at least once a week. They should look for patterns of suspicious behavior across the whole network. If a system cannot send its logs to the central server, staff must check those logs by hand at least once a month. Anything strange must report it to the Incident Response Team right away. These experts will then compare the data with other events to see if a real attack is happening. Any sign of illegal or unauthorized activity must trigger a formal investigation immediately.
CMMC Objectives Covered in This Section:
A central log server must filter and link records to find possible cyber attacks. This turns massive amounts of data into useful information by spotting suspicious patterns. To help staff focus on important events, the system must hide unneeded or repetitive data. Additionally, the system must allow staff to create custom reports on demand. These reports should let investigators search for specific times, events, or actions.
CMMC Objectives Covered in This Section:
The central log server must be separate from the systems it watches. This prevents a hacker who breaks into one system from changing the audit record. Only a small group of administrators have the power to manage the logging settings or data. Other users with review accounts can only look at the logs and add notes. They cannot change or delete anything. Systems that cannot send data to the central server must keep records for 180 days. These systems must also limit log access to authorized administrators only.
CMMC Objectives Covered in This Section:
You must keep audit records for at least one year to support investigations and meet legal rules. Systems that cannot send logs to the central server must store them for at least 180 days.
CMMC Objectives Covered in This Section:
All information systems must sync their clocks to a central internal time service. Systems use this shared time to create accurate timestamps for every audit record. The internal service should pull from at least two reliable outside sources. This ensures the system stays on time even if one source fails.
CMMC Objectives Covered in This Section:
FedRAMP guidance on how to write a control implementation statement states the following:
Write your policies before you start drafting your security plan. K2 GRC shows you exactly how each part of your policy connects to your security goals.
The input screen shows the specific policy rule and its ID number. This identifies relevant policy statements when writing your system security plan implementation statements. The system then adds your work to the final security plan template.
Protecting your organization’s data is about more than checking a box for compliance. It is about having the peace of mind knowing exactly what is happening inside your network. Without a clear Audit and Accountability policy, you are flying blind. If a breach happens, you could lose data and the trust of your clients. Don't let the stress of complex CMMC requirements keep you up at night. You deserve to feel confident and prepared. Jump start your readiness using the CMMC Audit and Accountability Policy template. This resource turns technical jargon into a clear, actionable road map for your team. Download our policy template today and build the "black box" your organization needs.
