How Mature Are Your Control Activities? Measuring Whether Controls Really Manage Risk

Organizations frequently spend enormous amounts of time documenting internal controls.

They build:

• Risk and control matrices

• Policies and procedures

• Approval requirements

• Reconciliations

• Segregation-of-duties controls

• System access controls

• Management reviews

• Automated controls

• Exception reports

• Supervisory reviews

Then Internal Audit, external audit, compliance, or management tests those controls and asks:

“Is the control operating effectively?”

That is an important question.

But there is another question that can tell management and the Audit Committee considerably more:

“How mature are our Control Activities?”

A control can operate successfully today while remaining highly dependent upon one employee, one spreadsheet, institutional knowledge, manual intervention, or a supervisor remembering to perform it.

Another organization may have the same control supported by documented procedures, assigned ownership, automated workflows, measurable performance indicators, exception monitoring, technology controls, and continuous improvement.

Both organizations technically have a control.

They clearly do not have the same level of control maturity.

Moving Beyond Effective or Ineffective

Traditional control testing frequently produces a binary conclusion:

Effective

or

Ineffective

A maturity assessment asks a different question:

How capable is this control of operating consistently, reliably, and sustainably over time?

For many organizations, a practical five-level maturity model can provide that answer:

Level 1 — Initial / Ad Hoc

Level 2 — Developing / Repeatable

Level 3 — Defined

Level 4 — Managed and Measured

Level 5 — Optimized

The objective is not automatically to move every control to the Level desired by the Organization's Governance. You have to know their risk appetite.

The required maturity should depend upon the significance of the risk.

A low-risk administrative control may operate adequately at Level 2 or Level 3.

A key financial reporting, cybersecurity, regulatory compliance, fraud-prevention, or safety control may need to operate at Level 4 or Level 5.

The principle should be straightforward:

Control maturity should be commensurate with risk.

COSO's Control Activities Component

COSO's Internal Control—Integrated Framework identifies three principles within the Control Activities component.

Principle 10 — Select and Develop Control Activities

The organization selects and develops control activities that help mitigate risks to achieving objectives to acceptable levels.

Principle 11 — General Controls Over Technology

The organization selects and develops general control activities over technology that support achievement of objectives.

Principle 12 — Deploy Through Policies and Procedures

The organization deploys control activities through policies establishing expectations and procedures putting those policies into action.

Those three principles provide an excellent architecture for a Control Activities Maturity Assessment.

Principle 10: Selecting and Developing Control Activities

The first maturity question is not:

“Do we have controls?”

Most organizations have hundreds or thousands of them.

The better question is:

“Can management demonstrate that the right controls have been deliberately designed to reduce identified risks to acceptable levels?”

Level 1 — Initial / Ad Hoc

Controls primarily develop in reaction to problems.

• Controls depend heavily upon individual employees.

• Control responsibilities may be unclear.

• Controls may not be linked to identified risks.

• Segregation of duties may be weak.

• Significant processes may contain control gaps.

• Management intervention frequently compensates for weak processes.

• Controls may exist because “we have always done it that way.”

The organization has controls, but there is limited evidence that it has systematically designed a system of controls.

Level 2 — Developing / Repeatable

Basic controls have become repeatable.

• Approvals and authorizations exist.

• Reconciliations are regularly performed.

• Supervisory reviews occur.

• Some segregation of duties has been established.

• Major processes have identifiable control owners.

• Similar transactions generally receive similar control treatment.

However, controls may still have only a weak connection to formal risk assessment.

Management knows what controls are performed, but may have difficulty explaining precisely which risks each control mitigates.

Level 3 — Defined

Controls are formally designed and documented.

Management can identify:

Risk → Control Objective → Control Activity → Control Owner → Evidence

Risk and control matrices may document:

• Significant risks

• Control objectives

• Key controls

• Preventive versus detective controls

• Manual versus automated controls

• Control frequency

• Control ownership

• Evidence retained

• Segregation-of-duties requirements

At Level 3, the organization has moved from having controls to having a defined control architecture.

Level 4 — Managed and Measured

Management begins measuring whether the control architecture actually works.

Management monitors such indicators as:

• Control exceptions

• Reconciliation differences

• Approval overrides

• Processing errors

• Duplicate transactions

• Segregation-of-duties conflicts

• Control failures

• Repeat audit findings

• Corrective-action aging

