Evaluate information systems, recognised internal-control frameworks, key controls, and control design.
Internal control matters in Performance Management because weak systems produce weak decisions. A control framework is not an audit checklist in this context; it is a way to evaluate whether information is complete, accurate, timely, protected, approved, and useful for management action. A strong response connects the control to the process objective and the decision risk.
Information systems are part of the control environment. A dashboard, KPI report, inventory module, payroll system, procurement workflow, or customer database is useful only if management can trust the data and the control trail behind it.
This lesson focuses on recognized internal-control frameworks, information-system controls, key control design, operating effectiveness, and control matrices. The goal is to move from framework language to practical management advice.
| Topic | Performance Management use |
|---|---|
| Control framework | Organize control environment, risk assessment, control activities, information, communication, and monitoring. |
| Information system | Assess whether data is reliable enough for decisions and accountability. |
| Key control | Identify the control that materially reduces a process, reporting, compliance, or asset risk. |
| Design assessment | Decide whether the control would address the risk if performed as described. |
| Operating effectiveness | Decide whether the control actually operated consistently and with evidence. |
| Control matrix | Link risk, control, owner, frequency, evidence, gap, and recommendation. |
A recognized framework helps structure the answer, but the value comes from applying it to the case facts.
| Framework element | Performance Management question |
|---|---|
| Control environment | Does leadership set accountability, ethics, role clarity, and control expectations? |
| Risk assessment | Has management identified what could prevent reliable reporting or effective operations? |
| Control activities | Are approvals, reconciliations, segregation, system checks, and reviews designed for the risk? |
| Information and communication | Does the system produce complete, accurate, timely, and useful information? |
| Monitoring | Does management know whether controls are operating and whether exceptions are fixed? |
The framework label should not replace the analysis. State the risk, the control objective, the existing control, the weakness, the consequence, and the improvement.
A key control is important enough that failure would make the process unreliable or expose the entity to significant risk. The best control is not always the heaviest control. It is the control that addresses the risk at the right point in the process without creating unnecessary delay or unclear accountability.
| Process risk | Possible key control | What makes it stronger |
|---|---|---|
| Sales are recorded without valid order approval. | System blocks order release until approval and credit check are complete. | Automated workflow, documented evidence, exception report, and independent review. |
| Purchases are made from unapproved suppliers. | Supplier master changes require independent approval. | Segregation between requester, approver, and master-data maintainer. |
| Payroll changes are unauthorised. | HR-approved change file reconciled to payroll master changes. | Access rights, audit trail, and periodic exception review. |
| Inventory records are unreliable. | Cycle counts reconciled to system records and investigated. | Count independence, variance threshold, and root-cause follow-up. |
| Management reports use incomplete data. | Data extraction reconciled to source system totals. | Owner sign-off, automated validation, and late-change control. |
| System access is excessive. | Role-based access review performed and documented. | Least-privilege roles, timely removal, and review by process owner. |
The distinction between design and operating effectiveness is central.
| Question | Design issue | Operating-effectiveness issue |
|---|---|---|
| What is wrong? | The control would not address the risk even if performed. | The control is appropriate but was not performed, evidenced, reviewed, or followed up. |
| Example | Same employee can create supplier and approve payment. | Supplier change approval exists but was skipped for several changes. |
| Recommendation | Redesign roles, workflow, control objective, or system rule. | Improve performance, evidence, training, monitoring, or escalation. |
| Evidence needed | Process map, risk-control matrix, system configuration. | Samples, logs, sign-offs, exception reports, review notes. |
This distinction improves the recommendation. A design failure needs redesign. An operating failure needs better execution, evidence, supervision, or monitoring.
Performance Management candidates should connect controls to information reliability. If KPI data, budget reports, cost allocations, or operating dashboards are unreliable, performance recommendations can be wrong even when the analysis method is sound.
| Control type | PM relevance |
|---|---|
| Input validation | Prevents incomplete, duplicate, or invalid transactions from entering the system. |
| Access rights | Limits who can create, approve, change, or view sensitive data. |
| Change management | Reduces risk that system changes break reports, workflows, or controls. |
| Interface reconciliation | Confirms data moved completely between systems. |
| Exception reporting | Directs management attention to unusual transactions or failed controls. |
| Audit trail | Provides evidence for review, accountability, and investigation. |
When the facts involve a new system, manual spreadsheet, interface, dashboard, or outsourced platform, consider whether data integrity, access, change control, backup, and exception review are adequate.
A control matrix is useful because it forces the response to connect risk, control, owner, frequency, evidence, and gap. A matrix can also show whether management has too many low-value controls and too few controls over the main risks.
| Matrix column | What to evaluate |
|---|---|
| Risk | Is the risk specific enough to control? |
| Control objective | What should the control prevent or detect? |
| Control activity | Does the activity address the objective? |
| Owner | Is the owner independent and accountable? |
| Frequency | Is the control timely enough for the risk? |
| Evidence | Would a reviewer know the control operated? |
| Exception handling | Are problems investigated and escalated? |
If the matrix is incomplete, state the missing owner, frequency, evidence, threshold, or escalation requirement.
Use this sequence for a control-framework issue:
| Pitfall | Correction |
|---|---|
| Naming COSO or another framework without applying it. | Use the framework to organize the specific process risk and control response. |
| Confusing design with operating effectiveness. | Ask whether the control is badly designed or merely not performed. |
| Recommending more approvals by default. | Match the control to the risk and consider cost, delay, and accountability. |
| Ignoring system evidence. | Identify logs, exception reports, reconciliations, and sign-offs needed. |
| Treating control as separate from performance. | Explain how the control improves information reliability, accountability, or decision quality. |