Standard
Responsibility Records
The Responsibility Records standard explains how an organization can document who owns, maintains, reviews, and supports important records, services, accounts, vendors, processes, and decisions.
Small organizations often operate through informal knowledge. One person may know which vendor handles the website, another may know where invoices are stored, and another may know who can approve account changes. That can work for a while, but it becomes fragile when someone is unavailable, leaves, changes roles, or simply forgets.
Responsibility records help make ownership visible.
They are not about blame. They are about clarity.
Purpose
The purpose of responsibility records is to help an organization understand:
- who owns an area of responsibility
- who maintains a record, service, process, or vendor relationship
- who should review information
- who should be contacted when something changes
- who can explain the current state
- who provides backup coverage
- what responsibilities are unclear or unassigned
Responsibility records are especially useful for small organizations where roles overlap and responsibilities are not always formally documented.
Core principle
The core principle is:
Every important record, service, account, vendor, or process should have a clear owner or responsible role.
This does not mean one person must do everything. It means the organization should be able to answer a basic question:
Who is responsible for keeping this understandable?
What a responsibility record is
A responsibility record is a practical note that connects an organizational item to a person, role, team, or outside provider.
It may describe responsibility for:
- a vendor relationship
- a service account
- a documentation area
- a recurring review
- a continuity note
- a financial process
- a website function
- a payment system
- a domain name
- a support inbox
- a shared drive
- a legal or administrative record
- a contractor relationship
- an incident follow-up item
Responsibility records help prevent important work from existing only in someone’s memory.
What a responsibility record is not
A responsibility record is not:
- a performance review
- a blame record
- a legal assignment by itself
- an employment contract
- a compliance certification
- a substitute for role descriptions
- a substitute for professional advice
- a guarantee that responsibilities are fully covered
The record supports clarity. It does not replace judgment, governance, employment agreements, legal review, or management.
Recommended fields
A basic responsibility record may include the following fields.
Item or area
Record what the responsibility applies to.
Examples:
- Website hosting
- Domain registrar
- Payment processor
- Vendor inventory
- Access reference register
- Continuity notes
- Incident timeline notes
- Accounting software
- Support inbox
- Insurance renewal
- Documentation review routine
The item should be specific enough to understand.
Responsibility category
Record the type of responsibility.
Examples:
- Account ownership
- Vendor relationship
- Record maintenance
- Billing awareness
- Review owner
- Continuity owner
- Incident follow-up
- Approval owner
- Backup owner
- External provider
Categories help make responsibility records easier to sort.
Primary owner
Record the person, role, team, or provider primarily responsible.
Examples:
- Founder
- Operations lead
- Finance owner
- Website maintainer
- Board treasurer
- External accountant
- IT support provider
- Documentation maintainer
Where possible, use both a role and a current person.
Example:
Finance owner: Jane Smith
This makes the record easier to maintain when people change roles.
Backup owner
Record who can help if the primary owner is unavailable.
Examples:
- Second administrator
- Board secretary
- Alternate maintainer
- External provider
- Founder
- Operations backup
Not every item needs a backup owner, but critical areas usually should.
Decision authority
Record who can make decisions about the item.
Examples:
- Founder approval required
- Finance owner may approve renewals
- Board approval required
- Operations lead may change vendor
- External provider may recommend, but not approve
- Unknown
This helps separate maintenance from authority.
Maintenance responsibility
Describe what the owner is expected to maintain.
Examples:
- Keep vendor record current.
- Review access reference quarterly.
- Confirm billing email before renewal.
- Update continuity notes after major changes.
- Save receipts in the approved folder.
- Confirm account ownership after role changes.
Keep this practical. Avoid turning the record into a long job description.
Review frequency
Record how often the responsibility should be reviewed.
Examples:
- Monthly
- Quarterly
- Twice per year
- Annually
- Before renewal
- After role changes
- After incidents
- As needed
Last reviewed date
Record the date the responsibility record was last checked.
Related records
Record related documentation.
Examples:
- Vendor inventory
- Access reference
- Continuity notes
- Incident timeline
- Contract folder
- Billing folder
- Review log
Use safe references. Do not store confidential materials inside the responsibility record unless the system is approved for that use.
Status
Record whether the responsibility is current.
Examples:
- Active
- Needs review
- Unassigned
- Shared
- External
- Archived
- Unknown
The most important status is often “Unassigned.” It reveals a gap.
Notes
Use notes for neutral context.
Examples:
- Backup owner should be added before next renewal.
- Ownership changed after website migration.
- External accountant handles filing reminders.
- Review this if payment processor changes.
- Responsibility currently shared between founder and operations lead.
Do not use notes for passwords, API keys, private keys, recovery codes, confidential evidence, or sensitive personal information.
Minimum recommended responsibility record
A very small organization can begin with this simple record:
| Field | Description |
|---|---|
| Item or area | What the responsibility applies to |
| Primary owner | Who is responsible |
| Backup owner | Who can help if unavailable |
| Responsibility | What should be maintained or reviewed |
| Related record | Where supporting documentation lives |
| Last reviewed | Date last checked |
| Status | Active, needs review, unassigned, or unknown |
This minimum version can create useful clarity quickly.
Examples
Example: Domain name
| Field | Example |
|---|---|
| Item or area | Primary domain name |
| Category | Account ownership |
| Primary owner | Website maintainer |
| Backup owner | Founder |
| Decision authority | Founder approval required for transfer |
| Maintenance responsibility | Confirm renewal status and registrar access reference |
| Review frequency | Quarterly |
| Related records | Vendor inventory, access reference |
| Status | Active |
| Last reviewed | 2026-07-08 |
Example: Vendor inventory
| Field | Example |
|---|---|
| Item or area | Vendor and service inventory |
| Category | Record maintenance |
| Primary owner | Operations lead |
| Backup owner | Founder |
| Decision authority | Operations lead may update records |
| Maintenance responsibility | Add new vendors, archive cancelled vendors, review unknown services |
| Review frequency | Quarterly |
| Related records | Review log, access references |
| Status | Active |
| Last reviewed | 2026-07-08 |
Example: Payment processor
| Field | Example |
|---|---|
| Item or area | Payment processor |
| Category | Vendor relationship |
| Primary owner | Finance owner |
| Backup owner | Founder |
| Decision authority | Founder approval required for major changes |
| Maintenance responsibility | Monitor account status, receipts, tax settings, and support notices |
| Review frequency | Quarterly |
| Related records | Vendor inventory, access reference, continuity notes |
| Status | Active |
| Last reviewed | 2026-07-08 |
Example: Incident timeline notes
| Field | Example |
|---|---|
| Item or area | Incident timeline notes |
| Category | Incident follow-up |
| Primary owner | Operations lead |
| Backup owner | Documentation maintainer |
| Decision authority | Primary owner may update timeline notes |
| Maintenance responsibility | Keep neutral notes during outages, vendor issues, or operational disruptions |
| Review frequency | After incidents |
| Related records | Incident timeline, review log |
| Status | Active |
| Last reviewed | 2026-07-08 |
Responsibility levels
Not every responsibility has the same importance.
A simple responsibility level can help prioritize attention.
Critical
A critical responsibility affects core operations, revenue, access, legal administration, communications, or continuity.
Examples:
- domain ownership
- payment processor ownership
- primary email administration
- banking or finance administration
- legal notices
- payroll
- primary documentation records
Critical responsibilities should usually have a primary owner, backup owner, access reference, and review routine.
Important
An important responsibility supports meaningful operations but may not immediately stop the organization if neglected.
Examples:
- analytics tools
- content systems
- shared drives
- vendor review
- insurance renewal tracking
- accounting software
Important responsibilities should still be reviewed.
Routine
A routine responsibility supports normal operations and can usually be reviewed less frequently.
Examples:
- maintaining archived vendor notes
- updating non-critical tool records
- reviewing optional subscriptions
- maintaining internal reference pages
Routine responsibilities should be clear enough not to disappear.
Unknown
Unknown means the organization is not sure who owns the area or how important it is.
Unknown should be treated as a review signal.
Ownership versus access
Responsibility records should not be confused with access records.
A person may be responsible for a service without personally holding every credential. Another person or system may manage access.
For example:
- The finance owner may own the payment processor relationship.
- The password manager may store the admin credentials.
- The founder may approve major account changes.
- The accountant may receive reports but not have full admin access.
The responsibility record explains who owns the work. The access reference explains where access is managed.
Ownership versus authority
Responsibility and authority are related, but not always the same.
A person may maintain a record but not have authority to make major decisions.
Examples:
- A website maintainer may update hosting records but may not transfer the domain.
- A bookkeeper may maintain accounting records but may not approve new bank accounts.
- A contractor may manage a tool but may not authorize billing changes.
- A board officer may approve decisions while staff maintain the records.
If decision authority matters, document it clearly.
Shared responsibilities
Some responsibilities are shared.
Shared responsibility can work, but it should not be vague.
Instead of writing:
Everyone handles this.
Write something clearer:
Operations lead maintains the record. Finance owner reviews billing fields. Founder approves vendor changes.
Shared responsibility should still identify who does what.
Unassigned responsibilities
An unassigned responsibility is not automatically a failure. It is useful information.
Marking something as unassigned helps the organization see a gap before it becomes a problem.
Examples:
- No backup owner for domain registrar.
- No one owns the review routine.
- No one knows who receives renewal notices.
- Incident timeline notes have no assigned maintainer.
- Vendor inventory exists but has no review owner.
Unassigned records should be reviewed and resolved when practical.
Review triggers
Responsibility records should be reviewed when:
- a new vendor or service is added
- an account owner changes
- someone leaves the organization
- a new person receives admin responsibility
- a vendor relationship changes
- billing ownership changes
- an incident reveals unclear ownership
- a continuity review identifies a key-person dependency
- a periodic review date arrives
Role changes are especially important. A record that names the wrong owner can create confusion during a disruption.
Relationship to vendor inventory
Vendor inventories and responsibility records work closely together.
A vendor inventory describes what services exist and why they matter.
A responsibility record describes who owns or maintains each service or record.
In small organizations, these may exist in the same spreadsheet. In larger organizations, they may be separate but linked.
Relationship to access references
Responsibility records and access references should remain distinct.
Responsibility records answer:
- Who owns this?
- Who reviews it?
- Who can explain it?
- Who is the backup?
Access references answer:
- Where is access managed?
- Where are credentials securely stored?
- Is MFA enabled?
- Who owns recovery?
Do not put passwords or secret values in either record.
Relationship to continuity notes
Responsibility records are important continuity tools.
If a founder, owner, manager, director, or key maintainer becomes unavailable, the organization needs to know who owns essential areas and who can help.
Continuity notes should refer to responsibility records instead of duplicating everything.
Relationship to incident timeline notes
Incidents often reveal unclear responsibilities.
After an outage, access issue, vendor problem, billing disruption, or operational mistake, review responsibility records to see whether ownership was clear.
Good follow-up questions include:
- Did people know who owned the affected service?
- Was there a backup owner?
- Was decision authority clear?
- Were vendor and access records current?
- Should a responsibility record be updated?
Common mistakes
Mistake 1: Treating responsibility as blame
Responsibility records should support clarity, not punishment.
The goal is to help people know who maintains what.
Mistake 2: Assigning everything to the founder
Founder-led organizations often assign too much to one person. That may be reality at first, but it should be visible.
If one person owns everything, continuity notes become more important.
Mistake 3: Not naming a backup owner
Some records can survive without a backup. Critical records usually should not.
Mistake 4: Confusing access with ownership
Having the password does not always mean owning the responsibility. Owning the responsibility does not always mean holding the credential directly.
Mistake 5: Letting records go stale after role changes
Responsibility records should be updated when people leave, join, or change roles.
Mistake 6: Using vague labels
Avoid vague labels such as:
- everyone
- admin
- team
- office
- management
Use clear roles or names where practical.
Suggested adoption path
A practical adoption path is:
- List the most important records, services, vendors, and accounts.
- Add a primary owner for each one.
- Mark anything unassigned or unknown.
- Add backup owners for critical items.
- Add review dates.
- Link responsibility records to vendor and access records.
- Review the records after major changes.
This can be done gradually. Start with the records that would create the most confusion if no one knew who owned them.
Public standard status
This standard is an early public draft.
It may be revised as examples, templates, feedback, and implementation notes improve.
Related templates
Related templates may include:
- Responsibility Record
- Vendor and Service Inventory
- Access Reference Register
- Continuity Notes
- Documentation Review Log
Related standards
Related standards include:
- Documentation Framework
- Vendor Inventory
- Access References
- Continuity Notes
- Incident Timeline
- Review Routines