TSC-CC4.2 Guidance

TSC-CC4.2 requires you to identify internal control deficiencies, evaluate their severity and impact, and communicate them to the right stakeholders fast enough that corrective action can happen before customers or reporting are harmed ¹. Operationalize it by running a documented deficiency intake-and-triage workflow with clear owners, timelines, evidence, and escalation paths.

Key takeaways:

• You need a written process to log, assess, and track control deficiencies through remediation with defined escalation points ¹.
• Auditors look for timely communication plus proof: tickets, meeting minutes, emails, risk acceptances, and closure evidence ¹.
• The usual failure is ad hoc handling (Slack decisions, no severity rubric, no follow-up). Fix it with a single system of record and recurring review.

TSC-CC4.2 is a “make it real” requirement. Most teams already find problems through incidents, internal audits, penetration tests, access reviews, customer escalations, or third-party risk assessments. The gap is what happens next: inconsistent severity calls, unclear escalation, and weak proof that leadership knew, decided, and funded remediation in time.

This page translates the tsc-cc4.2 guidance requirement into an operator-ready playbook. The practical goal is simple: every control deficiency should be (1) captured, (2) evaluated using a consistent rubric, (3) communicated to the appropriate level of management or governance, and (4) tracked to closure (or formally accepted) with an audit-ready trail ¹.

If you are a Compliance Officer, CCO, or GRC lead supporting SOC 2, treat this as your deficiency-management standard operating procedure. You will also find it useful for ISO 27001 corrective actions, internal audit issue management, and board reporting, but the authoritative text for this page is the AICPA Trust Services Criteria ¹.

Regulatory text

Excerpt (TSC-CC4.2): “COSO Principle 17: The entity evaluates and communicates internal control deficiencies in a timely manner” ¹.

What the operator must do (what “evaluate” and “communicate” mean in practice)

Under TSC-CC4.2, you must run a repeatable process that:

1. Detects and records deficiencies (control design gaps, operating failures, or missing controls).
2. Evaluates each deficiency for severity and impact so you can prioritize remediation.
3. Communicates deficiencies to the right internal audiences (control owners, security leadership, compliance, executive leadership, and governance bodies) quickly enough that decisions and remediation are not delayed ¹.

Auditors generally expect more than “we fix things.” They expect an issue lifecycle with defined responsibilities, evidence of escalation, and proof that the organization’s governance structure is informed and responsive.

Plain-English interpretation (what you’re being held to)

You need a system that prevents control problems from dying in Slack. If a control fails, your organization should be able to answer:

• Who found it?
• When was it logged?
• Who evaluated it, using what criteria?
• Who was told, and when?
• What remediation was approved, by whom?
• What changed, and when was it verified effective?

If you can produce those answers with consistent artifacts, you are aligned to TSC-CC4.2 ¹.

Who it applies to (entity and operational context)

Applies to: Organizations undergoing a SOC 2 audit under the AICPA Trust Services Criteria common criteria ¹.

Operationally, it touches:

• Security and IT operations (incidents, vulnerability management, change management)
• Engineering (secure SDLC findings, code review gaps, pipeline control failures)
• GRC/compliance (control testing, SOC 2 readiness, internal audit issue management)
• HR and Finance (access provisioning failures, segregation-of-duties exceptions)
• Third-party risk management (deficiencies discovered in third-party reviews that affect your control environment)

If you have multiple products or business units, auditors will expect the deficiency process to cover the in-scope systems and the people who operate them, not just the compliance team.

What you actually need to do (step-by-step)

Step 1: Define what counts as a “deficiency”

Create a short definition section in policy/procedure that includes:

• Design deficiency: control missing or not suitably designed.
• Operating deficiency: control exists but was not performed as designed.
• Evidence deficiency: control may have operated, but proof is missing or incomplete (this still becomes a SOC 2 problem during testing).

Keep the definition aligned to your control set and testing approach ¹.

Step 2: Stand up a single intake channel (one system of record)

Pick one place where every deficiency is recorded:

• GRC tool issue module, or
• Ticketing system (Jira/ServiceNow) with a dedicated “Control Deficiency” issue type, or
• A controlled spreadsheet only as a temporary bridge (high risk for audit gaps)

Minimum fields to capture:

• Unique ID
• Date identified
• Source (control test, incident, customer, third party assessment)
• Affected control(s)
• In-scope system(s)
• Initial description
• Owner (person, not team)
• Status (open / triaged / remediating / pending validation / closed / risk accepted)

Step 3: Implement a severity and escalation rubric

Create a rubric that is easy to apply and hard to argue with. Keep it tied to business impact and audit impact. Example categories you can operationalize without inventing external thresholds:

• High severity: likely customer impact, likely audit exception, or systemic failure across multiple controls/systems.
• Medium severity: limited scope but real control failure; remediation required with management visibility.
• Low severity: isolated documentation/evidence issue with low likelihood of recurrence; still tracked and fixed.

Then define escalation:

• High: notify security leadership + compliance, and include in governance reporting.
• Medium: notify control owner + compliance, review in recurring deficiency meeting.
• Low: assign and track; batch reporting acceptable.

This satisfies the “evaluate and communicate” expectations in TSC-CC4.2 ¹.

Step 4: Run a recurring deficiency review meeting (monitoring and follow-up)

Establish a cadence (weekly or biweekly is common as a practice choice) and document:

• Attendance (compliance, security, control owners)
• Decisions (severity, due dates, resourcing)
• Escalations triggered
• Blocks and dependencies

This directly supports timely communication and reinforces that deficiencies are not handled ad hoc ¹.

Step 5: Tie remediation to change management and validation

Require each deficiency to have:

• A remediation plan (what will change, where, who approves)
• Target completion date
• Validation method (re-test control, collect new evidence, run a sample)

