An enterprise customer's security questionnaire wants to know how you grant and revoke accounts. A SOC 2 kickoff puts access controls at the top of the list. Someone finally pulls the user list and finds a contractor who finished up in March, still holding a login to the admin console. Around fifty people, these tend to land in the same quarter, and they are all the same question.
The instinct at that moment is to go shopping, and identity governance vendors are happy to meet you there. Most of them are built for companies ten times your size and will quote you accordingly. At fifty people that is the wrong first spend, because the controls that close the most risk and satisfy most of an access review are sitting in the identity provider already on your monthly bill.
What you are missing is the order to switch them on.
Why fifty is where this breaks
Under about twenty people, access control runs on memory and goodwill. You know everyone, you know roughly what they can reach, and when somebody leaves you can picture the four systems to shut off.
Past fifty, three things outrun that. Joiners, movers and leavers arrive monthly instead of quarterly. The number of places identity lives has quietly gone from six to forty, because every team bought its own tool and nobody was counting. And access is nobody's actual job, so it only ever gets added. Removal requires someone to notice, and noticing is not on anyone's Tuesday.
That is the failure mode an auditor goes looking for, and it has a name in both of the frameworks you are likely being measured against. SOC 2 covers it under CC6, the logical access criteria: how you grant access, how you take it away, whether least privilege is enforced, and whether you can produce evidence that a human reviewed any of it. NIST CSF 2.0 files the same ground under PR.AA, identity management, authentication and access control. Two vocabularies, one question. Who can reach what, and can you show your work.
Identity and access management is the discipline that answers it. At your size it is mostly sequencing.
The order
1. Get everything behind one identity provider
You cannot control access that is spread across forty separate app logins, and no amount of process fixes that. The first job is consolidation: get your applications authenticating against a single identity provider, which for most companies is the one already included in Google Workspace or Microsoft 365.
This is unglamorous and it is the step that makes every later step possible. Provisioning, deprovisioning, reviews and evidence all become tractable once identity lives in one place, and all of them stay miserable while it does not. It is also the same first move as a Zero Trust rollout, because identity is the first pillar of that model and this is the deeper cut on it.
Expect to find applications that will not integrate, usually the cheap tier of something a team bought on a credit card. Write those down. They become your exception list, and the exception list is a thing an auditor will ask to see.
2. Single sign-on, then phishing-resistant MFA
With one provider in place, turn on single sign-on for everything that supports it. Then enforce multi-factor authentication, starting with the accounts that would hurt most.
Make it phishing-resistant where you can. SMS codes and push prompts both fall to real-time relay attacks, and push fatigue is a well-worn way in. Hardware keys and passkeys do not have that weakness. NIST's digital identity guidelines are the reference if you want the reasoning at length.
While you are in there, switch off legacy sign-in protocols. Anything speaking basic auth skips MFA entirely, which makes the rest of this exercise decorative.
3. A handful of roles you can keep current
Role-based access done badly produces sixty bespoke roles that nobody has updated since the person who wrote them left. That is worse than no roles, because it looks like control on paper.
At fifty people you want a small set of role templates mapped to job function. A support engineer gets the helpdesk, the logging tool and read access to the staging database, and does not get production. A salesperson gets the CRM and the proposal tool. Least privilege is the default, and edge cases get handled as exceptions rather than as new permanent roles.
Resist modelling every situation. The roles you can actually maintain beat the roles that perfectly describe your org chart on the day you wrote them.
4. Write down joiner, mover, leaver
Three flows, written down before you automate anything.
Joiner: a new hire gets role-based access on day one, granted from their role rather than by copying whoever sits nearest to them. Access cloning is how permissions spread.
Mover: a role change removes the old access as well as adding the new. This is the one nearly everybody misses, and it is why the person who moved from support to sales two years ago can still read your ticket queue.
Leaver: access is revoked within hours, not at the end of the month, and the revocation leaves a record. Deprovisioning is the control small teams fail most often, and it is the one that leaves a departed contractor holding a login.
You can run all three from a checklist to begin with. What matters is that they exist and that someone owns them.
5. Access reviews that leave evidence
Quarterly, per application, reviewed by somebody who understands what the access is for. A manager who knows the job can spot the wrong permission. A spreadsheet of usernames reviewed by IT cannot.
What an auditor wants at the end is a timestamped record of who reviewed what, what they decided, and what changed as a result. If a review never removes anything and leaves nothing behind, it was a meeting.
Privileged accounts get their own pass, on their own cadence. More on those in a moment.
Where a spreadsheet is fine, and where it stops being fine
At fifty people, a well-run spreadsheet plus native provisioning in your identity provider will genuinely get you through a first SOC 2. Auditors test whether the control operated, not whether you bought software to operate it. Compliance-automation vendors tend to leave that sentence out of their guides, for reasons that are not hard to work out.
The claim is "not yet" rather than "never," and the moment it changes is specific enough to plan for. Automation starts earning its cost when collecting the evidence becomes the bottleneck rather than the control itself. In practice that shows up as a few things at once: the app count passes what one person can review in a sitting, joiner and leaver volume turns provisioning into a part-time job, and review frequency climbs because you are now maintaining two frameworks instead of one. When your quarterly review takes a week of someone's time and still produces gaps, SCIM auto-provisioning and a governance layer are worth the money.
Buying that platform at fifty people, before the flows are written down, mostly automates a process you have not defined yet. The spreadsheet at least forces you to define it.
Privileged access is a smaller, sharper problem
Your production and cloud-admin access is not the same problem as everyday app access, and it should not share a process with it.
It is a much smaller set of accounts and a much larger blast radius, which makes it worth treating separately. Standing administrator rights are what an attacker is hoping to land on, so the goal is that almost nobody holds them all the time. Separate admin identities from daily-driver accounts, put your hardest authentication in front of them, and grant elevation for a window rather than permanently where your tooling allows it. Review them on their own schedule, more often than the quarterly pass.
Canada's Cyber Centre has guidance on managing administrative privileges that covers this in a few pages, and it holds up as a checklist regardless of where you operate.
Where to start honestly
Before you buy an identity platform, and before you start flipping switches, it is worth knowing where you actually stand.
"We have SSO" is not the same as knowing that every application is behind it, that your exception list is written down, that movers lose their old access, that your last access review produced a record someone could read back to you. Those are specific, checkable things, and they map almost one to one onto CC6 and PR.AA. Most teams find the gap is not where they assumed.
We are building SOCLedger for the part that comes after: continuous SOC 2 and ISO 27001 evidence collection, so the access reviews you run leave an audit trail without anyone assembling it by hand at quarter end. It connects to the identity provider and the systems you already run, and the ledger fills itself. Public beta lands in Q4 2026, the waitlist is open now, and waitlist members get early access with founder pricing held for good.
If you would rather have someone sequence the rollout with you and sit through the first access review, that is what our team is for.