A.8.3 Information access restriction: requirements and evidence

What A.8.3 information access restriction requires in ISO 27001

A.8.3 asks the organization to restrict access to information and other associated assets in line with its topic-specific policy on access control. When an auditor or a customer questionnaire asks how access to data is restricted, this is the control that answers it, and the answer has to point to a written access control policy and to the systems that enforce it. The risk the control addresses is over-broad access: people, services and devices that can read, change or delete information they have no business need to touch. That risk is hard to contain in practice because access does not sit in one place. It spreads across applications, shared drives, cloud consoles, databases, email distribution lists and temporary exceptions that were never removed. A control that only exists in a policy document does not restrict anything, so the assessor will look for the mechanisms that carry the policy into each system.

The control has a 2013 lineage. The 2013 edition covered the same subject under A.9.4.1 Information access restriction, and the ISO/IEC 27002:2022 correspondence table traces A.8.3 back to it. In the 2022 edition it sits in the technological theme beside A.8.2 Privileged access rights, which covers the most powerful accounts, and it depends on the organizational controls A.5.15 Access control and A.5.18 Access rights, which set the policy and govern how rights are granted, changed and removed. Auditors commonly test these controls together, so the same access review, joiner and leaver records and role definitions can serve several of them. Before you map evidence, confirm with your certification body how it wants the controls cross-referenced in the Statement of Applicability.

For a practical starting point, list every system that holds sensitive information and record who can reach it, through which role or group, and whether that grant matches the access control policy. Note the enforcement point for each system, such as the identity provider, an application permission model, a file-level rule or a cloud resource policy. Where a system cannot enforce the policy itself, document the compensating control and its owner. Self-hosted open-source platforms such as authentik, FreeIPA, midPoint and Nextcloud can each enforce or evidence part of this chain, as described in the topic sections that follow, but each one still needs to be confirmed against your own environment and policy.

Which systems, data and teams A.8.3 covers

A.8.3 applies wherever information can be reached, so the first task is deciding which systems, data classes and people fall inside the access control policy. Each decision below changes which restrictions you must configure, which logs you must keep and which reviews an assessor will sample.

Applications holding sensitive data

Every application that stores or displays sensitive information needs its own access rules, not just a network boundary. List each application, the data classes it holds and the roles that may read, change or export them. An assessor will pick one application and ask you to show that a user outside those roles cannot reach the same records through the interface or the API.

File stores and shared folders

File shares and collaboration platforms often carry the most sensitive information in an organization because files are copied freely. Decide whether access follows folder membership, group membership or per-file sharing, and document who can download, sync or share. Self-hosted file platforms can enforce rules on user group, IP address and file type, so confirm which rules your platform supports before writing them into the policy.

Identity providers and single sign-on

When applications delegate sign-in to a central identity provider, that provider becomes part of the access restriction. Decide which applications rely on it, which groups map to which application roles and who administers the mapping. Evidence should show the group-to-role mapping, the change history and the offboarding path for a leaver.

SaaS admin consoles

Administrative consoles for SaaS services often sit outside the internal network and grant broad access to customer data. Inventory each console, who holds an admin role and whether roles are scoped to a business unit or the whole tenant. Assessors often ask for the list of console administrators and proof that it was reviewed recently.

Data classes and their owners

The restriction you apply depends on the classification of the information, so the classes must exist before the controls do. Name an owner for each class who approves access requests and periodic reviews. Evidence is the classification register linked to the access rules that apply to each class.

Contractors and third parties

External staff, suppliers and managed service providers often hold accounts that outlive their contracts. Decide which third parties receive accounts, how those accounts are time-limited and who approves them. Keep the contract scope, the access grant and the removal record together so you can show that access ended with the engagement.

Role, attribute or context-based rules

Decide whether access depends on a job role, on attributes such as department or location, or on context such as device posture, IP address or time of day. Role-based rules are easiest to evidence through access reviews. Attribute and context rules need documented logic and test cases showing that a request outside the conditions is denied.

How an assessor tests information access restriction

