ISO 27001 A.8.3: enforcing information access restriction

The due-diligence questionnaire asks who can open your finance drive. Your access policy says finance staff only, but the sharing settings say otherwise, and the deal is waiting.

This guide covers ISO 27001 A.8.3, the control that makes your systems obey the access rules your policy writes down. It is for security managers, IT heads and CTOs at 25–250 person firms. You must prove enforcement in configuration, then keep it proven without a dedicated access team.

What does ISO 27001 Annex A information access restriction require?

ISO 27001 Annex A information access restriction (A.8.3) requires your systems to enforce the access rules your policy writes down. Permissions in apps, databases and cloud platforms must give nobody anonymous or unknown access. Each user sees only what their role justifies, read is kept apart from change and delete, and sensitive systems are walled off.

A.8.3 is a preventive technological control. Enforcement in the system stops the unauthorised read or write before it happens, rather than detecting it afterwards. It protects confidentiality, integrity and availability at once. Permissions decide who sees data, who changes or deletes it, and who can break the systems serving it.

Do not confuse it with ISO 27001 clause 8.3, which belongs to the management-system requirements on risk treatment. The two share a number and nothing else. The 2013 edition also numbered its access controls differently, so check any older mapping before you reuse it.

For the highest-value information, the control points towards context-aware techniques. Access decisions weigh who is asking, from which device, from where and for how long. Some techniques can even follow a document after it leaves your environment.

Your classification scheme sets the restriction levels. Without it, "restricted" has no agreed meaning. Auditors test the control alongside the joiner-mover-leaver lifecycle in A.5.18 and the admin-tier rules in A.8.2, so expect questions to cross those boundaries.

How does A.5.15 relate to A.8.3, and why do auditors test them as a pair?

A.5.15 writes the access rules; A.8.3 proves systems obey them. Auditors test the two as a pair, tracing a policy statement into live group memberships and permissions. A firm can pass the paper and fail the configuration, and in practice it is the technical enforcement in A.8.3 that fails.

That outcome is the norm at 25–250 people, because permissions pile up. Everyone is added to the shared workspace and the all-staff group gets edit rights. A departed contractor's account stays active, and nobody's job is to notice. The NCSC Identity and Access Management Guidance lists least privilege among the aspects of identity to get right, limiting the access or functionality different users have. Unchecked growth in permissions undoes exactly that.

Enterprise buyers know this. A policy PDF costs nothing to produce, so their due-diligence teams ask for completed access reviews and permission exports. Those are much harder to fake.

The failure mode has a name: policy-to-configuration drift. The access-control document describes an ideal world while the systems gather years of ad-hoc grants that nobody checks. When a breach happens, "the policy said the right thing" is no defence, because regulators and claimants look at what the systems allowed.

Drift compounds quietly. Each grant is small and reasonable on the day it is made. A year later, the finance drive has a long tail of readers that nobody can explain. The policy usually belongs to whoever owns governance and the configuration belongs to IT, so the seam between those two owners is where drift lives.

How do you build a role-to-permission matrix and enforce it through IdP groups?

Build a role-to-access matrix listing each role, the systems and data classes it touches, and the level of access: view, edit, delete or admin. Ten to fifteen roles covers most firms at this scale. Then enforce it through identity provider groups, never individual grants, so a person gets a role and the role carries the permissions.

The matrix is the artefact that ties the written policy to the technical configuration, and the first thing to show an auditor. Each row is a role such as support agent, finance analyst or engineering lead. Each column is a system or data class from your classification scheme, and each cell holds one of the four access levels. Resist one row per person: if the matrix needs many more than fifteen rows, it is describing people rather than jobs.

Least privilege is the design rule behind every cell. The NIST SP 800-53 Rev. 5 Glossary on Least Privilege defines it as granting each entity only the minimum system resources and authorisations needed to perform its function.

Enforcement through Entra ID or Okta follows four moves:

1. Create one group per role. Name the groups after the matrix rows so a reviewer can read one against the other.
2. Map groups to permissions in each system. Applications, databases and cloud platforms take their access from the group, not from the person.
3. Remove direct grants. Export per-user permissions, reconcile them against the matrix, and either delete each exception or place it in a group. Direct grants are how permission sprawl and privilege creep start.
4. Assign by role when people join or move. A person gets a role, and the role carries the permissions.

Shared team logins are the other route to sprawl. Teams adopt them to save SaaS licences, and the saving costs the individual accountability that every investigation depends on.

A shared account is a decision not to know who did it.

Where a system cannot support individual identities, document the shared account on the risk register with an owner and a review date. Auditors then see a managed exception rather than a discovery.

How do you close anonymous access paths without buying a DLP suite?

Close anonymous routes by hunting open shares, 'anyone with the link' documents, unauthenticated storage buckets and guest access in collaboration tools. Public access suits only genuinely public material. For sensitive data, use the conditional-access features your identity provider already includes, such as compliant-device rules and blocked legacy protocols. You rarely need a DLP platform.

Sweep four places first:

• Collaboration shares. Run the external-sharing report and list every 'anyone with the link' document.
• Cloud storage. Review bucket and container policies for public read, and switch on account-level public-access blocks where your provider offers them.
• API endpoints. Check which endpoints answer without authentication, and whether each one is meant to.
• Guest access. List guest and external accounts in collaboration tools, with an owner and an expiry for each.

'Anyone with the link' as the default sharing model turns your document store into an unauthenticated data store. Change the tenant default first, then handle the exceptions one by one. Then test from outside: open a private browser window with no sign-in and try each sensitive link. If a document opens, the control has failed whatever the policy says.

Dynamic access management at this scale means switching on the policies your identity provider already includes, licence tier permitting. Require a compliant device for sensitive applications and step up authentication for unusual locations. Block legacy protocols too, since they cannot perform step-up authentication and so sidestep every condition you set.

Let classification set the bar: the more sensitive the data, the tighter the audience and the stronger the conditions. Isolate the crown-jewel systems, such as production data, payroll and client records, behind their own groups and, where warranted, their own network or workspace boundary.

Buying a DLP platform before the role matrix exists is the expensive mistake, because a tool can only enforce rules somebody has defined. Dedicated tooling is worth a look later, for high-value documents that must stay controlled after they leave your environment.

Conditional access layered on top of a missing role matrix is just conditional chaos.

How do joiner-mover-leaver changes and quarterly reviews keep access restricted?

Wire access changes to HR events so leavers and movers lose rights on the HR date, including through notice periods, the window auditors probe hardest. Then review access quarterly on sensitive systems. The system owner confirms each holder still needs each right, and every removal actually happens, traceable to a ticket.

Notice-period blindness is the usual gap: access untouched between resignation and exit, which is exactly when the risk is highest. Make the HR system's dates the trigger rather than an email to IT. Movers need the same rule, because someone who moves from support to sales keeps the support-system access until somebody removes it.

Timestamps matter. Auditors cross-check permission removals against HR dates, so each ticket should carry both the date HR recorded and the time the access actually ended.

A quarterly review that survives questioning has four parts:

1. Pull the facts. Gather holders, grants and last-use data for each sensitive system.
2. Name the judge. The system owner, not the IT administrator, confirms each holder still needs each right.
3. Raise the removals. Every revocation becomes a ticket.
4. Close the loop. Sign off only after the tickets are done and the permission has actually gone.

Bulk approve-all clicks produce the opposite result. Privilege creep stays intact while the sign-off evidence dissolves under one auditor question, such as asking the owner what they removed last quarter.

An access review that approves everything is a record of attendance, not a control.

Quarterly is the defensible cadence at 25–250 people, with event-driven checks on every mover and leaver. Annual-only reviews leave nine more months of unchecked creep. Less sensitive systems can sit on a slower cycle, and the automation section below covers generating review packs and revocation tickets without manual compiling.

