CC4.2 Evaluating and communicating deficiencies

What CC4.2 asks when a control deficiency turns up

CC4.2 asks three things of you once a control has been found not to work: evaluate the deficiency, communicate it to the people who must act, and monitor the corrective action until it is closed. The criterion restates COSO Principle 17, which says the organization evaluates internal control deficiencies and communicates them promptly to those responsible for corrective action, including senior management and the board where appropriate. If you have found a failed control, or you expect an auditor to find one, this is the test your records will be read against. An assessor will not only look at the defect. They will look at what happened to it afterward.

The risk CC4.2 addresses is a known weakness that sits unfixed. A deficiency is often noticed by someone who has no authority to fix it, recorded in a ticket or spreadsheet, and then forgotten. In practice this is hard for three reasons. Deficiencies arrive from many sources, including internal testing, access reviews, vulnerability scans, incident post-mortems, customer complaints and audit findings, so no single queue sees them all. Severity is judged inconsistently from one team to the next, so a serious gap can look minor. And escalation records are often missing, so there is no proof that the board or senior management ever heard about a significant problem.

Before your fieldwork, confirm three things. First, that every deficiency source feeds one register with a documented severity scale and a named owner for each item. Second, that your escalation rules say which severities reach senior management and the board, how quickly, and who records that it happened. Third, that each corrective action has a target date, a verification step and a closure record signed off by someone other than the person who fixed it. Ask your CPA firm which evidence they expect to see for each of these, because the wording of your criteria mapping and the depth of testing depend on your system and scope.

Which deficiencies and channels fall under CC4.2

CC4.2 applies to any deficiency that surfaces from monitoring, testing or operations, so the process has to know where findings come from before it can evaluate them. The decisions below set which sources feed the process, how wide the scope runs and who must receive the results.

Ongoing monitoring results

Alerts, control dashboards and recurring checks show when a control has stopped operating as designed. Each failed check that the team does not classify is a potential deficiency that CC4.2 expects someone to evaluate. Ask which monitoring outputs are routed into the deficiency log and which are only reviewed informally. Records that never reach the log cannot be evaluated, communicated or closed, so the gap is visible to an assessor.

Separate evaluation outputs

Findings from the separate evaluations described under CC4.1, such as internal audit reports and independent reviews, are often the most formal deficiencies in the program. Confirm that each finding is logged with its severity and owner, not only summarized in the audit report. Scope decisions here determine how many separate evaluations feed the process and how much review time the team must budget.

Penetration test and vulnerability findings

Penetration test results and vulnerability scan output describe weaknesses in systems that carry in-scope data. Import them into one tracker so duplicate findings from repeated scans are merged and each item has a single owner and due date. Tools such as DefectDojo can deduplicate imported findings, but the team still decides severity and whether a finding is a control deficiency. Confirm which scanners and testers feed the tracker.

Access review exceptions

Access reviews that find users with excess rights, leavers still active or approvals missing are deficiencies in the access controls that CC6 tests. These exceptions must be recorded, corrected and shown to have been corrected before the examination period closes. Decide whether every exception is logged or only those above a set threshold, because the threshold determines how much of the access review workload turns into tracked remediation.

Incidents and near misses

Security incidents and operational failures can reveal control deficiencies even when the incident itself is closed. Post-incident reviews should ask whether a control failed, was missing or was bypassed, and log the answer. Decide whether near misses count, since including them adds review effort but gives management earlier warning. Confirm how incident records link to the deficiency log.

Vendor and subservice organization issues

When a subservice organization such as a cloud provider or hosting partner has an exception in its own SOC report, or fails to deliver a control the service organization depends on, that issue can become a deficiency in the service organization's system. Decide who reviews each vendor's report, who tracks the complementary controls the organization relies on, and how vendor-caused gaps are logged. Confirm this scope with the auditor before fieldwork.

How an assessor tests CC4.2 and what they ask for

This table maps each step an assessor takes on CC4.2 to the evidence requested and the findings that most often appear. Read it as a checklist of what your deficiency records must show before fieldwork starts, since a complete log is the starting point for every other test.

