An online system can run for a long time because one person remembers its screens, rules, and exceptions. The problem emerges when that person is unavailable, changes roles, or leaves: a routine task can become an urgent interruption, while a small change may feel too risky to make.
The answer is not to document every detail or create bureaucracy that slows work down. It is to make the knowledge needed to operate, fix, and improve the system accessible. This guide offers a practical way to reduce reliance on one person.
What it means for maintenance to depend on someone
Dependency is not limited to who writes the code. It also exists when one person alone knows how to restore access, where to investigate an error, which integration must not be changed, or whom to contact during an outage. If the team cannot complete a normal task without asking that person, important knowledge is concentrated.
NIST’s Secure Software Development Framework (SSDF) groups secure development practices around preparation, protection, production, and vulnerability response. It does not prescribe one procedure for every organization; it provides a framework that should fit the situation. The practical point here is that maintainable operations need understandable responsibilities and procedures, not just technology.
Start with tasks that must not get stuck
Do not try to document the entire system at once. List tasks that could stop important work or delay a response if nobody else knows how to perform them. Examples include:
- Creating or removing access and reviewing administrative permissions.
- Checking whether the system is available and where to look for relevant errors.
- Releasing a change and checking that the service still works.
- Contacting an integration provider or escalating an incident.
- Restoring an approved configuration or starting an authorized recovery.
- Responding to a security update or a reported vulnerability.
Prioritize by operational impact, frequency, and how difficult the knowledge is to replace. A rare but critical task with no known alternative may deserve attention before a simple daily task.
Document what someone needs to take action
A useful guide answers specific questions: what is the task, who may perform it, what must be ready first, how can the result be checked, and whom should the person contact if it fails? Do not put passwords, private keys, or sensitive data in shared documents. Say where they are managed securely, not what they are.
For each priority procedure, record at least:
- Purpose and scope: what the procedure covers and what it does not.
- Primary and backup owners: who performs it, who approves it, and who gets notified.
- Steps and checks: readable instructions and a way to confirm the result.
- Dependencies: systems, providers, permissions, or people involved.
- Escalation: what to do if the procedure fails and how to record what happened.
- Review date: when it was last checked and who should update it.
Use screenshots or diagrams when they clarify a sequence, but do not make them a substitute for instructions. An image can become outdated and does not explain what to do when an exception occurs.
Share responsibilities and prepare backups
Having a backup does not mean everyone needs full access. Define who may view, change, approve, and escalate. Keep permissions appropriate to the task and review them when team responsibilities change.
Ask someone who did not write the guide to test it. Have them complete a safe task in an appropriate environment and note where they hesitate. This reveals implicit instructions, missing permissions, and steps that existed only in the author’s memory. Where a system has separate environments, do not experiment in production: NIST guidance includes separating and protecting development, test, and production environments as part of secure practices.
Make maintenance a routine
An ignored guide can be almost as unhelpful as no guide at all. Schedule brief reviews around work that already happens: a significant update, a provider change, staff turnover, or a periodic check. Confirm that owners are still current, instructions still work, and tool links are valid.
Use a simple tracking record for changes and issues. It can be an existing work-tracking tool. Each entry should state the issue or change, its priority, who owns it, what decision was made, and how closure was verified. NIST recommends identifying and responding to vulnerabilities; its guidance also describes assessment, prioritization, and remediation as activities to organize. That does not mean every issue deserves the same urgency: set criteria that fit your risk and operational impact.
Good maintenance does not depend on someone remembering everything. It depends on the team being able to find information, decide who acts, and verify the result.
A starting plan for this week
- Choose three maintenance tasks whose interruption would have the greatest impact.
- Assign a primary owner and a backup for each, with appropriate permissions.
- Write brief steps, success checks, and an escalation route.
- Ask someone else to test the instructions without help from the author.
- Fix the gaps and set a review date.
A small team does not need to become a process department. Start where someone’s absence could block important work, then expand documentation as the system and work change. The aim is for someone else to continue safely, not for everyone to know how to do everything.
Before you finish, answer one concrete question: if the person who knows the software best were unavailable tomorrow, which task would get stuck first? Document that task, assign a backup, and test the procedure. That first step turns a vague risk into an improvement the team can verify.
Source: Appendix C SSDF Analysis — National Institute of Standards and Technology (NIST), NCCoE
