Chapter 10 Part 1: Hierarchical Internal Controls and Control Loop Theory
Book: Enterprise Risk and Opportunity Management: Concepts and Step-by-Step Examples for Pioneering Scientific and Technical Organizations
Author: Allan S. Benjamin
ISBN: 9781119288428
Chapter 10 is the capstone. Benjamin closes the book by showing how internal controls for TRIO organizations can be fully integrated with EROM, not parked in a compliance corner. This first post covers Sections 10.1 and 10.2: the principles, the governance picture, and the methodological basis for hierarchical control loops. The examples and conclusions come in Part 2.
Controls should come from objectives and drivers
Benjamin restates four principles that run through the whole book:
- Internal controls derive from strategic objectives, tactical objectives, core operating standards, and the risk/opportunity drivers that affect whether you meet them.
- Drivers come from factors that move aggregate risks and opportunities, not just individual scenarios.
- Control design focuses on protecting assumptions and fixing weaknesses so aggregate risk stays within tolerance and opportunity stays within appetite.
- Controls should come from staff thinking honestly about what could go wrong and how to monitor and prevent it.
That last point sounds obvious. In practice, many control frameworks start from generic checklists rather than the specific drivers that actually threaten a mission.
Control theory, but for organizations
Benjamin borrows from mechanical control theory. In a heating system, a thermostat reads temperature (measured variable), compares it to a set point, and adjusts airflow (controlled variable) to keep the room comfortable. Hazards like bad weather or equipment failure are disturbances.
Organizations can use the same loop structure. A controller monitors process state, acts through control mechanisms, and keeps operations within limits. The twist for TRIO enterprises: you need hierarchical control loops, not one thermostat for the whole building.
A primary control loop ties to a key organizational objective and stems from risk or opportunity drivers. Each monitoring or control activity inside that loop may itself need a secondary loop if it carries its own risks (“control needs”). Those secondary activities may need tertiary loops. The hierarchy continues until the residual risk is manageable.
This mirrors organizational hierarchy but does not copy it exactly. Control loops can cross organizational boundaries because control needs do not always follow reporting lines. What you do need is a clear mapping between control structures and management structures so everyone knows who owns what.
Governance, risk management, and internal control
OMB Circular A-123 nests the functions: internal control sits inside program/project risk management, which sits inside enterprise risk management, which sits inside governance. Benjamin illustrates this for both strategic planning and performance evaluation.
The important design choice is bidirectional integration. COSO tends to treat internal controls as an input to ERM while ERM is not necessarily an input back to controls. Benjamin argues TRIO enterprises need the reverse link too. Risk and opportunity analysis should inform which controls exist and how they are tested. Controls should not be a static layer sitting above the technical work.
EROM teams at each organizational unit, communicating horizontally and vertically, pair naturally with hierarchical control structures. Risks, opportunities, and controls can then be treated consistently at every level and rolled up the same way.
Section 10.2: What counts as a control loop
Merriam-Webster defines a control loop as a process regulated by feedback. Benjamin notes that some feedback in his planning diagrams informs decisions without regulating them, so they are not control loops by that strict definition. The operational loops in Section 10.2.1 are the real thing.
Leveson’s model (2011) is the template: controller, process, measured variables, controlled variables, monitoring mechanisms, disturbances. Each near-term, mid-term, and long-term objective that matters to the mission can get its own loop.
The hierarchical stack looks like this:
- Primary loop: anchored on an organizational objective, driven by risk/opportunity drivers, formatted like the standard single loop.
- Secondary loops: spawned when a monitoring or control activity in the primary loop has its own risks that need active management.
- Tertiary loops: same logic applied to secondary loop activities, and so on.
The thermostat example makes the abstraction concrete. For organizational controls, the “temperature” might be policy currency, reviewer competency, or communication quality between assurance teams.
RACI matrices: who does what
Every activity that spawns a lower-level loop needs an owner, oversight, and communication to interested parties. Benjamin favors RACI matrices (Responsible, Accountable, Consulted, Informed).
Table 10.1 in the book is a blank form. For each control loop and monitoring/control activity, you fill in the org and person for each RACI role. The point is to eliminate gaps. If no one is accountable for monitoring reviewer turnover, your tertiary loop for oversight quality is fiction.
Note the IIA-style distinction lurking here: Responsible means ensuring completion; Accountable means actually doing the work. Mixing those up is how controls end up on paper but not in practice.
Why hierarchy beats flat checklists
Flat control inventories struggle with TRIO complexity. A hierarchical loop structure forces you to ask, for every control activity, “what could fail about this activity itself?” Policy development needs a loop. Review team oversight needs a loop inside that. Budget support for matrixed reviewers needs a loop inside that.
That recursive questioning is tedious. It is also how you catch the failure modes that sink programs after the primary process looked fine on PowerPoint.
Coming in Part 2
Section 10.3 walks through two worked examples: a Safety and Mission Assurance organization’s role in enterprise risk management, and NASA’s Commercial Crew Program risk-based assurance model. Sections 10.4 and 10.5 fold GAO Green Book and MIT safety principles into the loop framework and summarize how this approach differs from COSO.
If Part 1 is the theory, Part 2 is where Benjamin shows you the wiring diagram.
Previous: Chapter 9 Strategic Integration · Next: Chapter 10 Hierarchical Controls Part 2