Assessor step	Evidence requested	Common finding
Inspect the deficiency log for completeness	Full export of the deficiency register for the period, with source, date identified and owner for each entry, plus the log's own change history	Deficiencies raised in tickets, email or meetings but never entered in the log
Confirm each deficiency is evaluated	Documented severity or impact rating, root cause notes and the reviewer who approved the rating	Deficiencies logged without severity, so the team cannot show which ones reached management
Trace escalations to the people who must act	Dated notices to control owners, senior management and, where relevant, the board or a board committee, with the minutes or pack that covered them	Escalations with no recorded date, or no evidence that the board received a summary of significant items
Check corrective action has a named owner and plan	Remediation tickets with owner, due date, planned action and any approved risk acceptance	Corrective actions with no owner, or due dates changed repeatedly without a recorded approval
Sample deficiencies and trace each end to end	Assessor-selected items traced from identification through evaluation, communication and corrective action, with the supporting artifacts for each step	Gaps in the trail for a sampled item, such as a fix deployed with no link back to the original deficiency
Check that closure was validated	Retest results, reviewer sign-off, or evidence that the control now operates as designed	Closures without validation, where a ticket is marked done but no one confirmed the control works
Test design and operation over the period	For Type 2 work, evidence spread across the observation period, not only at a single point; for Type 1, evidence of design as of the report date	Process documented well but not followed consistently across the period
Report exceptions in the report	Any exception the auditor identifies is described in the report, with management's response, rather than removed from the scope of testing	Teams that close or reclassify items late to avoid an exception; auditors look for these changes in the log history

Building the deficiency process in the order auditors check it

This sequence turns CC4.2 into a working process: a defined deficiency standard, clear escalation, one register, owned corrective actions, regular review and closure that someone other than the owner can verify. Each step leaves a record an auditor can sample.

Define what counts as a deficiency
Write a short standard that states what a control deficiency is for your organization, including failed operation of a control, a control that is missing or poorly designed, and an evidence gap that prevents the control from being shown. Map each in-scope criterion to the controls that operate it so reviewers know what a failure looks like. The output is an approved definition, signed off by the control owner and the person accountable for the control environment. Done means every control in the control matrix can be checked against that definition.
Set a severity scale and apply it consistently
Create a severity scale with a small number of levels, each described by impact on the criteria, likelihood, and whether compensating controls exist. The scale reflects your organization's own judgment, not a category supplied by the framework, so document the reasoning behind each level and the people who decide it. Apply it the same way across teams and record the rationale for every rating, because an auditor will test whether similar deficiencies received similar treatment. The output is a written scale with worked examples.
Set escalation thresholds and recipients
For each severity level, name who must be told, how quickly, and through which channel. Lower levels may go to the control owner and the security or compliance lead, while higher levels reach senior management and, where the risk warrants it, the board or a board committee. Write these thresholds into a policy so the routing does not depend on who happens to notice the problem. The output is an escalation matrix with named roles, and a record that the recipients acknowledged receipt.
Stand up a single deficiency register
Open one register that holds every deficiency from internal reviews, monitoring alerts, penetration tests, vulnerability scans and audit fieldwork. Require consistent fields: identifier, description, linked criteria and controls, severity, date identified, source, owner, root cause, compensating controls, and status. Where scanning or testing tools already produce findings, configure them to feed the register rather than maintaining a parallel list. The output is a register that holds all open and closed items and can be exported for the auditor.
Set corrective action plan rules
Require every open deficiency to have a corrective action plan that names a single accountable owner and a due date set by the owner and approved by the escalation recipient for that severity. The plan should state the fix, the root cause it addresses, and how the fix will be verified. Confirm internally what due-date expectations your policies set, since no fixed timeline is specified by the criteria. The output is a documented plan attached to each register entry, with approval recorded.
Run a recurring review of open items
Hold a standing review, at a cadence the policy sets, where the compliance lead walks through every open item, checks whether due dates are realistic, escalates anything overdue or newly severe, and records decisions. Include a summary for senior management and, for higher severity items, a report to the board or its committee. The output is minutes or a dated review record showing who attended, what changed and what was escalated. These records are often what shows that monitoring of deficiencies actually happens.
Define closure criteria that require validation
Closure should require evidence that the corrective action works, not only that the owner marked it done. Define what validation looks like for each type of fix, such as a retest, a re-performed control, a sample of new evidence, or a review by someone independent of the owner. Record the validator, the date and the evidence reference in the register before the item moves to closed. The output is a closed item that another person could reopen from the record alone.
Confirm the process before fieldwork
Test the whole sequence on a sample of recent deficiencies before the auditor asks. Pick items from different sources and severities, and confirm each has a definition, rating rationale, escalation record, owner, plan, review entries and validated closure. Fix gaps in the register and policy now, and tell the auditor what the process is so the review period evidence matches the written design. The output is a short internal test record showing the process operated as written.

