ISO 27001 A.8.3: Information Access Restriction

Quick Reference (60 Seconds)

The Bottom Line: A.5.15 writes the access rules and A.5.18 grants rights to people. A.8.3 is where the rules are enforced in the information itself: on the bucket, the folder, the database table, the application screen and the shared document. It also asks you to go further for your most valuable information, with controls that stay attached to the data when it leaves your systems.

What the Control Asks For

In short

Annex A 8.3 asks organizations to restrict access to information and other associated assets in line with their access control policy.

Do you need this control?

A.8.3 is not mandatory in itself: under clause 6.1.3 you include it if your risk assessment calls for it, and record the decision in your Statement of Applicability. In practice almost every organisation that holds information in systems includes it.

What ISO 27002:2022 Adds

ISO 27002 8.3 (paraphrased) asks you to restrict access according to your topic-specific access control policy, considering:

• (a) no access to sensitive information by unknown or anonymous identities; public or anonymous access only to storage that holds no sensitive information
• (b) configuration mechanisms to control access to information in systems, applications and services
• (c) controlling which data each user can access
• (d) controlling which identities or groups have which access: read, write, delete and execute
• (e) physical or logical isolation of sensitive applications, application data or systems

Dynamic access management should be considered for sensitive, high-value information when you need to:

• control who can access it, for how long and in what way
• share it outside the organisation and keep control over who can open it
• manage its use and distribution in real time
• stop unauthorised changes, copying, distribution and printing
• monitor its use and record changes for later investigation

Such techniques should protect information through its life cycle, with rules based on identity, device, location or application and on your classification scheme, supported by operational, monitoring and reporting processes. They protect information by requiring authentication or certificates, limiting access to a time window, encrypting it, setting print permissions, recording who accessed it and how, and alerting on attempted misuse.

27002 adds that dynamic access management does not replace normal access control lists; it adds conditions and real-time evaluation for the most sensitive information, works outside your own environment, and helps incident response because permissions can be withdrawn at any time.

What Belongs to Neighbouring Controls

"Shall" vs "Should" Analysis

• Shall (once you have selected this control): access to information and associated assets is restricted in line with the access control policy.
• Should (27002 guidance): the five points, and dynamic access management where your high-value information needs it.

Why It Matters

Most Data Exposure Is an Access-Restriction Failure

Many large data exposures do not need an attacker to break anything. A storage bucket left public, a database reachable without a password, a file shared with "anyone with the link", or a folder every employee can read does the job. Security researchers routinely find exposed cloud storage and open databases holding customer records, including from Indian companies, and the CERT-In Directions treat data leaks as reportable incidents.

Excess permissions inside the organisation matter too. When everyone can read everything, one phished account or one disgruntled employee exposes it all.

Public Cases

Summaries of publicly reported incidents; facts as reported by regulators and in public sources.

• Capital One (2019): an attacker used a server-side request forgery flaw to obtain credentials for a cloud role that had far broader storage access than it needed, and copied data on over 100 million people. The US Office of the Comptroller of the Currency fined Capital One $80 million in 2020. The lesson for A.8.3: scope each identity's data access narrowly.
• Punjab National Bank (detected 2018): employees misused access to the bank's SWIFT messaging system, which was not integrated with its core banking system, to issue unauthorised letters of undertaking over several years. RBI later penalised a number of banks for not complying with its directions on SWIFT controls. The lesson: restrict and reconcile access to high-value functions, and separate duties.

Regulatory Drivers

• DPDP Act 2023: reasonable security safeguards (s.8(5)); a data leak from a public bucket is a personal data breach to be intimated under s.8(6) once the Rules apply. Penalty for failing to take safeguards: up to ₹250 crore.
• CERT-In Directions (2022): data breaches, data leaks and unauthorised access are reportable within 6 hours of noticing.
• RBI (Cyber Security Framework 2016; Master Direction on IT Governance 2023), SEBI CSCRF (2024) and IRDAI (2023): expect need-to-know access to customer data and controls over critical systems.
• PCI DSS v4.0.1: Requirement 7 (restrict access by business need to know) and 3.x (protect stored account data).

Scope and Applicability

What the Control Covers

