it is already owned

These guides keep saying that an identity needs an owner.

The contractors guide said every external account needs an internal owner, the person who hired the contractor, and that an account nobody will claim gets disabled. The acquisition guide asked, for every inherited artifact, whether the ownership is clear. The service accounts guide said no identity should be owned by somebody who has left.

That is half an argument: the owner is the requester, and an unclaimed account goes into a queue. What none of them did was argue why that person, or say who owns the function itself when nobody has it as a job.

Here is that argument, and it starts somewhere you may not like.

you do not have a gap

The standard framing is that a company your size has an ownership vacuum. No security team, no head of identity, nobody accountable, so nothing gets owned and everything drifts.

That framing costs you, because it points at the wrong fix.

Identity at your company is already owned. It is owned by whoever last touched the admin console. That person makes the decisions, holds the credentials, knows which integrations exist, remembers why the odd exception was made, and is the reason anything works. They did not apply for the role and nobody appointed them to it. They have it anyway.

So the intervention is to write down the ownership you already have. That sounds like a shrug. It is the only option left once you accept that you cannot staff your way out of a structural condition.

the staffing answer does not exist at your size

Dedicated security leaders are scarce and expensive, and almost all of them work for large companies. A fractional arrangement costs real money every year, and it still leaves the daily console work with somebody inside. Set either against the security budget of a company with sixty people and no security team, and the number does not fit. Pretending otherwise is how this advice usually goes wrong.

So nobody is coming. The function is going to be operated by somebody who has another job, and the question is only whether that fact is recorded.

the argument to reject

You will have heard a line in one wording or another: security cannot be the security leader’s responsibility alone.

Taken as a statement about culture, that is fine. Taken as an operating model, it is the most expensive sentence in this field, because “everybody is responsible” resolves in practice to “the request goes to whoever answers first, and nobody carries the consequence.”

At five thousand people, distributed responsibility has committees underneath it. At sixty people it has nothing underneath it. That is the absence of a model, described approvingly.

two roles, and only two

Here is the shape that fits a company with no identity team. It costs nothing and it is deliberately smaller than any framework you have been shown.

The accountable executive. One named person, and at your size that is a founder or the chief technology officer. They operate nothing. They are on the hook for exactly three things: approving the access policy, protecting the recurring hour it takes to maintain any of this, and being the escalation when somebody refuses to give up access they no longer need.

There is a regulatory version of this split, worth knowing even though it probably does not bind you. NIS2 requires management bodies to approve the risk-management measures and oversee their implementation, says they can be held liable for the entity’s infringements, and obliges them to take training (Article 20). The much-quoted temporary ban on serving as a director is real but narrow: it sits in a different article, applies to essential entities only, and is available only after an authority has set a deadline that the entity missed (Article 32). Nothing equivalent exists for important entities.

Your company is quite possibly outside all of it. Where the law has thought hardest about this, it puts approval at the top and operation somewhere else, which is the split proposed here.

The system operator. One named human per system: your collaboration suite, your code host, your cloud project, your finance system, your CRM, your password manager, your HR tool. Written as a name, never as a team and never as a title.

You can probably write that list without asking anybody, and if you can, that is worth noticing. Being able to name who touches a console proves nothing on its own, because that is a log entry and ownership is a decision. It is still a strong hint that the vacancy you think you have is occupied.

two roles and one rule

1. 1accountable executiveOne founder or CTO. Approves the policy, protects the hour, takes the escalations. Operates nothing.
2. 2system operatorOne named human per system. A name, never a team or a title.
3. 3one owner per artifactThe person who wanted it. If they leave, it falls to the operator until reassigned.

and one rule for everything else

Every external account, service account, grant, token, key, shared credential and domain gets exactly one named internal owner.

The owner is the person who wanted it. The person who created it is only a log entry. This generalises the contractors rule, and it closes a gap the service accounts audit leaves open: the audit collects who created an identity, and the rule then asks who owns it. Those are often different people. Creator is a log entry. Owner is a decision.

There is no unowned state. If the requester has gone, ownership defaults to the system operator until it is reassigned. Orphaned stops being a category and becomes a queue.

The owner is on the hook for four things, deliberately no more. Answer “is this still needed” within five working days. Name a new end date whenever they extend, because there is no indefinite state. Be named in the record. And the fourth, which is what makes people accept the first three: they do not carry blame for a breach. Ownership means answering the question, and consequences sit with the accountable executive.

That fourth item is a promise your company makes. Write it into the policy in those words, or the first three will be resisted and they will be right to resist.

That clause is what separates this from the frameworks you have been sold. RACI splits accountable from responsible and then needs a governance apparatus to keep the split meaningful. You do not have one and will not build one. Two roles and a promise not to blame the operator is what fits.

where this argument is weak

Three places, and it is better to name them first.

It concentrates what it claims to fix. Writing down that one person operates identity turns a diffuse accident into a documented dependency on a single human. That is the failure these guides keep finding at the level of accounts, promoted to the level of the function. The defence is a named deputy who has proven, once, on a written date, that they can get in without the operator. A written procedure does not count; one successful attempt does. Readers who skip that step are worse off than before.

There is no evidence yet that written ownership reduces incidents. There is framework language and there is vendor survey data. Neither is an outcome study. The tool-count guide runs into the same wall: the mechanism is sound, and nobody has measured whether it works. If you know of the study, send it.

Being named has a real cost. Everyone has seen the ordinary version: the named person becomes the one asked why, in front of the board, forever, including about decisions they inherited. Resisting a name in a column is a rational response. The answer is the fourth item above, in writing, before anyone is asked to accept a name.

the sheet

One spreadsheet. Six columns: artifact, system, owner as a named human, accountable executive, last reviewed, end date. One tab per system.

The first row of the first tab is one sentence, and it is the whole guide:

Identity, as a function, is operated by [name] and accountable to [name].

Three things keep it from becoming a document nobody opens.

Offboarding reads it. The first step of your leaver checklist becomes “pull this person’s owned artifacts”. A record that nothing consumes is a policy, and policies rot.

Diligence answers come out of it. When a buyer or an acquirer asks who owns what, you answer from the sheet. That is the selfish reason to keep it current and the reason a founder will protect the hour.

And one hour a quarter. Sort by last reviewed, oldest first. Email each owner the one question. No reply in five days means the thing gets disabled, and if that turns out to be wrong you turn it back on.

the thing your size makes easy

At sixty people you can write down who decided what, and when, by hand, in an afternoon. At five thousand you cannot, and companies that reach five thousand without having done it never go back and reconstruct it, because by then it cannot be reconstructed.

This is the one part of the job your size makes easier, and it expires quietly while you are busy.

You already have an owner. Put their name on it before they leave.