Principle 17: Evaluates and communicates deficiencies

Principle 17 sits in the Monitoring Activities component of the COSO Internal Control – Integrated Framework. In practice, it is the difference between “we found issues” and “we governed issues.” You can have strong control testing and still fail Principle 17 if deficiencies are not evaluated with consistent criteria, communicated to the correct level of management, tracked through remediation, and re-tested to confirm closure.

For a Compliance Officer, CCO, or GRC lead, the operational goal is simple: create an end-to-end deficiency lifecycle that is easy to run, easy to evidence, and hard to bypass. This page focuses on turning Principle 17 into a working requirement: a defined taxonomy, an evaluation method, a communication and escalation model, and an evidence package that stands up to internal audit, external audit, and regulator questions.

COSO is a framework, not a statute, but it commonly underpins SOX, internal audit programs, and enterprise control expectations. The operator’s standard is consistency: consistent identification, consistent evaluation, consistent communication, and consistent follow-through, aligned to COSO guidance ¹.

Regulatory text

Excerpt provided: “COSO internal control principle 17 implementation expectation.” ¹

What the operator must do (requirement-level):

• Establish a defined method to evaluate control deficiencies (including how you determine severity and impact).
• Communicate deficiencies promptly to the people who can take corrective action and make risk decisions.
• Ensure deficiency information reaches senior management and the board when the nature of the deficiency warrants escalation, consistent with your governance structure and risk appetite.
• Maintain evidence that deficiencies are tracked to remediation and that remediation is validated, not assumed.

This interpretation aligns to the Principle 17 intent: evaluate identified internal control deficiencies and communicate them in a timely manner to parties responsible for corrective action, including senior management and the board of directors, as appropriate ¹.

Plain-English interpretation (what Principle 17 requires)

A deficiency is any condition where a control is missing, poorly designed, not operating, or not documented enough to be relied on. Principle 17 requires you to do four things reliably:

1. Decide what the deficiency means (severity, scope, and business impact).
2. Tell the right people (control owner, process owner, compliance, risk, IT, senior leaders, board committees).
3. Fix it (with an approved remediation plan and deadline).
4. Prove it’s fixed (re-test or otherwise validate, then document closure rationale).

If your deficiency handling depends on individual judgment, inbox searches, or “we’ll get to it,” you do not have an operationalized Principle 17 program.

Who it applies to (entity and operational context)

Entity types: Any enterprise organization using COSO as its internal control framework baseline ².

Where it shows up operationally:

• SOX / ICFR programs (control testing, deficiency evaluation, audit committee reporting)
• Compliance programs (regulatory obligations, policy controls, surveillance, complaint handling controls)
• Information security and privacy controls (access management, change management, incident response controls)
• Third-party risk management (due diligence controls, ongoing monitoring controls, SLA controls)
• Finance, procurement, and operational controls (approvals, reconciliations, segregation of duties)

Functions involved:

• Control owners and process owners (first line)
• Compliance / risk / internal audit (second and third line roles vary by model)
• Legal and HR (for conduct-related deficiencies)
• IT and security (for technology control deficiencies)
• Senior management and board/audit committee (for escalations)

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

1) Define your deficiency taxonomy (write it down)

Create a short standard that defines:

• What qualifies as a deficiency vs. observation vs. enhancement
• Severity levels (example: low/medium/high) and what drives severity (financial impact, regulatory impact, customer impact, operational disruption, likelihood, control frequency)
• What triggers escalation to senior management and the board (for example: repeat issues, systemic issues, high-risk domains, evidence of misconduct, breakdowns in oversight)

Operator tip: Keep severity criteria small enough that two reviewers reach the same conclusion.

2) Standardize intake (one front door)

Set up a single workflow for deficiency intake from:

• Control testing (SOX, internal audit testing, compliance monitoring)
• Self-assessments (RCSA)
• Incidents and operational risk events
• Third-party monitoring findings
• Regulatory exam findings

Minimum required fields:

• Control ID/name, process, owner, location/system
• Description of condition and criterion (what is, what should be)
• Evidence references (files, tickets, screenshots, logs)
• Date identified, source, reviewer

3) Evaluate severity and root cause (separate the two)

Run two tracks in your workflow:

• Severity assessment (impact/likelihood, scope, affected controls, compensating controls)
• Root cause (training gap, unclear procedure, system limitation, access model, resourcing, governance failure)

Add a required reviewer/approver step (Compliance, Risk, Internal Audit, or a Deficiency Review Committee) for material items.

4) Assign remediation with accountable ownership

For each deficiency:

• Name a single remediation owner (not a group mailbox)
• Define corrective actions with acceptance criteria (what “done” means)
• Set due dates and interim milestones
• Require management to document any decision to accept risk instead of remediate, with rationale and duration

5) Communicate on a cadence, with escalation rules

Build a reporting package that rolls up:

• New deficiencies by severity and domain
• Aging and overdue items
• Repeat findings and systemic themes
• Exceptions/risk acceptances awaiting approval
• Closure metrics (what closed this period, and how validated)

Communication routing (example model you can tailor):

• Control owner + process owner: real-time notifications
• GRC/Compliance leadership: periodic rollup with trends
• Senior management risk committee: escalations + systemic themes
• Audit committee/board: high severity, systemic control failures, repeat failures, significant risk acceptances

6) Validate closure (don’t close on promise)

A deficiency closes only after you have:

