Single points of failure in a small company: systems, people, vendors

Systems

A single point of failure is anything whose loss stops work with no fallback. In a small company they come in three kinds, and the three are tangled together. Start with systems, because they are the easiest to spot.

The obvious ones are the internet connection, the one server in a closet, and the main business application. The less obvious ones are admin accounts. If one person holds the only Global Administrator role in Microsoft 365, the whole tenant depends on them: when they are out, nobody can reset a locked admin, change a license, or add a user. Microsoft advises keeping Global Administrators to fewer than five people and keeping emergency access accounts for lockouts. One named admin is not enough.

• Admin roles held by exactly one person.
• Apps and portals that only one person can sign in to.
• Groups, teams, and sites with a single owner.
• Domain, DNS, and certificate renewals tied to one person's email.

People

People are the hardest to see because the dependency is knowledge, not access. The one person who knows how to close the month, quote a custom job, or fix the label printer. Nothing in any system says they are the only one; the rest of the team just knows to ask them.

The test is simple: if this person were unreachable for two weeks starting tomorrow, what would stop? Ask it about every seat, including the owner's. The answers are usually longest for the longest-tenured people, and longest of all for the owner.

Vendors

A vendor becomes a single point of failure in two ways. The firm depends on one supplier with no alternative, or the firm depends on one employee as the only contact the supplier knows. The first is a purchasing question. The second is a continuity question, and it is far more common. A supplier who only has one email address for you will keep writing to it after that person leaves.

How to see all three in Microsoft 365

Microsoft 365 already holds most of the evidence, and none of it requires reading anyone's messages. Directory data shows who holds admin roles and who owns groups, teams, and connected SharePoint sites. Enterprise app assignments show who can sign in to which connected apps. Mail metadata, meaning sender, recipients, and dates, shows which employees exchange mail with which outside domains, so you can see when a vendor only ever writes to one person. Calendar metadata shows who organizes the recurring meetings that keep processes running.

There are limits. For shared mailboxes, sending history is easy to see from metadata, but the list of who holds permissions is not always visible to outside tools. Last sign-in dates need a Microsoft Entra ID P1 or P2 license. Treat anything you cannot see as unknown rather than covered, and ask the people involved to fill the gap.