TL;DR

• The core risk for companies without an IT team isn’t weak security settings, it’s that operational knowledge exists in one person’s head and nowhere else (the “bus factor” problem).

• The minimum viable documentation set is five documents: an admin/super-admin inventory, an app registry with owners and billing contacts, an access policy by role, an offboarding runbook, and break-glass recovery procedures.

• Storing this documentation only inside the Google Workspace it describes creates a circular trap: if you’re locked out of Workspace, you’re also locked out of the instructions for getting back in.

• Documentation stays current when updates are tied to events that already happen (a new hire, a canceled subscription, an offboarding) rather than a recurring calendar reminder nobody honors.

• Some of this can be kept current automatically by the right platform; the judgment calls, like who is allowed to authorize emergency access, still have to be written by a human.

About the Author: ShiftControl is built by former ExpressVPN operators who managed IT for a company that grew from 100 to over 700 employees across seven offices, and now build software specifically for Google Workspace companies that don’t have (and don’t want to hire) a dedicated IT team.

What Is the “Bus Factor” Problem in IT, and Why Does It Hit Small Companies Hardest?

The bus factor is the number of people who could disappear from a project before it stalls completely. In a lot of small Google Workspace companies, the answer for IT is one: usually a founder, COO, or an early ops hire who set up the Workspace, added every app, and has been quietly maintaining it since.

That works fine until it doesn’t. The founder goes on leave. The ops lead takes another job with two weeks’ notice. Someone gets sick for a month. None of these are edge cases; they’re the normal texture of running a company. The problem is that when IT knowledge exists in one person’s head alone, the company’s operational continuity depends on that person’s availability, not on any system.

This shows up as concrete, specific failures:

• Nobody else knows the super-admin account exists, let alone how to access it.

• A vendor invoice comes due and nobody knows who owns that relationship or whether the tool is even still in use.

• An employee leaves and their access to a dozen apps stays live because only one person knew they had it in the first place.

• The company gets locked out of an account and there’s no documented recovery path, just someone’s memory of “I think I set up backup codes somewhere.”

None of these require a cyberattack to become painful. They’re everyday operational risk, and they compound quietly until the day someone needs the information and it isn’t there.

What Should a Small Business Actually Document First?

Before writing anything, it helps to separate documentation from security policy. A security checklist tells you what settings should be turned on. Documentation tells you what currently exists and who’s responsible for it. This article is about the second one: the minimum viable record that lets someone other than you keep the company running.

Five documents cover the core of it. None of them need to be elaborate. A shared doc with clear ownership beats a polished wiki nobody updates.

1. Admin and Super-Admin Inventory

This is a plain list: every account with admin or super-admin rights in your Google Workspace admin console, what level of access each one has, and why. Super-admin access is the master key to your entire Workspace, so it should never live in more heads than necessary, but it also can’t live in exactly one head with no record.

At minimum, log:

• Who holds super-admin rights, and the business reason

• Who holds delegated admin roles (e.g., user management only, no billing)

• When each admin role was granted and by whom

• The recovery email and phone number tied to each admin account

2. App Registry With Owner and Billing Contact

Most small companies accumulate SaaS tools the way a junk drawer accumulates batteries: one at a time, for a specific reason, without anyone tracking the total. SaaS sprawl is common in small organizations, with many tools adopted without formal IT oversight, which is the working definition of shadow IT. Left unmanaged, that sprawl and the excess permissions that come with it are now a leading vector behind SaaS-targeted breaches.

An app registry doesn’t need to be exhaustive to be useful. It needs, for every tool that touches company data:

• The internal owner (the person who’d know if it broke or should be canceled)

• The billing contact and renewal date

• Whether it connects to Google Workspace via SSO, SCIM, or OAuth permissions

• Whether it’s still actively used

This single document does double duty: it’s your it asset inventory template and the starting point for real saas spend management, because you can’t manage spend on tools you haven’t listed.

3. Access Policy by Role

