Introduction
SOC 2 Trust Services Criteria CC7.2 requires that the entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, or errors affecting the entity’s ability to meet its objectives. For IAM specifically, CC7.2 is the criterion that requires authentication anomaly detection, privileged session monitoring, and the technical infrastructure to surface suspicious access patterns without relying on manual log review.
Most organisations pursuing SOC 2 Type II have some form of monitoring in place. Authentication failures are logged. System events are recorded. Security teams review logs on a defined schedule. CC7.2 requires more than this. The criterion expects that monitoring is proactive and automated: anomalies are detected as they occur or shortly after, not discovered during a weekly log review. The distinction matters because the threat scenarios CC7.2 is designed to surface, credential stuffing, session hijacking, and insider access abuse, often complete within hours. A weekly log review discovers them after the fact. Automated anomaly detection surfaces them during or immediately after the event.
The authentication layer is where CC7.2 is most relevant for IAM-focused organisations. Every access event generates an authentication event. Authentication events contain the signals that distinguish normal access from anomalous access: geographic location, device identity, time of day, MFA outcome, and session duration. An anomaly detection layer that evaluates these signals continuously and generates alerts when they indicate suspicious patterns is what CC7.2 requires at the authentication layer.
This blog covers what CC7.2 requires technically, what SOC 2 Type II auditors examine for the criterion, and how Adaptive MFA anomaly detection and privileged session monitoring satisfy it.
What CC7.2 Requires
CC7.2 is part of the System Operations category and covers monitoring of system components for anomalies. The criterion applies broadly to infrastructure monitoring, application monitoring, and security event monitoring. For IAM, the relevant scope is authentication event monitoring, access pattern monitoring, and privileged session monitoring.
Automated anomaly detection
CC7.2 requires that monitoring be automated and capable of detecting anomalies without requiring manual examination of every log entry. The monitoring infrastructure must evaluate events against a baseline of normal behaviour and generate alerts when events deviate from that baseline.
The baseline comparison is what distinguishes anomaly detection from event logging. Event logging records that events occurred. Anomaly detection evaluates whether events are consistent with expected patterns and surfaces those that are not. A user logging in from their usual location at their usual time using their usual device is an expected event. The same user logging in from a different country two hours after their last domestic login is an anomaly that warrants investigation.
For CC7.2 operating effectiveness in a SOC 2 Type II engagement, the monitoring must have operated continuously throughout the audit period. Anomaly detection deployed in the month before the audit does not satisfy operating effectiveness for a 12-month period. The continuous operation evidence is what Type II auditors sample from across the period.
Response to detected anomalies
CC7.2 requires not only that anomalies be detected but that appropriate actions be taken when they are identified. The response component requires that alerts generate investigation workflows, that suspicious sessions can be terminated, and that the response actions are logged with timestamps.
For authentication anomalies, the response is typically step-up authentication: escalating the authentication challenge when signals indicate elevated risk. For privileged session anomalies, the response may include immediate session termination by an administrator. Both response types must produce logged evidence of the action taken.
Authentication Layer Anomaly Detection for CC7.2
The authentication layer is the primary monitoring surface for CC7.2 in IAM environments. Every access attempt generates an authentication event containing the signals that indicate normal or anomalous access patterns.
Signals that indicate authentication anomalies
Geographic anomalies: a user authenticating from a location significantly different from their historical access pattern, or from a location inconsistent with their role or the organisation’s operations. Impossible travel: two authentication events for the same user from geographically distant locations within a timeframe that makes physical travel impossible.
Device anomalies: authentication from an unrecognised device that has not previously been associated with the user account, particularly when combined with other risk signals. For environments where device compliance is enforced, authentication from a non-compliant device is an anomaly by definition.
Time-of-day anomalies: authentication at unusual hours significantly outside the user’s historical access pattern. For privileged users with defined permitted access hours, any authentication outside those hours is a policy violation as well as a potential anomaly.
MFA failure patterns: multiple consecutive MFA failures for the same account, or MFA failures across multiple accounts from the same source IP, are indicators of credential stuffing or account takeover attempts.
Behavioural baseline deviations: access to systems or resources not previously accessed by the user, session durations significantly longer or shorter than the user’s historical pattern, or access volume significantly higher than baseline.
How Adaptive MFA implements CC7.2 anomaly detection
Akku’s Adaptive MFA evaluates each authentication event against the signals above. AI-powered anomaly detection compares the authentication context with the user’s behavioural baseline and the organisation’s access patterns. When signals indicate elevated risk, the authentication challenge escalates: an additional MFA factor is required, the session is held for administrator review, or access is blocked pending investigation.
Every anomaly detection event is logged with the triggering signals, the risk assessment, the response action, and the outcome. This event stream constitutes the CC7.2 monitoring evidence: a continuous record showing that anomaly detection was operating throughout the audit period, that anomalies were surfaced, and that appropriate responses were triggered.
Risk and audit dashboards surface anomaly patterns for administrator review. MFA failure spike alerts, geographic anomaly notifications, and new device access events are presented in the admin console as actionable items requiring investigation. The dashboard provides the monitoring interface CC7.2 requires: a view into the anomaly detection output that enables timely response.
Privileged Session Monitoring for CC7.2
CC7.2’s system component monitoring requirement extends to privileged access monitoring. Privileged users with access to critical systems represent the highest-impact anomaly scenario: an administrator whose session is compromised or who is abusing their access has significantly more potential impact than a standard user.
What privileged session monitoring requires
Real-time visibility into active privileged sessions is the operational monitoring capability CC7.2 requires for the privileged access layer. Administrators must be able to view all currently active privileged sessions and identify any that appear anomalous: unexpected target systems, unusual session duration, or activity patterns inconsistent with the session’s stated purpose.
Session termination capability is the response component: when a suspicious session is identified, it must be terminable immediately. The termination action must be logged with the administrator’s identity, the termination timestamp, and the reason.
Historical session review, examining completed session recordings for anomalous behaviour, is the retrospective monitoring component. For CC7.2 operating effectiveness, both real-time monitoring and retrospective review capabilities must be demonstrated.
How AkkuReka’s monitoring addresses CC7.2
The Akku admin console provides real-time visibility into all active privileged sessions. Each session displays actor identity, target system, session duration, protocol, and current activity status. Any active session can be terminated instantly from the console. Termination events are logged with administrator identity, timestamp, and reason.
SMARTAudit Trails provide the retrospective monitoring capability. Session recordings indexed by timestamp, command string, and SQL query text allow administrators and security teams to search across historical sessions for specific command patterns or query types without reviewing every recording manually. This searchable recording infrastructure is what makes retrospective anomaly detection operationally viable at scale.
The combination of real-time monitoring with immediate termination capability and retrospective session search satisfies CC7.2’s monitoring and response requirements for the privileged access layer.
What SOC 2 Type II Auditors Examine for CC7.2
Monitoring infrastructure examination
Auditors examine whether automated anomaly detection is in place and operating continuously. They review the monitoring infrastructure configuration, verifying that it evaluates authentication events against baselines rather than only logging them. They look for evidence of anomaly alerts generated during the audit period, verifying that the detection capability was active throughout.
A monitoring infrastructure with no anomaly alerts generated during a 12-month audit period raises a credibility question: either the environment experienced no anomalous events, which is implausible for most organisations, or the monitoring is not sufficiently sensitive to detect the anomalies that occurred.
Alert and response evidence
Auditors examine a sample of anomaly alerts generated during the audit period. For each alert, they verify that it was investigated and that a response was documented. An alert that generated no investigation record indicates that the monitoring produces alerts but the response component is absent.
The response documentation does not need to show that every alert indicated a genuine security incident. Most anomaly alerts will be false positives or low-severity events. What the documentation must show is that alerts were reviewed, assessed, and either investigated or cleared with a documented rationale.
Privileged session monitoring demonstration
Auditors may request a demonstration of real-time privileged session monitoring capability. They ask administrators to show the current active sessions view and demonstrate session termination capability. An organisation that cannot demonstrate this capability during the audit has a gap in CC7.2 implementation for the privileged access layer.
Diagnostic Questions
Does your authentication infrastructure evaluate each login event against a behavioural baseline and generate alerts when anomalies are detected, or does it log authentication events without evaluating them for anomalous patterns?
For anomaly alerts generated in the last 12 months, is there a documented investigation record for each alert showing that it was reviewed, assessed, and either investigated or cleared with a rationale?
Can administrators view all active privileged sessions in real time from a monitoring console, and can any active session be terminated instantly from that console with the termination event logged?
Does your monitoring infrastructure generate alerts for geographic anomalies, impossible travel events, MFA failure spikes, and new device access events, or are these patterns only discoverable through manual log review?
Has your anomaly detection infrastructure been operating continuously throughout the last audit period, with evidence of detection events from across the full period available for auditor sampling?
CTAs
See how Akku’s Adaptive MFA anomaly detection and privileged session monitoring address SOC 2 CC7.2 requirements across authentication and privileged access layers.
Book a conversation with the Akku team to assess your current monitoring infrastructure against SOC 2 Type II CC7.2 operating effectiveness requirements.
FAQs
What is the difference between CC7.1 and CC7.2 in SOC 2, and do they require separate controls?
CC7.1 requires that the entity uses detection and monitoring procedures to identify changes to configurations or new vulnerabilities, and conducts ongoing monitoring of the environment. It focuses on configuration monitoring and vulnerability detection. CC7.2 requires monitoring of system components for anomalies indicative of malicious acts, errors, or events affecting objectives. It focuses on behavioural anomaly detection and incident precursor identification. Both are required and they address different monitoring layers. CC7.1 is satisfied by configuration monitoring and vulnerability scanning capabilities. CC7.2 is satisfied by authentication anomaly detection, privileged session monitoring, and security event correlation. Satisfying one does not satisfy the other.
What does CC7.2 require for the response to detected anomalies, and how is this evidenced?
CC7.2 requires that appropriate actions be taken when anomalies are detected. The response component requires that alerts generate investigation workflows, that suspicious sessions can be terminated, and that the actions taken are logged. Evidencing the response component requires: alert records showing that anomalies were detected with triggering signals and timestamps, investigation records showing that each alert was reviewed and assessed, response records showing what action was taken for each alert, whether investigation, clearance, or escalation, and for privileged session anomalies, session termination records where termination was the response. The absence of response records for anomaly alerts is a CC7.2 finding regardless of how effective the detection infrastructure is.
How does Adaptive MFA’s step-up authentication function as a CC7.2 anomaly response?
When Adaptive MFA’s anomaly detection identifies elevated risk signals at an authentication event, the response is to escalate the authentication challenge: requiring an additional factor, blocking the authentication pending investigation, or routing the session for administrator review. This step-up response is both a security control and a CC7.2 compliance mechanism. The step-up event is logged with the triggering signals, the risk assessment, the additional factor required, and the outcome. For auditors examining CC7.2, this event stream demonstrates that the monitoring infrastructure detected anomalies, generated a proportionate response, and logged the response with sufficient detail for evidence review.
What constitutes a sufficient baseline for authentication anomaly detection under CC7.2?
A sufficient baseline captures the typical authentication patterns for each user or user category: normal geographic locations, normal device types, normal access hours, normal session frequencies, and normal resource access patterns. The baseline must be established from historical data with sufficient depth to distinguish genuine patterns from noise. For new users with limited historical data, peer group baselines, comparing the user’s behaviour to others in the same role or department, can supplement individual baselines. The baseline must be updated continuously to accommodate legitimate changes in user behaviour, such as travel or role changes, without generating persistent false positive alerts.
Can the same monitoring infrastructure satisfy both SOC 2 CC7.2 and ISO 27001 A.8.16 simultaneously?
Yes. SOC 2 CC7.2 and ISO 27001:2022 A.8.16 both require monitoring of system components for anomalous behaviour with appropriate response actions. The same Adaptive MFA anomaly detection infrastructure, risk and audit dashboards, and privileged session monitoring capability satisfy both criteria from the same technical controls. The evidence required differs in format and audit context: SOC 2 auditors sample anomaly alert records and investigation documentation across the Type II audit period, while ISO 27001 auditors examine monitoring procedures and evidence that the monitoring was operating effectively during the certification period. The underlying monitoring infrastructure that generates this evidence is identical for both frameworks.
How frequently should anomaly alert thresholds be reviewed to maintain CC7.2 operating effectiveness?
Anomaly detection thresholds should be reviewed when the baseline changes significantly, when the false positive rate indicates that thresholds are miscalibrated, and at least annually as part of the ISMS review process for ISO 27001 or the controls review for SOC 2. Thresholds that generate too many false positives create alert fatigue, leading to alerts being dismissed without investigation. Thresholds that are too permissive miss genuine anomalies. The threshold review process itself should be documented and the outcomes recorded, as the review process is evidence that the monitoring infrastructure is actively managed rather than passively operated.
