A five-person team can run for months without an operations manual. Everyone knows which accounts matter, who pays for hosting, where the domain is registered, and which client promised to send the missing files.
Then somebody takes a holiday.
A renewal notice reaches an inbox nobody checks. The person who owns the analytics account is unavailable. A decision from last week’s call never became a task. Nothing is technically broken, but ordinary work starts waiting for the one person who remembers how everything fits together.
A useful operations checklist does not document every click. It records the few details the team would need if the usual person could not answer.
Quick answer: List the systems that can stop work, name an owner and backup owner for each one, record how access is recovered, and give every recurring cost a review date. Keep meeting decisions in the task system and test backups before they are needed.
The document should be short enough to review every month. If nobody opens it, its completeness does not matter.
- Accounts
- Owners
- Access
- Recovery
- Review
- Access Ownership, admin rights, routine access, and recovery paths stay written down.
- Meetings Decisions become owned tasks in the system the team already checks.
- Infrastructure Domains, DNS, hosting, backups, and monitoring have visible owners.
- Billing Renewals, payment owners, and exit notes sit on a shared calendar.
Start with the systems that can interrupt work
Do not begin with every application the team has tried. Begin with the systems whose failure would block revenue, communication, delivery, or recovery.
A small inventory may include:
- company email;
- domain registrar;
- DNS provider;
- website hosting;
- cloud server or control panel;
- source-code repository;
- file storage;
- payment processor;
- accounting platform;
- analytics;
- customer support;
- scheduling;
- password manager;
- project-management system;
- primary communication channel.
For each system, record its purpose, owner, backup owner, billing account, renewal date, recovery method, and the place where operating notes are stored.
The owner is responsible for keeping the record current. Ownership does not mean that one person should hold the only login.
Separate ownership from access
Teams often treat these as the same question.
The account owner controls the relationship with the provider. That person may receive billing notices, approve changes, or prove the organization’s identity. Access describes who can use the system and what each person can do.
A contractor may need WordPress access without owning the hosting account. A marketer may need analytics reports without permission to change billing. A developer may need DNS records without control of the registrar.
Write down both:
- Who owns the provider relationship?
- Who has administrative access?
- Who needs routine access?
- Who can recover the account?
- Who should lose access when a project ends?
If the answer to every question is the same person, the system has a dependency worth fixing.
Make recovery possible without sharing everything
Recovery deserves its own field in the inventory.
A password may be stored correctly while the recovery email belongs to a former employee. Multifactor authentication may depend on one phone. Backup codes may exist only as a screenshot on the same device they are supposed to recover.
Record where recovery codes are stored, which email or phone receives recovery messages, and who can prove ownership to the provider. Do not place the actual passwords or recovery codes inside the operations checklist.
When credentials have accumulated across several browser profiles, use a controlled process to move passwords between browsers without losing access. A migration file containing readable passwords should be temporary, verified, and removed after use.
Recovery information should survive the loss of one laptop, one phone, or one person’s availability.
Turn meeting decisions into owned work
Meeting notes often preserve what people said while losing what must happen next.
A useful follow-up separates four things:
- Decisions Settled choices the team will act on.
- Action items Concrete work with a clear output.
- Owners and deadlines Who moves each item, and by when.
- Open questions Blockers that still need an answer.
The transcript or recording can remain as evidence. It should not become the task list.
For a repeatable process, use the workflow for turning meeting transcripts into clear action items. The important step happens after summarization: tasks must enter the system where the team already checks work.
Review overdue actions during the next meeting. Do not create a second hidden list inside the notes document.
Keep infrastructure ownership visible
A website can remain online while its operational setup becomes fragile.
The domain may renew through a founder’s personal card. DNS may sit in an account created by an old agency. The server may be documented, but nobody knows whether its backups have ever been restored. A plugin license can expire without taking the site down immediately, which makes the missing renewal easy to ignore.
For each website or application, record:
- Registrar
- DNS provider
- Hosting provider
- Server or platform
- Technical owner
- Billing owner
- Backup location
- Restore instructions
- Monitoring destination
- Renewal dates
- Support contact
If the team plans to leave shared hosting, keep the VPS migration checklist beside the rollback plan. Migration notes belong with the system record, not in a forgotten chat thread.
Treat backups as a recovery process
A backup job reporting success proves that a file or snapshot was created. It does not prove that the team can restore service.
The inventory should answer:
- What is backed up?
- How often is it backed up?
- Where is the copy stored?
- Who receives failure alerts?
- How is a restore started?
- When was a restore last tested?
The answer may differ by system. A website needs files and a database. A cloud application may need an export. A repository already has version history, but secrets, deployment settings, uploaded assets, or external services may live elsewhere.
Choose one low-risk restore test. Record the result and anything that was missing.
Put renewals on a calendar before the invoice arrives
Recurring costs fail quietly.
A card expires. A monthly tool continues after the person who requested it leaves. An annual plan renews because cancellation required notice several weeks earlier.
Keep a renewal list with:
- service;
- billing frequency;
- expected amount or pricing page;
- payment owner;
- business owner;
- renewal date;
- cancellation deadline;
- current use;
- replacement or exit notes.
Review annual subscriptions at least a month before renewal. The goal is not to cancel aggressively. It is to make the decision while there is still time to export data or change providers.
Document the handoff, not every screen
A useful operating note explains what another competent person would need to continue.
It may contain:
- why the system exists;
- where administration happens;
- who owns it;
- how access is requested;
- where recovery material lives;
- which changes are risky;
- how to check whether it is working;
- where the rollback instructions are stored.
It does not need screenshots of every menu. Interfaces change, and detailed click-by-click instructions age quickly.
Keep screenshots only when they explain a setting that is difficult to identify by name.
A monthly review that can actually happen
Schedule one short review. Twenty minutes is enough for a small inventory if the team deals with problems separately instead of solving each one during the review.
Check:
- New systems added this month.
- People who joined, left, or changed roles.
- Accounts without a backup owner.
- Recovery methods tied to unavailable people.
- Failed backups or alerts.
- Renewals in the next 60 days.
- Open actions from important meetings.
- Infrastructure changes without updated notes.
Assign the repair work. Do not let the review become a two-hour administration meeting.
Some months there will be nothing to change. That is useful information too.
Digital operations checklist
Accounts and ownership:
- Critical systems are listed.
- Each system has an owner and backup owner.
- Administrative access is limited and recorded.
- Former staff and contractors have been removed.
- Recovery email and phone details are current.
Passwords and recovery:
- Credentials are stored in the approved system.
- Multifactor authentication is enabled where appropriate.
- Recovery codes are protected outside the device they recover.
- Browser exports and other temporary credential files have been removed.
- At least one backup person understands the recovery path.
Meetings and decisions:
- Decisions are separated from discussion notes.
- Every action has an owner.
- Deadlines are explicit.
- Open questions name the person responsible for resolving them.
- Tasks live in the normal task system.
Infrastructure:
- Registrar, DNS, hosting, and server ownership are documented.
- Monitoring reaches an active inbox or channel.
- Backups cover the data needed for recovery.
- A restore procedure exists.
- A recent restore test has been recorded.
- Migration and rollback notes are stored together.
Billing and vendors:
- Recurring services have owners.
- Renewal and cancellation dates are visible.
- Payment methods are current.
- Unused subscriptions are reviewed.
- Data export or exit steps are known for critical vendors.
Open the inventory beside the calendar. Pick the next renewal and the next account with no backup owner. Those two rows are enough for the first review.
Sources and verification
- NIST Cybersecurity Framework 2.0
- CISA Cyber Guidance for Small Businesses
- CISA: Turn On Multifactor Authentication
- CISA #StopRansomware Guide (backup practices)
- ICANN: Registering Domain Names
This checklist is general operational guidance. Security, legal, contractual, and retention requirements vary by organization and jurisdiction.