How does identity security support data protection compliance?

Identity security supports data protection compliance by providing evidence that access to personal data is controlled, justified and reviewable. It is one part of the technical and organisational measures required by the UK GDPR and the Data Protection Act 2018, helping an organisation apply principles such as confidentiality, integrity, accountability and data protection by design.

It connects access decisions with data protection responsibilities. A data protection programme should identify what personal data is held, why it is processed, who needs to use it and how long it should be retained. Identity security gives effect to those decisions by linking access rights to defined roles, employment status, contractual duties and business requirements. A finance employee, for example, may need access to supplier records but not employee health information, while a system administrator may need technical access without being permitted to use the underlying business data for unrelated purposes.

Access should therefore be based on a documented business need rather than convenience. Role-based access, attribute-based rules and separate administrative accounts can help prevent broad permissions becoming the default. Where a person’s responsibilities change, their access should change with them. When an account is no longer required, it should be disabled or removed as part of the organisation’s joiner, mover and leaver process.

Identity governance also supports accountability. Organisations should be able to explain who approved access, which role or rule allowed it, when the permission was granted, and when it was last reviewed. This information can support records of processing, internal control testing, audits and investigations. Evidence should be understandable and linked to a named owner; a collection of technical logs without context is less useful than a clear record showing the decision, approver, scope and review outcome.

• Access requests and approvals, including the business justification.
• Changes to roles, groups and permissions.
• Successful and failed sign-in activity where relevant to the risk.
• Use of privileged accounts and administrative functions.
• Periodic access attestations and actions taken to correct inappropriate access.
• Account disablement when a user, supplier or service no longer requires access.

Logs should be protected from unauthorised alteration and retained for an appropriate period. Retaining every identity record indefinitely can create its own data protection issue, particularly where logs contain usernames, device identifiers or details about user activity. A documented retention schedule should specify what is recorded, why it is needed, who can view it and when it will be securely deleted or anonymised.

Identity security can reduce the impact of a personal data breach, but it cannot remove the need for breach management. Detection of unusual sign-in behaviour, disabled accounts, access from unexpected locations or changes to privileged permissions may help an organisation investigate an incident. The response process should then establish which identities, systems and data were affected, preserve relevant evidence, contain the access and assess whether notification duties apply. A security control is not a substitute for the organisation’s legal assessment of a breach.

Special care is needed for privileged identities, shared accounts, service accounts and external users. Administrative access should be separated from ordinary work, granted only for defined tasks and monitored appropriately. Shared credentials weaken accountability because actions cannot reliably be attributed to an individual. Service accounts should have a named owner, a defined purpose, limited permissions, controlled credentials and a review or retirement process. Supplier access should be limited to the systems and data necessary for the agreed service, with responsibilities recorded in the relevant contractual arrangements.

Identity controls should be proportionate to the risk. A data protection impact assessment may identify the sensitivity and volume of personal data, the consequences of unauthorised access, the number and type of users, and the exposure created by remote or third-party access. Those findings can inform authentication requirements, approval levels, monitoring, segregation of duties and review frequency. Higher-risk processing may require stronger and more closely monitored controls than a low-risk internal application.

Compliance also depends on operational discipline. Policies should state how identities are created, verified, changed, suspended and deleted. Staff and administrators need guidance on credential handling, suspicious access and reporting routes. Control owners should test whether policies operate in practice rather than relying solely on their existence. Where an organisation uses a cloud platform or managed service, it should understand which identity controls it operates itself and which are provided by the supplier.

Identity security is therefore best treated as an auditable control framework rather than a single product or configuration. It helps demonstrate that access is connected to a legitimate purpose, limited to what is necessary, monitored over time and removed when no longer justified. S2 Technology Group can help organisations review these identity and access arrangements alongside wider IT security and governance requirements, while formal compliance decisions remain the responsibility of the organisation and its advisers.