Audit Logging, Monitoring, and Accountability for CPCSC

Most organizations produce logs. Application servers generate them, firewalls record them, identity providers track them. The volume is rarely the problem. The problem is that producing logs and operating an auditable monitoring program are two fundamentally different activities, and ITSP.10.171 expects the latter.

The distinction matters because the CPCSC certification program does not ask whether an organization collects logs. It asks whether the organization defines which events require logging, captures sufficient detail in each record, reviews those records on a defined cadence, responds to anomalies with documented rationale, and retains the evidence long enough to support investigation. That chain, from event definition through retention and response, is what separates a logging configuration from an accountability program.

This post covers the two ITSP.10.171 control families that address this challenge directly: Audit and Accountability (AU) and Security Assessment and Monitoring (CA). Together, they define what it means to not just log events but to prove that someone was watching, responding, and improving.

Audit and Accountability (AU): What ITSP.10.171 Requires

The AU family covers the lifecycle of audit records, from deciding what to log through storing, reviewing, and protecting those records. It draws from the same NIST SP 800-171 Rev 3 lineage as the rest of ITSP.10.171, and organizations familiar with NIST SP 800-171 will recognize the structure. The requirements break down into several operational areas.

Audit Event Definition

The starting point is defining which events the organization considers auditable. This is not a default logging configuration shipped with an application. ITSP.10.171 expects a deliberate decision about which events carry security significance: authentication successes and failures, privilege escalations, access to controlled information, changes to security configurations, account modifications, and administrative actions.

Content of Audit Records

Defining which events to log is only the first requirement. ITSP.10.171 also prescribes what each record must contain: the type of event, when it occurred, where it occurred, the source of the event, the outcome (success or failure), and the identity of the user or process involved. The standard expects records detailed enough to reconstruct what happened without ambiguity.

In practice, this means timestamp precision matters, timezone consistency matters, and the correlation between an identity in a log entry and an actual person or service account must be traceable. Logs that record an IP address but not a user identity, or that capture a username but not the action outcome, fall short of the content requirements.

Audit Storage and Protection

Audit records must be retained long enough to support after-the-fact investigation and must be protected against unauthorized modification or deletion. The standard expects controls that prevent a compromised account from erasing evidence of the compromise.

This means centralized log storage with access controls separate from the systems being monitored. If an administrator can delete both the system logs and the centralized copies, the protection requirement is not met. Write-once storage, log forwarding to a separate security boundary, or immutable log retention in a cloud-native logging service are all implementation paths that satisfy the intent.

Audit Review, Analysis, and Reporting

This is where the AU family diverges most sharply from what organizations actually do. ITSP.10.171 does not just require that logs exist. It requires that someone reviews them, that the review happens on a defined schedule, that anomalies are investigated, and that the investigation produces a documented outcome.

Audit Reduction and Report Generation

At volume, raw audit data becomes unmanageable. The standard expects organizations to have the capability to reduce audit data into meaningful reports, whether through automated correlation, SIEM queries, or structured review procedures that filter noise from signal. The goal is operational: audit data should inform decisions, not just fill storage.

Security Assessment and Monitoring (CA): Continuous Oversight

The CA family shifts focus from individual audit records to the health of the security program as a whole. Where AU asks whether events are being logged and reviewed, CA asks whether controls actually work, whether known weaknesses are tracked, and whether monitoring is continuous.

Security Assessments

ITSP.10.171 requires organizations to assess their security controls, not just implement them. This means testing whether controls operate as intended, whether gaps exist between policy and practice, and whether the program is achieving its security objectives. The assessments must produce findings, and those findings must be addressed.

For Level 2 certification, this takes a formal turn: assessments must be conducted by independent assessors accredited through the Standards Council of Canada. The organization cannot simply self-certify that its controls work. This is a structural difference from Level 1, where self-assessment and attestation through Canada Buys is sufficient.

Plan of Action and Milestones (POA&M)

When assessments identify weaknesses, ITSP.10.171 expects a documented plan to address them. The Plan of Action and Milestones is not optional and not aspirational. It is a tracked artifact that records what was found, what the organization intends to do about it, who is responsible, and when the remediation is expected to be complete.

Organizations accustomed to SOC 2 will recognize this as similar in intent to management response letters and remediation tracking, but more structured. The POA&M must be maintained as a living document, reviewed periodically, and updated as items are completed or timelines shift. An assessment that finds issues without a corresponding POA&M is an incomplete assessment.

Continuous Monitoring

The standard requires ongoing monitoring of the security posture, not just point-in-time assessments. This includes monitoring the effectiveness of security controls, tracking changes to the system and its environment, and conducting ongoing assessments at a defined frequency.

Continuous monitoring does not mean real-time dashboards for every control, though some controls warrant that level of attention. It means the organization has a strategy for how it will maintain visibility into its security posture between formal assessments. Configuration monitoring, vulnerability scanning cadences, access review schedules, and periodic control testing all contribute to this requirement.

System Interconnections

