ISO 27001 A.8.3 - Information Access Restriction

Requirement

“Access to information and other associated assets shall be restricted in accordance with the established topic- specific policy on access control.”

Plain-language meaning

The organization should make sure users can only access the information, functions, applications, databases, reports, exports, and assets they need for their role.

This is where access control policy becomes actual system behavior. It is not enough to say “least privilege” in a policy. Application roles, database permissions, menus, maintenance utilities, exports, print functions, and temporary support access must match the approved access rules.

Why this matters

Excessive access creates confidentiality, integrity, availability, fraud, and intellectual property risks. A user with too much access may see data they should not see, change records without authority, extract sensitive information, or bypass intended workflows.

Shared databases and multiple applications accessing the same data create a common failure point: one application may restrict information correctly while another exposes the same data through reports, exports, maintenance utilities, or poorly designed roles.

Implementation guidance

1. Define access rules by owner and business need

The owner of each application, service, solution, database, or information set should define:

2. Align restrictions with classification and handling

Access rules should reflect the information classification scheme. Highly sensitive information normally needs tighter role restrictions, stronger authentication, logging, export control, and review.

3. Control shared database access

Where several applications use the same database, access restrictions must be tested across all paths. One application should not become a back door to information restricted in another application.

4. Hide restricted functions and information

Users should not normally see menus, functions, reports, or manual instructions for features they are not allowed to use. Hidden or disabled functions reduce accidental misuse and make attempted access easier to interpret.

5. Control extracts, printouts, and downloads

Information that is exported, printed, downloaded, or copied into another format should remain subject to the same handling rules. Access restriction fails if sensitive data is protected inside the application but can be freely exported.

6. Manage dynamic privilege and support sessions

Temporary privilege changes, remote support sessions, and third-party troubleshooting should be explicitly authorized, time-bound, logged, and visible to the authorized user where applicable.

Examples include:

• service desk remote control of a workstation;
• supplier engineer troubleshooting;
• temporary access to production data;
• emergency access to maintenance utilities;
• elevated access for incident response.

Audit guidance

Auditors should verify:

• access control policy and topic-specific rules;
• application owner access decisions;
• role-to-permission matrix;
• user access listings;
• database and application permission consistency;
• classification-to-access mapping;
• restricted menu/function behavior;
• report, export, print, and download controls;
• maintenance utility access;
• dynamic privilege authorization and logs;
• start/end time for temporary privilege;
• evidence showing actions taken during elevated sessions.

Audit sampling should include little-used application areas such as maintenance utilities, admin consoles, bulk export features, report builders, and support tools.

Evidence examples

Strong evidence

• Information owners approve access rules.
• Roles define create/read/modify/delete/export/admin permissions.
• Application and database permissions are consistent.
• Sensitive functions are hidden or blocked for unauthorized users.
• Exported or printed information remains controlled.
• Dynamic privilege sessions show authorization, start/end time, actions, and review.
• Access reviews remove excessive permissions.

Weak evidence

• Policy says least privilege but no access matrix exists.
• Application roles are inherited from defaults.
• Database access is broader than application access.
• Users can see restricted menus or reports.
• Exports bypass classification and handling rules.
• Support staff can take over sessions without explicit approval or logging.
• Temporary privilege has no end time or post-use review.

Common failures

Exam traps

Related controls and concepts

• A.8 Technological Controls MOC
• A.8.2 Privileged Access Rights
• A.5.15 Access Control
• A.5.16 Identity Management
• A.5.18 Access Rights
• A.5.12 Classification of Information
• A.5.13 Labelling of Information
• A.5.10 Acceptable Use of Information and Other Associated Assets
• Risk Assessment
• Statement of Applicability
• Access Control Matrix
• Access Review Checklist
• Information Classification and Handling Matrix
• Information Access Rule Matrix
• Information Access Restriction Review Checklist
• Dynamic Privilege Session Record
• Sensitive Function and Export Control Checklist
• A.8.3 Audit Evidence Pack
• A.8.3 Audit Checklist

KB-ready summary

• Define access rules by information owner and business need.
• Map roles to create/read/modify/delete/export/admin permissions.
• Check application, database, reporting, and export paths.
• Hide or block restricted functions and sensitive utilities.
• Log and review dynamic privilege or support-session access.

Templates and checklists

• Information Access Rule Matrix
• Information Access Restriction Review Checklist
• Dynamic Privilege Session Record
• Sensitive Function and Export Control Checklist
• A.8.3 Audit Checklist