Describe the permission, not just the job title

A role can group permissions for people doing similar work, but the role’s name does not demonstrate that its permissions remain appropriate. Write the allowed action against the resource: for example, preparing an invoice is different from approving its payment or administering the application.

Authentication establishes a sign-in; authorisation determines permitted actions. MFA does not answer whether an authenticated user has excessive access. Treat access design as its own business and technical decision.

Validate and revisit business need

ACSC guidance addresses both ordinary and privileged access in relation to duties. Privileged access enables sensitive administration and deserves deliberate attention, but ordinary access can also expose information or allow important changes. Guidelines for system access

Ask an accountable business owner to validate the need and an appropriate technical owner to explain the effective permissions. Review the result when duties or systems change. A review should examine what the account can do, not merely confirm that the employee still works there.

Make exceptions explicit

Separation of duties divides responsibilities that should not be concentrated without consideration. A small team may face constraints; that is a reason to document the decision and suitable oversight rather than pretend conflicting duties have disappeared. NIST’s AC-5 and AC-6 provide relevant control concepts. Security and Privacy Controls for Information Systems and Organizations

For an exception, record its purpose, scope, authorising owner and review or expiry condition. Emergency access also needs a planned arrangement. Do not remove it blindly in an attempt to make a permission list look tidier. These are design decisions for the organisation and its identity specialists.

An invented invoice workflow

A business defines three responsibilities: preparing an invoice, approving it and administering the system. Its proposed access matrix lists the actions each responsibility needs. Where staffing means a person must perform more than one function, the decision is recorded for review by the business owner.

This example does not establish an adequate financial control or prescribe one universal role model. It shows how to make permissions and exceptions discussable.

An access-design checklist

  • Name the resource, action and business justification.
  • Identify the approving owner and technical implementer.
  • Examine ordinary and administrative permissions.
  • Include application or service identities where relevant.
  • Record exceptions and when they must be reconsidered.
  • Check the effective outcome after an authorised change.

A service account represents an application or process, so its ownership and purpose need attention even when no employee uses it as an everyday login.

Optional depth: check the application result

In Microsoft Entra ID, an application can manage its own session. A directory action alone must not be described as instantly ending all application access. The actual revocation and verification process depends on the integration and application behaviour. Revoke user access in Microsoft Entra ID

Use an IAM or security architect to assess effective access, non-human identities and emergency arrangements. A control catalogue is material for selection and tailoring; referring to it does not establish compliance or certification.

  • Employee onboarding, role changes and offboarding — Apply access decisions to joining, moving and leaving.
  • MFA and passkeys — Distinguish authentication from authorisation.
  • What an integration involves: data, permissions and failure recovery — Understand integration identities and permissions.