• Management overrides

• Control-performance trends

Controls are no longer merely documented.

Their performance is measured.

Level 5 — Optimized

Control design becomes dynamic.

Changes in:

• Risk

• Technology

• Business processes

• Regulation

• Fraud threats

• Organizational structure

• Transaction volume

• Data analytics

can trigger reconsideration of the control design.

Management continually asks:

“Is there a better control?”

Unnecessary controls may be eliminated.

Manual controls may be automated.

Detective controls may be replaced or supplemented with preventive controls.

Data analytics may identify exceptions across entire populations rather than relying upon limited samples.

The organization is continually improving the relationship between risk and control.

Principle 11: General Controls Over Technology

Modern organizations cannot have mature business-process controls while maintaining immature technology controls.

Consider how many critical controls now depend upon:

• ERP systems

• Accounting applications

• Cloud platforms

• Automated workflows

• Databases

• Interfaces

• Artificial intelligence

• User-access permissions

• System configurations

• Automated calculations

A beautifully designed automated control becomes questionable if unauthorized users can change the program or underlying data.

Technology maturity therefore matters.

Level 1 — Initial / Ad Hoc

• Access may be granted informally.

• Privileged access is poorly controlled.

• Changes may occur without formal approval.

• Terminated employees may retain access.

• System configurations may not be documented.

• Technology controls depend heavily upon particular IT personnel.

Level 2 — Developing / Repeatable

Basic IT general controls exist.

These may include:

• Password requirements

• User provisioning

• Backup processes

• Change approvals

• Security administration

• Basic system monitoring

Processes are repeatable but may not be consistently documented or independently reviewed.

Level 3 — Defined

Formal IT general-control processes cover areas such as:

• Logical access

• Privileged access

• User provisioning and termination

• Change management

• System development

• Computer operations

• Backup and recovery

• Cybersecurity

• Application interfaces

• Technology acquisition and maintenance

Responsibilities and evidence requirements are documented.

Level 4 — Managed and Measured

Technology controls generate measurable information.

Management monitors:

• Access violations

• Privileged accounts

• Failed login activity

• Emergency changes

• Unauthorized changes

• Security incidents

• Patch status

• Backup failures

• System availability

• User-access-review exceptions

IT control performance becomes part of enterprise control reporting.

Level 5 — Optimized

Technology increasingly strengthens the control system itself.

Organizations use:

• Automated access governance

• Continuous monitoring

• Exception analytics

• Automated segregation-of-duties analysis

• Continuous configuration monitoring

• Workflow controls

• Automated alerts

• Data analytics

• AI-assisted anomaly identification

Technology is no longer simply something that must be controlled.

It becomes an important mechanism for improving control maturity.

Principle 12: Policies and Procedures

Organizations often confuse documentation with control maturity.

They point to a 300-page policy manual and conclude:

“Our controls are well documented.”

Perhaps.

But a policy sitting on a SharePoint site does not control anything by itself.

The maturity question is:

“Are policies translated into procedures that people understand, consistently perform, evidence, supervise, and update?”

Level 1 — Initial / Ad Hoc

• Policies may be incomplete or outdated.

• Procedures depend upon institutional knowledge.

• Employees learn processes primarily from coworkers.

• Responsibilities are unclear.

• Documentation of control performance is inconsistent.

Level 2 — Developing / Repeatable

Basic policies and procedures exist.

Employees generally know what is expected.

However:

• Documentation varies among departments.

• Procedures may lag behind actual practices.

• Control evidence may be inconsistent.

• Responsibilities may depend upon particular individuals.

Level 3 — Defined

Policies and procedures formally establish:

• What must be performed

• Who performs it

• When it is performed

• Who reviews it

• What evidence must be retained

• How exceptions are handled

• Who receives escalation

Employees responsible for significant controls receive appropriate training.

Level 4 — Managed and Measured

Management measures compliance with established procedures.

It can identify:

• Controls not performed

• Controls performed late

• Missing evidence

• Unresolved exceptions

• Policy violations

• Repeat failures

• Overdue corrective actions

Control owners become accountable for measurable performance.

Level 5 — Optimized

Policies and procedures evolve with risk.

Management periodically asks:

• Is this policy still necessary?

• Does the procedure still address the risk?

• Can the control be simplified?

• Can it be automated?

• Are employees bypassing it?

