How to Make Sure Only the Right People Can See the Right Things
ISO 27001 Control 8.3 Information access restriction is the “gatekeeper” control.
If 5.15 (Access control) sets the rules, Control 8.3 is about making sure your actual systems, apps and data stores enforce those rules in practice – no more “everyone has access to everything on the shared drive since 2014”.
It covers both:
- Traditional access controls (roles, permissions, ACLs, networks), and
- More advanced dynamic / context-aware controls (device, location, document rights, expiry, etc.) for your most sensitive information.
This guide walks through what ISO 27001 Control 8.3 really expects and how to implement it in a way that’s practical for busy IT and security teams.
What ISO 27001 Control 8.3 Actually Expects
In plain English, ISO 27001 Control 8.3 – Information access restriction expects you to:
- Restrict access to information and other assets in line with your access control policy.
- Prevent anonymous or uncontrolled access to anything sensitive.
- Use technical controls (permissions, ACLs, groups, network controls, etc.) to enforce “need to know”.
- Isolate particularly sensitive systems or data physically or logically.
- For higher-risk information, use dynamic, context-aware access controls (document protection, conditional access, expiry, etc.).
- Log and monitor access so you can prove what happened and investigate issues.
Auditors will look for:
- A clear link from your access control policy (5.15) to real permissions and configurations.
- Evidence that sensitive information isn’t just “open to everyone”.
- Some thought about how you handle data that leaves your core systems (e.g. documents emailed externally).
Step 1 – Start from Policy, Classification and Ownership
All access restriction should be driven by what the information is and who owns it, not by who shouts loudest.
Make sure you have:
- An access control policy
– Defines how access is granted, reviewed and removed.
– Sets principles such as least privilege and need-to-know. - Information classification
– Clear levels: e.g. public, internal, confidential, highly confidential.
– Simple, understandable handling rules for each level. - Asset and data owners
– Named owners for key systems, applications and shared repositories.
– Owners approve who should have access to “their” information.
Control 8.3 is about making those rules real in the systems – but you need the rules first.
Step 2 – Block Anonymous Access to Anything Sensitive
This is the most basic – and often most revealing – check.
You should:
- Prohibit anonymous / unauthenticated access to:
– Internal line-of-business apps
– File shares and document libraries with anything above “public”
– Admin interfaces
– Internal APIs that handle sensitive data - Allow anonymous/public access only where deliberate
– Public websites or documentation that you intentionally publish.
– “Public” storage areas that contain no sensitive data.
And crucially:
- Document where anonymous access is allowed and why – so it’s a conscious design choice, not an accident.
This alone can clear up a surprising number of risks.
Step 3 – Configure Access Controls Properly (Roles, Groups, Permissions)
Now you translate “need to know” into actual system permissions.
For each major system or repository:
- Define roles / groups properly
- Avoid per-user permissions where you can.
- Use role-based access (e.g. “Finance – Read”, “HR – Admin”) aligned to job functions.
- Assign permissions by role/group, not individual
- People join/leave groups; groups carry the access.
- Makes joiner/mover/leaver processes far simpler and more auditable.
- Set appropriate permission types
- Read / write / delete / execute / admin separated where possible.
- Limit “full control” and admin roles to the minimum.
- Avoid “everyone” or “domain users” style access
- Especially on file shares, document libraries and wikis.
- Replace with named groups that reflect who actually needs access.
- Align with identity and privileged access controls
- Make sure this fits with your identity management (5.16) and privileged access (8.2) arrangements.
Control 8.3 is satisfied when an auditor can pick a system, ask “who should see what?”, and find that the permissions match the answer.
Step 4 – Use Physical or Logical Isolation for Sensitive Assets
For particularly sensitive systems or data, just “having the right permissions” might not be enough. You also want isolation.
That might look like:
- Separate networks or VLANs for:
– Payment systems
– Security tooling and logging infrastructure
– Highly sensitive back-office systems (e.g. payroll, HR, board materials) - Dedicated, access-controlled locations
– Restricted file shares or document libraries for confidential projects.
– Separate tenants or subscriptions for highly sensitive workloads. - Tightened access paths
– Only specific jump hosts, VPNs, or bastion services can reach sensitive servers.
– Admin access restricted to defined management networks.
This supports Control 8.3 by making it much harder for someone to accidentally or deliberately wander into areas they shouldn’t.
Step 5 – Introduce Dynamic / Context-Aware Access for High-Risk Data
Traditional ACLs and permissions are great inside your core systems. But once information leaves those systems – via email, downloads, sync to devices – they lose power.
That’s where dynamic access management comes in.
When dynamic access makes sense
Consider it for:
- Highly sensitive documents (M&A, board packs, security investigations).
- Confidential designs or customer data shared with partners.
- Files that leave your environment but still need control (e.g. external consultants).
Typical dynamic access controls
You might use:
- Document-level controls
– Rights management / information protection labels.
– Restrict print, copy, forward, download.
– Expiry dates or time-limited access. - Conditional access
– Only allow access from managed devices, certain locations, or with MFA.
– Block access from risky or unknown devices. - Re-authentication and step-up controls
– Require re-authentication for certain documents or actions.
– Step-up MFA when risk is higher (new device, unusual location). - Monitoring and alerting
– Log how sensitive documents are accessed and used.
– Alert if rules are violated or unusual access patterns emerge.
Dynamic controls don’t replace normal permissions – they travel with the data and give you ongoing control and visibility.
Step 6 – Log, Monitor and Review Access
Access restriction is only half the story – you also need to see what’s actually happening.
Make sure:
- Access events are logged for key systems and repositories
– Successful and failed logins
– Access to sensitive folders, records or functions
– Privileged changes (permissions, roles, admin actions) - Logs are sent to central logging / SIEM
– So you can detect unusual patterns, brute force attempts, or mass downloads. - Regular access reviews occur
– Owners review who can access their data (at least annually, more often for critical systems).
– Leavers’ accounts and group memberships are removed promptly.
This gives you evidence that Control 8.3 is operating over time, not just correctly configured once.
Step 7 – Handle External Access and Sharing Carefully
A lot of information access risk now sits in external sharing – SaaS collaboration, shared drives, guest accounts, file shares sent to customers, etc.
Good practice under Control 8.3:
- Define clear rules for external sharing
– What can be shared? With whom? Through which channels?
– When must you use protected links or document rights? - Use controlled sharing mechanisms
– Named guest accounts or secure links rather than “anyone with the link”.
– Expiry dates on shared links where possible. - Review external access regularly
– Clear up old guest accounts and external shares.
– Remove access when projects end.
Combined with dynamic protection, this lets you safely collaborate without losing control of sensitive assets.
Quick Implementation Checklist for ISO 27001 Control 8.3
Use this as a fast sense-check:
- ISO 27001 Control 8.3 (Information access restriction) is covered in your access control / information security procedures, not just in theory.
- Anonymous or unauthenticated access is blocked by default for anything above “public”.
- Major systems and repositories use roles/groups and least privilege, not “everyone/full control”.
- Particularly sensitive systems and data are physically or logically isolated (separate networks, folders, tenants, or apps).
- For high-risk information, you use dynamic access controls (rights management, conditional access, expiry, etc.), especially when data leaves core systems.
- Access events are logged and monitored, with meaningful alerts for suspicious behaviour.
- Regular access reviews are carried out by data/system owners, and leavers’ access is removed promptly.
- External sharing and third-party access are controlled, time-bound and regularly tidied up.
- Your approach is aligned with broader access management guidance (e.g. ISO 29146) and other ISO 27001 controls (5.15, 5.16, 8.2, 8.4).
Bringing It All Together
ISO 27001 Control 8.3 – Information access restriction – is where your access control policy stops being words on a page and starts being real, enforced behaviour in your systems.
If you:
- Cut off anonymous access to anything sensitive,
- Use roles and least privilege properly,
- Isolate and dynamically protect your most sensitive information, and
- Log, monitor and regularly review who has access,
you’ll not only have a strong answer for an auditor – you’ll massively reduce the chance of “I didn’t realise everyone could see that” being the start of your next incident report.
Explore the ISO 27001 Controls