What does control A.3.8 require?
The full life cycle of identities related to PII processing shall be managed.
This control sits within the shared security controls (Table A.3) and applies to both PII controllers and PII processors. It extends the standard ISO 27001 identity management requirements to specifically address systems that process personal data, recognising that compromised identities are one of the most common pathways to privacy breaches.
What does the implementation guidance say?
Annex B (section B.3.8) provides detailed guidance on identity lifecycle management for PII processing systems:
- Compromised credentials — Address situations where user access control is compromised, such as corruption or compromise of passwords. Have procedures in place to detect and respond to credential compromise promptly
- Deactivated/expired IDs — Do not reissue deactivated or expired user IDs for PII processing systems. This preserves the integrity of audit trails and prevents identity confusion
- Shared responsibility — Where customers (e.g. in a SaaS context) are responsible for some aspects of user ID management, this should be clearly documented in service agreements
- Jurisdiction-specific checks — Some jurisdictions require checks for unused credentials at a specific frequency. Identify and comply with any such requirements applicable to your organisation
- See also A.3.9: Access Rights for related requirements
- See also A.3.23: Secure Authentication for related requirements
The guidance covers the full lifecycle: creation, provisioning, modification, suspension, deactivation and deletion of identities. Each stage should be documented and controlled.
How does this map to GDPR?
Control A.3.8 maps to GDPR Article 5(1)(f) (integrity and confidentiality principle). Robust identity management is a core technical and organisational measure under Article 32 (security of processing). Compromised or poorly managed identities can lead to unauthorised access to personal data, which is both a security incident and a potential data breach requiring notification under Articles 33 and 34.
How does this relate to ISO 29100 privacy principles?
As a shared security control, A.3.8 supports the broader ISO 29100 framework. Identity management is a direct implementation of the information security principle, ensuring that only authorised individuals can access PII and that their access can be traced, reviewed and revoked throughout the identity lifecycle.
Free yourself from a mountain of spreadsheets
Embed, expand and scale your compliance, without the mess. IO gives you the resilience and confidence to grow securely.
What evidence do auditors expect?
When assessing compliance with A.3.8, auditors will typically look for:
- Identity lifecycle procedures — Documented procedures covering creation, modification, suspension and deactivation of user identities for PII processing systems
- Joiner/mover/leaver process — Evidence that identity changes are triggered by HR events (new starters, role changes, departures) and actioned promptly
- No reuse of deactivated IDs — Evidence that deactivated or expired user IDs have not been reissued to new users in PII processing systems
- Unused credential reviews — Evidence of periodic reviews to identify and deactivate dormant accounts, with documented frequency and results
- Compromise response — Procedures and evidence of response to credential compromise events (password resets, account lockouts, investigation records)
- Service agreements — Where customers manage their own user IDs, agreements that clearly define responsibilities
What are the related controls?
| Control | Relationship |
|---|---|
| A.3.4 Roles and responsibilities | Defined roles determine what access each identity should have |
| A.3.5 Classification of information | Access to higher-classified PII should be restricted to appropriately authorised identities |
| A.3.3 Policies for information security | Identity management procedures should implement the access control requirements defined in security policies |
| A.3.7 Information transfer | Identities used to access transfer systems must be managed through the same lifecycle controls |
| A.3.12 Response to Security Incidents | Identity compromise that leads to unauthorised access may trigger breach notification obligations |
What changed from ISO 27701:2019?
For a step-by-step approach, see the Transition from 2019 to 2025.
In the 2019 edition, this requirement was covered under Clause 6.6.2.1 (user registration and deregistration). The 2025 version broadens the scope to explicitly cover the full identity lifecycle, not just registration and deregistration. The guidance now includes specific provisions for compromised credentials, non-reuse of deactivated IDs, and jurisdiction-specific credential check requirements. See the Annex F correspondence table for the full mapping.
Manage all your compliance, all in one place
ISMS.online supports over 100 standards and regulations, giving you a single platform for all your compliance needs.
Why choose ISMS.online for identity management governance?
ISMS.online helps you govern the identity lifecycle for PII processing systems:
- Access control register — Document who has access to which PII processing systems, with role-based access levels linked to defined responsibilities
- Joiner/mover/leaver workflows — Trigger identity provisioning, modification and deactivation tasks from HR events, with tracked completion and approval
- Periodic access reviews — Schedule and track access reviews for PII processing systems, with built-in reminders and audit trail of review outcomes
- Incident response — Log credential compromise events and track the response through to resolution, including evidence of remediation actions taken
- Supplier access governance — Where third parties or customers manage their own identities, document the shared responsibility model and monitor compliance
- Compliance reporting — Generate reports on identity governance status, including dormant accounts, overdue reviews and open access change requests
FAQs
Why should deactivated user IDs not be reissued?
Reissuing a deactivated user ID to a new person creates ambiguity in audit trails. If a system logs actions by user ID, it becomes impossible to distinguish between actions taken by the original and subsequent holders of that ID. For PII processing systems, where audit trails are critical for demonstrating compliance and investigating incidents, this ambiguity is unacceptable. Always create new, unique user IDs for new users.
How often should we check for unused credentials?
At minimum, review unused credentials quarterly. Some jurisdictions or industry regulations may require more frequent checks. Automated tools can flag accounts that have not been used within a defined period (e.g. 90 days), allowing your team to investigate and deactivate dormant accounts promptly. Combine automated detection with a manual review process to catch accounts that may have been missed.
What should we do when credentials are compromised?
Immediately reset or suspend the compromised credentials and investigate the scope of the compromise. Determine whether any PII was accessed or exfiltrated. If a personal data breach has occurred, assess the need for notification under applicable legislation (e.g. GDPR Articles 33 and 34). Document the incident, the response actions taken and the outcome. Review the root cause and implement measures to prevent recurrence, such as enforcing multi-factor authentication or strengthening password policies.