Evidence that shows deficiencies were evaluated, communicated and closed

An auditor testing CC4.2 follows one deficiency from discovery to closure and asks for a record at each step. The cards below cover the artifacts that carry that trail, and the review routine that keeps them current between audits.

Deficiency register with status history

The register is the master list of every control deficiency found by monitoring, internal review, testing, incidents or the auditor. Each entry needs an identifier, the control it affects, the date it was logged, the source that found it, and a dated history of every status change. Check that entries are never deleted, only moved through statuses, because an auditor who sees gaps in identifiers or edited dates will question the whole record. Every status change must carry a date and a name.

Documented severity evaluations

For each deficiency, the record should show how the organization judged its severity and whether it is a control deficiency, a significant deficiency or a more serious failure, along with the reasoning. Write down the criteria used, such as the likelihood of a commitment being missed and the effect on customer data. Auditors test whether the evaluation was consistent across items and whether the person who made it had the authority to do so.

Escalation records and board minutes

CC4.2 expects significant deficiencies to reach senior management and, where appropriate, the board. Keep the escalation notice, the date it was sent, the recipients, and the minutes showing that the item was discussed and a decision was recorded. A notice that was sent but never discussed is weak evidence, so the minutes should name the item and the decision taken.

Corrective action plans with owners and dates

Each deficiency that needs remediation should have a written plan naming the action, the accountable owner, the target date and any interim compensating control. Plans that change target dates should record the reason and the approver of the change. Ask whether the owner has the access and budget to finish the work, because a plan with an owner who cannot act is a finding waiting to happen.

Closure validation and retest results

Closing a ticket is not enough. The record should show how the fix was verified, such as a retest of the vulnerability, a re-performed control check, or a sample of transactions after the change. Store the retest output and the name of the person who validated it, separate from the person who made the fix. Where the fix relies on a tool, such as a rescanned host or a rerun pipeline check, keep the scan or check output with its date.

Recurring review cadence records

A standing review of open items, held on a fixed schedule such as monthly, shows that deficiencies stayed under management attention over the whole period. Each meeting should leave an agenda, attendance, the list of open items with age, and minutes recording what was discussed and decided. Between audits, schedule the meeting in advance, assign someone to take minutes, and file them the same day so the review trail is never reconstructed later.

What meeting CC4.2 costs in money and effort

