Standard

Access References

The Access References standard explains how an organization can document where access is managed without turning documentation into a password list.

Small organizations often depend on accounts, admin panels, software tools, cloud services, payment systems, domain registrars, email accounts, and other services. When access information is only remembered by one person, the organization can become fragile. But writing secrets directly into general documents creates a different problem.

This standard provides a safer middle path.

It helps organizations record enough information to understand how access is governed, while keeping credential values in approved secure systems.

Purpose

The purpose of an access reference is to help an organization understand:

• what account, tool, system, or service exists
• who is responsible for it
• where credential values are securely stored
• what method is used to protect access
• how access should be reviewed
• who should be contacted if access changes
• what should not be written into general documentation

An access reference should point to the correct secure location. It should not contain the secret itself.

Core principle

The core principle is:

Document where access is managed, not the credential value itself.

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

Use references such as:

• password-manager item names
• secure vault locations
• identity provider names
• account owner names
• responsible team or role
• MFA method notes
• recovery process notes
• review dates
• support contact paths

Do not record passwords, API keys, MFA recovery codes, private keys, seed phrases, payment card data, or other sensitive values in general documentation.

What an access reference is

An access reference is a record that helps people understand how access is organized.

It may describe:

• the service or system
• the purpose of the account
• the responsible owner
• the approved storage location for credentials
• whether MFA is enabled
• the type of MFA used
• the recovery owner or escalation path
• when access was last reviewed
• what related services depend on the account

For example, an access reference might say:

Domain registrar access is managed in the organization password manager under the item name “Primary Domain Registrar.” MFA is enabled. The responsible owner is the operations lead. Review quarterly.

That tells a future maintainer where to look and who owns the account without exposing the password or recovery codes.

What an access reference is not

An access reference is not:

• a password list
• a backup of credential values
• a place to store API keys
• a place to store MFA recovery codes
• a place to store private keys
• a place to store seed phrases
• a substitute for a password manager
• a complete identity and access management program
• a cybersecurity policy
• a compliance control by itself

The access reference exists to improve clarity. It should not become a new source of credential exposure.

Why access references matter

Many small organizations have informal access habits.

Common problems include:

• one person knows where every account is
• old accounts are forgotten
• vendor portals are not documented
• admin access is unclear
• MFA is enabled but recovery ownership is unclear
• passwords are stored in unsafe documents
• payment and domain accounts are difficult to locate
• no one knows which services depend on which accounts

Access references help reduce that confusion.

They also help separate two different needs:

1. The need to know that an account exists.
2. The need to access the account securely.

Those should not always be handled in the same document.

Recommended fields

A basic access reference record may include the following fields.

Service or account name

Record the name of the service, platform, vendor, or account.

Examples:

• Domain registrar
• Website hosting account
• Email admin account
• Payment processor
• Cloud storage workspace
• Accounting software
• Social media account
• Password manager
• Analytics service

Purpose

Describe why the account exists.

Examples:

• Manages the primary website domain.
• Hosts the public website.
• Processes customer payments.
• Stores shared business documents.
• Manages email addresses for the organization.

The purpose should be clear enough for someone unfamiliar with the account to understand why it matters.

Responsible owner

Record the person, role, or team responsible for maintaining the account.

Examples:

• Founder
• Operations lead
• Finance owner
• Website maintainer
• External accountant
• IT support provider

Avoid using only someone’s memory as the ownership system. If possible, connect the record to a role rather than only a named person.

Approved credential storage location

Record where credential values are stored.

Examples:

• Password manager: item name “Domain Registrar”
• Secure vault: “Finance Tools / Payment Processor”
• Identity provider: managed through company SSO
• External provider: managed by accounting firm
• Not applicable: access controlled by invitation only

This field should point to the secure system. It should not contain the password, API key, recovery code, or secret value.

MFA status

Record whether multi-factor authentication is enabled, if known.

Examples:

• Enabled
• Not enabled
• Unknown
• Not applicable

This field is informational. It should not include recovery codes.

MFA method notes

Record a general note about the type of MFA used.

Examples:

• Authenticator app
• Hardware security key
• SMS
• Email confirmation
• SSO-based MFA
• Managed by vendor
• Unknown

Keep the note general. Do not record codes, backup codes, private keys, or device-specific secrets.

Recovery owner or escalation path

Record who should be contacted if access recovery is needed.

Examples:

