| Scope and covered activity | ISO/IEC 27018 gives public-cloud PII processor privacy guidance for handling customer instructions, disclosure, deletion, and processor evidence. | GDPR is binding EU personal data law for controllers, processors, lawful processing, data-subject rights, security, breach response, and transfers. | Write the scope memo so teams can see when ISO/IEC 27018 is the implementation structure, when GDPR controls the obligation or assurance question, and where evidence can be reused without changing the source test. |
|---|
| Who must act | ISO/IEC 27018 ownership should sit with the team that can operate the relevant management system, control process, risk method, supplier relationship, incident process, privacy process, or AI governance scope. | GDPR ownership should sit with the controller or processor that carries the Article 28 processor duties or Article 24 accountability obligations, with the relevant supervisory authority as the public enforcer where the law applies. | Do not copy owners from one side to the other; map accountable owners, reviewers, and approvers separately. |
|---|
| Trigger or threshold | ISO/IEC 27018 work is triggered by scope definition, implementation, certification readiness, customer assurance, control gaps, incidents, supplier changes, or management review. | GDPR work is triggered by its own legal, assurance, framework, contract, customer, or risk-management event. | Use the trigger to route intake: standards implementation, regulatory response, assurance report, framework mapping, customer request, or operational remediation. |
|---|
| Core obligations | ISO/IEC 27018 requires practical governance: scope, roles, risk or impact decisions, evidence, operating cadence, monitoring, review, and improvement. | GDPR expects its own required or recommended outcomes, which may include legal duties, assurance criteria, control objectives, profiles, or risk methodology. | Translate both sides into a single task register only after labeling which requirement or guidance source each task satisfies. |
|---|
| Evidence and records | ISO/IEC 27018 evidence should show the process operating: owners, decisions, registers, control records, test results, review minutes, audit samples, or corrective actions. | GDPR evidence should match its own proof model, such as regulatory records, attestation evidence, framework profiles, risk analysis, or contractual assurance. | Build an evidence matrix with one row per claim and columns for source, owner, artifact, date, review trigger, and reuse permission. |
|---|
| Timing and cadence | ISO/IEC 27018 timing follows implementation, audit, certification, review, supplier, incident, or change cycles rather than a single universal deadline. | GDPR timing follows the legal effective date, assurance period, framework version, contract milestone, or publication lifecycle that applies to that side. | Track dates separately so an ISO review cycle does not get mistaken for a statutory deadline or assurance reporting period. |
|---|
| Enforcement or assurance route | ISO/IEC 27018 is usually tested through certification audits, internal audits, customer assurance, management review, or governance review, depending on how the organization adopts it. | GDPR is a binding EU regulation: organizations must meet applicable legal duties, and audits or attestations may test compliance evidence, but GDPR is not a voluntary framework that teams can choose to adopt. | Separate audit readiness from legal compliance and from voluntary framework maturity so executives see the actual consequence of gaps. |
|---|
| Overlap and reuse | ISO/IEC 27018 can supply reusable management-system evidence, control operation records, risk decisions, and review outputs. | GDPR can reuse some of that evidence when the control, process, risk, or duty is genuinely the same. | Reuse evidence only after checking scope, actor, date, data type, service, supplier, and acceptance criteria; otherwise keep separate records. |
|---|
| Practical decision rule | Use ISO/IEC 27018 when the main work is building, operating, reviewing, or proving a management-system or standards-based control process. | Use GDPR when the main work is satisfying that side's law, assurance route, framework outcome, risk method, or external reporting expectation. | If both apply, keep the primary obligation visible and use the other side as supporting structure, not as a substitute source. |
|---|