Evaluate internal control frameworks, design effectiveness, operating effectiveness, and IT controls.
Control frameworks help practitioners evaluate whether controls are designed to address risk and whether those controls operate as intended. In Assurance cases, the issue is rarely the framework name by itself. The issue is whether the framework, control design, evidence, and IT environment support the engagement objective.
A strong response separates design effectiveness from operating effectiveness, identifies IT dependencies, and explains the reporting or communication consequence of control deficiencies.
This lesson focuses on how to:
A control can look appropriate on paper and still fail in practice. A control can also be performed consistently but still fail to address the right risk. These are different problems and should be analyzed separately.
| Question | Design effectiveness | Operating effectiveness |
|---|---|---|
| Main issue | Would the control address the risk if performed as described? | Was the control performed consistently and properly during the period? |
| Evidence | Process description, control objective, segregation, approval levels, system configuration. | Signed reviews, logs, exception reports, reconciliations, timestamps, and reperformance. |
| Common weakness | Control does not cover the risk, lacks authority, or is performed by the wrong role. | Control is skipped, late, undocumented, incomplete, or performed without competence or independence. |
| Assurance effect | Design gap may require different controls, different procedures, or direct substantive work. | Operating failure may increase assessed risk and require more substantive work or communication. |
For example, a monthly review of all manual journal entries may be well designed if the reviewer is independent, understands the risk, and investigates unusual entries. It may still fail operationally if the review was not performed for three months or if the evidence shows only a signature with no investigation of exceptions.
A recognized framework gives structure, but the response should still apply the case facts. The framework is the evaluation lens, not the answer.
| Framework or lens | When it helps | Assurance focus |
|---|---|---|
| Internal control framework | Evaluating control environment, risk assessment, control activities, information, communication, and monitoring. | Whether controls address reporting or subject-matter risks. |
| IT general controls lens | Evaluating systems, access, change management, operations, backup, and security. | Whether automated evidence and processing can be relied on. |
| Compliance control lens | Evaluating deadlines, regulatory rules, grant restrictions, contract terms, or policies. | Whether the entity can demonstrate compliance against suitable criteria. |
| Service or operational control lens | Evaluating service delivery, program performance, economy, efficiency, or effectiveness. | Whether controls support mandate objectives and reliable reporting. |
The chosen lens should fit the user decision. A lender covenant compliance engagement may emphasize compliance controls and reportable evidence. An audit of financial statements may emphasize internal control over financial reporting and IT controls supporting system-generated reports.
Many Assurance cases include system risk. IT should not be treated as separate from evidence. If the practitioner relies on a system report, automated calculation, workflow approval, access log, or electronic exception report, IT controls affect whether that evidence is reliable.
| IT area | Risk | Assurance response |
|---|---|---|
| User access | Unauthorized users may change records, approve transactions, or bypass segregation of duties. | Review access rights, approval, periodic recertification, and termination procedures. |
| Change management | Unapproved system changes may affect processing or controls. | Inspect change tickets, testing evidence, approvals, and migration controls. |
| Automated controls | System controls may be misconfigured or overridden. | Test configuration and consider the IT general controls supporting the automated control. |
| Audit logs | Logs may be incomplete, altered, or not reviewed. | Assess log retention, review process, exception follow-up, and administrator access. |
| Backups and recovery | Data loss or service disruption may affect operations and reporting. | Review backup schedule, restore testing, incident response, and recovery responsibilities. |
| Data extraction | Reports used as evidence may be incomplete or filtered incorrectly. | Test report parameters, completeness, source-system controls, and reconciliation to records. |
An IT weakness can have a broad effect. If terminated employees retain access to the accounting system, the issue may affect payroll, purchases, journal entries, and system-generated evidence. The response should consider whether additional procedures are needed beyond the immediate exception.
Classify the issue before recommending. A design problem, operating problem, documentation problem, IT problem, and monitoring problem may require different responses.
| Deficiency type | Example | Assurance implication |
|---|---|---|
| Design deficiency | No independent review of a complex estimate. | The control cannot address the risk as designed. |
| Operating deficiency | A review exists but was not performed for several months. | Control reliance may not be appropriate for the affected period. |
| Documentation deficiency | A control may have occurred but no evidence remains. | The practitioner may need alternative evidence or more substantive procedures. |
| IT deficiency | Users retain access after termination. | Broader system reliability, unauthorized change, and fraud risk may increase. |
| Monitoring deficiency | Exceptions are reported but not resolved. | Communication and remediation tracking may be required. |
Recommendations should be proportionate. A missing approval may require a defined approval threshold, clearer authority, system workflow controls, or compensating review. A system access problem may require role-based access, periodic recertification, timely deactivation, and monitoring of privileged accounts.
| Step | Question | Output |
|---|---|---|
| 1. Risk | What reporting or assurance risk should the control address? | Risk and assertion or criterion. |
| 2. Framework | Which control lens fits the engagement context? | Framework or evaluation basis. |
| 3. Design | Would the control address the risk if performed? | Design conclusion. |
| 4. Operation | Did the control operate consistently with evidence? | Operating conclusion. |
| 5. Assurance effect | What changes in procedures, reliance, communication, or remediation are needed? | Engagement response. |
Use this sequence when a case includes a control matrix, process description, IT exception, internal audit finding, or management action plan.
| Pitfall | Correction |
|---|---|
| Naming a framework without applying it. | Explain how the framework helps evaluate the specific control issue. |
| Confusing design and operating effectiveness. | Ask separately whether the control could work and whether it did work. |
| Relying on undocumented controls. | Require evidence of performance or plan alternative procedures. |
| Ignoring IT dependencies. | Assess access, changes, automated controls, logs, and report reliability. |
| Recommending a control without communication. | State who should receive the deficiency and what follow-up is needed. |