Running GDPR and ISO 27001 Together: One Program, Not Two

An SMB subject to GDPR and pursuing ISO 27001 certification often ends up running two programs: a GDPR track for the supervisory authority and an ISMS track for the certificate. The expensive part is not either standard — it is the duplication. The GDPR security measures and the ISO 27001 Annex A controls are the same controls written into two ledgers.

GDPR and ISO/IEC 27001:2022 are different instruments. GDPR is a data-protection regulation with an accountability principle — the controller must demonstrate compliance, and the Article 30 RoPA, the DPIA, and the Article 32 security measures are its evidence. ISO 27001 is a management-system standard — define scope, run a risk assessment, pick Annex A controls, operate the ISMS, audit it. They are not the same, but they share the entire operational security surface: access control, encryption, logging, vulnerability management, incident response, vendor management, business continuity. An SMB that merges them pays for that surface once.

This is the cross-pillar companion to the GDPR pillar and the ISO 27001 pillar, and the GDPR-side mirror of the PCI DSS / ISO 27001 joint implementation.

Why an SMB ends up with both

GDPR applies the moment you process personal data of EU data subjects — for most SMBs, that is every customer and employee. ISO 27001 is a choice, pulled in by a customer security questionnaire, an enterprise or public-sector contract requirement, or a deliberate decision to build a security program. An SMB that hits both rarely plans the overlap; it acquires each separately and discovers the duplicate cost when the second evidence-gathering sprint re-collects what the first already had.

The fix is one program with two reporting outputs, designed from the start.

Scope: the ISMS scope contains the GDPR processing

ISO 27001 lets you define the ISMS scope (clause 4.3). GDPR applies to all processing of EU personal data, regardless of scope statements. The efficient shape: make the ISMS scope cover the systems and business units that process personal data, so the security controls the GDPR Article 32 measures require are the controls the ISMS operates and audits. A narrower ISMS scope that excludes the CRM or the HR system leaves the GDPR processing outside the audited perimeter — the worst outcome, because you run GDPR controls and ISO 27001 controls separately on adjacent systems.

One network diagram, one asset register, one system inventory — used by both. The RoPA tells you what is processed where; the ISMS asset register tells you what is secured how. They reference the same systems.

Article 32 and Annex A: one set of security measures

GDPR Article 32 requires security measures appropriate to the risk — pseudonymisation and encryption where appropriate, confidentiality, integrity, availability and resilience, and a process for regularly testing and evaluating the effectiveness of those measures. It does not prescribe specific controls. ISO 27001 Annex A is the control catalogue. The Article 32 "general description of technical and organisational security measures" that the RoPA records (Article 30(1)(g)) is the GDPR-facing summary of the Annex A controls the ISMS operates.

The merge: write each control once under ISO 27001, and cite it from the RoPA’s security column. A combined control matrix maps the overlap:

Write one policy and one evidence routine per row; the RoPA’s security column points at the ISMS control, and the ISMS control references the RoPA activity it protects.

Risk assessment: one assessment, two cuts

ISO 27001 mandates a risk assessment (clauses 6.1.2, 6.1.3) covering the ISMS scope — the ISO 27001 risk assessment is the broad artifact, producing the Statement of Applicability.

GDPR requires a DPIA (Article 35) for high-risk processing, not a full ISMS risk assessment. The DPIA template is a narrower, personal-data-impact cut.

The merge: run the ISO 27001 risk assessment once at ISMS scope, then carve the personal-data-impact rows into DPIAs for the high-risk processing operations the RoPA flagged. Same threat list, same asset register; the DPIA’s "risks to data subjects" section is the GDPR cut of the ISMS risk register’s personal-data rows. One analysis, two documents generated from it.

Incident response: one runbook, two notification clocks

This is the highest-value merge. GDPR Article 33 starts a 72-hour breach-notification clock; ISO 27001 Annex A.5.24–A.5.27 requires an incident-response plan with detection, reporting, assessment, response, and learning. The data subject rights and 72-hour clock article describes the GDPR breach runbook.

The merge: one incident-response procedure (the ISMS A.5.24 plan), with the GDPR 72-hour notification steps embedded as a branch — when the incident is a personal-data breach, the procedure runs the Article 33(3) notification template and the Article 34 high-risk communication decision. One runbook, one breach register, one tabletop exercise (ISO 27001 tabletop) that tests both the ISMS response and the GDPR 72-hour path. The breach register is the evidence both auditors ask for.