Organizations that connect their systems with external entities, whether partners, subcontractors, or government networks, must document those interconnections and ensure they comply with applicable security requirements. In the defence supply chain, where specified information may traverse multiple organizations, this control carries particular weight. Each interconnection represents a boundary where security responsibilities must be clearly defined.

Where Existing Programs Overlap

Organizations with established security programs will find meaningful overlap with the AU and CA families, though the degree depends on which framework they currently operate under.

The key insight across all three: existing programs create a foundation, not a pass. The mapping exercise identifies what translates directly, what needs adjustment in documentation or evidence format, and what represents a genuine gap requiring new controls.

Common Gaps That Surface During Assessment

Even organizations with functioning security programs encounter predictable gaps when measured against ITSP.10.171's AU and CA requirements.

Audit Event Coverage at the Application Layer

Infrastructure logging is typically well covered. Operating systems, firewalls, and identity providers ship with configurable audit capabilities. The gap appears at the application layer, where development teams build logging for troubleshooting, not for security audit trails. Events that matter for ITSP.10.171, such as changes to user roles, modifications to authentication configurations, access to records containing specified information, and cross-tenant data access in multi-tenant environments, are frequently absent from application logs. Closing this gap requires collaboration between security and development teams to define auditable events at the application level.

Alert Triage Without Documentation

Security operations teams that actively monitor and respond to alerts can still fail the AU review requirement if they do not document their triage process. The pattern is common: an alert fires, an analyst investigates, determines it is benign or takes action, and clears the alert. From an operational standpoint, the work was done. From an evidence standpoint, nothing happened.

Missing Audit Review Cadence

ITSP.10.171 expects a defined cadence for audit log review, not a reactive process that only engages when something looks wrong. Organizations that rely entirely on automated alerting without scheduled manual review of aggregate audit data leave a gap. The standard assumes that some patterns only emerge through periodic, deliberate review of log summaries and trends, not just through threshold-based alerts.

No POA&M Process

Some organizations track remediation informally, through tickets, emails, or spreadsheets that are maintained inconsistently. ITSP.10.171 expects a formal POA&M that tracks findings from security assessments, vulnerability scans, and audit reviews in a single, maintained artifact. The gap is not usually in the organization's willingness to fix issues. It is in the lack of a structured process to track them from identification through closure.

Evidence of Assessment Independence

For Level 2, the requirement for independent assessment is explicit. Organizations that conduct internal security reviews but have never engaged an independent assessor will need to build that into their assessment planning. Internal reviews remain valuable for ongoing monitoring, but they do not satisfy the third-party certification requirement.

Building the Evidence Layer

The operational advice for meeting AU and CA requirements comes down to building an evidence layer on top of existing security operations. In many cases, the security work is already being done. What is missing is the connective tissue that turns operational activity into auditable evidence.

Frequently Asked Questions

Does CPCSC Level 1 include audit logging requirements?

Level 1 draws from a subset of ITSP.10.171 families, and based on its alignment with CMMC Level 1, the AU family is not expected to be among the required families at Level 1. However, organizations anticipating Level 2 certification should not defer audit logging implementation. Building the audit event definitions, centralized log storage, and review cadence takes time, and retrofitting these capabilities under deadline pressure is significantly more expensive than building them incrementally. The Level 1 self-assessment guide covers the expected Level 1 requirements in detail.

What is the difference between AU and CA controls in ITSP.10.171?

The AU (Audit and Accountability) family addresses the mechanics of audit records: which events to log, what each record contains, how records are stored and protected, and how they are reviewed. The CA (Security Assessment and Monitoring) family addresses the health of the security program as a whole: whether controls are assessed for effectiveness, whether weaknesses are tracked through a Plan of Action and Milestones, whether monitoring is continuous, and whether assessments are conducted by qualified and, for Level 2, independent assessors. AU is about the data. CA is about what the organization does with the data and whether the program is working.

Can existing SOC 2 or ISO 27001 controls satisfy these requirements?

Existing certifications provide a substantial head start. SOC 2 CC7 controls for monitoring and ISO 27001 Annex A logging controls map well to AU requirements. SOC 2 CC4 controls for internal monitoring and ISO 27001's management review and corrective action processes align with CA requirements. The gaps tend to be in the specificity of documentation rather than the absence of capability. ITSP.10.171 expects explicit audit event definitions, formal POA&M tracking, and defined review cadences, which some existing programs handle less formally. The practical approach is to map current controls to ITSP.10.171 assessment objectives, identify where evidence format or documentation depth needs adjustment, and extend the program to close genuine gaps.

Do I need a SIEM to meet ITSP.10.171 audit requirements?

ITSP.10.171 does not prescribe specific technology. The standard requires centralized audit record storage, protection against unauthorized modification, review and analysis capabilities, and report generation. A SIEM is one way to meet these requirements, but it is not the only way. Managed logging services, cloud-native security tooling, and well-configured log aggregation platforms can all satisfy the intent if they provide centralized storage, access controls, search and analysis capabilities, and retention management. The key question is whether the solution supports the operational workflow (defined review cadence, documented triage, immutable retention) rather than whether it carries a specific product label.