ISO 27001 A.8.3: Restrict access to the information people need
Information access restriction ensures that people and services can reach only the information and actions their authorised work requires. ISO 27001 Annex A.8.3 concerns implementing restrictions consistent with the organisation's access-control policy. A manager's approval is not enough if the application, shared folder or collaboration platform grants something broader.
What A.8.3 requires in practice
A.8.3 requires access to information and associated assets to be restricted in line with the organisation's own access control policy. The policy states the intent; this control is where the intent becomes enforced reality in systems, shared storage and applications.
Putting it into practice means working out, for each important information set, who needs what kind of access and for what purpose. A reader, an editor and an approver are different needs. The restrictions must then be implemented in the technology so that the permitted people can do their tasks and others cannot reach the information, whichever route they try.
Outputs are defined access needs, configured permissions that match them and evidence from checking real access. The control does not prescribe role-based access, a directory product or a review interval; those are methods an organisation may choose when they fit its environment.
Define the action as well as the information
Access is not a single yes-or-no concept. A person may need to view a record without changing it, contribute a document without deleting others' work, or process one customer's information without seeing another's. Identify the relevant actions and boundaries before choosing a role or group.
Translate those needs into a model the system can enforce. Role-based permissions can be useful for stable responsibilities, while particular situations may require additional conditions or narrower assignments. Avoid choosing a broad predefined role merely because its name sounds close to the business function. Check what the role actually permits, including inherited and indirect access.
Examine all routes to the same information
The normal user interface may not be the only route. Reports, exports, shared links, integrations and alternative application functions can expose the same information. A restriction that hides a menu item should not be assumed to protect the underlying action or record. Appropriate technical design and authorised testing are needed to establish effective enforcement.
Where information is shared externally, decide the audience, permitted use and duration. More dynamic controls may help limit access or distribution, but their capabilities and limitations need verification. Do not promise that a permission change can retrieve every uncontrolled copy previously made. The control model should reflect what the technology can actually do.
Why information access restriction matters to the business
Most accidental disclosure comes from access that was broader than anyone intended. A shared folder open to the whole company, a report visible across customer teams or a link that never expires can undo the best policy. Customers who share sensitive information expect segregation, and some contracts require it explicitly. Restricting access also limits the damage when an account is compromised, because the intruder reaches only what that account could. Good restriction supports confidentiality commitments, reduces the volume of material exposed in an incident and makes investigations faster. When an auditor tests with real accounts and finds that permissions match the stated rules, confidence in the wider management system rises noticeably.
How to implement A.8.3
Start from the information, then work down to the technical permission.
- Identify the information sets and systems that need restriction, ranked by sensitivity and business consequence.
- For each, define who needs to view, change, share or delete, and for what reason, before choosing any role or group.
- Translate those needs into roles, groups or conditions the system can enforce, checking what each predefined role truly allows, including inherited rights.
- Close alternative routes to the same information, such as exports, reports, shared links and integrations that bypass the main screen.
- Set rules for external sharing covering audience, purpose and how long access should last.
- Test with designated accounts and sample records, then correct any gap through your normal change route and keep the results as evidence of what was checked and what was found.
- Review effective access when roles change, projects close or collaboration spaces are retired, rather than relying only on the original approval.
Illustrative BPO example: permissions across customer teams
A fictional BPO provider creates separate workspaces for two clients but assigns both teams to a broad operations group. The workspace names suggest separation, while inherited rights allow staff to read both sets of records. A review of team lists alone would miss the effective access.
The provider defines the required customer boundaries and adjusts the permission model through an approved change. Using designated test accounts and sample records, it confirms that each role can perform its own tasks and cannot read or modify the other customer's information. Evidence records the expected and observed results. The test examines actual enforcement rather than the appearance of separate folders.
Illustrative construction example: a link that outlives a tender
A hypothetical contractor shares selected tender documents with an external adviser. The link is broadly accessible to anyone receiving it and remains valid after the assignment. The owner assumes that emailing it only to one person establishes a lasting restriction.
The contractor changes the arrangement to an authorised, limited audience with an appropriate end condition. It reviews what was previously shared and whether additional action is needed. A controlled test confirms the intended recipient's access and the rejection of an unauthorised account, then checks access after expiry. The lesson is that distribution choice and permission enforcement are different decisions.
Manage exceptions without losing the model
Temporary collaboration and urgent work can require an exception. Identify who approves it, the scope, the reason and when it should end. Check the resulting permission and remove it when no longer needed. Repeated exceptions may indicate that the role design no longer matches the organisation's work.
Review changes in responsibilities and information sensitivity. A repository created for general material can gradually accumulate confidential content without its access model being reconsidered. Ownership should include responsibility for such changes, not just technical administration of the storage location.
Evidence of the effective restriction
Useful evidence connects the business rule, approved permission, system configuration and authorised test. Permission extracts or matrices are possible tools, not mandatory document titles. The ISMS needs appropriate information for selected control implementation and operation; evidence should not unnecessarily reproduce sensitive records simply to demonstrate that they exist.
Test both permitted and denied actions using suitable accounts and non-sensitive data where possible. Include relevant inherited rights and sharing paths. A screenshot of a settings page may be useful, but it does not replace a test of the important boundary. Record limitations accurately when a platform cannot enforce the desired restriction.
Connect this control with access-control policy, access-rights lifecycle management and authentication. The risk treatment process should address any residual gap between required and technically available restriction.
Common nonconformities with A.8.3
Findings usually show a policy that is sound on paper and permissions that are wider in practice.
- Broad group membership giving staff access to folders outside their duties.
- Restrictions applied to the screen but not to exports, reports or other routes to the same record.
- External links left open after an assignment ended, so former advisers can still read documents.
- Access never adjusted when a person moved to a different team.
- No evidence that effective permissions were ever tested against the stated rules.
Frequently asked questions
Does a successful login prove access is authorised?
No. Authentication establishes confidence in an identity. Authorisation determines which information and actions that identity may use. Both need appropriate control.
Are folder names sufficient to separate sensitive information?
No. Names describe organisation; permissions enforce access. Check inherited rights, shared links and the actions available to representative users.
Must every organisation use dynamic access technology?
No universal product or model is required. Select an effective approach for the information, sharing needs and risks, and verify the outcome.
Turn access intentions into enforceable boundaries
Discuss information-access design with Sterling, linking implementation, practical documentation, employee learning and agreed Effivity ISO & GRC automation software. Scoped authorised vulnerability scanning and findings review can support the wider programme. Sterling continues through agreed preparation while certification remains an independent decision. Enrol in ISO/IEC 27002 Information Security Controls to strengthen practical control selection and review. Return to the technological controls directory.