What SaaS Providers Must Implement Under SOC 2 Criteria CC6.6, CC6.7 and CC7.2 for Logging, Monitoring and Incident Response

SOC 2 Type II attestation requires SaaS providers to demonstrate operational effectiveness of security controls over time. Three criteria within the 2022 Trust Services Criteria address logging, monitoring and incident response: CC6.6, CC6.7 and CC7.2. These are not suggestions or aspirational standards—they are binding control objectives that auditors test using specified procedures.

Leadership is accountable for the security outcome: that the organization detects and responds to security events appropriately. But accountability without clear ownership, a defined sequence and measurable progress creates organizational risk. This article explains what these criteria require, what auditors look for during testing, and where ownership must reside.

The Business Consequence of Logging and Monitoring Failures

A SaaS provider that cannot demonstrate logging completeness, retention discipline and monitoring coverage faces three material risks. First, the organization may fail its SOC 2 Type II examination, which blocks sales to regulated customers and disqualifies the provider from procurement processes. Second, an undetected security event can escalate silently, increasing breach impact and regulatory exposure. Third, the absence of evidence during incident investigation increases legal and compliance costs.

The 2022 Trust Services Criteria make logging and monitoring outcomes mandatory for attestation. An auditor testing these controls expects to see evidence of policy, procedure, technical implementation and operational practice. Missing any component results in a qualified opinion or control exception.

What CC6.6, CC6.7 and CC7.2 Require

The Trust Services Criteria organize security obligations into categories. CC6 addresses logical and physical access controls. CC7 addresses system operations. Three specific criteria govern logging, monitoring and response:

CC6.6: The Entity Implements Logical Access Security Measures to Protect Against Threats from Sources Outside Its System Boundaries

This criterion requires logging of access attempts from external sources. Auditors test whether the organization logs authentication events, network traffic crossing boundaries, and failed access attempts. They expect retention policies that support investigation and documentation showing that logs are reviewed.

Evidence auditors request includes firewall logs, VPN connection records, authentication system logs showing both successful and failed attempts, and meeting minutes or tickets demonstrating review activity. The absence of failed login logs is a common deficiency, as is retention shorter than the organization's stated policy.

CC6.7: The Entity Restricts the Transmission, Movement, and Removal of Information to Authorized Internal and External Users and Processes

This criterion requires logging of data movement. Auditors test whether the organization captures file transfers, database exports, email transmission of sensitive information, and API calls that retrieve or modify data. They expect evidence that the organization can reconstruct who moved what information, when, and to where.

Testing focuses on data loss prevention logs, application audit trails, database transaction logs and cloud storage access logs. Auditors select samples of data movement events and verify that logs contain sufficient detail for investigation. Insufficient logging granularity—logs that show an action occurred but not which records were accessed—is a frequent finding.

CC7.2: The Entity Monitors System Components and the Operation of Those Components for Anomalies That Are Indicative of Malicious Acts, Natural Disasters, and Errors

This criterion requires active monitoring, not merely log collection. Auditors test whether the organization has defined what constitutes an anomaly, deployed technical controls to detect those conditions, and established procedures for alert handling. They expect evidence that monitoring is continuous and that alerts generate action.

Evidence includes security information and event management (SIEM) configurations, alert definitions, escalation procedures, and tickets or incident records showing response to alerts. Auditors test a sample period—typically the audit observation period—and verify that alerts during that window were reviewed and handled according to procedure. Organizations that collect logs but do not monitor them operationally fail this control.

Log Retention Requirements and What Auditors Test

The Trust Services Criteria do not prescribe a specific retention period, but the organization must define a policy and demonstrate adherence. Auditors test whether logs exist for the entire observation period—usually between three and twelve months depending on the engagement—and whether the organization can produce them on request.

Testing involves requesting logs from a randomly selected date within the observation period and verifying completeness. If logs have been deleted prematurely, or if the organization cannot produce them due to technical failure, the control fails. Common retention periods are ninety days for high-volume operational logs and one year for authentication and administrative access logs, but organizational policy governs.

Organizations must also demonstrate that retention is automated and does not depend on manual intervention. Auditors expect evidence of storage provisioning, backup procedures and tests showing that logs can be retrieved and searched after the retention period begins.

Monitoring Coverage: What Must Be Monitored and How Auditors Test It

CC7.2 requires monitoring of system components and operations. Auditors test whether the organization has identified all components within scope—applications, databases, operating systems, network devices—and whether monitoring covers each. They expect a monitoring plan or inventory that documents what is monitored, how, and by whom.

Testing includes selecting system components from the scoping document and verifying that alerts for those components reach the monitoring system. Auditors also test whether the organization detects known attack patterns, such as brute-force authentication attempts, privilege escalation or lateral movement. Organizations often fail this test when monitoring covers infrastructure but not application-layer events.