This table lists each cost component of running CC4.2 deficiency evaluation and corrective action, who is paid for it, whether it is one-time or recurring, and what pushes it up. Use it to build a quote request, since no price or duration is stated here and each line depends on your own scope.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up and what to ask a quote to include
Tooling or licenses for the deficiency register and ticketing	Software vendor or open-source project maintainers; your platform team for hosting	Recurring for commercial licenses; one-time for setup and integration	Commercial licenses scale with users or sources. Open-source options such as DefectDojo (BSD-3-Clause) and CISO Assistant (AGPL-3.0-only) can remove license spend, but hosting, upgrades and support remain. Ask the quote to list hosting, setup, data migration and upgrade effort separately.
Engineering time for remediation	Your engineers, or an implementation partner if scoped in writing	One-time per deficiency, with recurring effort as new deficiencies appear	This is usually the largest and most variable line. It rises with the number of findings, the age of unresolved items and the number of system owners. Ask the quote to state which remediation work is included and which is owned internally.
Management time for evaluation and board reporting	Control owners, the CISO or equivalent, and the board or its committee	Recurring, usually on a set reporting cadence	Time grows with the number of severity levels, owners and reporting packs. A clear severity scale and a standard board summary reduce it. Ask the quote to show who prepares each report and how many reviews are assumed.
Evidence upkeep for the review cadence	Control owners and the compliance lead	Recurring across the observation period	Effort rises with how many sources feed the register, such as scanners, tickets and audit findings, and how often they are reconciled. Deduplicating findings at import reduces the manual review load. Ask the quote to confirm which evidence artifacts are produced each cycle.
External testing or review of corrective action	Independent testers or reviewers, if you buy them	Recurring, often tied to the testing schedule	Scope, number of systems and the depth of retesting drive the price. Confirm whether retest of closed findings is included, since that is where many engagements add cost. Ask for scope and deliverables in writing before work starts.
Auditor sampling effort	Your team (to produce records) and the independent CPA firm (to sample and test)	Recurring each examination period	Auditors sample deficiency records and closure evidence. Incomplete tickets, undated decisions or missing approvals increase follow-up requests. Ask your auditor in the engagement letter what samples they expect and in what format.

Self-hosted open-source tools that support deficiency tracking

Deficiencies found by monitoring, audits and tests need one place where they are recorded, scored, assigned and followed to closure. The three tools below each cover part of that path, from scan results to findings consolidation to framework mapping. None of them replaces the judgment of the people who evaluate a deficiency, and the organization remains responsible for the evidence that shows it was handled.

DefectDojo findings register

DefectDojo (BSD-3-Clause) imports and reimports findings from more than 500 security tool report formats through its UI or API, and the open source edition includes this capability. A generic findings import covers sources that have no native parser, such as a spreadsheet from an internal review. Its deduplication relies on per-tool hashcode fields, so repeated results from the same scanner update one finding rather than creating duplicates. Check that your chosen parsers produce stable hashcodes, because unstable values inflate the register and make trend reporting unreliable. Confirm the license terms with your own counsel before embedding it in a product.

Greenbone scan results store

Greenbone Community Edition (AGPL-3.0-or-later) runs the gvmd service, which schedules scan tasks, manages users and permissions, and stores results in PostgreSQL. Users review findings in the Greenbone Security Assistant web interface, which gives a record of who looked at each result. For CC4.2 this matters because scan output is often the first source of a deficiency, and the schedule and access records show whether it was evaluated promptly. Ask the vendor or your counsel how AGPL-3.0-or-later obligations apply if you modify and expose the service to users outside your organization.

CISO Assistant assessment records

CISO Assistant (AGPL-3.0-only) ships more than 200 frameworks, including SOC 2, and runs audits and compliance assessments against them with automatic mapping between frameworks. It can hold the record that links a deficiency to the criterion it affects and to the corrective action taken. Use it to show a reviewer that a deficiency under CC4.2 was communicated and tracked against the right control, instead of rebuilding that link during fieldwork. Confirm which SOC 2 criteria are loaded in your version and check that its mappings match your own control matrix. The AGPL-3.0-only license carries copyleft obligations that your legal team should review before deployment.

Who owns the evaluation, who prepares the evidence, and who tests it

Your organization owns CC4.2 in full. Control owners know where their controls can fail, security and compliance leads decide how deficiencies are rated, and senior management and the board decide what gets escalated and what risk the organization accepts. None of these decisions can be delegated to a tool or a vendor, because the assessor will look for evidence that people with authority reviewed the results and acted on them.

Control owners: report suspected control failures promptly and provide the facts needed to rate them.
Security and compliance leads: set the severity scale, assign owners and due dates, and decide whether a finding is a deficiency, a significant deficiency or a closed item.
Senior management: reviews open deficiencies at a set cadence and approves risk acceptances in writing.
The board or a board committee: receives summaries of significant deficiencies and corrective action status, with minutes that record the discussion.
Corrective action owners: close items with evidence and not only with a status change.

