Risk Appetite and Change Appetite Govern the Implementation Path

The first six posts covered the foundations. Now the path must be built.

Before sequencing a single component, most programs skip a governing question: What does the right implementation path look like for this organization?

Many default to a framework, a vendor roadmap, or what worked somewhere else. None of those account for the organization you actually have.

Many factors shape the path. Two are rarely named: risk appetite and change appetite. They are not the same thing, and treating them as if they are leads to implementation designs that do not survive contact with the organization.

Risk appetite is how much unresolved identity risk the organization will carry while the program matures. It determines enforcement pace, how long you operate in identify but do not block mode, and how quickly assessment turns to action. Assumed risk appetite is not a strategy. It is drift. Someone has to name it.

Change appetite is how much disruption the organization can absorb and at what pace. It accounts for competing initiatives, stakeholder friction, and available organizational energy. Low change appetite demands a different sequence. Not slower, but more deliberate.

Together they govern sequence, depth, enforcement pace, and scope. Starting with a limited set of functions across a limited selection of applications, then expanding as appetite allows, is not a compromise. It is a design decision.

Think of this as a decision matrix. Appetite inputs, stakeholder positions, competing priorities, and leadership signals feed a structured case for what to tackle in what order. Trusted relationships make that analysis accurate. Without them, you get the answer people think you want, not the one that reflects reality. Sometimes leadership names the problem directly. That signal shapes the path too.

Once the case is built, it has to be sold. Stakeholder analysis, sequencing rationale, and why this path fits the organization are all part of that work. Executives will have other thoughts. Sometimes the sequencing shifts. That is part of the process.

Start by getting clear on:

• Has risk appetite been named, or is it being assumed?

• What is competing for change capacity right now?

• Which components demand faster action because of risk?

• Where are temporary controls needed while permanent ones are built?

• Who has authority to make these decisions, and are they engaged?

Where you begin is a decision, not a default.

❓What is the harder part: building the case for the sequencing, or navigating the organizational dynamics that shape it?