This table walks through the steps an assessor typically takes to test A.8.3, the evidence each step produces and the findings that most often appear. Read it as a planning checklist for your own evidence, then confirm the exact procedures with your certification body, since each auditor sets its own sampling and testing approach.

Test step	What the assessor checks	Evidence requested	Common finding
Confirm the policy	The access control policy defines who may access which information, and how approvals, reviews and removals work	Approved access control policy, version history, owner sign-off	Policy exists but does not name systems, data classes or review frequency
Select applications and data stores	A sample of business applications, file shares, databases and cloud storage holding sensitive information	System inventory, data classification register, asset-to-owner mapping	Shared folders or SaaS tenants missing from the asset inventory
Compare permissions to policy	Whether granted permissions match the approved roles and the least-privilege intent of the policy	Role definitions, permission exports, sample user access reports	Users hold rights beyond their role, or group membership grants unintended data access
Test a joiner or mover	A new hire or a transferred employee receives only the access their new role needs, with approval	Access request tickets, approver records, before and after permission exports	Old access remains after a role change because no one removed it
Test a leaver	Access is removed for a sampled leaver within the time the policy sets	HR termination record, account disable log, removal timestamps across systems	Accounts disabled in the directory but still active in a separate application or SaaS tool
Review exceptions	Any access outside the standard roles has a documented reason, owner and expiry	Exception register, risk acceptance, expiry or recertification records	Exceptions granted with no end date and no periodic review
Check administrative consoles	Administrative interfaces that can change access are limited to authorized staff and covered by the policy	Admin console user lists, configuration exports, access logs	Admin consoles reachable by staff outside the policy's scope
Review access certifications	Owners periodically confirm that remaining access is still needed	Review campaign records, decisions to keep, change or revoke, completion evidence	Reviews completed on paper without evidence that revocations were carried out

How to implement A.8.3 step by step

This sequence turns the access control policy into enforced permissions across applications, identity providers and data stores, then proves through reviews and documented exceptions that restrictions still match the policy. Each step ends with an artifact an auditor can sample.

Define access control rules for information
Start from the topic-specific access control policy and translate it into rules that name the information classes, the roles or groups allowed to use them, and the permitted actions (view, edit, export, share, delete). The policy owner, usually the information owner with security sign-off, approves the rules. Done means a signed, versioned rule set that maps each information class to its permitted actions, which becomes the reference for every later step.
Inventory systems and data stores
Build a register of applications, databases, file shares, collaboration platforms and cloud storage that hold information covered by the rules. Record the owner, the classification of the data, and where authentication and authorization are enforced. Gaps usually appear here: shadow tools, exports to spreadsheets and integrations with service accounts. Done means each store has an owner and a classification, and the register is reconciled against the asset inventory.
Map who can reach what
For each system in the register, export the current effective access: user accounts, group memberships, role assignments, API tokens and service accounts, and sharing links where the platform supports them. Compare this against the rules from the first step and list every mismatch, including users who hold access through inherited or nested groups. Done means a mapping exists for each in-scope store and every mismatch has a ticket with an owner.
Configure permissions in applications and identity providers
Move enforcement into the systems that hold the data. Central identity services such as authentik can handle sign-in and group claims for applications that support OAuth2, OpenID Connect, SAML or LDAP, while each application maps those groups to its own roles. Remove direct user grants in favor of group-based grants and confirm that the application, not only the front end, checks permissions. Done means test accounts for each role show the expected allowed and denied actions, and the configuration is stored as code or exported for the change record.
Add data-level and context rules where needed
Where the rules depend on more than identity, such as network location, file type, device or time, add conditions at the data layer. For example, Nextcloud's File Access Control app can deny upload, download, sync or deletion based on user group, IP address, tags, MIME type, file name, request time or user agent (illustrative of the capability; confirm the rule options in your installed version). Test each rule with a positive and a negative case. Done means each context rule has a documented purpose, a test result and an owner who can change it.
Run access reviews
Schedule periodic reviews in which named reviewers confirm, change or revoke each access item for their systems. midPoint access certification campaigns support this by giving designated reviewers a defined period to decide on role assignments, which also helps catch access accumulation and segregation of duties conflicts. Done means each campaign has a record of who reviewed what, the decisions taken, and the revocations completed, with timestamps that an auditor can sample.
Document and approve exceptions
Some access will fall outside the rules for legitimate reasons, such as a vendor support account or an emergency break-glass path. Record each exception with the business reason, the scope, the compensating controls, an approver and an expiry or review date. Review the exception log at each access review. Done means every deviation from the rule set is traceable to an approved record, and expired exceptions have been closed or renewed with fresh approval.
Keep the evidence current and ready for audit
Set a routine that refreshes the access mapping, the configuration exports, the test results and the review records whenever systems, roles or the policy change. Confirm with your certification body how much evidence and which sampling approach it expects, since assessors decide the depth of testing. Done means an evidence index links each rule to its configuration, test result, review record and exception log, and an owner confirms the index is current.