Vendor management: one DPA, one Annex A.5.19 assessment

GDPR Article 28 requires a data-processing agreement with every processor; ISO 27001 Annex A.5.19–A.5.23 requires supplier relationship management including security assessment. The merge: one vendor register, where each vendor row carries both the Article 28 DPA status (signed / pending) and the A.5.19 security assessment (passed / gaps). The vendor security questionnaire you send is the same artifact for both standards — the answers feed the RoPA’s recipient column (GDPR) and the supplier risk register (ISO 27001).

The evidence-sharing pattern

Evidence folders organised by control topic, not by standard:

evidence/
access-control/        # policy + access reviews → Art 32 + A.5.15
encryption/            # crypto inventory + key mgmt → Art 32(1)(a) + A.8.24
logging/               # log config + review records → Art 32 + A.8.15
vuln-mgmt/             # scan reports + remediation → Art 32(1)(d) + A.8.8
incident-response/     # IRP + breach register + 72h template → Art 33-34 + A.5.24
vendor-mgmt/           # DPA register + supplier assessments → Art 28 + A.5.19
risk/                  # ISMS risk register + DPIA rows cut from it
ropa/                  # Article 30 RoPA (GDPR-specific)
soa/                   # Statement of Applicability (ISO 27001-specific)
isms-governance/       # mgmt review, internal audit minutes (ISO 27001-specific)
data-subject-requests/ # request log + responses (GDPR-specific)

The GDPR auditor asks for incident-response evidence → incident-response/. The ISO 27001 auditor asks the same → same folder. The ropa/, data-subject-requests/, soa/, isms-governance/ folders are the single-standard work, isolated so the shared controls stay clean.

The cadence: align the years

Run the two on a single annual heartbeat:

1. Risk refresh — update the ISO 27001 risk assessment; cut the new DPIA rows for GDPR high-risk processing.
2. Control review — walk the combined matrix; update policies; record evidence; refresh the RoPA’s security column.
3. Internal audit (ISO 27001 9.2) — audit the merged program against both standards’ control expectations, including a sample of data-subject requests.
4. Management review (9.3) — present results, including GDPR compliance status.
5. DPIA review — confirm flagged high-risk operations still have valid DPIAs; run new DPIAs before new high-risk processing goes live.

Stagger the internal audit ahead of any GDPR supervisory-authority interaction so the same evidence gets reviewed internally first.

Where the standards genuinely diverge

• Data subject rights (Articles 15–22). GDPR’s rights machinery — access, rectification, erasure, portability, objection, automated-decision rights — has no ISO 27001 analog. The request-handling process is GDPR-only work.
• Breach notification to a supervisory authority (Article 33) and to data subjects (Article 34). ISO 27001 has incident response but no external-notification-to-authority clock. The 72-hour template and the high-risk communication decision are GDPR-only work.
• RoPA. The Article 30 register is GDPR-only.
• DPIA vs ISMS risk assessment. Both are risk analyses but the DPIA is personal-data-impact scoped and trigger-defined; the ISMS risk assessment is broader. They are different documents cut from the same analysis.
• ISMS management clauses. ISO 27001 clauses 5 (leadership), 9 (internal audit, management review), 10 (continual improvement) are the management-system machinery; GDPR has no equivalent.

Operational controls merge; rights machinery, notification clocks, RoPA, and ISMS governance do not.

How this fits the series

This is the cross-pillar bridge between the GDPR pillar and the ISO 27001 pillar, and the GDPR-side mirror of the PCI DSS / ISO 27001 joint implementation. It assumes you have read the RoPA, the data subject rights and 72-hour clock, and the DPIA template — the merge rests on those artifacts — and the ISO 27001 risk assessment and SoA template on the ISO side.

What to do next

If you are running GDPR and ISO 27001 as separate projects, the first move is the combined control matrix — one row per topic, the GDPR article and Annex A control side by side. That document shows the overlap and the single-standard tails in one view. Reorganise your evidence folders by control topic. Embed the GDPR 72-hour notification branch into the ISMS incident-response plan, and run one tabletop that exercises both paths. The merge collapses two evidence sprints into one; the single-standard work stays isolated and small.

Running GDPR and ISO 27001 as separate projects and paying for it twice? Book a joint-program design session — we build the combined control matrix, embed the 72-hour notification path into your incident-response plan, and sequence the audit cadence so one internal audit feeds both. Bilingual EN/FR, no obligation. → /contact · /iso-27001-assessment/ · download the GDPR for SMBs readiness guide