SORF Project

Standard

Continuity Notes

The Continuity Notes standard explains how an organization can document essential information before a founder, owner, director, manager, maintainer, or other key person becomes unavailable.

Small organizations often depend on one or two people who understand how everything works. They may know which vendors matter, where records are stored, how renewals are handled, who can approve changes, which accounts are critical, and what should be checked first when something goes wrong.

That knowledge is valuable, but it can become fragile if it exists only in someone’s memory.

Continuity notes help preserve enough context for other people to take the next practical steps.

Purpose

The purpose of continuity notes is to help an organization understand what should happen if a key person is unavailable because of illness, travel, departure, emergency, resignation, death, access loss, overload, or another disruption.

Continuity notes help answer questions such as:

The goal is not to document every possible scenario. The goal is to make the first steps clearer.

Core principle

The core principle is:

Document the information someone would need to understand the organization’s essential responsibilities, services, records, and next steps if a key person became unavailable.

Continuity notes should reduce confusion without exposing sensitive information unnecessarily.

What continuity notes are

Continuity notes are practical records that help preserve organizational memory.

They may include:

Continuity notes are especially useful for founder-led organizations, small nonprofits, community projects, and small teams where formal operations staff may not exist.

What continuity notes are not

Continuity notes are not:

Organizations may need professional legal, financial, insurance, tax, governance, human resources, cybersecurity, or continuity planning support depending on their situation.

This standard provides a practical documentation structure. It does not replace professional advice.

A basic continuity note may include the following fields.

Key person or role

Record the person or role the continuity note applies to.

Examples:

If appropriate, include both the role and current person.

Role summary

Describe what the person or role is responsible for.

Examples:

The summary should be plain enough for someone outside the role to understand.

Immediate first steps

List the first practical actions someone should take if the person is unavailable.

Examples:

Keep this list short. The first steps should help people orient themselves.

Critical responsibilities

List responsibilities that may need attention quickly.

Examples:

Critical responsibilities should connect to responsibility records where possible.

Critical vendors and services

List essential vendors and services connected to the person or role.

Examples:

Do not duplicate the full vendor inventory unless necessary. Link or refer to it.

Record safe references to access documentation.

Examples:

Do not record passwords, API keys, MFA recovery codes, private keys, seed phrases, or other secret values in continuity notes.

Credential values should remain in the approved systems the organization uses to protect them.

Important contacts

Record contacts who may need to be informed or consulted.

Examples:

Avoid collecting unnecessary personal information. Use only what the organization is authorized and comfortable maintaining.

Decision authority

Record who can make decisions if the key person is unavailable.

Examples:

Decision authority can be sensitive. The continuity note should refer to governing documents, bylaws, contracts, or policies where appropriate rather than trying to replace them.

Recurring obligations

Record recurring duties that could be missed.

Examples:

Use general awareness unless specific dates are safe and useful to include.

Record locations

Record where important records are maintained.

Examples:

Use safe references. Do not expose sensitive documents to people who should not access them.

Backup owner

Record who can assist if the primary person is unavailable.

Examples:

Critical roles should usually have a backup owner or escalation path.

Last reviewed date

Record when the continuity note was last reviewed.

Review frequency

Record how often the continuity note should be reviewed.

Examples:

Notes

Use notes for neutral context.

Examples:

Do not use notes to store credentials, recovery codes, private personal details, sensitive incident evidence, or confidential legal information.

A small organization can begin with this minimum record:

Field Description
Key person or role Person or role the note applies to
Role summary What they are responsible for
First steps What to check first if unavailable
Critical responsibilities Important duties that may need attention
Critical services Essential vendors or systems connected to the role
Access references Safe references to access records
Backup owner Who can help if unavailable
Last reviewed Date last checked

This minimum version is enough to reduce avoidable confusion.

Examples

Example: Founder continuity note

Field Example
Key person or role Founder
Role summary Maintains product direction, website, payment setup, vendor relationships, and documentation updates
First steps Check vendor inventory, support inbox, access references, and current project notes
Critical responsibilities Domain renewal, payment processor, customer support, website updates
Critical services Domain registrar, website host, email provider, payment processor
Access references “Primary Domain Registrar,” “Website Hosting Admin,” “Payment Processor Admin”
Backup owner Operations backup
Last reviewed 2026-07-08