Self-hosted open-source tools that produce A.8.3 evidence

Access restriction starts with knowing who is asking. Identity providers hold the user directory and enforce sign-in decisions, so applications inherit one set of accounts and groups rather than maintaining their own. In the open-source space, authentik and FreeIPA address different parts of this job. authentik is an identity provider for web and other applications, while FreeIPA centers on Linux and UNIX hosts.

Application delegation: authentik acts as the identity provider for applications through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so each application delegates sign-in instead of storing passwords itself.
Group-based authorization: Applications that trust authentik can be limited to specific groups, which gives the assessor a single place to see who can reach which system.
Linux and UNIX single sign-on: FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC, tying host logins to a central directory.
Evidence to retain: Provider configuration exports, group membership records, and sign-in logs that show which accounts reached which applications.
Licensing: authentik is MIT licensed and FreeIPA is GPL-3.0-or-later, so review obligations differ if you modify and distribute either project.

Confirm with your platform team which provider types your version supports, and whether each application you rely on can accept the protocol you intend to use.

Evidence that passes an A.8.3 audit

An assessor testing A.8.3 wants to see that access to information is restricted as the access control policy says, and that the restrictions still hold on the day of the audit. The six artifacts below connect the policy to the systems that enforce it. Each one goes stale quickly unless someone schedules its review or generates it from the system of record.

Access control policy

This is the topic-specific policy that A.8.3 points to, so it is the first document an assessor reads. It should name the information classes, the systems in scope, who approves access, and how restrictions are enforced at the application and data level. Review it on a fixed cycle and after any change to the identity provider or to a data classification scheme. Check that the version history shows who approved each revision, and that the systems named in it match the current asset inventory.

Access matrices per system

An access matrix lists, for each system or data store, which roles or groups can read, write, change or delete which information. It turns the policy into something testable. Build it from the identity provider's group membership rather than by hand, and reconcile it against the application's own permission model, because the two often diverge. Ask whether each entry has a named owner who signs off on changes.

Identity provider configuration exports

Exports of the identity provider's applications, providers, groups and policy bindings show how sign-in and authorization are wired. For authentik, export the provider and application configuration so that each protected application's access rules are visible in one file. Store exports in version control with dated commits. Compare each export against the last one at every review, since silent changes to group mappings are a common source of unintended access.

Access certification campaign records

Certification campaigns show that someone other than the account holder checked whether access is still needed. Keep the campaign scope, the designated reviewers, the deadline, each keep, change or revoke decision, and the evidence that revocations were carried out. With midPoint, the campaign outputs can be retained as records. Confirm that reviewers are not reviewing their own access and that unanswered items are escalated rather than silently kept.

Nextcloud rule exports and change records

Where Nextcloud restricts file actions, the File Access Control rules are themselves evidence. Export the rule set on a schedule and store each export with the date and the change ticket that justified any modification. The rules can deny upload, download, sync and other actions based on group, IP address, tags, MIME type, file name, request time or user agent, so each rule needs a documented purpose. Test a sample of rules to confirm they block the actions they describe.

