ISO 27001 and GDPR: What the ISMS Covers—and What It Does Not

ISO/IEC 27001 can provide much of the operating discipline needed to protect personal data, but an ISO 27001 certificate does not demonstrate compliance with the EU General Data Protection Regulation. The two frameworks solve different problems. ISO 27001 defines requirements for an information security management system (ISMS); the GDPR creates legal duties concerning personal data, individual rights, accountability and regulatory response.

The productive question is therefore not whether one “covers” the other. It is which GDPR outcomes can rely on ISMS processes and which require additional privacy, legal and operational work. That distinction prevents duplicate controls while keeping important legal obligations visible.

Start with scope, not a control crosswalk

An ISO 27001 scope may cover one product, legal entity or location. GDPR obligations follow the processing of personal data and the organisation’s role as controller or processor. Those boundaries can differ materially.

Map three views before comparing requirements:

1. ISMS boundary: entities, services, locations, technology and interfaces included in the management system.
2. Processing boundary: personal-data purposes, categories, data subjects, systems, recipients, locations and retention periods.
3. Legal-role boundary: where the organisation acts as controller, joint controller or processor, including changes by service or processing activity.

If a payroll application is outside the ISMS but processes employee data, the certification scope does not address that processing. If a SaaS platform is in scope, the organisation still needs to determine whether it is a controller for account data and a processor for customer content.

Where an ISMS creates useful GDPR foundations

The official ISO overview describes ISO/IEC 27001:2022 as a risk-based management system for establishing, implementing, maintaining and continually improving information security. That structure supports several GDPR obligations without replacing their legal interpretation.

Risk and security governance

ISMS risk assessment can help identify confidentiality, integrity and availability threats to personal data. Risk treatment can assign controls, owners, resources and acceptance decisions. This is valuable for GDPR Article 32, which requires measures appropriate to risk, and for the accountability principle more broadly.

The same risk record is not automatically a data protection impact assessment. A DPIA examines likely high risks to people’s rights and freedoms, the necessity and proportionality of processing, and measures addressing those risks. Security risk may be one input, but privacy harms can arise even when data remains confidential—for example, from unfair profiling or excessive collection.

Asset, data and dependency visibility

Asset inventories, ownership, data-flow documentation and supplier records can support records of processing and processor oversight. They help teams answer where personal data resides, which systems protect it and which third parties can access it.

However, a technical asset inventory rarely records every GDPR field. Legal basis, processing purpose, data-subject category, transfer mechanism and retention justification need their own structured records. Use the required documented information guide to avoid confusing useful ISMS records with documents that privacy law may require.

Access, secure development and operational control

Access control, identity lifecycle management, logging, vulnerability management, secure engineering, backup and change control can all support protection of personal data. The relevant controls should be selected through risk treatment rather than applied as an unexamined universal set.

Evidence should demonstrate operation, not merely design. For access control, examine approved access, periodic reviews, removals and exceptions. For secure development, trace privacy and security requirements into design decisions, tests and releases. The Annex A control lookup helps locate control themes, but legal counsel or a privacy specialist should determine how the GDPR applies to a particular processing activity.

Incident detection and response

An ISMS can provide reporting channels, triage, investigation, containment, recovery and lessons learned. GDPR response adds a personal-data breach assessment: whether confidentiality, availability or integrity of personal data was compromised; the likely risk to individuals; whether supervisory notification is required; and whether affected people must be informed.

The GDPR sets a 72-hour supervisory notification rule where notification is required, measured from awareness, with reasons required for delay. That makes early legal and privacy participation essential. The incident-management evidence guide explains how to preserve decisions and operating records across the response lifecycle.

Supplier governance

ISO 27001 supplier controls can support due diligence, contractual security, service monitoring and change management. GDPR Article 28 imposes specific processor-contract terms and conditions for engaging subprocessors. A generic security schedule or an ISO certificate is not enough by itself.

Review the supplier’s role, processing instructions, assistance duties, breach notice, deletion or return arrangements, audit provisions and transfer conditions. Then connect those legal terms to the ongoing security assurance described in the supplier audit guide.

What ISO 27001 does not decide

Several GDPR questions remain outside the core purpose of an ISMS:

GDPR concern	Why the ISMS is insufficient on its own	Additional evidence
Lawful basis	Security controls do not determine whether processing is lawful	Purpose and basis assessment, consent or contract records where relevant
Transparency	An ISMS does not establish what information must be given to individuals	Privacy notices, change approvals and delivery records
Individual rights	Access control is not a process for access, erasure, objection or portability requests	Request log, identity verification, searches, decisions and response records
Data minimisation	Protecting collected data does not show that collection is necessary	Field-level purpose review and product decision records
Retention	Backup and deletion controls do not set lawful retention periods	Retention schedule, legal rationale and disposal evidence
International transfers	Supplier security does not create a valid transfer mechanism	Transfer inventory, mechanism and transfer-risk assessment where required
DPIAs	Information-security risk is narrower than risk to people	DPIA method, consultation, approval and review records
Data protection officer	ISO 27001 does not decide whether designation is legally required	Applicability assessment, appointment and independence evidence

The official GDPR text remains the authoritative starting point. Member-state law and supervisory guidance may also affect the analysis. AuditPrepared guidance is operational, not legal advice.

Build one evidence model with separate conclusions

Create a mapping at the level of outcomes and evidence rather than forcing clause-to-article equivalence. For each processing activity, record:

• the GDPR obligation and accountable privacy owner;
• the supporting ISMS process and owner;
• shared records, such as risk decisions or incident timelines;
• privacy-specific records still required;
• scope limitations and assumptions; and
• how often operation will be tested.

For example, one incident ticket may support both systems. The security team owns technical investigation and recovery; the privacy team assesses personal-data impact and notification; legal validates regulatory interpretation; communications manages approved messages. The same evidence can be referenced, but the conclusions remain distinct.

Audit the relationship without overclaiming

A combined review should sample both management-system operation and privacy outcomes. Useful questions include:

• Does the processing inventory reconcile to ISMS assets and supplier records?
• Are privacy risks visible when security risk is accepted?
• Can the organisation identify when it became aware of a personal-data breach?
• Do processor contracts match actual subprocessors and data locations?
• Can a rights request find data across primary systems, archives and relevant providers?
• Are retention rules implemented and tested, including exceptions?

Pass, partial and fail examples

Pass: A sampled service has an identified legal role and purpose, reconciled data flow, current risk decisions, effective security controls, tested rights handling and processor oversight. Evidence spans both governance systems.

Partial: The service sits within the ISMS and security controls operate, but the processing record omits a subprocessor and the transfer assessment has not been updated. Security assurance is present; the GDPR conclusion remains incomplete.

Fail: The organisation presents an ISO certificate as its sole GDPR evidence and cannot show lawful basis, rights handling, breach decisions or processor terms for the sampled processing.

A defensible conclusion

ISO 27001 can make GDPR security and accountability work more repeatable. It brings risk ownership, controlled processes, evidence, audit and improvement. It does not answer the legal questions that define lawful processing or the rights owed to individuals.

Use the ISMS as an operational backbone, then add privacy-specific roles, decisions and records. Keep scope differences explicit, test both systems through the same real processing activities and report separate conclusions. That approach captures the efficiency of integration without creating false assurance.