ISO 27001 A.5.16: identities and accounts, explained for startups

A.5.16 Identity management

Every person has one account of their own, created and removed in a controlled way. What proves it: each person has a unique account from your identity provider, and the account list matches your staff list.

A certification auditor samples identity provider user list compared with the staff list. A file that usually does the job: an identity provider user export next to the staff list, with any extra accounts explained.

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.5.16 walks you through it in this order.

1. Use one identity provider, such as Google Workspace, Microsoft Entra or Okta, for every staff account.
2. Stop using shared logins, or name an owner for each one you cannot remove.
3. Compare accounts with the staff list every quarter.

The free ISO 27001 readiness assessment asks one question that evidences it:

• Which identity provider do your staff sign in to work systems with?

Policies, connectors and the SOC 2 overlap

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

Connected systems that pull evidence for it:

• Amazon Web Services, IAM users: who has access, with each user's multi-factor authentication status and last login.
• GitHub, Organization members: all members of the organization with their access type.
• Google Workspace, Directory users: all users in the Workspace domain with admin, suspended and 2-Step Verification enrollment status.
• Okta, Users and last sign-in: Okta users with their status and last sign-in time.
• Microsoft Entra ID, Users and last sign-in: directory users with their enabled status, user type and last sign-in.
• Linear, Workspace members: Workspace members with their active, admin and guest status.
• Jira, Site users: users on the Jira site with their active status and account type.
• Slack, Workspace members: Workspace members, admins, guests and deactivated accounts.

The same evidence counts toward SOC 2. The Trust Services criterion that cover this ground: CC6.2, user provisioning.

Organizational controls

A.5.16 is one of the 37 organizational controls in Annex A. How the company runs security: policies, roles, suppliers, incidents, continuity and legal duties. Most of these are written decisions and the records that show you follow them.

Nearby controls in the same theme:

• A.5.13, labeling information
• A.5.14, sending information out
• A.5.15, access control rules
• A.5.17, passwords and secrets
• A.5.18, granting and removing access
• A.5.19, supplier security

Before it: A.5.15, access control rules. After it: A.5.17, passwords and secrets. Every control, by theme, is on the Annex A controls page.