Exception register

An exception register records each case where access differs from the policy, such as a temporary grant, an access rule that cannot be enforced in a legacy application, or a user outside the normal group model. Each entry needs an owner, a justification, a compensating measure, and an expiry date. Review open exceptions at a fixed interval and close them when the underlying gap is fixed. Assessors often test the register against the access matrices, so unrecorded differences are the main risk here.

What meeting A.8.3 costs in money and effort

This table breaks down the money and labor behind restricting information access, showing who is paid for each component, whether it is one-time or recurring, and what pushes it up or down. Use it to shape a written scope before asking for quotes, because most of the effort sits in configuration and access review rather than software licenses.

Cost component	Who is paid or who does the work	One-time or recurring	What drives it up or down
Tooling and licenses	Software vendor or open-source project; no license fee for self-hosted open source, but hosting and support may still be paid	Recurring for commercial licenses and hosting; one-time for setup	Number of identity-enabled applications and whether you choose commercial support. Self-hosted open source removes license spend, not configuration labor
Engineering time for identity and application permissions	Internal platform or IT engineers, or an implementation partner under a fixed-scope written agreement	Mostly one-time, with recurring changes as applications are added	Number of systems, data classes and integrations that need permission rules, and how many roles must be designed
Data-level control configuration	Internal engineers, application owners and sometimes the implementation partner	One-time build, recurring tuning	Number of sensitive data classes and locations, such as file shares, collaboration tools and object storage
Access review effort	Designated reviewers, usually business or system owners, plus an administrator to run the campaign	Recurring, at the review frequency your policy sets	Reviewer load: number of users, role assignments and entitlements per reviewer, and how clearly roles are named
Leaver and mover processing	IT operations and HR process owners	Recurring	Staff turnover, number of joiner, mover and leaver events, and whether provisioning is automated from the HR source
Evidence upkeep	Internal compliance or security staff who keep exports, review records and change tickets	Recurring	How often evidence is collected and whether it is generated automatically from logs and review tools or assembled by hand
External testing or review	Independent security testers or assessors, paid under separate written scope	Periodic, if you choose to buy it	Application count, complexity of permission models and the depth of testing requested
Auditor sampling and assessment	The independent auditor or certification body, not the implementer	Periodic, tied to the audit cycle	Number of systems in scope, number of sampled access events and quality of evidence you can produce on request
Remediation after review findings	Internal engineers or the implementation partner	Recurring, lumpy	Volume of excess access found in reviews and how many roles need redesign

How identity, permissions and data-level rules fit together

No single tool satisfies A.8.3 on its own. Access restriction is a stack of layers, and an assessor will test each one against the topic-specific access control policy. The identity provider authenticates users and applications, and applications delegate sign-in to it. For example, authentik can act as an identity provider through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, and FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC. Confirm which protocol each application uses and whether it can actually be forced through the provider, because an application with a local login database sits outside the identity layer entirely.

Authentication answers who the user is, not what they may do. The application or platform must enforce role permissions, and the organization must decide which roles exist, who approves them and which functions they unlock. Data-level rules sit underneath that. In Nextcloud, the File Access Control app can deny upload, modification, deletion, download and sync when rules match on user group, IP address, collaborative tags, MIME type, file name, request time or user agent. Each layer can be configured correctly and still leave a gap, so the policy should name the rule owner for each layer and the test that proves it works.

Permissions drift over time, so the last layer is review. midPoint access certification campaigns have designated reviewers decide within a set timeframe whether to keep, change or revoke items such as role assignments, which counters access accumulation and supports segregation of duties. Plan for a recurring campaign, record each decision and keep the revocation tickets. Ask any implementation partner or vendor to show how a removed role propagates to the applications beneath the identity provider. Assessors will look for that chain of evidence, not for a single configuration screenshot.

Who does what for A.8.3: your team, a partner and the auditor

Your organization owns the control. The access control policy, the rules for who may reach which information, and every decision to grant, change or revoke access stay with your management, data owners and system owners. A partner can draft the rules and build the tooling, but it cannot decide what a business role should see, and it should not approve its own access requests. Expect to name owners for each system and each information class, and to keep records that show those owners acted.

