Delivery discipline
A good design, built right.
Who owns the requirement, who signs off on scope, and who tests it separately from the person who built it.
The book spends most of its pages on what the operating model should be. This page is about the part in between: the project, the integrator, the cutover weekend, and the weeks after, when a well-designed model either becomes the way identity works or quietly turns into a configuration nobody agreed to.
Skipping that discipline is one of the most common ways a good framework fails before real use ever tests it, not because the design was wrong, but because no one owned getting it built right. The Modern Identity Operating Model, Chapter 12
In brief
- Delivery fails the way identity fails: quietly, with nobody being careless.
- Before work starts, three questions need a name next to each: who owns the requirement, who signs off on scope, and who tests separately from the person who built it.
- Nine habits carry a design from requirement to evidence, each with what done looks like.
Start with the three questionsAbout 16 minutes to read in full
This page extends Chapter 12, Building the Identity Governance Framework of The Modern Identity Operating Model.
Why delivery gets its own page
Delivery fails the way identity fails
The book tells the story of a company that replaced its HR system and stood up a new identity governance platform at the same time. Nobody was careless. The source of truth was still being rebuilt under the platform that depended on it, testing was thin, and the people who would run the new system had not been prepared to run it. The strain showed up months after go-live.
It is the same mistake the book’s four jobs of identity (Source, Registry, Governance, Enforcement) warn about: collapsing two jobs into one. Delivery has its own versions of that collapse. The person who built the workflow is also the person who says it works. The integrator who configured the platform also decides what the requirement meant. The project that stood it up is also, by default, the only thing keeping it running.
Delivery discipline is keeping the deciding, the building, and the checking in different hands.
None of that needs a program office. It needs three questions answered before work starts, a clear meaning of done, and enough structure after go-live that the model survives the project team leaving.
Before anything is built
Three questions with a name next to each
If these do not have answers, the work is not ready to start, no matter how ready the platform is.
Who owns the requirement?
A person on the business side of the line, not the builder. The business owns what access should mean. Technology owns how the system delivers it. The requirement belongs to the first group.
Who signs off on scope?
Someone with the authority to say no to additions and the standing to defend what was left out. Usually the sponsor, or the owner the sponsor names for this wave.
Who tests, separately from who built it?
Builders test their own work, and should. Acceptance is a different act, done by someone who did not build it, against the requirement rather than against the configuration.
In a small program one person may hold two of these. Write down which two, and make sure the third is someone else. The Decision-Rights Matrix is the natural place to record it.
The discipline, in order
Nine habits, from requirement to evidence
In roughly the order a delivery runs. Each ends with what done looks like, because a habit without a test is only a good intention.
Group one · Before the build
Most delivery failures are decided here, long before anyone notices them.
1Requirements have an owner who is not the builder
The analyst writes the requirement down. The business owner of the outcome agrees it is right. The engineer builds to it. Those are three roles even when two share a chair. The book describes an engineer who found a workflow step and a set of attributes that did not line up, and raised it instead of guessing. The architect, engineer, and analyst went back to the client together. It cost an afternoon.
Why first: When nobody owns the requirement, engineering makes strategy by default, one configuration choice at a time. The result can be technically flawless and still not be what anyone agreed to.
Done looks like: Every requirement has a named owner who can answer a question about it within a day, and the builder knows who that is.
2Requirements are written in the operating model's language
"Automate onboarding" cannot be tested. A requirement that names the identity type, the authoritative source, the attribute that signals the event, what that event triggers, and who owns the result can be. Use the model's vocabulary: worker type, business role and access role, entitlement, owner, sponsor. Trace each requirement to the standard it implements, so a tester can tell a defect from a disagreement.
Why here: Who sponsors a contractor, what event retires a service account, what happens when an agent's sponsor leaves: if the requirement does not answer those, the build will answer them by accident.
Done looks like: Every requirement names an identity type, a source, and an owner, and you can point from it to the standard it serves.
3Scope is signed and bounded like a wave
The book defines a wave as a bounded unit of operating change, with explicit scope, clear dependencies, success conditions, closeout criteria, and clear ownership. A statement of work or project charter should carry all five. Write the out-of-scope list as carefully as the in-scope one. For systems that will not be integrated in this wave, or ever, record the decision against the catalog entry along with what holds the line in the meantime: tighter monitoring, manual review, narrowed access, or an owned risk acceptance.
Why here: Scope that grows mid-build turns a focused wave into everything at once. Scope that quietly shrinks turns a legacy system into an exception only an audit finds.
Done looks like: A signed scope that names what is in, what is out, what must be true first, and what closeout means, with every out-of-scope system carrying a recorded decision rather than a silence.
Group two · During the build
Where the design meets real data, and where independence matters most.
4Acceptance criteria are tied to the model, not to the screens
"The workflow runs" is a test of the tool. "A contractor whose end date passes loses access within the agreed window, in every system in scope, and the sponsor was told beforehand" is a test of the model. Write acceptance criteria as outcomes the operating model promises, agree them with the requirement owner before the build starts, and resist rewriting them after the build to match what got built. Worked examples are further down this page.
Done looks like: Acceptance criteria were signed before testing began, and none were changed without the requirement owner's agreement.
5Someone who did not build it tests it
Builders unit test. An independent tester, or the requirement owner in user acceptance, tests against the requirement. Test the states the diagram leaves out, because that is where access outlives its purpose: the no-show, the extended leave, the rehire, the contractor who converts to an employee, the end date that moves three times. Test what should not happen as carefully as what should. A mover should lose old access, not only gain new. A request for a toxic combination should be blocked, not approved.
Test with data in the shape production will send it: events out of order, a full sync that overwrites a newer change, two records that should correlate and do not.
Why it matters: Separation of duties applies to delivery too. One person building, testing, and promoting a change is a concentration of capability, whatever their intentions.
Done looks like: Every test result records who ran it, and that name is not the builder's. Test accounts and test data are removed before go-live, and someone checked.
Group three · Go-live and after
The project ends. The model has to keep going without it.
6Cutover is a sequence with a decider and a way back
Write the cutover as an ordered run sheet: what is frozen, what is migrated, in what order, what happens to lifecycle events that arrive mid-cutover, and how to reverse each step. Name one person who makes the go or no-go call against criteria agreed in advance. Before switching on automated provisioning or removal, run a reconciliation between the new system and the authoritative sources, and look at what it would change before it changes anything. The first automated leaver run is not the moment to learn that correlation matched the wrong records.
Done looks like: A signed go decision, a cutover log showing each step and who performed it, a back-out plan that someone actually read, and a first reconciliation whose mismatches each have an owner.
7Hypercare ends on criteria, not on a date
Hypercare is the period after go-live when the builders stay close enough to fix things fast. Its exit should be the book's test for closing a wave: the new behavior is owned, operating, measured, and no longer dependent on project attention to survive. In practice that means the operations team has run the runbooks themselves, reconciliation is coming back clean or being worked, queue volume has settled, and the people approving and reviewing access were trained before they needed it, not after.
Done looks like: A written exit with each criterion met and signed by the operations owner who now carries it.
8Change control protects the model after the project is gone
After go-live, every change to a connector, a workflow, an access role, or a policy rule is a change to how identity behaves: it needs a reason, an impact assessment, approval, testing, and a back-out. Keep two kinds of change apart. A change to the model itself, such as a new standard, a new identity type, or a change to what an access role means, belongs in the governance forum. A change to how the model is implemented belongs in your normal change process. Either way, whoever operates the service has to be told, because a change the operator never heard about is a seam failure waiting to look like an outage.
What auditors expect: This is not identity-specific invention. NIST SP 800-53 calls for configuration change control with testing, validation, and documentation of changes (CM-3 and CM-3(2)) and impact analysis before a change (CM-4). ISO/IEC 27001:2022 covers it in Annex A 8.32 (change management), 8.29 (security testing in development and acceptance), and 8.31 (separation of development, test, and production environments). PCI DSS v4.0.1 Requirement 6.5 asks for documented change procedures, separation of roles between production and pre-production, and removal of test data and test accounts before go-live. In a SOX environment, change management is one of the IT general controls your auditors will test.
Done looks like: No change reaches production in an identity system without a ticket that shows reason, approval, test, and back-out, including changes made by an outside provider.
9Evidence of delivery is produced as you go
The book describes moving from reconstructing evidence under pressure to producing it as part of normal operation. Delivery is the easiest place to start. Keep these in one place, as they happen: the approved requirements, the signed scope, the acceptance criteria, the test plan and results with tester names, the defect log and how each defect was resolved, the go or no-go decision, the cutover log, the first reconciliation, and the hypercare exit.
Done looks like: An auditor asking "how do you know this went in the way it was approved" gets a folder, not a project.
Worked examples, illustrative
What done means
Illustrative acceptance criteria, to adapt rather than copy. The point is the shape: each one is something a person who did not build the flow could check, and each traces back to a promise the operating model makes.
A leaver flow for contractors
Lifecycle pillar. Source job and enforcement job.
- The trigger is the record, not a person remembering. The end date on the authoritative record for contractors fires the flow. Tested with an end date in the past, today, moved earlier, and extended more than once.
- The sponsor hears first. The named sponsor is notified ahead of the end date, with a way to extend that requires a new end date rather than a blank one.
- Access ends everywhere in scope within the agreed window. Sign-in is disabled first. Every connected application follows. Every application that cannot be integrated produces a task with an owner and a due date, and someone checks it was done.
- Conversion does not carry access across. A contractor who becomes an employee is correlated as the same person but starts from the employee access model. Tested in both directions.
- Reconciliation agrees. After the first cycle in production, no active account belongs to a contractor whose record has ended, or every one that does has a named owner working it.
An access model for one application
Access pillar. Governance job.
- Every access role has an owner, a purpose, and a review cadence. If a role cannot be described in a sentence an approver would understand, it is not finished.
- The application owner signed the mapping. The mapping from business role to access role was reviewed and signed by the person accountable for what access in that application means, not by the team that configured it.
- Conflicts cannot be requested. The capabilities that must never sit together are named, no access role bundles them, and a test request for a toxic combination is blocked.
- Movers lose as well as gain. A change of business role removes the old access role, not only adds the new one.
- The first review is possible. A real review ran on the new model, and reviewers finished it without calling the identity team to ask what they were looking at.
Intake for service accounts and agents
Governance pillar, enforced at creation.
- Worker type drives the required fields. Selecting service account requires an owner, a purpose, a credential-handling plan, and a review cadence. Selecting agent requires a sponsor, a delegated boundary, a review cadence, and a shutdown path.
- Missing fields stop creation. Tested by trying to create each type with the owner left blank. It should fail.
- The shutdown path works. Tested by actually using it on a test agent, not by reading the procedure.
- An owner leaving is an event. When the owner or sponsor leaves, the identity is flagged for reassignment rather than continuing on its own.
Integrators and providers
Distribute the work, keep the understanding
Most identity programs deliver with outside help. A system integrator builds the platform. A managed service provider runs it afterward. Sometimes the same firm does both. None of that is a problem in itself. The book draws the line clearly: execution may be distributed, specialized implementation may be external, but ownership and the core knowledge of how the model works stay inside. You can outsource activity. You cannot outsource accountability.
What stays with you
The requirements, the scope decision, the acceptance criteria, the go or no-go call, and the change approval. Someone internal has to be able to challenge the integrator's assumptions, which means someone internal has to understand them.
What the integrator delivers
The build, their own testing, and the knowledge to run it. Make that last one an acceptance criterion, not a courtesy: your people ran the runbooks during hypercare, and can explain the design without the integrator in the room.
What the provider runs
Day-to-day operation, under your change control. A handover from integrator to provider is a cutover of its own.
Put these in the statement of work or the service agreement, because when someone else runs the systems, lifecycle is something you contract for, and a contract that never mentions it is silent for the ordinary reason that nobody thought to ask:
- Named accounts for every provider engineer. No shared administrative login. A shared account cannot be offboarded, only rotated, and it erases who did what.
- Notice when their people change. How quickly they tell you when someone on their team leaves, and how quickly that person's access to your environment is removed.
- Independent acceptance. The integrator tests its own work, and your side, or a third party, accepts it against your criteria.
- Changes go through your process. Emergency changes are reviewed after the fact, not skipped.
- Evidence you can see. What evidence you receive, how often, and in what form, so you are not taking the control on trust.
- A way out. Your configuration, documentation, and identity data leave with you.
Chapter 20 has five questions any organization relying on a provider can ask in one conversation. They work just as well in the meeting before you sign.
- Who has access to our environment, and can you show me right now?
- How often is access reviewed, and who signs off on it?
- What happens within twenty-four hours of someone at our organization being terminated?
- Do you use shared or admin accounts to manage our environment, and if so, how is individual action tracked?
- What do we get if we leave, and can we walk away with our own identity data intact?
Where it connects
Delivery runs through all five pillars
Delivery is not a sixth pillar. It is how each of the five gets from design to operation intact.
- Governance. Decision rights decide who owns requirements, who signs scope, and who approves change. Deferred scope lands in the risk register as a tracked remediation plan or an owned acceptance, not in a parking lot.
- Lifecycle. The hardest test cases are lifecycle cases: the states between hired and gone, the data arriving in the wrong order, the transition no attribute announces.
- Access. Acceptance means the business owner of the access signed what it means, and separation of duties held in the build as well as in the model.
- Technology. Integrations fail visibly, automation has a back-out, and nothing switches on before reconciliation says the data can be trusted.
- People & Change. Training, communication, and sponsor visibility are delivery work, scheduled before go-live. Adoption is measured after, because live is not the same as used.
Take these with you
Templates that carry delivery
None of these is a project plan. Each gives a delivery something to build and test against.
Decision-Rights Matrix
Who owns requirements, who signs scope, who approves change.
Identity System Catalog
Where out-of-scope and cannot-integrate decisions get recorded against each system.
Lifecycle Map
The flows and states your lifecycle test cases come from.
Access Model Template
What the application owner signs before the access model is accepted.
Governance Exception Record
For scope you deferred and gaps you accepted, so they stay visible.
Role-Based Training Matrix
Training for approvers, owners, and operators, scheduled as part of the delivery.
Adoption Metrics Tracker
Evidence for the hypercare exit that people are working the model, not only that the system is up.
The full pack, the glossary, and the figures are all on the toolkit.
From the book
The longer treatment
The surrounding argument is in The Modern Identity Operating Model:
- "Building the Framework in Practice," Chapter 12. The passage that points here.
- "The First Mistake Most Teams Make" and "Implement the Model in Waves," Chapter 11. The HR and governance platform story, and the definition of a wave that scope and hypercare exit are built on.
- "Not Every System Will Modernize" and "Seams Between Teams," Chapter 16. On deciding on purpose what will not integrate, and why so many outages are really handoff failures.
- "Outsourcing Versus In-House" and "Building Team Trust," Chapter 20. On what stays internal, the five questions for a provider, and the engineer who raised the question instead of guessing.
- "The Account You Cannot Offboard," Case Study 8 in Chapter 23. A provider, a shared administrative account, and a contract that never mentioned lifecycle.
Go deeper in the book
Chapter 12, Building the Identity Governance Framework, covers how the governance framework is built before it is delivered.
Coming soon: get notified