Confirm with your auditor which severity categories and escalation thresholds they expect to see documented before fieldwork begins.

Where CC4.2 usually fails and how to close each gap

CC4.2 is rarely missing on paper. It fails when deficiencies exist but nobody records them, ranks them consistently, escalates them, or proves the fix worked. The cards below cover six gaps that assessors commonly test, each paired with the fix that closes it.

Deficiencies live in chat and email

When a control failure is raised in a chat thread or an email, it has no owner, no status and no date, and it disappears once the thread scrolls away. An assessor testing CC4.2 will ask for the population of deficiencies over the period and will not accept a search through inboxes as a complete list. Close the gap with one deficiency register that every team must use, and check that a sample of chat-raised issues appears in it. A self-hosted tracker such as DefectDojo can hold findings from security tools, while other issues can be logged in the same system under a consistent template.

Severity judged differently by each team

Engineering, security and operations often rate the same deficiency differently, so the same issue is urgent to one group and routine to another. CC4.2 expects deficiencies to be evaluated, which requires a shared scale with defined criteria for impact and likelihood. Write the scale into the monitoring procedure, and record the rationale for each rating so the reviewer can see why it was set. Recheck a sample of ratings each quarter to confirm teams apply the scale the same way.

Board escalation never recorded

Many programs escalate serious deficiencies informally, in a hallway conversation or a verbal update, and leave no record. CC4.2 refers to communicating deficiencies to senior management and the board as appropriate, so the escalation decision itself must be traceable. Define in advance which severities go to the executive team or a board committee, and keep the meeting minutes or a dated memo showing what was presented and what was decided. Where the board chooses not to escalate an item, record that decision too.

Corrective actions without owners or dates

A remediation item that says "fix MFA gap" with no named owner and no due date cannot be tracked, and an assessor will treat the deficiency as unresolved. Each corrective action should name one accountable person, a target date set when the action is agreed, and the criteria that show it is complete. Review overdue items at a fixed cadence and record any date change with a reason. Ask your team to confirm that every open action in the register meets this standard before fieldwork begins.

Fixes closed without validation

Teams often mark a deficiency closed when the change ships, without checking whether the control now operates as designed. CC4.2 covers tracking corrective action to closure, and closure should mean evidence that the fix works. For each closed item, retain the test result, configuration output or re-scan that confirms the outcome, and have someone other than the implementer approve the closure. Vulnerability items can be confirmed with a rescan in a scanner such as Greenbone Community Edition, which stores results in PostgreSQL and lets reviewers compare runs.

CC4.1 findings logged separately

Deficiencies found by continuous monitoring, internal audit and penetration tests are often stored in different tools, so no one sees the whole picture when judging severity or trends. CC4.2 evaluates deficiencies regardless of which evaluation found them, so separate logs make it hard to show completeness. Route findings from each CC4.1 source into one register, tag each entry with its source and control reference, and reconcile the sources at a set interval. This is also where a compliance platform such as CISO Assistant, which maps controls across frameworks, can help link a finding to the criteria it affects.

Questions buyers ask about CC4.2 before hiring help

How much effort does a CC4.2 deficiency process take to set up and run?

Setup effort depends mainly on how many controls are in scope, how many teams own them, and whether anyone already logs issues in a consistent way. The first build covers defining severity levels, agreeing who evaluates each deficiency, setting escalation paths to senior management and the board, and creating a register. Running it is recurring work: logging new deficiencies, reviewing them on a set cadence, and chasing corrective actions to closure. Teams with many control owners and frequent changes will spend more time on triage than a small team with a stable environment. Ask a partner to size these drivers in the written scope rather than accepting a generic estimate.

Can a company run CC4.2 in-house without an outside partner?

Yes. CC4.2 is a management process, and the organization owns it. Companies with an experienced security or compliance lead, clear control owners and a habit of reviewing findings can usually run it themselves. Outside help tends to be useful when the team lacks time to design the severity model, when findings are scattered across scanners, tickets and spreadsheets, or when the first audit period is approaching and no one has tested the process end to end. Whatever the choice, the organization should be able to show that deficiencies were evaluated, communicated and closed on a consistent basis.