This is the rulebook, not the current state. It answers: when someone joins as a sales rep, what should they get access to on day one? When someone moves from marketing to product, what changes? Access control documentation like this turns “who has access to what” from a memory exercise into a lookup.

A simple table works better than prose here:

Once this exists, provisioning a new hire stops being a judgment call and becomes a checklist. It’s also what makes an offboarding runbook actually work, because you can’t reliably revoke access you never documented granting.

4. Offboarding Runbook

An employee offboarding checklist is one of the highest-leverage documents a small company can write, because the cost of getting it wrong is direct: a former employee retaining access to email, shared drives, or a customer database. The runbook should list, in order, every system that needs access revoked, who’s responsible for each step, and how to confirm it’s done, not just started.

At minimum it should cover:

• Google Workspace account suspension and data transfer

• Removal from every third-party app tied to their role (per the access policy above)

• Password manager credential rotation for shared logins they had access to

• Physical asset return and device wipe, if applicable

5. Break-Glass Recovery Procedures

This is the document most companies skip, and it’s the one that matters most in a genuine crisis. Break-glass procedures cover what happens when normal access breaks down entirely: the super-admin is unreachable, an account is locked out, or MFA devices are lost.

It should specify, in writing, before you need it:

• Where recovery codes are stored (not in the inbox of the account they’d recover)

• Who is authorized to invoke emergency access, and under what conditions

• The exact steps to regain super-admin control of Google Workspace

• Who to call first if this is the result of a security incident, not just a lockout

This last point connects to incident response. A written incident response plan template doesn’t need to be a 40-page document. It needs a clear first move: who gets called, what gets isolated, and what evidence gets preserved, because the first hour after discovering a compromised account shapes everything that follows.

Where Should This Documentation Actually Live?

Building on the five documents above, the harder question is where to put them, and this is where a lot of well-intentioned documentation quietly fails. The instinct is to store everything in Google Drive, inside the same Workspace it describes. That creates a circular problem: if the Workspace is locked, compromised, or the super-admin account is the thing that’s inaccessible, the document explaining how to fix that is unreachable too.

The same logic applies to an it security policy template or any written policy: if it lives exclusively inside the system it governs, it’s not a backup plan, it’s a single point of failure wearing a different hat.

A workable structure separates “day to day reference” from “break-glass access”:

• Day-to-day documents (app registry, access policy, offboarding runbook) can live in Drive or in dedicated it documentation tools, since these are things you’ll reference and update regularly and don’t need during an actual lockout.

• Break-glass material (super-admin recovery codes, emergency contact list, the recovery procedure itself) needs to live somewhere reachable independent of Workspace: a password manager with offline access, a physical printed copy in a locked drawer, or a separate cloud account entirely.

This mirrors how the compliance frameworks Google Workspace itself operates under actually work. Google Workspace is SOC 2 compliant and ISO-aligned, but under the shared responsibility model, the organization using Workspace is still responsible for documenting and managing its own access controls and configurations. Google securing its infrastructure doesn’t cover your company writing down who has admin rights and where the recovery codes live. That responsibility doesn’t transfer.

How Do You Keep Documentation Current Without It Becoming a Second Job?

The honest failure mode for most documentation is that it gets written once, during a burst of good intentions, and goes stale within a quarter. Nobody has the bandwidth to schedule a monthly “review the docs” meeting and actually keep it.

The fix is to stop treating updates as a separate task and instead attach them to events that already happen:

• A new tool gets purchased → add it to the app registry the same day, with owner and billing contact, before the login is even shared around.

• Someone joins the team → their access gets granted according to the role policy, which either confirms the policy is right or immediately surfaces where it’s outdated.

• Someone leaves → the offboarding runbook gets executed and, in the same sitting, reviewed for anything it missed.

• An admin role changes → the admin inventory gets updated as part of granting or revoking that access, not as an afterthought.

This is the same logic behind why an app registry matters for shadow it discovery tools: catching new tools at the point of purchase is far cheaper than doing a company-wide audit twice a year to find what quietly crept in.