Closure should mean “verified effective,” not “we think it’s fixed.” Keep validation evidence attached to the deficiency record ¹.

Step 6: Formalize risk acceptance (when you won’t remediate)

Sometimes you cannot remediate quickly (legacy system, contract limitation with a third party, business tradeoff). If you accept risk:

• Document the decision, rationale, compensating controls, and approval authority.
• Set a review trigger (e.g., re-approve annually, or on material change). This is a policy decision; pick a cadence you can execute.

Auditors typically challenge undocumented risk acceptance because it breaks the “communicate and respond” chain ¹.

Step 7: Keep an audit trail end-to-end

Your goal is a neat packet per deficiency: intake → evaluation → communication → remediation → validation → closure.

If you use Daydream, configure a workflow that maps deficiencies to controls, collects evidence in-line, and produces an exportable audit trail without chasing screenshots across tools. Treat it as your system of record rather than a reporting layer.

Required evidence and artifacts to retain

Keep these artifacts in a controlled repository with access controls:

1. Deficiency management procedure/policy (owned by GRC/Compliance) ¹
2. Deficiency log with required fields and statuses ¹
3. Severity rubric and escalation matrix ¹
4. Evidence of communication, such as:
   • email notices to control owners/leadership
   • meeting minutes with decision notes
   • governance reporting excerpts (e.g., risk committee deck pages)
5. Remediation artifacts, such as:
   • change requests, PR links, config change approvals
   • updated procedures or control narratives
6. Validation evidence, such as:
   • re-test worksheets
   • screenshots/log extracts showing the control ran
   • internal audit follow-up notes
7. Risk acceptance memos and approvals where applicable

Common exam/audit questions and hangups

Auditors commonly press on these areas (SOC 2 practicality, not enforcement):

• “Show me the last few deficiencies and how you decided severity.” Expect to produce the rubric and examples applied consistently ¹.
• “Who was notified, and when?” If the only record is a Slack thread, you may struggle.
• “How do you know remediation worked?” Closing without validation is a frequent hangup.
• “Do you track evidence gaps as deficiencies?” Many orgs treat missing evidence as “just paperwork,” but it affects audit results.
• “How do you ensure timely communication?” You need defined escalation triggers and proof they are used ¹.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails TSC-CC4.2	Fix
Deficiencies are tracked in multiple places	No complete population; missed escalations	Mandate one system of record and reconcile monthly
No severity rubric	Decisions look arbitrary; hard to defend timeliness	Publish a rubric; require reviewer sign-off
“Closed” means “work started”	No proof of effectiveness	Require validation artifacts before closure
Missing evidence isn’t treated as a deficiency	Repeats every audit cycle	Track evidence gaps as findings with owners and due dates
Leadership not in the loop for higher-risk issues	Breaks “communicates” expectation	Define escalation path and keep meeting minutes/emails

These map directly to common documentation and review gaps auditors flag under TSC-CC4.2 ¹.

Enforcement context and risk implications

SOC 2 is an audit framework, not a regulatory enforcement regime ¹. Your risk is commercial and operational:

• Untracked deficiencies become repeat audit exceptions, which can delay report issuance and impact customer renewals.
• Poor communication and escalation increase the chance that control failures turn into security incidents or reporting errors.
• Weak deficiency management also undermines your ability to assert effective governance over third parties and internal teams.

Practical 30/60/90-day execution plan

First 30 days: Put structure in place

• Publish a deficiency management procedure aligned to TSC-CC4.2 language ¹.
• Choose the system of record and create the deficiency intake form/issue type.
• Define severity levels and an escalation matrix with named roles (control owner, GRC, security leader).
• Train control owners and testers on “what to log” and “what good evidence looks like.”

Days 31–60: Operate the process and prove it works

• Start recurring deficiency review meetings; store minutes in a controlled location.
• Backfill currently known gaps into the log (open audit items, pentest findings, prior SOC 2 management letter items).
• Implement a closure checklist that requires validation evidence.
• Build a lightweight dashboard for open items, aging, and high-severity items for leadership consumption.

Days 61–90: Mature, test, and audit-proof

• Run an internal spot-check: pick a sample of deficiencies and verify end-to-end evidence exists ¹.
• Tune the rubric based on disputes and edge cases. Document rule changes and effective date.
• Add risk acceptance workflow (template + approval route) and confirm it’s used.
• Prepare an “auditor packet” template: policy, log export, sample deficiency packages, and governance reporting examples.

Frequently Asked Questions

What qualifies as an “internal control deficiency” under TSC-CC4.2?

Any gap in control design, operation, or evidence that could prevent your controls from meeting their objectives should be treated as a deficiency and evaluated and communicated in a timely manner ¹.

Does TSC-CC4.2 require a specific severity scoring model?

No specific model is mandated in the text; auditors expect a consistent method that you actually apply and can evidence across findings ¹.

Can we manage deficiencies in Jira instead of a GRC tool?

Yes, if Jira is controlled, has required fields, preserves history, and supports attachments/links that demonstrate evaluation, communication, remediation, and validation ¹.

Are missing screenshots or incomplete logs really “deficiencies”?

In practice, yes. If you cannot prove a control operated, you have an audit problem that should be tracked, evaluated, and fixed through the same deficiency workflow ¹.

How do we show “timely communication” to auditors without hard timelines in the criterion?

Define internal escalation targets and triggers in your procedure, then show evidence that notifications and decisions occurred promptly relative to discovery and risk level ¹.

What if the deficiency is in a third party’s control (e.g., a cloud provider)?

Log it, assess impact to your commitments, communicate internally, and track mitigation (compensating controls, contract action, or risk acceptance) with supporting records ¹.

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control management

Footnotes

1. AICPA TSC 2017