The control whose owner changed teams in April

In April, the engineering manager who ran the quarterly access review became head of platform. It was a promotion. The recurring invite moved with him, because invites belong to people rather than to jobs, and he kept accepting it for two more quarters out of habit — for an estate that was no longer the one the control was written about.

Nobody removed the control. Nobody argued it was unnecessary. Nobody did it on the systems it was for. By the time anyone looked, the last review of those systems was dated March.

Three registers, same month

Forty people, one product. The quarterly access review above. Owner field says a name; the name is accurate; the person it names now runs something else. Last instance: March, five months before anyone noticed.

A hundred and twenty people, two regions. The assessment of the companies inside the boundary was owned by someone in finance who left in May. Her replacement inherited the invoices, the renewals and the purchasing card, and none of the register. Last assessment: the previous October.

Twenty-five people, no premises. The annual refresh of what people are expected to do when they get a suspicious email was owned by the People team, which was one person, who went on leave in February. The invite was never declined. It just stopped being accepted.

Three different causes — a promotion, a resignation, a leave of absence — and one identical shape. In each case the owner field was true when it was written and false by the time it mattered, and in each case the evidence of that is a date rather than an argument.

What would you do

You have inherited all three registers. Fourteen controls across them are marked as running; three of them have not produced anything for between five and eleven months, and you only know that because you have just spent an afternoon checking by hand.

You want a mechanism, not an afternoon. Whatever you choose has to survive the next reorganisation, the next resignation and the next parental leave, none of which you will be told about in time.

Optimising for

Finding out within a month that a control has stopped.

You cannot know

• Which people changes are coming in the next twelve months
• Whether a control stopped or ran without leaving a trace
• How much of anyone else's week you can actually claim
• Whether the register will still be in this tool next year

Choose an option

Reassign the three owners now and move the invites to the new people.Connect the register to the directory so owner changes propagate automatically.Publish one list monthly: every control, the date of its last instance, oldest first.Make each control the responsibility of a role rather than a named person.

The part that cannot be fixed forward

Reassigning the owner fixes next quarter. It does nothing at all about the five months, and the five months are inside a period you may want to make claims about.

That is a separate decision, with a separate cost, and it is the one people get wrong under pressure.

What would you do

The access review did not happen in the second or third quarter. It is now October. The period you want to claim runs from the first of January, so two of the four expected instances are missing and the window is still open for the fourth.

You can run the review this week. What you cannot do is make it have happened in June.

Optimising for

Describing a five-month gap to the next reviewer without losing their trust.

You cannot know

• Whether anything bad actually happened during the five months
• How this reviewer has treated similar gaps elsewhere
• Whether your buyer reads the exceptions section at all
• What the review would have found in June

Choose an option

Run it now, date it today, and record that two instances did not happen.Run it now and date the artefact June, since that is when it was due.Change the control's cadence to annual, so one instance is all the year owed.Shorten the period you claim so it starts after the gap.

Check

Your register names roles rather than people, and every role has a current occupant. Which part of the orphan problem have you actually solved?

Choose one answer

All of it. A role cannot change teams.The reassignment case, provided somebody checks the role is filled.None of it, because handovers never include the register.The detection problem, since roles are visible in the org chart.

Check answer

Worth remembering

• An orphaned control is one whose last instance predates a people change nothing connected to it.
• The people record and the control register are both accurate; the missing thing is an edge between them.
• Detect silence rather than cause: one monthly list of controls by last instance, oldest first.
• Naming a role instead of a person survives promotions and departures but not vacancies.
• Reassigning an owner fixes the next instance and does nothing about the gap already there.
• Dating an artefact earlier than the work converts a survivable miss into a false record.