Account administration decisions that are cheap now and costly later

Administration is the part of a business platform that nobody evaluates during a trial and everybody lives with afterwards. The features get demoed. The admin console gets a five-minute tour. Then one person inherits it, and three years of small decisions harden into the thing that is too painful to change.

This page answers the questions that come up in that order: the ones people ask on day one, the ones they ask after the first incident, and the ones they wish they had asked before the team doubled.

What to take away

What should I set up before the first user logs in?

There is a short list of decisions that are cheap now and expensive later, because everything else gets built on top of them.

Give administration its own accounts. The person who administers the platform should have a normal working account and a separate administrative one. Day-to-day mail and browsing happen in the first; the second is used only to change settings. This single split limits the blast radius of a compromised session or a bad link, and it makes the audit log meaningful: every administrative action is attributable to a deliberate act rather than to someone's ordinary Tuesday.

Create a break-glass account and then leave it alone. One account that is not tied to any individual, not enrolled in the same second factor as everyone else, and not dependent on any single person's phone. Its credentials go somewhere physical and controlled. Test that it works, on a schedule, and record the test. Organizations lose access to their own tenant more often through a departed administrator or a lost device than through any attack.

Decide the naming convention now. Address format, display-name format, what happens with duplicates, what happens with contractors. You will not change it later without breaking things that reference the old form.

Turn on logging before you need it. Audit logs usually have a retention period, and the period frequently starts when logging is enabled, not when the account was created. Investigating an incident and discovering that the relevant window has already aged out is a common and entirely avoidable failure. Decide the period against what you might be asked rather than against what is tidy, which is the practical argument in the guidance on logging and monitoring.

Decide who can install and connect third-party applications. By default, many platforms let any user grant an external application access to their data. That is a genuine convenience and a genuine risk, and the default is a decision you are making whether or not you look at it. Deciding who may connect an external application is a team collaboration tools question as much as a security one.

Should permissions go to people or to groups?

Groups. Always groups, even when the group has one member.

Assigning access directly to individuals feels faster and produces a system nobody can audit. " is to open each item and read a list of names. And when someone leaves, their access is scattered across hundreds of individual grants rather than removed by taking them out of two groups.

Build groups around function, not around the current org chart. "Whoever handles supplier invoices" survives a reorganization. "The finance team as of last March" does not.

The practical test: can you describe every person's access by naming the groups they belong to? If you cannot, you have exceptions, and exceptions are what leak.

What does a good joiner, mover, leaver process look like?

Most administration pain is really lifecycle pain. Three events, and only one of them is usually handled well.

Joiner is the easy one, because someone is waiting and complaining. The thing to get right is that new access comes from a defined role, not from copying an existing person's account. Copying is how one over-privileged account quietly becomes twenty.

Mover is the one that is almost universally broken. When someone changes role, their new access is added and their old access is never removed. After a few internal moves, long-tenured people accumulate access to everything they have ever touched. Nobody notices, because nothing is ever denied. Treat a role change as a leave and a join: remove first, then add.

Leaver is the one with legal and practical consequences. Before you delete anything, work out:

Deleting the account is usually the last step, not the first. Suspending it (access revoked, data intact), buys time to answer all of the above.

Retention rules differ by country, and the answer rarely comes from the platform. In the United States there is no single federal retention period for business email; the constraint usually arrives as a litigation hold or a sector rule. The IRS generally asks employers to keep employment tax records for four years.

In Canada, the Personal Information Protection and Electronic Documents Act (PIPEDA) sets the federal baseline, and Quebec, Alberta and British Columbia add provincial rules. The Canada Revenue Agency generally asks businesses to keep records for six years from the end of the last tax year they relate to.

Neither country tells you how long to keep a departed employee's mailbox. Write that number down before anyone leaves, because a legal hold later overrides it.

How much administrative power should administrators have?

Less than the platform offers by default, and different amounts for different jobs.

Most platforms distinguish between full administrative control and narrower roles: someone who can reset passwords but not change security policy, someone who can read audit logs but not alter them, someone who manages billing but not data. Use them. The person who does daily user administration does not need the ability to change your authentication configuration.

Microsoft 365 names those roles Global Administrator, Helpdesk Administrator and Global Reader. Google Workspace names them Super Admin, Groups Administrator and Help Desk Admin.

Two rules that hold regardless of platform:

Review the administrator list on a schedule. Elevated access granted "temporarily" for a project is never revoked by anyone except a scheduled review.

What is the third-party application problem?

When a user connects an external tool to your platform, they grant it access on their own behalf: often to their mail, files, or calendar, sometimes to the whole organization's. The connection outlives their interest in the tool.

Pay attention to scope rather than to the vendor's reputation. An application that asks to read all mail in the organization is a different risk from one that asks to read a single calendar, no matter who makes it.

Both major suites let you restrict this. In Microsoft Entra the control sits under Enterprise applications, where user consent settings can be limited or switched off. In Google Workspace it sits under Security, in API controls, where app access control can be set to trusted apps only.

What should be tested, not assumed?

Administration is full of settings that look configured and are not functional. Test these:

Which admin controls do people wish they had set up first?

Asked after the fact, the answers are consistent:

None of these depend on which platform you chose. All of them are harder to introduce once there are people and content in the system.

How does this change as the organization grows?

The transitions are more abrupt than people expect.

Below the point where anyone specializes, administration is one person's side responsibility. The main risk is bus factor: one person knows everything and has documented none of it. The mitigation is not more process, it is a written record of decisions and a second person who can get in.

At the point where teams stop knowing each other, informal access control fails. You cannot rely on "ask before you share" once people cannot name everyone. This is the moment defaults and a sharing policy stop being bureaucracy and start being the only thing that works.

At the point where you have compliance obligations, retention, audit, and evidence become the constraints. This is when the decision to enable logging on day one either saves you or costs you.

The mistake is administering as though you are still at the previous stage. The mistake in the other direction, building a large organization's governance for a team of eight, is real, but it is far cheaper to fix.

What to ask a vendor about administration

During an evaluation, the admin console gets less scrutiny than it deserves. Ask:

That last question is the most revealing one. Every platform has a set of actions reserved to the vendor. Knowing which ones, before you depend on the platform, tells you where your control actually ends.

The published secure configuration baselines for cloud business applications are a reasonable starting point for deciding which of those settings you should be enforcing, independent of whose product you are running.

Where to read next

This layer sits underneath everything else on the estate, so its consequences show up elsewhere. The mail decision is where a missed leaver hurts first, and the hosting arrangement determines who holds the keys to the domain. The storage decision is where orphaned content accumulates, and the suite decision usually determines which directory you already own.

Common questions

How many administrators should a small organization have?

At least two, so that one person's absence is not an outage, and no more than the number of people who genuinely need to change settings. The number worth watching is how many hold the highest level of rights, which should be small, named, and reviewed twice a year.

Where should the break-glass credentials actually live?

Somewhere physical and controlled, such as a safe, with a written note of who may open it and under what circumstances. The point is that it does not depend on the platform you would be locked out of, or on any single person's device.

Do we need to review access if nothing has changed?

Yes, because things change without anyone deciding they have. Projects end, contractors finish, and people move teams without a formal move. A review that removes nothing is usually a review that was not really done.

What do we do about the application somebody connected two years ago?

Find out what it can reach and who owns it. If nobody can name an owner or a purpose, revoke it and see who complains. That is a blunt method and it is faster than any investigation, provided you do it on a Tuesday rather than a Friday.