NIST's Cybersecurity Framework 2.0, published on February 26, 2024, gives small teams a way to talk about risk across the business. It sorts cybersecurity outcomes into six functions: Govern, Identify, Protect, Detect, Respond and Recover. Its Small Business Quick-Start Guide, NIST SP 1300, is written for small and medium-sized businesses that have modest or no cybersecurity plans in place and are starting to put one together. The first useful conversation is about what the business depends on and who owns the decisions.

Under Govern, one of the first actions the guide lists is to understand who within your business will be responsible for developing and executing the cybersecurity strategy. Under Identify, it suggests documenting internal and external threats, and the responses to them, in a risk register. Its sample asset inventory already includes a column for each asset's administrator or owner and one for the risk to the business if you lose access to that asset. For a small team, the register can be a short table with one risk and one named person per row.

What a risk owner does

NIST IR 8286r1, a December 2025 report on integrating cybersecurity and enterprise risk management, describes the risk owner as the party responsible and accountable for keeping a risk in line with the organization's requirements. The owner can work with a risk manager, who manages and monitors the chosen response. On a small team, those two roles can be a business owner who sets the priority and a technical owner who does the work and tests it.

To choose the business owner, ask who feels the impact first, who can approve the time or money for a fix, and who can accept what is left on the company's behalf. The technical owner should hold administrator access, or manage the provider who does, and be able to run the test and explain the result plainly. Name a backup for each role so the entry still works when the usual person is away.

An owner is a named person, not "IT" or a company name. CSF 2.0 places responsibility and accountability for cybersecurity risk with organizational leadership. A provider can administer a system and carry out the fix, but someone inside the business should decide the priority and accept what remains.

The owner's job is a decision. IR 8286r1 names four ways to respond to a negative risk:

  • Accept it when it sits within your tolerance, and keep monitoring it.
  • Mitigate it with actions that make the problem less likely or limit the damage.
  • Transfer part of the consequences to another party, for example through cybersecurity insurance, knowing that some consequences, such as lost customer trust, often cannot be transferred.
  • Avoid it by making sure the risk cannot occur, which may be the best option when there is no cost-effective way to reduce it, and count the cost of the opportunity you give up.

Start with one service

Take shared email. List who administers it, what a serious outage or compromised account would interrupt, and who can make a decision when the usual administrator is away. Write down what you already have in place and where you would find the recovery instructions.

Pull the administrator list from the system rather than from memory. In the Microsoft 365 admin center, go to Roles, then Role assignments, select a role such as Global Administrator, and open its Assigned or Assigned admins tab to see who holds it. Microsoft's article on assigning admin roles also describes an Export admin list option that saves the full list of administrators as a .csv file.

In the Google Admin console, a super administrator can go to Menu, then Account, then Admin roles, click a role and then Admins. Google notes that this view shows direct assignments only, not people who receive a role through a group, so also check which groups hold admin roles and who belongs to them.

Compare what you find with who should have that access. Microsoft recommends as few Global Administrators as possible and the least permissive role that does the job, such as Password Administrator for someone who only resets passwords. It also recommends having at least one Privileged Authentication Administrator, because that role, like another Global Administrator, can reset the password of a Global Administrator who is locked out.

Google recommends more than one super administrator account, each managed by a separate person who also has a separate account for daily work. It also advises giving each administrator their own identifiable admin account, because when several people share one login, the audit log cannot show who made a change.

While the list is open, confirm that every administrator signs in with multifactor authentication. Microsoft says to require it for all users, especially administrators, and the quick-start guide calls enabling it one of the fastest, cheapest ways to protect your data.

If a provider administers the system, record which accounts and roles are the provider's, who there can act in an emergency, and how to reach them. In Microsoft 365, a provider that is a Microsoft partner can also hold delegated administration, and Microsoft describes the partner's Admin Agent role as nearly equivalent to a Global Administrator. Ask the provider what access it holds and count it with the rest. The quick-start guide's Recover section also asks you to understand who within and outside your business has recovery responsibilities.

Then pick one improvement you can check. That might mean reviewing administrator access, documenting an emergency contact, or rehearsing how to respond if a mailbox is compromised. Assign a person and a date. When the review comes around, ask whether the change worked and what risk is next. A short record of decisions makes it easier to explain why a control exists and keep it current when the team changes.

Turn one risk into a decision

Consider a shared payroll mailbox. Several people can read it, a provider can administer it, and only one person knows what to do if access is lost. The risk is specific: payroll could be delayed if that person is unavailable during an account problem. Assign a business owner who can set the priority and a technical owner who can test recovery. A single person can fill both roles on a small team, but document who covers for them.

Write the risk as a scenario someone could act on. IR 8286r1 advises using common phrasing and the same elements in every risk description, such as the threat, the asset, the method and the impact. "Email could get hacked" gives the owner nothing to decide. "If someone loses access to the payroll mailbox, or a member's account is taken over, while the one person who knows the recovery steps is away, payroll runs late" names the asset, the event and the cost, and it points toward the fix.

Write down what would prove progress