What Can a Platform Keep Current Automatically, and What Still Needs a Human?

Some of this genuinely doesn’t need manual upkeep. A platform connected to your Google Workspace admin console and your HR system can maintain a live, accurate picture of who has access to what, because it’s watching the actual state of the system rather than relying on someone remembering to update a spreadsheet. This is the specific gap ShiftControl was built to close: it syncs with HRIS platforms like HiBob, BambooHR, and Gusto to automate provisioning and de-provisioning, and it gives visibility into which third-party apps have OAuth access to your Workspace data, including the shadow IT that shows up outside any formal purchase process. Setup takes about 10 minutes through a single Google Workspace login, without a lengthy new implementation project.

That covers the access policy and app registry categories almost entirely. It does not cover the judgment calls that make break-glass procedures work: who is trusted to authorize emergency access during a crisis, what the escalation order is, and what the company considers an acceptable risk to take under pressure. Those decisions have to be made and written down by a person, because they reflect the company’s actual risk tolerance, not just its current system state.

For the incident response side specifically, ShiftControl includes IR-1 through a partnership with Blackpanda as part of the subscription itself, rather than as a costly add-on tier. That means the “who do we call” step in a break-glass document has a concrete, already-in-place answer: 24/7 access to incident responders, one annual incident response credit for the full organization, and support with containment and initial investigation. Ransomware poses significant risk to small businesses, making a documented incident response plan worth having settled in advance.

Frequently Asked Questions

What is a bus factor in IT, and how do I calculate mine?

The bus factor is the number of people who’d need to be unavailable before critical knowledge or systems become inaccessible to the rest of the company. For most small Workspace companies, it’s one: whoever holds super-admin rights and remembers how everything was configured. You calculate it by asking, honestly, who else could get into the admin console and act correctly under pressure today.

Do I need a full IT runbook template, or can I start smaller?

Start smaller. A single shared document covering the five items in this article (admin inventory, app registry, access policy, offboarding runbook, break-glass procedures) is a functional it runbook template on its own. Expand it once those five are solid.

How is documentation different from an IT security policy?

A security policy states rules you intend to enforce, like requiring MFA. Documentation records the current state of your systems and who’s responsible for them. You need both, but this article is specifically about the second, since it’s the part most companies skip.

Where should password and recovery code documentation live?

Not inside the Google Workspace they’d help you recover. Use a dedicated password manager with offline or emergency access, or a physically secured backup, so the recovery path survives a Workspace-level lockout.

How often should I update this documentation?

Tie updates to events, not a calendar: new hires, tool purchases, departures, and admin role changes. This keeps the documents accurate without adding a standing task nobody prioritizes.

Can software replace this documentation entirely?

Partially. A platform connected to your Workspace and HR system can keep access records and app inventories current automatically. It can’t make the human judgment calls, like who’s authorized to approve emergency access, so those still need to be written down deliberately.

What’s the very first thing I should document this week?

The admin and super-admin inventory, and the break-glass recovery procedure. Both are short to write, and both are the documents you’d miss most urgently if you were suddenly unavailable.

About ShiftControl

ShiftControl is IT operations software purpose-built for Google Workspace, built for operators rather than IT teams. It gives small and growing companies provisioning and access management, SaaS spend visibility, app-permission visibility, and incident response from one platform instead of four separate tools and a spreadsheet, with setup in about 10 minutes through a single Google Workspace login. It was founded by former ExpressVPN operators who scaled that company’s IT function from 100 to over 700 employees across seven offices, and it includes cyber incident response through Blackpanda as a standard part of the subscription. ShiftControl publishes transparent pricing, with a standard per-user rate and a separate discounted tier for startups.

If your company’s IT knowledge currently lives in one person’s head, the fastest fix isn’t a new tool, it’s an afternoon spent writing the admin inventory and the offboarding runbook. Start there this week. When you’re ready to see how much of the rest can run itself, take a look at ShiftControl.