• Founder
• Operations lead
• External IT provider
• Vendor support
• Account owner listed in password manager
• Board secretary
• Finance owner

This field is especially useful for continuity planning.

Related services

Record any related services that depend on the account.

Examples:

• Domain registrar connects to website hosting.
• Payment processor connects to accounting software.
• Email account is used for password resets.
• Cloud storage holds vendor records.
• Social media account uses the primary email inbox.

This helps people understand dependencies.

Last reviewed date

Record the date the access reference was last reviewed.

The goal is not constant review. The goal is to avoid records becoming stale forever.

Review frequency

Record a realistic review schedule.

Examples:

• Monthly
• Quarterly
• Twice per year
• Annually
• After staffing changes
• After vendor changes
• After incidents

A simple review routine that actually happens is better than a complicated one that is ignored.

Notes

Use this field for neutral, non-sensitive context.

Examples:

• Account is owned by the organization, not a personal email account.
• Vendor support requires billing email confirmation.
• Account should be reviewed before renewal.
• Access is currently limited to two administrators.

Do not use notes to store secrets.

What not to record

The following should not be recorded in general access-reference documentation:

• passwords
• passphrases
• API keys
• private keys
• seed phrases
• MFA recovery codes
• one-time passwords
• payment card numbers
• full identity documents
• customer records
• confidential contracts
• regulated data
• security questions and answers
• backup codes
• database credentials
• production secrets
• encryption keys

If an organization needs to manage those values, it should use secure systems designed for that purpose.

Examples

Example: Domain registrar

Example: Payment processor

Example: Email admin account

Access-reference maturity levels

Organizations can adopt this standard gradually.

Level 1: Basic awareness

At this level, the organization records:

• service name
• purpose
• responsible owner
• secure storage reference
• last reviewed date

This is enough to reduce confusion.

Level 2: Operational clarity

At this level, the organization also records:

• MFA status
• recovery owner
• related services
• review frequency
• notes about ownership

This helps with handoffs and continuity.

Level 3: Managed review

At this level, the organization has:

• a regular review schedule
• documented ownership changes
• access reviews after role changes
• access-reference updates after vendor changes
• continuity notes connected to key accounts

This is more appropriate for organizations with multiple people, multiple systems, or higher operational dependency.

Review triggers

Access references should be reviewed when:

• a new important account is created
• a vendor or service changes
• a key person leaves
• a new person receives admin access
• MFA settings change
• recovery ownership changes
• a domain, payment, email, or hosting account changes
• an incident or outage involves account access
• a periodic review date arrives

The review does not need to be complicated. It should confirm that the record still points to the right secure location and responsible owner.

Relationship to continuity planning

Access references are closely connected to continuity planning.

If a key person becomes unavailable, the organization may need to know:

• which services are essential
• who owns them
• where credentials are securely stored
• who can approve recovery
• which systems depend on the account

Access references help continuity notes stay safer because they avoid placing secret values directly inside continuity documents.

Relationship to vendor inventory

Access references also connect to vendor and service inventories.

A vendor inventory explains what services exist and why they matter. An access reference explains how access to those services is managed.

The two records can reference each other without duplicating sensitive information.

Common mistakes

Mistake 1: Creating a shared password spreadsheet

A shared spreadsheet containing passwords, API keys, recovery codes, and admin credentials can create serious exposure.

Use a password manager or secure vault for credential values. Use access references to point to the appropriate secure location.

Mistake 2: Recording too much detail

An access reference should not contain every sensitive operational detail. It should be useful without being dangerous.

Mistake 3: Naming people without roles

If every record depends on one person’s name, the documentation may become stale when that person leaves or changes responsibilities.

Where possible, include both a role and a current person.

Mistake 4: Forgetting recovery ownership

MFA may be enabled, but if no one knows who owns recovery, the organization may still be stuck during a handoff or disruption.

Mistake 5: Never reviewing the records

Access references should be reviewed periodically. Even a short quarterly review is better than no review at all.

Minimum recommended access reference

A very small organization can begin with this minimum record:

This minimum version is enough to create a useful starting point.

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:

• Access Reference Register
• Vendor and Service Inventory
• Responsibility Record
• Continuity Notes
• Documentation Review Log

Related standards

Related standards include:

• Documentation Framework
• Vendor Inventory
• Responsibility Records
• Continuity Notes
• Review Routines

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