Blogs

From policy to permissions

ISO 27001 access control is not just about who can log in. It is about defining clear roles and permissions so every person, admin, and system has only the access they need to do their job, nothing more.

In practice, that means translating Annex A expectations into a usable access model across identities, cloud platforms, and admin tools. Auditors want to see that model reflected in your real systems, not just documented in a policy.

What this means for audits

For Australian organisations preparing for certification, access control becomes a practical design task. You need to show who can do what, where they can do it, and how access is granted, reviewed, and removed.

If roles are messy, over-privileged, or undocumented, auditors usually treat that as an access control weakness rather than a technical detail. Clean role design makes both audit evidence and day-to-day security much easier.

Why teams care

A strong access control design reduces the risk of privileged misuse, shared accounts, and accidental overreach. It also gives security and compliance teams a structure they can actually evidence during an ISO 27001 audit.

That is why this blog focuses on real roles and permissions in Azure AD, Okta, AWS, Azure, GCP, Google Workspace, and Microsoft 365. The goal is to make Annex A practical, not theoretical.

Annex A coverage

In ISO 27001:2022, access control is no longer just one control. It is spread across multiple Annex A controls that cover access policy, identity and authentication, privileged access, user access provisioning, and secure access to systems and services.

Practical meaning

The practical takeaway is simple. Annex A expects you to control access in a structured way across the full identity lifecycle, not only at the login screen.

That means defining who gets access, how it is approved, how it is reviewed, and how it is removed.

What auditors look for

For teams preparing for an ISO 27001 audit, this matters because auditors usually look for the connection between written policy and actual permissions in tools like Azure AD, Okta, AWS IAM, Google Workspace, and Microsoft 365.

Least privilege

Give users, admins, and service accounts the minimum access required to do their work. This reduces the blast radius if an account is compromised or misused.

Need to know

Access should be limited to the systems, records, and functions a person actually needs. This is especially important for sensitive data, finance systems, and security tools.

Separation of duties

Do not let one person control every step of a sensitive process. Split approval, execution, and review where possible so no single account can complete and hide risky actions alone.

Joiner mover leaver

Access should be granted, changed, and removed through a controlled process. A clean JML workflow helps you prove that permissions follow employment changes and role changes over time.

Azure AD

Use group-based access instead of assigning permissions one user at a time. This makes roles easier to review, reduces drift, and gives you a clearer audit trail.

Keep global admin membership extremely limited and separate helpdesk, security, and application administration into distinct roles. That structure is easier to justify under least privilege and separation of duties.

Okta

Build custom admin roles instead of giving broad super-admin access. Assign permissions around support, directory, application, or security tasks so the access model matches real duties.

Use JIT or controlled approval processes where possible, especially for elevated access. This supports temporary access use cases without leaving standing privilege in place.

Good design pattern

A practical identity model usually looks like this: users have standard access, approvers have limited approval authority, helpdesk can reset accounts but not assign broad privileges, and security admins manage high-risk settings.

AWS, Azure, and GCP

Use least-privilege IAM roles for workloads, engineers, and automation accounts. Separate read, write, admin, and billing functions so access does not accumulate into broad cloud superuser permissions.

Keep role scope narrow and prefer environment-specific access for production, staging, and development. That makes it easier to prove that sensitive production access is tightly controlled.

Google Workspace and Microsoft 365

Limit super admins to a very small set of trusted personnel. Use delegated admin roles for support and operational tasks so every elevated action is tied to a defined responsibility.

This reduces the risk of a single account being able to control identity, email, sharing, and security settings all at once. It also gives auditors a cleaner story about privilege separation.

Design pattern to follow

A good cloud and productivity stack usually follows the same pattern: business users get standard access, platform engineers get scoped admin rights, security teams get monitoring and policy access, and finance or billing access stays separate from technical administration.

Why this helps

A matrix makes it easy to spot excessive access, missing approvals, and shared responsibilities that should be split. It also gives auditors a single artifact that connects policy to actual permissions.

What to keep in the matrix

Include the role name, system name, allowed actions, approval owner, review frequency, and any time-bound access conditions. That level of detail is usually enough to support both governance and audit evidence.

Too many global admins

One of the fastest ways to create audit problems is giving broad admin access to too many people. Auditors often see that as weak privilege control and poor separation of duties.

Shared accounts

Shared logins break accountability because you cannot prove who did what. They also make access reviews and incident investigations much harder than they need to be.

No regular reviews

If access is granted but never recertified, roles drift away from current job needs. That often leads to findings because the organisation cannot show that permissions are still appropriate.

Weak JML process

If joiner mover leaver steps are informal, access changes can be delayed or missed entirely. Auditors usually expect a repeatable workflow with approvals, timestamps, and evidence.

Access control policy

Auditors want to see a written policy that explains how access is requested, approved, granted, reviewed, and revoked. The policy should clearly match the way your team handles real access decisions.

Role and permission matrix

They usually ask for a matrix that shows who can do what in each system. This helps them confirm that access is controlled by role, not by informal exceptions or one-off approvals.

Access review evidence

Regular recertification is important because it proves permissions are still appropriate. Evidence should show who reviewed access, when the review happened, and what changes were made afterward.

JML records

Joiner mover leaver records matter because they show access was given and removed through a defined process. Auditors often use these records to test whether the organisation actually enforces access control or just describes it.

Practical support

CyberSapiens helps organisations translate ISO 27001 access control requirements into real roles, permissions, and reviewable workflows. That includes identity platforms, cloud IAM, and admin role design.

Audit-ready outcomes

The goal is to reduce over-privileged access, improve joiner mover leaver control, and make evidence easier to collect during an ISO 27001 audit. This usually results in fewer access-related nonconformities.

Where we help most

We are especially useful when access control spans Azure AD, Okta, AWS, Azure, GCP, Google Workspace, and Microsoft 365 at the same time. That is where role clarity and evidence usually break down first.

What is access control in ISO 27001?

It is the set of policies, roles, and technical controls that decide who can access which systems, data, and admin functions. In practice, it is about defining permissions clearly and proving they are granted and reviewed properly.

How do you design roles and permissions for ISO 27001?

Start by mapping job functions to systems and then assign the minimum access needed for each function. After that, add approvals, access reviews, and joiner mover leaver controls so the model stays current.

What do auditors check for access control?

They usually check the policy, role matrix, approval records, periodic access reviews, and evidence that access was removed when people changed roles or left. They also test whether privileged access is kept tight and justified.

Ketki Tidke

Cyber Security and GRC Lead Auditor
ISO 27001 Lead Auditor

Ketki is a certified ISO 27001 Lead Auditor specialised in Governance, Risk and Compliance, with experience consulting public, private, and government clients. She evaluates threats, risk impacts, and regulatory requirements across multiple industry frameworks.