A useful entry can fit on one screen. Record the service, what could go wrong, the business impact, the decision owner, and when to review it. The notional register template in IR 8286r1 adds columns worth borrowing, which NIST names Priority, Risk Response Type, Risk Response Cost, Risk Response Description and Status. Priority can be a number such as 1, 2 or 3, or a scale such as high, moderate and low, and for a negative risk the response type is one of the four responses above. NIST posts a template spreadsheet alongside IR 8286r1.

Add the details you will need on a bad day: the technical owner, the named backup, where the recovery instructions are kept, and the next check with its date. Leave passwords and recovery codes out of the register. Record only where they live, such as the business password manager, and limit who can edit the register itself.

For the payroll example, the first check could be whether an authorized backup administrator can locate the recovery instructions and explain the first action. The next check might be whether the team can recognize and report an account problem promptly. Keep the notes where the people responsible can find them during an interruption. That record helps you decide what to tackle next without assuming every control matters equally.

A worked example

Imagine a ten-person accounting office on Microsoft 365. Payroll questions, timesheets and payroll-service notices arrive in a shared mailbox with four members. An outside IT provider administers Microsoft 365, and the office manager is the only person who has handled a lockout. The managing partner decides the risk is outside the firm's tolerance, because a late payroll affects everyone, and chooses to mitigate it.

The partner and the office manager write the entry together. It covers five points:

  • The risk is that lost access to the payroll mailbox, or a takeover of a member's account, delays payroll while the office manager is away.
  • The priority is high and the planned response is to mitigate.
  • The managing partner owns the decision, the office manager owns the work, and a staff accountant is the backup.
  • The first improvement is a one-page recovery sheet kept outside the mailbox, due in two weeks.
  • The first check is a short drill in which the staff accountant finds the sheet and explains the first step, with a review in 90 days.

Microsoft's shared mailbox guidance adds specific checks. People reach a shared mailbox through membership permissions, not a shared password. The mailbox also has its own user account with a system-generated password nobody is meant to use, and Microsoft says to block sign-in for that account and keep it blocked. Microsoft also notes that you cannot prevent members from deleting messages in a shared mailbox. The member list is the list of people who can read and delete payroll mail, so the review compares it with the four names the partner approved.

The drill finds a gap. The recovery sheet depends on the office manager's phone, which is the second sign-in factor on the only internal administrator account, and that becomes the next entry. Microsoft's guidance for this situation is to keep two or more emergency access accounts. These are cloud-only Global Administrator accounts reserved for emergencies and not tied to any one person, and Microsoft recommends protecting them with a passkey (FIDO2) and validating them at least every 90 days and after IT staff changes. The office asks its provider whether the firm has such accounts, who may use them and where their credentials are kept.

How to check that it worked

A change is done when someone other than the person who made it can show that it works. For the payroll entry, that means:

  • The backup finds the recovery instructions without help and explains the first action, using a device and account that do not depend on the affected mailbox.
  • The administrator list in the admin console matches the names in the register.
  • Staff know how to report a suspected account problem and can recognize common warning signs NIST lists, such as loss of usual access or multiple failed login attempts.
  • If the firm has emergency access accounts, an authorized person tells whoever monitors sign-in alerts, then signs in with one and completes an administrative task, as Microsoft's validation steps describe.
  • Someone records the date, what worked and what did not.

The quick-start guide asks whether you have practiced your incident response plan to see if it is feasible, and a walk-through of the payroll scenario is a practical first rehearsal. It also suggests naming a business champion who develops and maintains the plan, and keeping a contact list for the business leader, technical contact, state police, legal counsel, bank and insurer.

At each review, look for new risks the fix created. IR 8286r1's example is multifactor authentication, which reduces an access risk but can add a productivity risk when people struggle with the new method. If that matters to your team, give it its own entry and owner.

Common mistakes and how to spot them

A register can look complete and still fail when it is needed. Watch for these signs:

  • The owner column names a department or a company instead of a person.
  • Review dates have passed without anyone noticing. Sort the register by review date at the start of each meeting.
  • Owners or backups on the register have left the business or changed jobs.
  • The recovery instructions live inside the system they are meant to recover, such as a note stored in the mailbox nobody can reach.
  • Every row is marked high priority, so the register no longer helps anyone choose.
  • A response was chosen and never tracked. In CSF 2.0, choosing, prioritizing, planning, tracking and communicating risk responses are parts of one outcome.

What to do this week

You do not need a complete register to begin. This week:

  • Pick one service, such as shared email.
  • Pull the administrator list from the admin console and compare it with who should have access.
  • Name the business owner, the technical owner and the backup for that service.
  • Write one entry with the scenario, the impact, the owner, the planned response, the next check and the review date.
  • Store the recovery instructions where the backup can reach them if the service is down.
  • Put the first check and a quarterly review on the owners' calendars.

Where ALCO can help

ALCO USA Inc is an IT services company headquartered in Caldwell, Idaho, with technicians serving businesses across Idaho. Its services include cybersecurity and compliance, Microsoft 365, Google Workspace, IT consulting and vCIO, and backup and disaster recovery. The ALCO help desk is staffed 24 hours a day, including holidays, and calls are answered by a person. If you want help pulling administrator lists or running the first recovery check, those are practical places to start.

Sources