Maslow was right. GRC Must Also Respect Hierarchy.

Charles Ndolo Mutiso · 2026-10-21

Maslow was right. GRC Must Also Respect Hierarchy.

Why effective governance, risk and compliance must begin with operational resilience before meaningful assurance can exist.

I have worked in highly structured, security-conscious environments where governance processes and controls were already established. I have also worked in completely unstructured environments where my first job was simply to bring sanity, establish accountability, and make systems dependable.

Both experiences taught me a principle close to Abraham Maslow’s hierarchy of needs: some conditions must exist before higher-order outcomes become meaningful.

Governance, Risk and Compliance (GRC) should respect the same logic. Yet organisations often treat every requirement, control, policy, and obligation as equally urgent at the same time. They are not.

Before compliance, can the environment survive? Before assurance, is it secure? Before expanding the control catalogue, do we know who owns the systems, who responds when they fail, and whether we can recover when something breaks?

That is where prioritisation begins. Not with the most beautiful policy, not with the longest checklist, and certainly not with impressive audit documentation built on a fragile operational environment.

The GRC Hierarchy: Available → Auditable → Assured

I propose a practical way to think about GRC maturity built on three interconnected foundations. This is not a replacement for established frameworks. It is a way to set priorities and recognise the dependencies between capability, accountability, evidence, and assurance.

An organisation must first be able to operate and withstand disruption. It must then be able to demonstrate what is happening in its control environment. Only then can it establish justified confidence that its controls work.

1. Available: Can the Organisation Survive?

Availability is often reduced to system uptime. Operational availability means far more: the people, infrastructure, processes, data, and recovery capabilities needed to sustain essential operations.

Key questions include:

• Are critical systems identified and assigned accountable owners?

• Are backup and recovery procedures established and regularly tested?

• Does the organisation understand its critical dependencies?

• Are incident response responsibilities clearly assigned?

• Do employees have the knowledge and authority to act under pressure?

An organisation may have sophisticated policies, advanced monitoring tools, and a comprehensive risk register, but this does not guarantee security. But if its database cannot be restored or nobody understands the dependencies behind a critical service, its control environment remains fragile.

Availability without security is equally dangerous. An insecure system stays up only until a preventable incident takes it down. Baseline security, ownership, continuity, and recovery readiness all belong at this first level. The goal is not just to keep systems running, but to operate securely, respond effectively, and recover predictably.

2. Auditable: Can the Organisation Demonstrate Control?

Once operations are stable, the next question is whether activities, controls, and decisions can be independently examined.

Auditability is not producing documents when an auditor arrives. It is the ability to show credible evidence that controls exist, responsibilities are understood, and decisions can be traced.

An organisation may claim that privileged, heavily invested access is reviewed regularly. Can it show who performed the reviews, when, which exceptions were found, and whether they were fixed? It may have a backup policy. Can it prove successful backups, restoration tests, and resolution of failed jobs?

A policy expresses intention. Evidence demonstrates practice.

An auditable environment has clear ownership, documented procedures, reliable logging, traceable change management, and consistent monitoring. The strongest evidence is a natural by-product of a well-run environment. No organisation should have to reconstruct months of control activity the week before an audit.

3. Assured: Can Leadership Trust the Control Environment?

Assurance asks a harder question: is the control actually effective against the risk it was designed to address?

A firewall rule may exist, but does it enforce the intended segmentation? MFA may be configured, but is it enforced on every privileged account? A DR plan may be documented, but has recovery within agreed objectives actually been demonstrated?

Assurance means justified confidence that:

• The control exists and is appropriately designed.

• It operates as intended.

• The supporting evidence is reliable.

• Deficiencies are identified and addressed.

• Residual risk stays within accepted tolerance.

No architecture eliminates every threat, and no audit guarantees against failure. Without these conditions, assurance becomes an administrative declaration rather than a defensible conclusion.

When Compliance Outpaces Operational Readiness

Consider an organisation that has invested heavily in certification. It has approved policies, a risk register, management reviews, and audit reports. On paper, it looks mature.

Then a major infrastructure failure strikes. The backups have never been tested through a full restore. Application dependencies are poorly documented. Several privileged accounts have no clear owner. The incident team is unsure who escalates to whom.

The organization has compliance documentation but cannot restore essential services. It tried to demonstrate auditability and assurance without first establishing resilience. The fix is to restore dependable operations, clarify accountability, and prove recovery capability, then let documentation and testing confirm the improvements.

Controls Do Not Operate Themselves

Technology cannot fix unclear ownership, weak competencies, or fragmented responsibilities. A well-configured control becomes useless if exceptions are never reviewed. A recovery procedure fails if nobody has practised it. An incident stalls if nobody knows who decides.

People must understand their responsibilities, have the skills to perform them, and hold the authority to act. A control is only as dependable as the human accountability behind it.

G, R and C Are Not Always Equal Priorities

Governance, risk, and compliance work together, but they do not always deserve equal attention at every moment. Sometimes governance must lead because accountability is fragmented. Sometimes risk dictates priorities because of a critical exposure. Sometimes legal obligations demand urgent action.

This does not mean regulatory requirements can be postponed at will. It means distinguishing mandatory obligations from the sequence of discretionary improvements, guided by risk, dependencies, business objectives, and resources rather than the length of the control catalogue.

Frameworks such as ISO/IEC 27001, the NIST Cybersecurity Framework, and COBIT remain valuable. The hierarchy simply helps determine what comes first and what must be proven before assurance claims can be trusted. And these levels are not one-time milestones: infrastructure changes, people leave, and threats evolve. Maturity demands continuous reassessment.

AT THE END OF THE DAY

Organisations cannot build reliable assurance on fragile foundations. They cannot prove control effectiveness without trustworthy evidence. And they cannot manage risk sustainably without capable people and systems that withstand disruption.

Available → Auditable → Assured.

The goal is not simply to be a compliant organisation. It is one whose people, processes, infrastructure, and data can be trusted to operate, withstand scrutiny, and recover when challenged.

Maslow understood hierarchy. So should GRC.