So your company decided to pursue ISO 27001 certification. Maybe a big customer required it, maybe your board wanted it, or maybe someone read a LinkedIn post about it and now it's on the roadmap. Whatever the reason, you're here now, looking at Annex A and wondering how much of your life is about to be consumed by access control documentation.
The good news: the user access control requirements in ISO 27001 are achievable for mid-sized companies. The bad news: the way most people interpret them leads to over-engineering, over-spending, or both.
Let's break down what ISO 27001 actually asks for and how you can meet those requirements with the tools you already have (plus maybe a bit of automation help).
What ISO 27001 says about access control
The relevant controls live primarily in Annex A, section A.9 (in the 2013 version) or section A.5.15 through A.5.18 and A.8.2 through A.8.5 (in the 2022 version). The numbering changed but the spirit is the same.
Here's what it boils down to:
A.5.15 Access control policy. You need a documented policy that defines how access is granted, modified, and revoked. This doesn't need to be a 50-page document. A clear, practical policy that your team actually follows beats an elaborate one that sits in a drawer.
A.5.16 Identity management. Unique identifiers for every user. Shared accounts should be eliminated where possible. If they can't be eliminated, they need to be documented and justified.
A.5.17 Authentication information. Passwords (or other authentication factors) need to be managed properly. Strong password policies, MFA where appropriate, secure credential handling.
A.5.18 Access rights. Access should be granted based on business need (least privilege). It should be authorized by someone appropriate. And it should be reviewed periodically.
A.8.2 Privileged access rights. Admin accounts and elevated privileges get extra scrutiny. They should be tightly controlled, separately authenticated where possible, and monitored.
A.8.3 Restriction of access to information. Access to sensitive data should be restricted based on the access control policy you wrote in A.5.15.
A.8.5 Secure authentication. The systems you use should enforce your authentication policies. Think MFA, session timeouts, lockout after failed attempts.
The "enterprise tool" misconception
Here's where a lot of mid-market companies go sideways. They read these requirements, talk to a consultant, and get told they need a governance platform that costs six figures. The consultant isn't necessarily wrong that these tools can help, but they're often wrong that you need them.
ISO 27001 is a management system standard. It cares about whether you have effective processes and can demonstrate they work. It does not prescribe specific tools. Your auditor is looking for evidence that you:
- Have defined policies for access control
- Actually follow those policies
- Can prove it with documentation
You can technically satisfy every access control requirement in ISO 27001 with manual processes, spreadsheets, and good discipline. The question isn't "can you?" but "should you?"
What you really need vs. what gets sold to you
Let's map the requirements to practical solutions for a company running on Microsoft 365 and Entra ID.
Access control policy: Write it. Seriously, just write it. One to three pages covering how access is granted (manager request, HR-driven), how it's changed (same process), and how it's revoked (triggered by offboarding). Keep it simple, specific, and actually reflective of what you do.
Role-based access: Define roles that map to job functions. "Software Developer" gets access to the code repository, CI/CD pipeline, and development Azure resources. "Sales Representative" gets access to the CRM, sales SharePoint site, and presentation materials. Document these mappings.
Provisioning with approval: When someone needs access, there should be a request and an approval. For standard role-based access, this can be automated (new hire in Sales role automatically gets Sales access). For exceptions, have a simple request workflow.
Access reviews: Quarterly review of who has access to what. Managers confirm their team's access is still appropriate. Document the results. This is the control that auditors pay the most attention to.
Privileged access management: Know who has admin rights. Keep the list as small as possible. Use separate admin accounts if feasible. Review privileged access more frequently than standard access.
Logging and evidence: Keep records of access changes. When someone was granted access, who approved it, when access was revoked. Your audit trail.
Building this in Entra ID
Entra ID gives you a solid foundation for most of these controls:
Conditional Access policies handle authentication requirements: MFA enforcement, session controls, device compliance.
Security groups implement role-based access. Create groups that map to your defined roles and assign application access through those groups.
Entra ID audit logs capture access changes, sign-in events, and administrative actions. These logs are your evidence for the auditor.
Access reviews (in Entra ID Governance, requires P2 licensing) let you set up periodic review campaigns. Managers get prompted to review their team's access and confirm or deny.
Privileged Identity Management (PIM) handles just-in-time activation of privileged roles. Instead of permanent admin access, users activate the role when needed, with approval and time limits.
These are solid capabilities. But here's the catch: using them effectively requires configuring and maintaining them across your entire user population. For a small IT team managing 200+ users, the operational overhead of running native Entra ID governance tools can eat up more time than you'd expect.
Where lightweight automation fits
The gap between "we have the native tools" and "we're consistently using them to maintain compliance" is where most mid-market companies struggle.
You configure access reviews once, but someone needs to make sure they run on schedule, follow up with managers who don't respond, and remediate the findings. You define role-based groups, but someone needs to keep them updated as the organization evolves.
This is where a focused governance tool adds genuine value. Not by replacing what Entra ID can do, but by making it operationally sustainable for a small team:
- Automated provisioning that enforces your role definitions consistently
- Access review campaigns that run themselves and track responses
- Compliance dashboards that show your ISO 27001 control status at a glance
- Audit reports that give your auditor exactly what they need
The point isn't to buy technology for technology's sake. It's to make your ISO 27001 access controls repeatable and provable without consuming your IT team's entire capacity.
A realistic timeline
If you're starting from scratch, here's a rough approach:
Weeks 1 to 2: Write your access control policy and define your role-to-access mappings. Weeks 3 to 4: Implement the role-based groups in Entra ID and configure Conditional Access. Week 5: Set up your first access review cycle. Ongoing: Run quarterly reviews, maintain documentation, refine roles as needed.
That's achievable. No six-month implementation project. No army of consultants.
If this sounds like your situation, Adcyma is free for up to 25 users. For larger teams, you can start a free 14-day trial. No credit card, no consultants.