System Support Health Check

Can you name, in a few seconds, exactly who owns this system?

Why this matters: Clear ownership prevents decisions and risks from falling between teams.

If that person left tomorrow, is there a clear next owner?

Why this matters: A tested backup reduces disruption when roles or availability change.

Does the owner have authority to approve routine changes?

Why this matters: Responsibility without decision authority creates delay rather than accountability.

Are business, technical and vendor responsibilities clearly separated?

Why this matters: Unclear boundaries allow incidents and changes to fall between teams.

When something fails, does everyone know who to contact first?

Why this matters: A clear first contact reduces delay during an incident.

Has this system been reviewed in the last six months outside of fixing a fault?

Why this matters: Planned review finds drift before it becomes an outage or entrenched workaround.

Are known workarounds or exceptions revisited periodically to check they're still needed?

Why this matters: Unreviewed workarounds become hidden dependencies and permanent control gaps.

Are patching, backups and access checks scheduled rather than ad hoc?

Why this matters: Routine controls fail when they depend on someone remembering them.

Are repeat incidents investigated beyond restoring service?

Why this matters: Repeated symptom fixes consume time while leaving the underlying risk in place.

Is there a plan before the system becomes unsupported or unstable?

Why this matters: Early planning avoids rushed replacement under operational pressure.

Does documentation exist explaining why the system is built the way it is, not just what it does?

Why this matters: Decision context prevents future changes from breaking important assumptions.

Could a new person understand the system without needing to ask the original builder?

Why this matters: Usable documentation reduces dependence on personal memory.

Is there a current record of system inputs, outputs and dependencies?

Why this matters: Undocumented dependencies turn small changes into wider failures.

Are access rights documented and explainable?

Why this matters: Unclear access creates security, continuity and audit risk.

Could someone other than the expert follow the recovery process?

Why this matters: A recovery plan is only useful if it works when the expert is unavailable.