Example: Finance owner continuity note

Field Example
Key person or role Finance owner
Role summary Maintains payment, bookkeeping, receipts, renewals, and financial vendor records
First steps Review accounting folder, vendor inventory, payment processor record, and upcoming renewals
Critical responsibilities Payment processor, accounting software, tax records, subscription renewals
Critical services Bank, payment processor, accounting software, accountant
Access references “Payment Processor Admin,” “Accounting Software Admin”
Backup owner Founder or treasurer
Last reviewed 2026-07-08

Example: Website maintainer continuity note

Field Example
Key person or role Website maintainer
Role summary Maintains website hosting, domain configuration, DNS records, content updates, and deployment process
First steps Check hosting provider, domain registrar, deployment repository, and latest change log
Critical responsibilities Website availability, domain renewal, DNS changes, deployment access
Critical services Domain registrar, DNS provider, website host, repository host
Access references “Primary Domain Registrar,” “Website Hosting Admin,” “Repository Admin”
Backup owner Founder
Last reviewed 2026-07-08

Continuity levels

Organizations can adopt continuity notes gradually.

Level 1: Basic key-person notes

At this level, the organization documents:

This is a useful starting point for very small organizations.

Level 2: Connected continuity notes

At this level, continuity notes connect to:

This helps the organization avoid duplicating information.

Level 3: Managed continuity routine

At this level, the organization has:

This is more appropriate for organizations with multiple people, higher dependency, or more formal governance needs.

Review triggers

Continuity notes should be reviewed when:

Relationship to responsibility records

Continuity notes should not replace responsibility records.

Responsibility records explain who owns what.

Continuity notes explain what should be known if a key person is unavailable.

The two records should support each other.

Relationship to vendor inventory

Continuity notes should refer to the vendor inventory for detailed vendor information.

The continuity note may list critical vendors, but the vendor inventory should hold the fuller record.

Relationship to access references

Continuity notes should use access references instead of containing credential values.

For example:

Access for the domain registrar is documented in the access reference register under “Primary Domain Registrar.”

This is safer than writing the password or recovery codes into the continuity note.

Relationship to incident timeline notes

If a key-person absence creates or worsens a disruption, incident timeline notes may help record what happened.

After the disruption, continuity notes should be reviewed to see what information was missing or unclear.

Common mistakes

Mistake 1: Waiting until something happens

Continuity notes are most useful before they are needed.

A simple draft is better than no record.

Mistake 2: Writing a long emergency manual no one will use

Continuity notes should be practical. Start with first steps, critical responsibilities, vendors, access references, and backup owners.

Mistake 3: Storing passwords in continuity notes

Continuity notes should not become secret storage.

Use secure systems for credential values and safe references in documentation.

Mistake 4: Assigning everything to one person

If one person is responsible for everything, the organization should be honest about that. Then it can decide which areas need backup coverage first.

Mistake 5: Forgetting decision authority

A backup owner may know what to do but may not have authority to approve changes. If authority matters, document where it is defined.

Mistake 6: Never reviewing the note

Continuity notes become stale when services, people, roles, and vendors change. Review them periodically.

Suggested adoption path

A practical adoption path is:

  1. Identify the key people or roles the organization depends on.
  2. Write a short role summary for each one.
  3. List the first steps someone should take if that person is unavailable.
  4. Identify critical responsibilities connected to the role.
  5. Identify critical vendors and services connected to the role.
  6. Add safe access-reference links.
  7. Add backup owners where possible.
  8. Set a review date.

This can begin with one person or one role. It does not need to cover the entire organization immediately.

Public standard status

This standard is an early public draft.

It may be revised as examples, templates, feedback, and implementation notes improve.

Related templates may include:

Related standards include:

Status: Draft · Version: 0.1 · Last updated: 7/8/2026

This standard is provided as a general educational resource. It is not legal, tax, financial, insurance, cybersecurity, compliance, or incident-response advice.