• Permissions on file shares, document libraries, cloud storage, databases, applications and APIs
• Public and anonymous access settings, sharing links and guest access
• Isolation of sensitive applications, data and systems (separate tenants, accounts, networks or databases)
• Dynamic access management for high-value information (sensitivity labels with encryption, information rights management, conditional access to data)

Who It Applies To

Information owners decide who should access their information; IT and platform teams configure it; the CISO sets the standard and checks it. Every organisation with information in systems needs it, scaled to its size.

Size-Based Applicability

Key Definitions and Terminology

Relationship to Other Controls

Detailed Implementation Guidance

Step 1: Remove Anonymous Access to Sensitive Information (27002 (a))

• Cloud storage: block public access at the account or organisation level (for example AWS S3 Block Public Access, Azure storage "allow blob public access" off, Google Cloud public access prevention). Allow public buckets only for genuinely public content, in a separate, labelled account or project.
• File sharing: disable or restrict "anyone with the link" sharing in Microsoft 365 and Google Workspace for internal and confidential content; make links expire; restrict external sharing to approved domains where possible.
• Databases and search clusters: no internet-exposed databases (Elasticsearch, MongoDB, Redis) without authentication; bind to private networks.
• APIs: every API that returns non-public data requires authentication and object-level authorisation.
• Check regularly: scan for public exposure monthly, and after any change, using your cloud provider's posture tools or a CSPM/DSPM product.

Step 2: Configure Permissions by Identity and Group (27002 (b)–(d))

• Grant access to groups that map to roles, not to individuals; keep group membership in the identity system (A.5.16, A.5.18).
• Separate read, write, delete and execute: most people need read; few need delete.
• Restrict which records users see inside applications (row- or tenant-level security, customer-segment filters), not only which screens.
• Remove broad defaults such as "Everyone", "All employees" or "Authenticated users" from confidential locations.
• Document the permission model for each important system (owner, groups, rights) so reviews under A.5.18 can check it.

Step 3: Isolate Sensitive Applications and Data (27002 (e))

• Put the most sensitive systems (payment, HR and payroll, core banking, health records) in separate accounts, subscriptions, tenants, databases or network segments (A.8.22).
• Keep production data out of development and test (A.8.31, A.8.33).
• For physical isolation, use separate hardware or rooms where the risk warrants it.

Step 4: Apply Dynamic Access Management to High-Value Information

Decide, from your classification scheme, which information needs controls that travel with it. Typical candidates: board papers, M&A documents, unreleased financial results, source code exports, customer data extracts, HR investigation files.

Remember the limits: rights management cannot stop someone photographing a screen. Combine it with classification, training and DLP (A.8.12).

Step 5: Monitor, Review and Respond

• Log access to sensitive data stores and alert on anomalies (A.8.15, A.8.16).
• Review permissions on sensitive locations with the information owner at least quarterly (A.5.18).
• When exposure is found, remove it first, then assess what was accessed (logs), and treat it as a potential data breach.

Information Access Restriction Standard (Template)

Information Access Restriction Standard: [Organisation] (A.8.3)

1. No anonymous or public access to information classified Internal or above.
   Public access is allowed only for content approved as Public, in locations set
   aside for it.

2. Cloud storage: public access blocked at organisation level; exceptions approved
   by the CISO and recorded. File sharing: "anyone with the link" disabled for
   Internal and above; external sharing only to approved domains; links expire
   after [30] days.

3. Permissions are granted to role-based groups, not individuals. Rights are limited
   to what the role needs (read, write, delete, execute). Broad groups such as
   "Everyone" are not used on Confidential or Restricted locations.

4. Applications restrict which records a user can see, not only which functions.

5. Systems holding Restricted information run in separate accounts, tenants,
   databases or network segments from general systems.

6. Restricted documents shared outside the organisation are protected with
   [sensitivity labels / IRM] that set who may open them, for how long, and whether
   they may be printed, copied or forwarded.

7. Access to Confidential and Restricted locations is logged; unusual access raises
   an alert. Exposure scans run [monthly] and after significant changes.

8. Information owners review permissions on their Confidential and Restricted
   locations at least quarterly.

Owner: [CISO]   Approved by: [Top management]   Review: annual