Policy and ownership: Approve the access control policy, name a data owner for each information class and a system owner for each application.
Access decisions: Approve joiner, mover and leaver requests, and record the business reason for each grant.
Periodic review: Run access reviews yourself, with reviewers who are not the people who administer the accounts.
Exceptions: Approve and time-limit any exception to the policy, and track it until it closes.
Operating records: Keep the review results, decisions and remediation tickets that the auditor will sample.

Before you engage anyone, confirm with your internal audit or compliance lead which of these records you already produce and which you must create.

Common gaps that fail access restriction reviews

Auditors testing A.8.3 rarely start with the access control policy. They sample real permissions and check whether those permissions match what the policy says. The gaps below are the ones that most often turn a well-written policy into a finding, and each one has a concrete fix that can be shown as evidence.

Access granted outside the policy

Applications, folders and admin consoles often get permissions through ad hoc requests, email approvals or copied roles from another user. A.8.3 expects access to follow the topic-specific access control policy, so every grant should trace to a documented rule and an approver. Check a sample of recent grants and ask for the request that authorized each one. Close the gap by routing all grants through one ticketed workflow that records the business owner, the role and the expiry date.

No periodic access review

Permissions drift over time as people change teams and projects end. Without a recurring review, access that was once justified stays in place indefinitely. Ask when the last review of each system happened, who signed it and what was changed as a result. Close the gap by scheduling reviews per system owner, with reviewers who can keep, change or revoke each item and a record of every decision. midPoint access certification campaigns can run this process for role assignments.

Shared accounts

Shared logins make it impossible to tie an action to a person, which undermines both restriction and accountability. Shared admin or service credentials used by several staff are a common finding during sampling. Look for generic accounts in directories, shared passwords in password managers and identical credentials across hosts. Close the gap by issuing named identities, moving service access to dedicated non-interactive accounts and rotating any credential that was shared.

Unmanaged file shares

Shared drives and file sync tools often hold sensitive records with inherited permissions nobody has reviewed. Restrictions on the application do not stop a user from downloading or syncing the same files elsewhere. Ask which shares contain restricted data, who can reach them from outside the corporate network and whether downloads and sync are limited. Close the gap by applying data-level rules such as group, network location and file type restrictions, and by documenting which rules enforce which classification.

Leavers keeping access

Accounts that remain active after a departure, contractor end date or role change are among the most cited access failures. Directory entries may be disabled while application-local accounts, API tokens and group memberships survive. Compare HR leaver records against active accounts in each system. Close the gap by tying deprovisioning to the HR or contract end event, revoking sessions and tokens as well as the login, and recording the time each removal was completed.

Policy text that does not match configuration

A policy may state least privilege and segregation of duties while the systems grant broad group rights and let one person request and approve their own access. Assessors compare the written policy with exported configuration, so any gap between the two becomes a finding. Ask for the policy, then pick two or three of its statements and verify each in the live system. Close the gap by writing rules that name the actual groups, providers and enforcement points, and reviewing the policy whenever those settings change.

A.8.3 questions buyers ask before hiring help

How much effort does A.8.3 information access restriction take to implement?

Effort depends mostly on how many systems hold sensitive information, how many of them already enforce access through a central identity source, and how well the access control policy is written. A control like A.8.3 is largely about making the access control policy enforceable in each application and data store, so the work is usually spread across identity, application permissions and data-level settings rather than in one place. Systems with local user lists, shared accounts or file shares without group rules take the longest to bring in line. Ask any partner to break the effort down by system and by control area in the written scope, and to state which systems are excluded.

Can a small team implement A.8.3 in-house?

Yes, a small team can often do much of the work in-house if it owns the access control policy and has administrators who understand the applications it runs. The work tends to be hardest for teams that lack a central identity provider, because each application then needs its own permission model reviewed and documented. A useful split is to keep policy decisions, role definitions and sign-off with the organization, and to bring in outside help for platform configuration, integration and evidence collection where the team lacks time or experience. Whichever route you take, plan for someone to keep the access rules current after go-live.

