A.8.3
Information access restriction
ISO 27001 · ISO/IEC 27001:2022 · Last verified July 2026
Objective
Restrict access to information and software functions according to the access control policy.
Points of focus
- Enforce tenant isolation so one customer's data or API scope cannot reach another's
- Restrict application functions by role, not just gate the login screen
- Apply least-privilege network policies, IAM roles, and object-store ACLs at the infrastructure layer
- Scope API tokens and service credentials narrowly rather than issuing broad, long-lived keys
Implementation notes
Enforce authorization independently at every layer a request passes through: the API must reject unauthorized calls even if the UI would never render the button, and the database or storage layer should enforce tenant boundaries even if application code has a bug. For multi-tenant SaaS, prefer database-level isolation mechanisms — row-level security, per-tenant schemas, or equivalent — over relying solely on application query filters, since a single missed WHERE clause becomes a cross-tenant incident rather than a contained bug. Model RBAC around actual application functions (read customer records, export data, modify billing) rather than generic "admin/user" buckets that don't map to what the system can actually do. For infrastructure, apply least-privilege IAM roles per service rather than a shared broad-access credential, and scope API tokens narrowly with expiration where the client supports it. Review the permission matrix and IAM policies together at least annually, since drift between the documented model and the deployed configuration is one of the most common findings in this area.
Audit tip: Ask your engineering team to demonstrate authorization at the API layer, not the UI — a curl request from a low-privilege token attempting an admin-only endpoint should fail. Auditors increasingly ask for this live rather than accepting a screenshot of the permission matrix.
Evidence auditors typically request:
- RBAC/permission matrix mapping application roles to functions and data scopes
- Tenant isolation test results or architecture documentation (row-level security, per-tenant schemas, or equivalent)
- IAM policy exports or IaC diffs showing least-privilege roles for services and infrastructure
- API token/scope inventory showing narrowly scoped, time-bound credentials rather than broad admin keys
Common gaps
- The application enforces role-based menus in the UI, but the underlying API endpoints don't independently check authorization, so a crafted request bypasses the restriction
- A shared service account with broad database access is used by three different microservices instead of scoped, per-service credentials
- Tenant isolation relies entirely on application-layer filtering with no database-level enforcement, so a single query bug becomes a cross-tenant data exposure
Cross-Framework Mapping
| Framework | Requirement | Implementation note |
|---|---|---|
| ISO 27001 | A.8.3 | This control |
| SOC 2 | CC6.1, CC6.6 | CC6.1 (logical access restriction) and CC6.6 (boundary protection against external threats) both bear on A.8.3 — SOC 2 examiners specifically probe whether authorization is enforced at the API layer, not only the UI. |
| GDPR | Article 32 | Article 32(1)(b) requires the ability to ensure ongoing confidentiality of processing systems — tenant isolation and function-level authorization are the concrete technical measures that make this more than a policy statement for a multi-tenant SaaS product. |
Primary sources
- ISO/IEC 27001:2022 Annex A: ISO/IEC 27001:2022 Annex A (A.8.3)