• Has technology changed the process?

• Are new risks emerging?

The policy and procedure system becomes a living component of risk management rather than a static compliance library.

A Control Activities Maturity Scorecard

Management and Internal Audit can combine the three COSO principles into a practical assessment.

COSO Principle	Current Maturity	Target Maturity	Gap
Principle 10 — Control Selection and Design	2.8	4.0	1.2
Principle 11 — Technology Controls	2.4	4.0	1.6
Principle 12 — Policies and Procedures	3.2	4.0	0.8
Control Activities Component	2.8	4.0	1.2

That tells management considerably more than:

“Control Activities are effective.”

It shows where the weakness exists and how significant the capability gap may be.

Take the Assessment Down to the Individual Control Level

The methodology becomes even more useful when applied to significant controls.

Consider an accounts-payable vendor-change control.

Level 1

An employee receives an email requesting a bank-account change and updates the vendor master file.

Level 2

A second employee approves the change.

Level 3

A documented procedure requires independent verification, approval, segregation of duties, and retention of evidence.

Level 4

Management measures vendor changes, exceptions, overrides, failed verifications, and unusual activity.

Level 5

Automated workflow, access controls, analytics, independent verification, continuous monitoring, and exception reporting work together to identify suspicious changes before payments occur.

is technically the same control objective:

Prevent unauthorized changes to vendor payment information.

But the organization's capability to achieve that objective is dramatically different.

Control Design and Control Maturity Are Not the Same Thing

This distinction is particularly important for auditors.

A control can be properly designed but immature.

It may depend upon:

• One experienced employee

• A manually maintained spreadsheet

• Institutional knowledge

• An undocumented review

• Management intervention

• An informal exception process

The control may work today.

The question is whether it will continue working when:

• The employee leaves

• Transaction volume doubles

• The organization implements a new system

• Management changes

• A sophisticated fraudster attacks the process

• Operations are decentralized

• The organization acquires another company

Maturity therefore provides another dimension for evaluating control sustainability.

Don't Average Away a Critical Weakness

There is also a danger in maturity scoring.

Suppose an organization scores:

Principle 10 — 4.2

Principle 11 — 1.8

Principle 12 — 4.0

The mathematical average is: 3.3

That number can be misleading.

If critical automated controls depend upon an IT environment operating at Level 1.8, the organization may have a significant control problem regardless of the average.

Maturity assessment should therefore identify critical dependencies and minimum acceptable maturity levels, not simply calculate averages.

Management Owns Control Maturity

Internal Audit should not decide how mature management's controls must become.

Management owns the system of internal control.

Management should therefore determine:

• Significant risks

• Risk appetite and tolerance

• Required controls

• Required maturity

• Resources necessary to achieve that maturity

Internal Audit can independently assess whether:

• Management's maturity assessment is reasonable.

• Controls actually operate at the claimed level.

• Evidence supports the rating.

• Significant maturity gaps have been identified.

• Remediation plans are reasonable.

• Reported improvements actually occurred.

That preserves Internal Audit's independence while providing management and the Audit Committee with considerably better assurance information.

Give the Audit Committee Better Information

Consider two ways of reporting the same problem.

Traditional Reporting

• Finding: Vendor master-file controls need improvement.

• Risk: High.

• Management Response: Corrective action underway.

Now consider:

Maturity Reporting

• Risk: Vendor payment fraud — High

• Current Maturity: Level 2 — Developing

• Required Maturity: Level 4 — Managed and Measured

• Gap: 2 Levels

• Primary Weaknesses: Manual verification, excessive access, inadequate monitoring and insufficient exception reporting.

• Target: Level 3 within six months; Level 4 within twelve months.

That tells the Audit Committee considerably more about the organization's actual control capability.

The Bigger Question

Organizations spend substantial resources creating and testing internal controls.

But the existence of controls should not be confused with a mature system of internal control.

The better questions are:

Are our controls deliberately linked to our risks?

Are technology controls strong enough to support them?

Are policies actually translated into consistently performed procedures?

Can management measure control performance?

Do controls improve as risks and operations change?

Ultimately, maturity assessment moves the discussion from:

“Do we have controls?”

to:

“How reliably can our controls manage risk today—and how confident are we that they will continue doing so tomorrow?”

That is a considerably more useful question for management, Internal Audit, external auditors, risk professionals, and the Audit Committee.