How long does A.8.3 work usually take, and what does the timeline depend on?

No fixed duration can be given for A.8.3 because it depends on the number of applications in scope, the state of current identity data and how quickly decisions can be made about who should access what. The main drivers are the count of systems that need integration, whether group structures already exist, the number of data sets that need restriction rules, and the availability of the business owners who approve access. Ask for a timeline that lists milestones per system and names the client staff needed for each. Treat any single overall duration without that breakdown as a sign that the scope has not been examined.

What does the work require from our own staff?

The work needs staff who can make access decisions and staff who can operate the systems. Business owners must confirm which roles should see which information, and system owners must approve changes to permissions. Your identity or IT team needs time for directory data cleanup, testing of sign-in flows and reviewing exceptions. Security or compliance staff should own the access control policy and collect the records that show access reviews happened. Ask a partner to list these roles and the hours each one is expected to commit before the work begins, so that the dependencies are visible in the plan.

Can a partner issue our ISO 27001 certificate for A.8.3?

No. A partner can prepare systems, configurations, documentation and evidence for A.8.3, but only an accredited certification body can audit your management system and issue an ISO 27001 certificate. The organization also owns its controls and the Statement of Applicability that declares them. Be cautious with any vendor or consultant that describes itself as a certifier for the control itself. You can check accredited certificates through the database that ISO points to, and you can read more about the certification body role on ISO's certification page.

How do we confirm a partner's scope in writing before work starts?

Ask for a written statement of work that names the A.8.3 scope in terms of systems, applications, data stores and user populations, and that lists what is excluded. It should separate deliverables the partner produces, such as configuration records, integration designs and evidence templates, from tasks the organization keeps, such as policy approval and access decisions. Confirm the timeline, the client responsibilities, the handover format for evidence and the support terms after delivery. Most engagements are fixed-scope, so the written scope should also state what a change request would cost to process and how it is approved.

What evidence should we expect a partner to leave behind for A.8.3?

Expect a set of records that an assessor can trace back to the access control policy. Typical items include a list of protected systems and data sets, role and group definitions, configuration exports from the identity provider and applications, records of access reviews with decisions, and change logs for permission updates. The evidence should be stored in a location the organization controls and should be explained in a short runbook. Ask the partner to show a sample of each artifact during handover, and confirm which items the organization must keep current after the engagement ends.

How DeployOpen prepares A.8.3 access restriction evidence

DeployOpen plans, implements and documents self-hosted open-source identity, permission and review systems inside the client's own infrastructure, under a fixed scope agreed in writing before work starts. For A.8.3, that work usually centers on three layers: the identity provider that applications delegate sign-in to, the directory and single sign-on services that Linux and UNIX hosts rely on, and the access certification process that checks whether standing permissions still match the access control policy. The client decides which systems fall in scope, who approves access and how often reviews happen. DeployOpen configures the tools, writes the runbooks and collects the records that show those decisions were carried out.

The evidence an assessor will ask for is mostly operational: the access control policy and the topic-specific rules derived from it, a list of applications and their provider configurations, group and role definitions with their owners, Nextcloud file access rules where file-level restrictions are needed, and completed access certification campaigns with reviewer decisions and revocations. DeployOpen can prepare these artifacts and document how they were produced, so the client's team can explain them. Before the work starts, confirm with your auditor which evidence formats and sampling they expect, because an assessor tests the operation of the control over time, not only its configuration on the day of the review.

DeployOpen does not issue audit reports, attestations or certifications. Only an independent auditor or accredited certification body can assess the control and conclude on conformity. The organization remains responsible for its controls, its risk decisions and the accuracy of what it presents as evidence. A reasonable first step is a written scope that names the systems, roles and review cycle in question, followed by a check of the existing access control policy against the Statement of Applicability. Ask any implementation partner to state in the statement of work which parts of the evidence the client's own staff must produce and maintain after handover.