What should you log to prove access restrictions hold?

Log permission changes and denied-access attempts in one central place. Then alert on the patterns that matter: privilege grants made outside the agreed process, and repeated denials against sensitive stores. Central authentication telemetry turns access restriction from a configuration claim into something you can show was working on any given day.

The ICO Guidance on Brute Force and Credential Attacks approaches access restriction from the attacker's side. It advises disabling unused accounts and locking accounts after too many wrong password guesses, citing the NCSC's recommendation of between five and 10 attempts. It also advises watching dormant and disabled accounts for unexpected activity.

Start with four alert rules:

• Out-of-process privilege grants. An admin role added with no matching ticket.
• Repeated denials on sensitive stores. The same identity refused again and again against finance or client data.
• Lockout spikes. Many accounts locking in a short window, which suggests password guessing.
• Dormant accounts waking up. A leaver's or long-idle account that suddenly signs in.

Between quarterly reviews, these logs are the continuous proof that the configuration held. A small firm can keep them in the identity provider's own audit log or forward them to one central store. What matters is that a single place answers "who changed this, and when?"

How do auditors test ISO 27001 A.8.3?

Auditors pick a sensitive data set from your classification scheme and trace it end to end: policy statement, role matrix, actual group membership, actual system permissions. They cross-check recent movers and leavers against permission timestamps and spot-check external sharing. Sensitive data reachable anonymously typically grades major; a single stale mover typically grades minor.

The auditor is looking for the seam where paper and configuration diverge. Expect them to ask one system owner to walk through the last access review they signed.

Expect five questions in the room:

• "Your policy says finance data is restricted. Show me, in the system, exactly who can open it today."
• "How would an anonymous user reach any of your data stores, and how do you know they can't?"
• "This person moved from support to sales in March. What happened to their support-system access?"
• "Who reviewed access to production last quarter, and what did they remove?"
• "Do any shared accounts exist, and where is the risk-register entry?"

The evidence set that answers them:

• The role-to-permission matrix, with identity provider group memberships that mirror it.
• Permission exports from the key systems, reconciled against the matrix.
• Conditional-access configuration showing device, location and authentication conditions.
• Completed review sign-offs, with removals traceable to tickets.
• Leaver and role-change tickets dated against HR dates, including notice periods.
• Public-surface controls: sharing settings, bucket policies and external-sharing reports.
• Logs and alert rules covering permission changes and unauthorised attempts.

The standard itself sets no grades. We work from certification-body practice. Sensitive data reachable anonymously or by almost everyone, or permissions with no link to the documented policy, is a total breakdown and grades major. An isolated stale mover, a review one cycle late or an undocumented shared account grades minor, aggregating to major where repeated seams show a pattern.

How can you automate A.8.3 enforcement with GRC engineering?

Every enforcement point has an API, so A.8.3 automates well. Scheduled jobs compare live groups and permissions against the role matrix and ticket the drift. Review packs build themselves, HR events trigger same-day revocation, and public-surface scans run continuously. The human layer keeps the judgement; the machine keeps the evidence.

The reconciliation job matters most. A machine catches the policy-to-configuration seam before the auditor does, and the drift ticket becomes evidence that you noticed and fixed it. Review packs follow the same logic. The owner receives holders, grants and last-use data and judges them. Removals flow back as tickets, and the sign-off trail writes itself.

HR-event revocation captures timestamps as standing evidence for the sampling auditors always do. Continuous public-surface monitoring alerts when something sensitive becomes link-shared or a bucket goes public. Deciding whether a finance analyst still needs write access stays a human call, because the automation removes the compiling, not the deciding.

At this scale the first pass takes weeks, and the cadence then satisfies both auditors and enterprise buyers. The table shows what each automation catches and the evidence it leaves.

Frequently asked questions