SOC 2 CC4.2: Evaluating and Communicating Deficiencies

SOC 2 CC4.2 requires an organization to evaluate the deficiencies its monitoring turns up and communicate them, in a timely way, to the people who can fix them and to senior management. It closes the CC4 series (Monitoring Activities), and a frequent finding under it is a team that discovers control gaps but has no record of who was told, what the plan was, or whether it was ever closed.

What does SOC 2 CC4.2 require?

In plain terms, CC4.2 is the other half of monitoring. Where CC4.1 requires evaluations that find whether controls are working, CC4.2 governs what happens to what they find. A deficiency is any place a control is missing, poorly designed, or not operating as intended, whether it surfaced from a vulnerability scan, an internal audit, a penetration test, or a failed access review.

The criterion has three moving parts. Someone with the standing to judge severity has to assess the deficiency, it has to be communicated to the party who can act on it and, when it matters, to senior management, and the organization has to track whether it was remediated. Timeliness runs through all three: a deficiency logged and left open indefinitely fails CC4.2 as surely as one that was never recorded.

CC4.2 maps to COSO Principle 17. It is deliberately not an incident-response criterion. Incidents are the subject of the CC7 series; CC4.2 covers control deficiencies found through monitoring, which are usually quieter than an incident and easier to sit on precisely because nothing is on fire.

What are the CC4.2 points of focus?

The AICPA defines 3 points of focus for CC4.2. Because the Trust Services Criteria are AICPA copyrighted material, the points of focus below are paraphrased and grouped by theme rather than reproduced verbatim; consult the official TSC document for exact wording.

• Assesses results. Management and, where appropriate, the board review the results of the ongoing and separate evaluations performed under CC4.1, so someone with authority judges what each finding means.
• Communicates deficiencies. Deficiencies are communicated to the parties responsible for corrective action and, when significant, to senior management and the board, rather than staying inside the team that found them.
• Monitors corrective action. Management tracks whether deficiencies are actually remediated on a timely basis, closing the loop rather than treating communication as the end of the process.

How do you meet CC4.2 in cloud environments?

Cloud environments meet CC4.2 by routing findings into a tracked workflow with owners, severity, and due dates:

• Findings flow into a ticketing system. Output from Config, Security Hub, GuardDuty, Defender for Cloud, and scheduled scans is routed to Jira, ServiceNow, or a similar tracker, so each deficiency becomes a ticket that carries its own history.
• Severity and remediation SLAs. Each finding is rated and assigned a remediation window by severity, which is the record that assessment happened and sets the clock timeliness requires. The ticketing, SLA, and remediation guide covers how to structure these windows.
• Named owners. Every open deficiency has an accountable owner, so communication reaches a specific person rather than a shared queue.
• Management reporting. A recurring report or dashboard summarizes open deficiencies, aging, and remediation status for leadership, satisfying the communicate-to-senior-management point of focus.
• Closure evidence. Tickets are closed with a note or artifact showing the fix, so the tracker shows deficiencies moving to resolution rather than only accumulating.

How do you meet CC4.2 on-prem?

On-prem environments apply the same discipline where findings come from internal scans, audits, and manual reviews rather than cloud services:

• A central deficiency or finding log. Results from internal vulnerability scans, internal audit, and control self-assessments are recorded in one tracker or risk register rather than living in scattered spreadsheets and email.
• Severity rating and target dates. Each finding is assessed for severity and given a remediation target, with higher-severity items on a shorter clock.
• Assigned owners and follow-up. Findings are assigned to the person responsible for the affected system, with a scheduled follow-up to confirm progress.
• Management review minutes. A periodic review brings open findings and their status to management, and the minutes are the evidence that deficiencies were communicated and tracked.
• Documented closure. Each finding is closed with a record of the corrective action taken, so the log demonstrates the full path from discovery to remediation.

Cloud vs on-prem at a glance

What evidence do auditors expect for CC4.2?

How does CC4.2 map to ISO 27001:2022?

The overlap is partial because ISO 27001 handles corrective action mainly through its management-system clauses: A 5.35 and A 5.36 cover the reviews that surface deficiencies, while the requirement to act on nonconformities and track them to closure lives in Clause 10.1 (nonconformity and corrective action) in the main body of the standard. Deficiency logs and review minutes reuse across both frameworks. The SOC 2 to ISO 27001 control mapping covers the full crosswalk across all five Trust Services Categories.

Related criteria

CC4.2 completes the CC4 Monitoring Activities series that CC4.1 opens: CC4.1 requires the evaluations that find deficiencies, and CC4.2 governs assessing, communicating, and remediating what they find. The deficiencies CC4.2 tracks often feed back into the risk assessment under CC3.2, since a recurring control gap changes the organization's risk picture. Communicating and remediating findings on a defined clock uses the same ticketing and SLA discipline described in the ticketing, SLA, and remediation guide.

Frequently Asked Questions

What does SOC 2 CC4.2 mean?

SOC 2 CC4.2 requires an organization to evaluate the internal control deficiencies its monitoring identifies and communicate them, in a timely manner, to the parties responsible for corrective action and to senior management and the board where appropriate. It also requires tracking whether those deficiencies are remediated. It is the second criterion in the CC4 Monitoring Activities series and maps to COSO Principle 17.

What evidence satisfies CC4.2?

The core evidence is a deficiency or finding tracker showing severity and an assigned owner, defined remediation SLAs by severity, management review or committee minutes that show deficiencies were communicated, remediation records or closed tickets showing corrective action, and leadership or board reporting for significant issues. Together these show findings were assessed, communicated, and tracked to closure.

What counts as a deficiency under CC4.2?

A deficiency is any place a control is missing, poorly designed, or not operating as intended. It can come from a vulnerability scan, an internal audit, a penetration test, a failed access review, or a control self-assessment. CC4.2 covers control deficiencies found through monitoring, which is different from a security incident, which the CC7 series addresses.

Does a SOC 2 exception mean we failed the audit?

No. Exceptions are a normal part of SOC 2 audits, and an exception is not the same as a failed report. What CC4.2 cares about is whether deficiencies are assessed, communicated to the right people, and tracked to remediation. A managed, documented deficiency process is exactly what auditors want to see, rather than a claim that nothing was ever found.

How is CC4.2 different from CC4.1?

CC4.1 requires the ongoing and separate evaluations that determine whether controls are present and functioning, such as scans, internal audits, and penetration tests. CC4.2 governs what happens to the deficiencies those evaluations find: assessing severity, communicating them to owners and management, and tracking corrective action to closure. CC4.1 finds the problems, and CC4.2 makes sure they get fixed.