IAM for Growing Mid-Sized Companies
Most mid-sized companies already do half of what an access audit wants, they just don't write it down. Here's what auditors look for and the order I'd fix things in.
The question usually turns up in a security questionnaire from a big customer, or in the first audit: "Can you show who has access to what?" At a company of a few hundred people, quite often nobody can.
Most companies between 100 and 1,000 people already do half of this. Someone disables accounts when people leave. Someone keeps an eye on who has admin. But it isn't written down, it depends on who's around that week, and there's no record of it happening. A handful of habits, done in the right order, plus evidence that you kept them, gets you most of the way. SailPoint and a six-month project can wait.
You've probably outgrown the ad-hoc version if a few of these sound familiar. Nobody can list every app the company uses, let alone who's in each one. Access requests arrive as Slack or Teams messages, or a quick "can you add me?" at someone's desk. Leavers keep access for days or weeks, especially in SaaS apps that aren't behind SSO. People who changed teams still have their old access on top of the new. The same three people have global admin "just in case". And there are service accounts and API keys that nobody owns.
What auditors will ask you for
An auditor doesn't care which tool you use. They want evidence that you do what your policy says, and that you do it consistently. If it isn't recorded, as far as they're concerned it didn't happen.
Which framework you're measured against depends on who's asking, but the access parts overlap a lot.
Cyber Essentials comes up with UK government contracts and smaller customers. Since v3.3 came in on 27 April 2026, missing MFA on cloud services where it is available is an automatic fail. It also wants unique accounts, least privilege, leavers' accounts removed, and separate admin accounts that aren't used for email or browsing.
ISO 27001:2022 tends to come from European and enterprise customers. The access controls sit in Annex A: 5.15 (access control policy), 5.16 (identity lifecycle), 5.17 (authentication information, so passwords and MFA), 5.18 (granting, reviewing and removing access rights) and 8.2 (privileged access).
SOC 2 is what US customers and SaaS buyers ask for. The CC6 "logical access" criteria boil down to three things: access is approved before it's granted, removed promptly when people leave, and reviewed regularly.
Whatever the framework, the requests look similar:
- A written access control policy. Short is fine, as long as you follow it.
- A sample of new starters, with proof each one's access was approved before it was granted: a ticket, an email or a form.
- A sample of leavers, comparing their HR leaving date with when each account was disabled. A gap of a few days can get flagged if it is not in line with your internal policies.
- Access reviews: a dated export of who had access, plus a manager's sign-off.
- A list of admin accounts, who holds them and why.
An "approve all" review where nobody lost any access won't get past an auditor, and it doesn't stop attackers. With SOC 2 Type 2 timing matters as well: they check that you did these things throughout the audit period, so a burst of activity the week before won't cover it.
Where I'd start
I'd go in this order, because each step makes the next one easier.
- Make an inventory. List your apps, who owns each one, and whether it's connected to SSO. A spreadsheet is fine to start with. Without it, you can't review access, write a leaver checklist or answer the questionnaire.
- Put everything you can behind one identity provider with SSO: Entra ID, Okta, Google Workspace or similar. Then disabling one account blocks new sign-ins to most apps in one go, though you still need to revoke sessions and remove the accounts inside the apps. The apps that aren't connected are where leavers keep access, so the inventory should make those obvious.
- MFA everywhere. Start with admins and cloud apps, since that's the Cyber Essentials auto-fail, then push towards phishing-resistant methods like passkeys and FIDO2 keys.
- Joiners, movers and leavers. Make HR the trigger, because the HR system is your source of truth for who works here. Joiners get access based on their role, and leavers are disabled on their last day. Movers are the one people get wrong. If a move is handled like a joiner, people only ever gain access and never lose it, and that's how privilege creep builds up, so movers should lose their old access as well as gain the new. Automate what you can with SCIM provisioning, which is separate from SSO, and keep a manual checklist for the apps that don't support it.
- Simple roles. A few basic ones by department, like "everyone in Sales gets X, Y and Z". Ten good roles beat 200 messy ones.
- Access reviews: quarterly for sensitive apps and admin rights, every six months or yearly for everything else. Managers or app owners confirm or remove access, and you keep the evidence.
- Privileged access. Separate admin accounts, so nobody does admin work from the account they read email on. A handful of global admins, not a dozen. Just-in-time access where you can, for example with Entra PIM. And two break-glass accounts, locked away.
- Non-human accounts: service accounts, API keys and now AI agents. Give each one an owner and rotate its secrets. I went into the agent side of this in more detail in The Best AI for IAM Depends on Which AI You Mean
Write the policy once you've decided the process, and make it describe what you actually do. A policy that promises monthly reviews when you do them yearly gives the auditor an easy finding.
Don't try to do all of this before your first audit, either. An inventory, most apps behind SSO, a leaver process that works and one access review on record show clear progress.
Tooling you probably already pay for
I'd decide how joiners, movers, leavers and reviews should work before buying anything, then pick the tool that fits. If you're on Microsoft 365 E3, you already have Entra ID P1, which covers SSO, MFA and Conditional Access, and E5 adds Entra ID P2, which covers PIM and basic access reviews. Okta and Google Workspace are the other common starting points.
The next step up is the lighter governance tools aimed at mid-sized companies, such as Lumos, ConductorOne or Zluri. They connect to your SaaS apps for access requests and reviews without turning it into an enterprise IGA project. Enterprise identity governance like SailPoint or Saviynt is usually overkill until you're much bigger or heavily regulated. Compliance automation tools like Vanta and Drata help you collect audit evidence, but if leavers aren't being disabled on time, a dashboard will just show that more clearly.
Useful links