What does the deficiency process need from control owners and management?

It needs named owners who accept responsibility for each control and for fixing its deficiencies. Control owners must report problems when they find them, supply the facts needed to judge severity, and commit to dates for corrective action. Management needs to set the severity criteria, approve risk acceptances, and receive summaries that show open items, overdue actions and recurring themes. Without management attention, deficiencies pile up in tickets nobody reads. Confirm with your leadership team how often they will review the register before the process goes live.

Will the SOC 2 auditor design our deficiency process for us?

No. The independent CPA firm tests whether the process exists, operates as described and is supported by evidence, but it does not design or run it. Designing the process is management's job, and an implementation partner may help prepare the system, templates and records. Auditors may also ask about deficiencies found during the audit period, and they will expect the organization to have identified and handled them. Any firm that offers to design your controls as part of the audit creates an independence question, so ask how that is handled before engaging.

What should we do about a deficiency found during the audit period?

Log it immediately, record what the control was supposed to do, what happened, and the date it was found, then evaluate its severity and tell the people who must act. Assess whether it indicates a broader failure, check whether other periods or systems are affected, and agree on corrective action with a dated owner. Keep the record of the fix and the evidence that it worked. Do not hide or delete the finding. Tell your auditor early so they can plan testing, because the way a deficiency is handled often matters as much as the deficiency itself. Confirm with your auditor how they want exceptions documented.

Do we need a single tool for CC4.2, or is a register enough?

A single tool is not required. What the criterion needs is a reliable record of deficiencies, their evaluation, who was told, and how corrective action was tracked to closure. A well-maintained register, even a controlled spreadsheet or ticket queue, can meet that need for a small program. Larger environments often benefit from tools that import findings from scanners and deduplicate them. For example, DefectDojo imports and reimports findings from more than 500 security tool report formats and deduplicates findings using per-tool hashcode fields, and Greenbone Community Edition stores scan results in PostgreSQL and schedules scan tasks. Confirm each tool's capabilities against its documentation before relying on it, as a tool does not make the process compliant by itself.

What should we ask a partner to include in a fixed-scope quote?

Ask for the written scope to list the controls and systems covered, the deficiency criteria and severity model to be built, the register or tool to be configured, the escalation paths and reporting templates, the training for control owners, and the evidence samples to be produced. Ask which items are one-time and which need recurring work, who performs each task, and what the organization must supply, such as named owners, access to systems and meeting time. Confirm the deliverables and acceptance criteria, and ask how the partner will avoid designing controls that the same firm later tests. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and it prepares systems and evidence without issuing audit reports.

How DeployOpen sets up CC4.2 evidence in your environment

DeployOpen helps organizations prepare the systems and records that show how deficiencies are evaluated, communicated and closed out. We plan and implement self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and we document the workflow so your team and your independent SOC 2 auditor can follow it. The organization owns its controls and decides what counts as a deficiency; an independent CPA firm performs the examination and issues the report.

How we scope

Agree in writing which sources of deficiencies are in scope, such as monitoring alerts, audit findings and vulnerability results.
Define the severity scale, owners, escalation paths and the people who receive board and senior management reporting.
Confirm with your auditor which period and evidence samples the CC4.2 workflow must cover before work starts.

How we build

Configure a self-hosted findings platform so results from scanners and testing tools land in one tracked register.
Set deduplication and ownership rules so each deficiency has a single accountable owner and a documented due date.
Test the escalation and closure workflow with sample deficiencies to confirm that records are complete and retrievable.

How we hand over

Deliver written procedures describing how deficiencies are evaluated, communicated to senior management and the board, and corrected.
Provide an evidence map linking each CC4.2 point of focus to the system records, exports and meeting minutes that show it.
Walk your control owners and auditor through the register so they can pull samples without rebuilding the trail themselves.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope engagement ends.
Review the deficiency register before each audit period so open items and aged corrective actions are visible in advance.
Confirm with your auditor how long records must be retained and what changes to the workflow need to be documented.