Risk Assessment and Treatment

Audit and Compliance Checklist

Metrics and KPIs

Common Pitfalls

Illustrative Scenarios

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative Scenario 1: SaaS Company, Public Storage and Sharing Links

Situation. A Pune SaaS company used cloud storage for customer exports. A support engineer had made one bucket public to share a file with a customer and never reverted it. Separately, dozens of "anyone with the link" shares of internal documents were circulating.

What changed.

1. Public access was blocked at the organisation level; a separate, labelled account was set up for genuinely public assets.
2. "Anyone with the link" sharing was disabled for internal content; external sharing was limited to approved domains with expiring links.
3. A monthly exposure scan and an alert on any policy change were added.
4. Customer exports now go through a secure transfer service with per-recipient access and expiry.

Lesson. The fix was mostly configuration, done once at the top level rather than file by file.

Illustrative Scenario 2: Financial Services Firm, Board and Deal Documents

Situation. Board papers and deal documents were emailed as attachments to directors and advisers, some using personal email. A draft results document was forwarded beyond its intended readers.

What changed.

1. A "Restricted: Board" sensitivity label applies encryption, limits opening to named people, blocks forwarding and printing, and expires after the meeting cycle.
2. Deal documents are shared through a data room with per-user access, watermarking and activity logs.
3. Directors received managed access on their own devices without storing local copies.

Lesson. Dynamic access management protects information that must leave your systems; ordinary folder permissions cannot.

Maturity Model

Figure · Tiers

Maturity levels for information access restriction

Target L3 for certification.

Key Takeaways

• A.8.3 enforces the access control policy in systems and in the information itself.
• No anonymous access to sensitive information: block public storage and open sharing by default.
• Grant role-based permissions and separate read, write, delete and execute.
• Isolate sensitive applications, data and systems.
• Use dynamic access management (labels with encryption, IRM, data rooms) for high-value information, especially when it leaves your systems.
• Scan, log and review so exposure is found quickly.

Multi-Framework Mapping

FAQ

How is A.8.3 different from A.5.15 and A.5.18?

A.5.15 sets the access control policy and A.5.18 manages people's access rights. A.8.3 is the technical restriction on the information: permissions, public-access settings, isolation and dynamic controls.

Is a public bucket always a nonconformity?

Not if it holds only information approved as public, kept separately. It is a problem when it holds anything sensitive, which 27002 8.3(a) says should never be anonymously accessible.

Do we need information rights management?

27002 says to consider dynamic access management for sensitive, high-value information. If you regularly share such information outside your systems, some form of it (sensitivity labels with encryption, IRM or a data room) is the practical way to keep control.

Does rights management stop all leaks?

No. It controls opening, copying, printing and forwarding in supported apps, and lets you revoke access, but someone can still photograph a screen. Combine it with classification, training and DLP.

What will the auditor ask?

Usually: show your public-access settings and the last exposure scan; show permissions on a confidential folder and a sensitive application; show how a confidential document is protected when sent outside.

Who decides who can access a folder or dataset?

The information owner, within the access control policy. IT configures it; the CISO sets the standard and checks it.

References and Further Reading

Standards

• ISO/IEC 27001:2022 Annex A 8.3; ISO/IEC 27002:2022 8.3.
• ISO/IEC 29146: a framework for access management.

Frameworks

• NIST SP 800-53 Rev 5: AC-3, AC-6, AC-14, AC-16, AC-21, SC-28.
• NIST CSF 2.0: PR.AA-05, PR.DS-01.
• CIS Controls v8: 3.3, 6.8.
• CISA Zero Trust Maturity Model.

Indian law and regulation

• Digital Personal Data Protection Act 2023: s.8(5), s.8(6).
• CERT-In Directions of 28 April 2022.
• RBI Master Direction on IT Governance (2023); SEBI CSCRF (2024); IRDAI (2023).

Public cases

• US OCC consent order and civil money penalty against Capital One (2020).
• Reporting on the Punjab National Bank letters-of-undertaking fraud (2018).

Singahi resources: related guides for A.5.15 Access control, A.5.18 Access rights, A.8.2 Privileged access rights and A.8.12 Data leakage prevention.