ISO 27001 access rights matrix with example
An access rights matrix shows who may use which systems, and why. It helps with the risk analysis, with how your information security management system (ISMS) works, and with conversations during an ISO 27001 audit. An identity provider (IdP) manages accounts and sign-ins. ISO/IEC 27001:2022 describes requirements for an ISMS. You define the actual roles yourself, fitted to your organisation (ISO ).
Use the matrix as a working document, not as a copy of Annex A. The standard does not prescribe a universal table of job titles. You decide what is proportionate, based on risk, job role and the access that is really needed. This page shows how to record that in practice, alongside your statement of applicability.
How to use the matrix
Put roles in the rows and information or systems in the columns. For each intersection, record a simple decision: no access, read, change or manage. Always add an owner, a reason, an approver and the date of the last check. You still need an individual list of users alongside it. A role on its own does not prove that the right person actually holds that role.
Fictional example: Rivierdata SaaS
Rivierdata has 32 employees and processes client data on a production platform. The product owner may read client tickets, but not access the production database directly. A database administrator has management rights, while a support employee works only through a restricted support view.
| Role | Production platform | Client data export | IdP management | Ticketing | Approval |
|---|---|---|---|---|---|
| Support employee | Read via restricted support view | None | None | Create/change | Support team lead |
| Product owner | Read | None | None | Read | Head of product |
| Developer | Temporary read, no change | None | None | Read | Engineering lead |
| Database administrator | Manage | Limited, ticket required | None | Read | IT manager |
| HR administrator | None | None | Read on leaving | None | HR manager |
| Security administrator | No content access | None | Manage | Read | CISO |
The “approval” column is not administrative decoration. It makes clear who accepts risk and who may grant an exception. Always give temporary development access an end date, and link the request to a ticket.
Joiners, movers and leavers
A matrix only works if it is linked to the employment cycle. That is why you should build three fixed triggers into your process.
Joiners. HR records the job and start date. The line manager chooses an existing role from the matrix. IT creates the account in the IdP and checks with the line manager that the assigned groups are correct. Keep the request and the first check as evidence.
Movers. When someone changes job, the new line manager assesses both the old and the new rights. Remove rights that are no longer needed straight away. A common mistake is adding new rights without removing the old role. This creates gradual privilege build-up.
Leavers. HR passes on the end date before the person leaves. The account block, revocation of tokens, transfer of files and any key change each have an owner. After the event, test in the IdP that a new sign-in is refused, and check in the application that existing sessions and tokens have been revoked separately. A log supports that test, but on its own it does not prove that future access is impossible.
A policy that says access is revoked “in good time” is not evidence that it works. Keep a real leaver notification, the time the block was applied and a check for remaining sessions.
Periodic review
Plan reviews based on risk. Critical management rights can be checked monthly or quarterly, while ordinary user roles might be checked every six months, for example. The ISO standard does not prescribe a fixed frequency for this matrix. Record the frequency you choose, the trigger and the person responsible, and adjust it after incidents, reorganisations or major system changes.
The reviewer compares the matrix with an export of active accounts and group memberships. For each deviation, the owner chooses: keep it with a reason, adjust it, or revoke it. A useful review report contains at least the sample, the deviations found, the action owner, the deadline and evidence of closure.
| Check | Question | Evidence |
|---|---|---|
| Accuracy | Does every user have the role that belongs to their job? | HR export and IdP export |
| Necessity | Is each sensitive access still needed? | Approval with reason |
| Temporariness | Have exceptions expired? | Ticket with end date |
| Execution | Are revoked rights really gone? | Block test, session check and IdP/application check |
Frequently asked questions
Must every employee be listed individually in the matrix?
No. Use roles for the design, and a current user-to-role export for implementation. This keeps the matrix readable, while you can still show individual access.
Is read access always low risk?
No. Read access to client data can be more sensitive than change rights in a test environment. Assess the impact of the information, not just the name of the permission.
How much detail does an auditor ask for?
The auditor wants to be able to follow how each decision was reached and whether access matches reality in practice. So show the matrix, a few approved requests, a review report and a sample of revoked accounts.