The organization must also demonstrate that someone is responsible for reviewing alerts and that reviews occur with defined frequency. Auditors request alert logs, review documentation and interview personnel to verify that monitoring is operational, not theoretical.

Incident Response Procedures and What Auditors Verify

The Trust Services Criteria require documented incident response procedures and evidence that the organization follows them. Auditors test whether the organization has defined what constitutes an incident, established escalation paths, assigned roles and documented response steps.

Testing involves reviewing the incident response plan, verifying that it has been approved by appropriate management, and selecting incidents from the observation period to verify handling. If no incidents occurred, auditors may test the most recent tabletop exercise or simulation. Organizations that have a plan but cannot demonstrate its use fail the control.

Evidence includes the incident response policy, role assignments, communication templates, post-incident review reports and training records. Auditors expect to see that incident data is preserved for investigation and that lessons from incidents feed back into monitoring and detection improvements.

Who Inside the Organization Is Accountable

Logging, monitoring and incident response span technical implementation, operational practice and strategic decision-making. Accountability cannot rest solely with IT operations or security engineering because these teams do not make policy, define risk appetite or allocate resources.

Adequate ownership requires three functions:

• **Strategic accountability:** An executive who defines what must be logged, how long logs must be kept, what constitutes an incident, and how the organization balances monitoring cost against risk. This role approves policies and accepts residual risk.
• **Operational accountability:** A manager who ensures that technical controls are implemented, monitoring occurs continuously, alerts are handled and incidents are investigated. This role translates policy into procedure.
• **Technical implementation:** Engineering personnel who configure logging, deploy monitoring tools and respond to incidents. This role executes defined procedures.

Organizations that lack the first function—strategic accountability—produce documentation that satisfies auditors on paper but does not reflect operational reality. The result is control failures during testing and undetected incidents during operations.

This is the gap that [virtual CISO leadership](/vciso/) closes: an executive who makes risk decisions, defines the security posture, and ensures that monitoring, logging and response reflect business priorities rather than only technical capability.

The Relationship Between SOC 2 Compliance and Managed Security Services

Many SaaS providers engage managed security service providers (MSSPs) to operate monitoring infrastructure or provide 24/7 alert handling. These services address technical implementation and operational accountability but do not provide strategic ownership.

An MSSP can deploy a SIEM, configure alerts and staff a security operations center. It cannot define what the organization considers an incident, determine appropriate log retention based on regulatory requirements and business risk, or make the judgment calls required during incident response. Those decisions require business context and risk authority that a service provider does not possess.

During SOC 2 examination, auditors test the organization's controls, not the service provider's. The organization must demonstrate that it has defined policies, that the MSSP operates according to those policies, and that the organization reviews the service provider's performance. This oversight function is a strategic responsibility.

Managed services and virtual CISO leadership are complementary, not substitutes. The MSSP provides operational capability; the vCISO provides governance, risk decisions and accountability to the board and executive team.

Practical Next Steps for Leadership

If your organization is preparing for SOC 2 Type II attestation or addressing findings from a prior examination, the following sequence addresses the most common gaps:

• **Verify logging coverage.** Document all system components within scope and confirm that each generates logs. Test whether logs include sufficient detail for investigation—user identity, timestamp, action taken, result.
• **Confirm retention.** Review current retention periods, compare them to stated policy, and verify that automated processes enforce retention without manual intervention. Test log retrieval from the oldest retained date.
• **Test monitoring.** Verify that alerts reach the monitoring system, that someone reviews them with defined frequency, and that alert handling generates tickets or incident records. If monitoring relies on a managed service, verify that the provider operates according to your policy.
• **Document incident response.** Confirm that the incident response plan has been approved by appropriate management, that roles are assigned and current, and that the organization has evidence of plan use—either through actual incident handling or tabletop exercise.
• **Assign strategic accountability.** Identify who inside the organization has authority to define logging scope, retention periods, monitoring priorities and incident thresholds. If no one currently holds this accountability clearly, address that gap before the audit period begins.

These controls are testable, auditable and subject to objective pass-fail criteria. Preparing for examination means producing evidence that the controls operate as documented, throughout the observation period.

When Outside Expertise Becomes Necessary

Organizations that lack the internal capacity to define logging scope, interpret audit findings or make risk-based decisions about monitoring coverage often engage temporary or fractional leadership. This is particularly common among SaaS providers preparing for their first SOC 2 examination or those addressing significant findings from a prior report.

Virtual CISO services provide strategic accountability without the cost or commitment of a full-time executive. The engagement focuses on governance: defining policy, interpreting regulatory and contractual obligations, making risk decisions and ensuring that technical implementation reflects business priorities. This is distinct from managed services, which provide operational execution.

If your organization is preparing for SOC 2 attestation and the accountability structure described in this article is unclear or unassigned, a confidential consultation can clarify the gap and the options for closing it. Heights Consulting Group offers this without obligation and without sharing your information.