The History of Maturity Models
Why Auditors Should Understand Where Maturity Models Came From
Auditors traditionally ask questions such as:
Does the control exist?
Is the control properly designed?
Is the control operating effectively?
Those questions remain fundamental to auditing.
But organizations increasingly need to answer another question:
How mature is the process or control system?
That question gave rise to what we now call maturity models.
Maturity models provide a structured method for evaluating how an organization progresses from informal, inconsistent practices toward processes that are defined, managed, measured, and continuously improved.
Today, maturity models are used throughout:
Internal audit
Internal control
Risk management
Cybersecurity
Information technology
Compliance
Quality management
Project management
Data governance
Artificial intelligence governance
Enterprise governance
Its history reaches back decades and helps explain why maturity assessments can provide auditors and management with information that a simple effective/ineffective conclusion cannot.
The Basic Idea Behind a Maturity Model
Consider two organizations performing the same control.
At the first organization, an experienced employee performs the control because she has done it for 15 years. There is little documentation, limited supervision, and no formal measurement.
At the second organization, the control has:
A documented control objective
An identified control owner
Written procedures
Defined evidence requirements
Formal supervisory review
Performance metrics
Exception reporting
Technology support
Periodic reassessment
Both organizations may be able to demonstrate that the control was performed yesterday.
But are their control systems equally mature?
Clearly not.
A maturity model attempts to measure that difference.
The point of having a mature system of internal controls is to create a system that will help assure an organization being a going concern.
The Quality Management Roots
One of the important early influences on modern maturity thinking came from the quality-management movement.
Philip B. Crosby introduced his Quality Management Maturity Grid in his influential 1979 book Quality Is Free.
Crosby's model described organizational quality management through five stages:
Uncertainty
Awakening
Enlightenment
Wisdom
Certainty
The terminology is different from today's maturity models, but the underlying concept should look very familiar.
Organizations do not suddenly become excellent.
They progress.
Management practices become increasingly systematic, institutionalized, measurable, and reliable.
That was an important idea.
Instead of simply asking:
“Do we have a quality program?”
management could ask:
“How mature is our approach to managing quality?”
That shift in thinking would become extremely influential.
The 1980s: Software Development Creates a Major Breakthrough
The maturity concept became much more formalized during the 1980s.
The U.S. Department of Defense faced a significant problem.
It relied upon contractors to develop increasingly complex software systems, but software projects were frequently plagued by:
Cost overruns
Schedule delays
Defects
Inconsistent development practices
Unpredictable performance
The government needed a better way to evaluate the capability of software contractors.
That challenge helped lead to groundbreaking work at Carnegie Mellon University's Software Engineering Institute (SEI).
In 1986, an SEI team led by Watts S. Humphrey, working with the Air Force and MITRE Corporation, developed a questionnaire for analyzing software processes based upon maturity. SEI's historical account identifies this work as an early step toward what became the Capability Maturity Model.
Watts Humphrey and Process Maturity
Watts Humphrey became one of the most important figures in the development of modern process maturity thinking.
Humphrey had spent decades at IBM before joining the Software Engineering Institute. At SEI, he established the Software Process Program and led development of the Software Capability Maturity Model.
His work addressed a fundamental management problem:
You cannot consistently produce predictable results from unpredictable processes.
The solution was not merely better inspection of the final product.
Organizations needed increasingly disciplined processes.
SEI's work therefore focused on evaluating the capability of the process producing the result.
That distinction should be particularly interesting to auditors.
It is remarkably similar to the distinction between simply finding errors and evaluating the system of internal control responsible for preventing or detecting those errors.
1987: Formal Assessment Takes Shape
By 1987, SEI was publishing formal guidance for assessing software engineering capability.
A July 1987 report by Watts Humphrey and David Kitson described an assessment methodology intended to characterize an organization's software engineering practices so that meaningful and sustainable process improvement could occur.
Another SEI effort developed a method for assessing the ability of potential Department of Defense contractors to develop software using modern software-engineering methods.
This was an important evolution.
Maturity was becoming more than a management concept.
It was becoming an assessment methodology.
The Five-Level Capability Maturity Model
The Capability Maturity Model for Software eventually formalized the concept around five maturity levels.
The classic structure became:
Level 1 — Initial
Processes are unpredictable, poorly controlled, and reactive.
Success frequently depends upon particular individuals.
Level 2 — Repeatable
Basic processes have been established sufficiently for earlier successes to be repeated.
Level 3 — Defined
Processes are documented, standardized, and integrated into organizational practices.
Level 4 — Managed
Processes are measured and controlled using quantitative information.
Level 5 — Optimizing
Continuous process improvement becomes institutionalized.
The terminology has evolved across different maturity models, but this basic progression became extraordinarily influential.
Think about what those five levels actually represent:
Ad Hoc → Repeatable → Defined → Measured → Continuously Improved
That concept extends far beyond software development.
CMM Becomes CMMI
Over time, different capability maturity models were developed for different disciplines.
That created another problem: organizations could find themselves working with multiple maturity models.
The Capability Maturity Model Integration—or CMMI—approach was developed to integrate maturity concepts into a broader process-improvement framework.
SEI credits Humphrey's earlier Software Capability Maturity Model and related assessment methods as foundations for the later development of CMMI.
The influence spread well beyond software engineering.
Organizations discovered that the maturity concept could be applied to almost any process where capability develops progressively.
COBIT Brings Maturity Thinking Into IT Governance
Auditors and information technology professionals encountered maturity concepts through another important framework: COBIT.
ISACA introduced COBIT in 1996 as a framework connecting information technology and control practices.
Over subsequent generations, process maturity and capability assessment became important elements of COBIT.
COBIT 5 used a process capability approach associated with ISO/IEC process-assessment standards, while COBIT 2019's performance-management approach incorporates a CMMI-based capability scheme ranging from Level 0 through Level 5.
This was particularly significant for the audit profession.
Auditors were increasingly able to say something more useful than:
“The IT control exists.”
They could evaluate how well the underlying IT process was implemented and managed.
Maturity Models Spread Everywhere
Once the concept proved useful, maturity models proliferated.
Today we encounter maturity assessments covering areas such as:
Cybersecurity maturity
Risk-management maturity
Internal-audit maturity
Compliance maturity
Data-governance maturity
Fraud-risk-management maturity
Enterprise-risk-management maturity
Project-management maturity
Privacy maturity
AI-governance maturity
Internal-control maturity
Different models use different terminology and scoring methodologies.
But most are trying to answer essentially the same question:
How far has the organization progressed from informal practices toward an institutionalized, measurable, sustainable, and continuously improving capability?
Where Does COSO Fit Into This History?
This requires an important clarification.
COSO's Internal Control—Integrated Framework is not itself a five-level maturity model.
COSO issued its original Internal Control—Integrated Framework in 1992 and refreshed it in 2013. The Framework provides principles-based guidance for designing, implementing, and evaluating systems of internal control.
COSO organizes internal control around five components:
Control Environment
Risk Assessment
Control Activities
Information and Communication
Monitoring Activities
The 2013 Framework supports those components with 17 principles.
COSO provides criteria for evaluating whether a system of internal control is effective.
But that does not prevent an organization from applying a maturity methodology to the COSO framework.
In fact, doing so can provide management, Internal Audit, and the Audit Committee with an entirely different perspective.
Effective Does Not Necessarily Mean Mature
This is one of the most important concepts for auditors to understand.
Suppose a monthly reconciliation is:
Properly designed
Performed every month
Reviewed by a supervisor
Supported by evidence
The auditor may reasonably conclude that the control is operating effectively.
But suppose the control also:
Depends upon one employee
Uses a complicated spreadsheet
Has poorly documented procedures
Produces no performance metrics
Has no automated exception reporting
Has never been reassessed
Would probably fail if the employee left
The control might be effective today but relatively immature.
That is not a contradiction.
The two assessments answer different questions.
Control effectiveness asks:
Does the control provide reasonable assurance that the relevant objective will be achieved?
Control maturity asks:
How developed, institutionalized, measurable, sustainable, and adaptable is the control?
Management needs both perspectives.
Applying the Five-Level Concept to Internal Control
For practical internal-control assessments, the historical maturity concept can be translated into terminology such as:
Level 1 — Initial / Ad Hoc
Controls depend heavily upon individuals and informal practices.
Level 2 — Developing / Repeatable
Basic controls exist and are generally performed consistently.
Level 3 — Defined
Controls are formally documented, assigned, standardized, and linked to risks.
Level 4 — Managed and Measured
Management measures control performance, exceptions, failures, and corrective actions.
Level 5 — Optimized
Controls are continuously reassessed and improved as risks, technology, processes, and organizational objectives change.
Notice the lineage.
The terminology may differ from Crosby, CMM, CMMI, COBIT, and other models.
But the underlying progression remains recognizable:
Reactive → Repeatable → Defined → Measured → Optimized
Why Maturity Models Are So Useful to Internal Auditors
Traditional audit ratings frequently tell management what is wrong.
A maturity assessment can tell management something different:
Where are we now, where should we be, and what capabilities must we develop to get there?
Consider an Internal Audit report stating: Risk Assessment — Needs Improvement
Now compare that with:
Current Maturity: Level 2 — Developing
Target Maturity: Level 4 — Managed and Measured
Major Gaps:
Inconsistent enterprise risk identification
Limited documentation of risk ownership
No formal risk-appetite linkage
Limited consideration of fraud risk
Inconsistent assessment of significant change
No enterprise risk-performance metrics
The second approach gives management a roadmap and helps to avoid conflict.
Not Everything Needs to Be Level 5
One of the biggest mistakes organizations can make with maturity models is assuming that every process should achieve the highest maturity level.
That can waste enormous resources.
The appropriate maturity level should depend upon:
Risk
Complexity
Regulatory requirements
Materiality
Cost
Organizational objectives
Technology dependence
Consequences of control failure
A low-risk administrative process may function perfectly well at Level 2 or Level 3.
A critical cybersecurity, financial-reporting, regulatory-compliance, or fraud-prevention process may warrant Level 4 or Level 5.
The objective is not maturity for maturity's sake.
The objective is:
Maturity commensurate with risk.
The Next Evolution for Internal Audit
The history of maturity models teaches an important lesson.
Organizations improve when they stop treating performance as simply good or bad and begin understanding the capabilities that produce sustainable performance.
Quality management learned that lesson.
Software engineering learned it.
Information technology governance learned it.
Cybersecurity learned it.
Risk management learned it.
Internal Audit should continue applying the same thinking to internal control.
An auditor should still ask:
Is the control properly designed?
and:
Is the control operating effectively?
But we should increasingly add a third question:
How mature is the control system responsible for managing this risk?
That question takes us beyond yesterday's control test.
It tells management whether the organization has developed the capability to manage the risk consistently tomorrow.
And that is ultimately what a mature system of internal control should accomplish.
Comments