River
Y CombinatorBacked by Y Combinator

Business & Revenue OpsFree

Undocumented Process Risk Audit Report

Every undocumented process ranked by who is the only person who can do it and how long you could survive without them.

Start here

The advice everywhere is to document your high-frequency, high-impact processes first, and that ranking is backwards on its most important axis. A task performed daily by three people is learned by osmosis and survives any one of them leaving. A task performed once a quarter by exactly one person is learned by nobody, and it is the one that produces a missed filing eleven weeks after the resignation, long after anybody thinks to connect the two events.

So the ranking here runs on two things that are observable rather than debated. How many people have ever done this, which access grants, ticket history and recurring calendar invites tell you without asking anyone. And how long the business tolerates it simply not happening, which NIST's contingency planning guide calls maximum tolerable downtime and defines as the outage an owner is willing to accept. Concentration multiplied by intolerance is the risk. Frequency is noise, and it is the axis every published matrix leads with.

What comes back is not an inventory. It is a ranked list, the three to write this month with the reason each one sits above the rest, and a register carrying every score behind every row so that somebody can argue with it on the numbers. Then the walkthroughs: the top-ranked process is one recording away from a written procedure, and the finished documents belong in a governed library rather than in another folder nobody searches.

Where the real answer already lives

Nobody can tell you which processes are undocumented, because the ones that matter are invisible to the person you would ask. Ask a team what they do and you get the work that has a name. The dangerous processes have no name: the thing Dana does on the second Tuesday, the reconciliation that happens because somebody noticed it needed to, the vendor portal one person has the login for. None of it appears on an org chart and all of it appears in system access and calendars.

So the signals worth reading are the ones nobody curated. An admin grant held by exactly one person is a process only that person can perform. A recurring invite with one attendee is a process running on somebody's memory. A ticket type closed by one name for eighteen months is a queue with no second pair of hands. A system with one seat is a dependency nobody priced. Each of those is a fact rather than an opinion, and each one names a process without anybody describing it.

The scoring then has to resist the pull toward completeness. NIST's business impact analysis works in three steps and only the third produces a plan: determine the processes and their tolerable downtime, identify what each one needs, then set recovery priorities so activities can be sequenced. An audit that returns forty gaps of equal weight gets read once and shelved, because a list with no order in it asks the reader to do the ranking that was the whole job.

How it works

  1. Send the team

    Roles, tenure, an org chart, or a plain list of who does what. Rough is fine.

  2. Add the evidence

    Access exports, a recurring meetings calendar, ticket or task history. Whichever of these you have.

  3. Find the concentration

    Processes only one person can perform get identified, including ones nobody thought to mention.

  4. Rank, then cut

    Each gets a tolerable downtime, the scores order the list, and the top three come with reasons.

What you get

  • Every process ranked by how badly it breaks if today's holder left tomorrow
  • The three to document this month, each with the reason it outranks the rest
  • Processes nobody named at all, inferred from access grants, ticket history and calendars
  • A count of how many people have ever performed each process, not who owns it
  • The tolerable downtime for each, which is what separates urgent from merely undocumented
  • The register with every score shown, so anybody can challenge a ranking on the numbers

Common questions

What do I actually need to send?

A list of who does what is enough to start. Everything else sharpens it: an export of who holds admin access to each system, a recurring meetings calendar, ticket or task history by assignee, a seat list from a tool. Those four are where the processes nobody names show up, because nobody curated them.

Why not just document everything eventually?

Because eventually is the failure mode, not the plan. A forty-row gap list of equal weight gets read once and shelved, and the rows that get written are the easy visible ones. Three ranked processes with a reason attached get written, and the ranking is what makes the fourth one someone else's decision rather than yours.

Isn't frequency a reasonable proxy for importance?

For importance, yes. For risk, it runs the wrong way. Frequent work spreads across people by repetition, so a daily task is usually the safest thing in the building. Rare work concentrates, because nobody else has had occasion to learn it, and a quarterly task performed by one person for six years is close to unrecoverable.

How does it know who really holds a process?

By what people were granted rather than what they were assigned. A system where exactly one account has admin is a process one person can perform. A ticket type closed under one name for eighteen months is a queue with no backup. A recurring invite with a single attendee is a process running on memory.

Somebody has already resigned. Does the ranking change?

Substantially, and that is the point. Once a specific person is leaving, everything concentrated on them moves to the top regardless of its impact score, and the ordering becomes what falls inside their notice period against what falls outside it. The output says which processes have to be captured before the last day. The handover workspace that dates every object they own runs the departure alongside it.

What do I do with the top three?

Get the holder recorded talking through each one, then turn the recording into a procedure. That is a much smaller ask than writing documentation and it is the only version a busy expert agrees to, which is what turning a walkthrough into an SOP handles. More packs sit in the template library.

Does this work for a team of five?

It works better, because concentration is higher and the signals are cleaner. In a five-person company almost every process has exactly one holder, so the ranking collapses onto tolerable downtime alone and the output is a short, unambiguous order of work rather than a scoring exercise.

Undocumented Process Risk Audit Report

Fill in the form and your workspace opens with the work already underway.