ISO 27001 A.8.3: restricting access to data, explained for startups

A.8.3 Information access restriction

People can reach only the data their role needs. What proves it: permissions set by role in your key systems, and a check that they match the access rules.

A certification auditor samples role-based permissions in key systems. A file that usually does the job: a role and permission export from your cloud provider or your application's admin panel.

How to put it in place

Each step leaves a record, and the record is what the auditor samples rather than the step itself. Inside Polara, the control card for A.8.3 walks you through it in this order.

1. Define roles for each key system and what each role can see.
2. Assign people to roles rather than giving individual permissions.
3. Check the roles during each access review.

No question in the readiness assessment covers A.8.3 directly, so the control card is its whole evidence path.

Policies, connectors and the SOC 2 overlap

In the ISO 27001 policy pack, the Access Control Policy covers A.8.3. An auditor reads the policy for the rule, then samples the records to see the rule was followed.

The same evidence counts toward SOC 2. The Trust Services criteria that cover this ground: CC6.1, logical access and CC6.3, least privilege.

Technological controls

A.8.3 is one of the 34 technological controls in Annex A. The controls built into your systems: access, devices, malware, vulnerabilities, backups, logging, networks, encryption and secure development. Exports and settings screenshots prove most of them.

Nearby controls in the same theme:

• A.8.1, laptops and phones
• A.8.2, privileged access
• A.8.4, source code access
• A.8.5, secure sign in
• A.8.6, capacity

Before it: A.8.2, privileged access. After it: A.8.4, source code access. Every control, by theme, is on the Annex A controls page.