• Evidence remediation is implemented (change ticket, policy update, system config proof, training completion evidence where relevant)
• Evidence remediation is effective (re-test results or monitoring output)
• Approval of closure (by evaluator independent from implementer, where feasible)

7) Map and evidence it (audit-ready packaging)

Maintain a simple mapping from Principle 17 to:

• Your deficiency management procedure
• Your workflows and reports
• Your evidence samples

If you use Daydream for GRC workflow, configure a dedicated “Deficiency Lifecycle” workflow with required fields, approvers, evidence attachments, and auto-generated reporting packs mapped to COSO Principle 17. This reduces the two common failure modes: missing artifacts and inconsistent classification.

Required evidence and artifacts to retain

Use this as your “ask list” for control owners and your own audit binder:

Governance and standards

• Deficiency management policy/standard (definitions, severity criteria, escalation rules)
• RACI (who evaluates, who approves severity, who reports, who remediates, who validates)
• Committee charters or management meeting terms of reference (if used)

Operational records

• Deficiency register (system of record export or report)
• Individual deficiency records with evidence attachments and timestamps
• Severity scoring worksheets or embedded scoring fields
• Root cause analysis records (where required by severity)

Communication artifacts

• Management reporting decks and distribution lists
• Board/audit committee materials (as applicable) and minutes references
• Escalation emails/tickets for time-sensitive issues (captured in system)

Remediation and validation

• Remediation plans with acceptance criteria
• Change management tickets, policy version history, training records (if relevant)
• Re-test plans and results; closure approvals

Common exam/audit questions and hangups

Expect these lines of inquiry:

• “Show me how you define a deficiency and how you classify severity. Who approves?”
• “How do you ensure all sources of findings feed into one lifecycle?”
• “How do you decide what goes to senior management vs. the board?”
• “Prove this item was remediated. Where is the validation evidence?”
• “How do you handle repeat findings? Do you treat them as systemic?”
• “Where are risk acceptances documented, and who approved them?”

Hangups that drive findings:

• No consistent severity model, so “high” in one area is “medium” in another.
• Closure without re-test evidence (“management said it was fixed”).
• Reporting exists, but distribution is unclear (“we think leadership saw it”).

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails Principle 17	How to avoid
Deficiencies tracked in spreadsheets across teams	No single source of truth; inconsistent fields; weak audit trail	Use one workflow and require intake for all findings
Severity decided informally	Inconsistent governance; poor escalation decisions	Write criteria; require reviewer approval for high severity
Closing items on due date extensions	Aging risk hidden; no accountability	Track original due date, revised due date, and approval
Root cause skipped	Repeat failures; remediation treats symptoms	Require root cause for higher-severity or repeat items
Board reporting is ad hoc	Governance gap	Define escalation triggers and a standard board package

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not list specific enforcement actions.

Operationally, weak deficiency evaluation and communication increases the chance that significant control failures persist across reporting cycles and spread across processes. It also creates a documentation gap: you may have done work, but you cannot prove governance and follow-through.

A practical 30/60/90-day execution plan

Day 0–30: Stand up the minimum viable deficiency lifecycle

• Draft and approve a deficiency management standard (definitions, severity, escalation).
• Define RACI and name approvers for severity and closure.
• Set up a single intake workflow (GRC tool or controlled register) with mandatory fields and evidence attachment rules.
• Produce a first management rollup report and confirm distribution.

Day 31–60: Make it consistent and auditable

• Train control owners and testers on classification and evidence expectations.
• Implement escalation triggers and a formal review forum for high-severity items.
• Add remediation acceptance criteria and closure validation requirements.
• Run a retroactive cleanup of open items: normalize severity, owners, and due dates.

Day 61–90: Prove it works and harden governance

• Perform sample-based QA on deficiency records (completeness, evidence, approvals).
• Add trend reporting: repeat findings, systemic themes, and overdue analysis.
• Conduct a tabletop “audit request” drill: produce end-to-end evidence for a sample of deficiencies.
• If you use Daydream, finalize COSO Principle 17 mapping and automated evidence packs for audits.

Frequently Asked Questions

What counts as a “deficiency” under Principle 17?

Treat a deficiency as a control design gap, a control operating failure, or missing/insufficient documentation that prevents reliance on the control. Your program should define this clearly and apply it consistently across all testing sources ².

Do we have to report every deficiency to the board?

No. Principle 17 expects communication to the appropriate level, with escalation to senior management and the board when warranted by severity, scope, or systemic risk. Document your escalation criteria and follow it consistently ³.

Can we close deficiencies when the remediation plan is approved?

Close only after implementation evidence and effectiveness validation exist (for example, re-test results). Approval of a plan is evidence of intent, not evidence the control now works.

How do we handle risk acceptance instead of remediation?

Require written rationale, approver identity, duration/expiry, and any compensating controls. Include accepted risks in the same reporting cadence so leadership sees the tradeoffs.

What’s the minimum evidence auditors expect for Principle 17?

A deficiency register with complete fields, documented severity and approvals, proof of communication/escalation, remediation plans, and closure validation evidence. Auditors also look for consistency across teams, not isolated examples.

How should Principle 17 work in third-party risk management?

Treat third-party control failures (missed due diligence, incomplete monitoring, SLA breaches, security exceptions) as deficiencies in your internal control system. Route them through the same evaluation, escalation, remediation, and validation lifecycle as internal findings.

Footnotes

1. COSO Internal Control guidance page; Weaver summary of COSO 17 principles

2. COSO Internal Control guidance page

3. Weaver summary of COSO 17 principles