# Public Cloud PII Processor Controls: [Organization name]

> Records how a public cloud service provider that processes personally
> identifiable information (PII) on behalf of its customers meets the
> practice set out in ISO/IEC 27018:2025, the third edition: the
> commitments made in customer agreements, transparency, sub-processor
> management, return and deletion, legally binding disclosure requests,
> breach notification and a control implementation table in the
> provider's own words. It sits on top of an ISMS under ISO/IEC
> 27001:2022 + Amd 1:2024 or a PIMS under ISO/IEC 27701:2025. Replace
> every `[bracketed]` value and every row marked *Example*. This is a
> documentation format, not legal advice.

<!--
Guidance: How to use this template
- Use it when the organization offers a public cloud service (IaaS,
  PaaS or SaaS) and customers upload personal data that the
  organization processes only on their behalf. A SaaS company that
  hosts its customers' user data is in this position.
- Fill section 3 (service and roles) and section 4 (customer agreement
  commitments) first: the rest of the document proves those
  commitments are kept.
- Main pitfall: making promises in the data processing agreement or on
  the trust page that operations cannot prove, such as deletion of
  backups within a fixed period, or notice of every new sub-processor.
  Every commitment in section 4 must have an owner and a record.
- ISO/IEC 27018 is a guidance standard, not a certifiable management
  system standard on its own. Organizations usually show conformity
  through the ISMS or PIMS audit with the 27018 controls in scope, or
  through independent attestation. Do not claim a "27018
  certification" unless your certification body confirms the wording.
- Related templates: `isms/pims-27701-statement-of-applicability`,
  `isms/cloud-services-security-policy`, `isms/cloud-27017-controls`,
  `legal-lite/dpa`, `isms/customer-security-addendum`,
  `isms/supplier-register`, `compliance/personal-data-breach-assessment`,
  `isms/cloud-exit-plan`.
-->

## Document control

<!-- Guidance: Owner is usually the privacy lead or the head of the cloud platform, with legal as reviewer because the commitments appear in contracts. Auditors check that the version here matches what is published to customers. -->

| Field | Value |
|---|---|
| Document ID | DOC-ISMS-103 |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@privacy-lead] |
| Approvers/reviewers | [@cto], [@legal-counsel], [@dpo], [@isms-manager] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal; section 5 content may be published] |
| Standard and edition | ISO/IEC 27018:2025; ISO/IEC 27002:2022; ISO/IEC 29100:2024; ISO/IEC 27001:2022 + Amd 1:2024 or ISO/IEC 27701:2025 |
| Next scheduled review | YYYY-MM-DD (at least every 12 months and after any change of sub-processor, region or contract template) |
| Services covered | [Service names and editions] |
| Hosting regions | [Region list] |
| Related documents | ISMS SoA DOC-ISMS-011, PIMS SoA DOC-ISMS-101, cloud services security policy DOC-ISMS-044, supplier register DOC-ISMS-066, customer security addendum DOC-ISMS-117 |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Document owner | [@privacy-lead] | [Prepared] | YYYY-MM-DD |
| Platform owner | [@cto] | [Approved] | YYYY-MM-DD |
| Legal | [@legal-counsel] | [Reviewed] | YYYY-MM-DD |
| Data protection officer | [@dpo] | [Reviewed] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 *(Example)* | YYYY-MM-DD | [@privacy-lead] | First version aligned with the 2025 edition |
| 1.1 *(Example)* | YYYY-MM-DD | [@privacy-lead] | New sub-processor SUBP-004 added for e-mail delivery |
| [x.y] | YYYY-MM-DD | [@author] | [Change summary] |

## Contents

<!-- Guidance: Sections 3 to 10 are the commitments and how they run; section 11 is the control table auditors walk; sections 12 to 14 keep it current. -->

1. Purpose and scope
2. ISO/IEC 27018:2025 at a glance
3. Service description and roles
4. Customer agreement commitments
5. Transparency
6. Sub-processor management
7. Assistance with data subject rights
8. Return, transfer and deletion
9. Legally binding disclosure requests
10. Breach notification
11. Control implementation table
12. Size tiers
13. Records and evidence
14. Review and maintenance
15. References

## 1. Purpose and scope

<!-- Guidance: Name the services and the customer data covered. Pitfall: covering only the production database and forgetting support tickets, logs and backups, which also hold customer PII. -->

This document sets out how [Organization name] protects PII that
customers place in [service name] when the organization acts as a PII
processor in a public cloud. It covers:

- customer content that contains PII (for example records uploaded or
  generated by customer users);
- PII in service operations data: support tickets, logs, backups,
  temporary files and test copies;
- every environment, region and sub-processor that touches that PII.

It does not cover processing where the organization is the controller
(for example its own staff, billing contacts or marketing data). Those
activities are handled in the PIMS scope (DOC-ISMS-100) and the record
of processing activities (`compliance/gdpr-ropa`).

## 2. ISO/IEC 27018:2025 at a glance

<!-- Guidance: Describe the standard at the level you can confirm in your copy. The third edition was published in August 2025 and replaces the 2019 edition. Published summaries describe guidance arranged by the ISO/IEC 27002:2022 themes plus an extended control set for public cloud PII processors aligned with the ISO/IEC 29100:2024 principles (Annex A). Summaries differ on Annex B: some describe it as a correspondence to the 2019 edition, others as extended implementation guidance. Confirm these details in your copy and record the references below. -->

ISO/IEC 27018:2025 gives guidelines for public cloud service
providers acting as PII processors. It adds cloud and privacy guidance
to the information security controls of ISO/IEC 27002:2022 and adds a
further set of controls specific to protecting PII in a public cloud.
It is used together with an ISMS or a PIMS; it does not replace them.

| Part of the standard | Use in this document | Reference confirmed in your copy |
|---|---|---|
| Cloud PII guidance added to ISO/IEC 27002:2022 controls | Section 11, rows with an ISMS link | [27018 clause ref] |
| Extended control set for public cloud PII processors | Sections 4 to 10 and section 11 | [27018 annex ref] |
| Correspondence with the 2019 edition | Transition of existing mappings | [27018 annex ref] |

Providers that mapped their controls to the 2019 edition should re-map
to the 2025 edition and update customer-facing statements. Where a PIMS
is run, published summaries of ISO/IEC 27701:2025 report an informative
mapping to ISO/IEC 27018 that helps align the two control sets; confirm
it in your copy of each standard.

## 3. Service description and roles

<!-- Guidance: Make the shared responsibility explicit. Questions to answer: who decides what PII is uploaded, who configures access, who is responsible for each layer? Pitfall: leaving customers to assume the provider handles their legal duties as controller. -->

| Item | Value |
|---|---|
| Service model | [SaaS / PaaS / IaaS] |
| Customer role | PII controller (or processor, where the customer itself serves another controller) |
| Provider role | PII processor (sub-processor where the customer is a processor) |
| Infrastructure provider | [Public cloud IaaS provider], a sub-processor of the organization |
| Categories of PII | [Customer end-user identifiers, contact details, usage events] *(Example)* |
| Special categories | [None by design / Health data for some customers] |
| Hosting | [Primary region], [DR region] |

| Responsibility | Customer | Provider | Sub-processor |
|---|---|---|---|
| Decide purposes and lawful basis | Owns | Does not decide | None |
| Decide which PII is uploaded | Owns | Advises on minimization features | None |
| Configure user accounts and roles in the service | Owns | Provides features and secure defaults | None |
| Protect the application and data layer | Shares (configuration) | Owns | Supports |
| Protect infrastructure | None | Oversees | Owns |
| Notify data subjects and authorities of a breach | Owns | Notifies the customer and assists | Notifies the provider |
| Respond to data subject requests | Owns | Assists | Assists where needed |

## 4. Customer agreement commitments

<!-- Guidance: List every privacy commitment the organization makes in its DPA, terms and trust page. Each needs an owner, an operating mechanism and a record. Auditors and customers will ask for proof of any one of them. -->

| ID | Commitment (own wording) | Mechanism | Owner | Record |
|---|---|---|---|---|
| COM-001 *(Example)* | Process customer PII only on the customer's documented instructions | DPA, service terms, change review for new uses | [@legal-counsel] | Signed DPAs, change records |
| COM-002 *(Example)* | Never use customer PII for marketing or advertising without express consent | Technical separation, marketing data policy | [@dpo] | Data flow reviews |
| COM-003 *(Example)* | Bind all personnel with access to confidentiality | Contracts and confidentiality agreement DOC-ISMS-051 | [@hr-lead] | Signed agreements |
| COM-004 *(Example)* | Disclose sub-processors and give notice before changes | Public list, notice period of [30] days *(Example)* | [@legal-counsel] | List history, notices sent |
| COM-005 *(Example)* | State the countries where PII may be processed | Region list, transfer mechanisms | [@legal-counsel] | Published location statement |
| COM-006 *(Example)* | Notify the customer of a breach affecting their PII without undue delay | Incident process, notice target [48] hours *(Example)* | [@security-lead] | Incident register DOC-ISMS-021 |
| COM-007 *(Example)* | Inform the customer of legally binding disclosure requests unless prohibited | Disclosure request procedure (section 9) | [@legal-counsel] | Disclosure log |
| COM-008 *(Example)* | Return and then delete customer PII at the end of the contract | Export tool, deletion runbook (section 8) | [@cto] | Deletion certificates |
| COM-009 *(Example)* | Assist the customer with data subject requests | Support runbook (section 7) | [@head-of-support] | Tickets |
| COM-010 *(Example)* | Allow the customer to verify compliance | Audit reports, certificates, questionnaire answers, audit right in DPA | [@isms-manager] | Shared reports log |

Keep the commitment wording here identical to the DPA template
(`legal-lite/dpa`) and the customer security addendum (DOC-ISMS-117).
When legal changes the contract template, update this table in the same
change.

## 5. Transparency

<!-- Guidance: Decide what is published and what is shared on request. Pitfall: a trust page that goes stale. Assign a review date to each item. -->

| Information | Published where | Update rule | Owner |
|---|---|---|---|
| Sub-processor list (name, service, location) | [Trust page URL] | On every change, before the change takes effect | [@legal-counsel] |
| Processing locations and transfer mechanisms | [Trust page URL] | On region change | [@legal-counsel] |
| Certificates and attestation reports | [Trust page, under NDA for reports] | On issue | [@isms-manager] |
| Security and privacy overview | DOC-ISMS-116 | Every 12 months | [@isms-manager] |
| Contact for privacy questions | [Trust page, DPA] | On change | [@dpo] |
| Retention and deletion periods for customer data | [Documentation page] | On change | [@cto] |

## 6. Sub-processor management

<!-- Guidance: Every party that can access customer PII is a sub-processor, including support tools and e-mail services. Questions to answer: is the same level of protection flowed down by contract, and are customers notified in time to object? Auditors sample a recent change and follow it through the flow. -->

```mermaid
flowchart TD
  A["Need for a new sub-processor"] --> B["Security and privacy assessment"]
  B --> C{"Assessment acceptable?"}
  C -- "No" --> D["Reject or require remediation"]
  C -- "Yes" --> E["Contract with flow-down terms"]
  E --> F["Update public list and notify customers"]
  F --> G{"Customer objection within notice period?"}
  G -- "Yes" --> H["Resolve: alternative, exemption or termination right"]
  G -- "No" --> I["Sub-processor goes live"]
  H --> I
  I --> J["Annual review in supplier register"]
```

| ID | Sub-processor | Service | PII accessed | Location | Flow-down terms | Last review |
|---|---|---|---|---|---|---|
| SUBP-001 *(Example)* | [IaaS provider] | Hosting and storage | All customer content (encrypted) | [Primary and DR regions] | Provider DPA | YYYY-MM-DD |
| SUBP-002 *(Example)* | [Support ticketing SaaS] | Customer support | Names and e-mails in tickets | [Region] | DPA, security addendum | YYYY-MM-DD |
| SUBP-003 *(Example)* | [Monitoring SaaS] | Error tracking | Scrubbed identifiers | [Region] | DPA | YYYY-MM-DD |
| SUBP-004 *(Example)* | [E-mail delivery service] | Transactional e-mail | E-mail addresses | [Region] | DPA | YYYY-MM-DD |

Assess each sub-processor with `compliance/supplier-security-assessment`
(DOC-ISMS-067) and keep the master record in the supplier register
(DOC-ISMS-066).

## 7. Assistance with data subject rights

<!-- Guidance: The customer answers data subjects; the provider gives tools and help. Pitfall: support staff answering a data subject directly and making decisions only the controller can make. -->

1. If a data subject contacts the organization directly about customer
   data, support does not act on the request. It records the request
   and forwards it to the customer within [2] business days *(Example)*,
   unless the customer has authorized another route.
2. The service provides self-service features for access, correction,
   export and deletion where possible. Document them in the customer
   documentation.
3. Where a customer needs help beyond the features, support opens an
   assistance ticket, performs the action only on the customer's
   written instruction and records what was done.
4. Track volume and response time as a PIMS measure.

## 8. Return, transfer and deletion

<!-- Guidance: State what happens to every copy of customer PII, including backups, logs and temporary files. Auditors ask for a deletion record and the method used. Pitfall: promising immediate deletion from backups that only expire on a rotation cycle. -->

| Data location | Return option | Deletion method | Deletion period after contract end | Evidence |
|---|---|---|---|---|
| Production data store | Self-service export in [format] | Logical deletion, then key destruction for the tenant | [30] days *(Example)* | Deletion job log |
| Backups | Not returned separately | Expire with the rotation cycle | [35] days *(Example)* | Backup policy DOC-ISMS-061 |
| Logs containing identifiers | Not returned | Expire per log retention | [90] days *(Example)* | Logging configuration |
| Temporary and cache files | Not returned | Automatic purge | [24] hours *(Example)* | Purge job configuration |
| Support tickets | On request | Purge on request or per retention rule | [12] months *(Example)* | Ticket purge report |

Issue a deletion confirmation to the customer on request, stating the
date and the data locations covered. Erase or destroy storage media
that held customer PII before reuse or disposal; for providers that
rely on an IaaS sub-processor, obtain its media sanitization assurance
through the supplier assessment. Align periods with
`data/data-retention-deletion-standard` and the cloud exit plan
(DOC-ISMS-076).

## 9. Legally binding disclosure requests

<!-- Guidance: Define how a request from a law enforcement or other public authority is handled. Questions to answer: who validates the request, when is the customer told, what is the minimum disclosed? Pitfall: front-line staff disclosing data under pressure before legal review. -->

```mermaid
sequenceDiagram
  participant AUTH as Authority
  participant LEG as Legal counsel
  participant DPO as DPO
  participant CUST as Customer
  AUTH->>LEG: Disclosure request for customer PII
  LEG->>LEG: Validate legal basis and scope
  LEG->>DPO: Inform and record in disclosure log
  alt Notice to customer is permitted
    LEG->>CUST: Notify customer and redirect authority where possible
  else Notice is legally prohibited
    LEG->>LEG: Record the prohibition and review date
  end
  LEG->>AUTH: Disclose minimum data required or reject
  LEG->>DPO: Close log entry with outcome
```

Rules:

- Only legal counsel may accept, challenge or answer a request.
- Reject or challenge requests that are not legally binding or are
  broader than necessary.
- Try first to redirect the authority to the customer, who is the
  controller.
- Record every request, including rejected ones, in the disclosure log
  with date, authority, scope, legal basis, customer notified (yes or
  no, and why) and data disclosed.
- Publish aggregate request numbers if the organization issues a
  transparency report.

## 10. Breach notification

<!-- Guidance: Align the provider's commitment with the customer's legal deadlines. Under the GDPR, for example, a controller notifies the supervisory authority within 72 hours of becoming aware (Article 33), and a processor notifies the controller without undue delay (Article 33(2)). Pitfall: waiting for a full investigation before the first notice. -->

| Step | Action | Target time *(Example)* | Owner |
|---|---|---|---|
| 1 | Detect and triage event under the incident response plan DOC-ISMS-020 | Ongoing | [@security-lead] |
| 2 | Decide whether customer PII is affected | Within [12] hours of detection | [@security-lead], [@dpo] |
| 3 | First notice to each affected customer | Without undue delay, target [48] hours | [@dpo] |
| 4 | Updates with new facts | Every [24] hours until contained | [@dpo] |
| 5 | Final report with cause and corrective actions | Within [30] days | [@security-lead] |

Content of the customer notice: description of the breach, categories
and approximate number of data subjects and records, likely
consequences, measures taken or proposed, contact point, and what is
still unknown. Assess each case with
`compliance/personal-data-breach-assessment` and record it in the
incident register (DOC-ISMS-021).

## 11. Control implementation table

<!-- Guidance: One row per control you apply from ISO/IEC 27018:2025, using the official reference in the "27018 ref" column and your own short description. The example rows are grouped by privacy principle themes from ISO/IEC 29100:2024; confirm the grouping and numbering in your copy. Do not copy control text. -->

| Row ID | 27018 ref | Theme | Implementation in this service (own wording) | Status | Owner | Evidence | Link |
|---|---|---|---|---|---|---|---|
| P18-001 *(Example)* | [27018 control ref] | Consent and choice | Customers control whether optional features that process PII are enabled | Implemented | [@head-of-product] | Feature settings documentation | COM-001 |
| P18-002 *(Example)* | [27018 control ref] | Purpose legitimacy | Customer PII is used only to provide the contracted service | Implemented | [@dpo] | Data flow review | COM-001, COM-002 |
| P18-003 *(Example)* | [27018 control ref] | Purpose legitimacy | No commercial use of customer PII for marketing or advertising | Implemented | [@dpo] | Marketing data separation review | COM-002 |
| P18-004 *(Example)* | [27018 control ref] | Data minimization | Temporary files holding PII purged automatically | Implemented | [@cto] | Purge job configuration | Section 8 |
| P18-005 *(Example)* | [27018 control ref] | Use, retention and disclosure limitation | Disclosure requests handled by legal with customer notice | Implemented | [@legal-counsel] | Disclosure log | COM-007 |
| P18-006 *(Example)* | [27018 control ref] | Use, retention and disclosure limitation | Record of PII disclosures to third parties kept | Implemented | [@legal-counsel] | Disclosure log | Section 9 |
| P18-007 *(Example)* | [27018 control ref] | Openness and transparency | Sub-processors and processing locations disclosed | Implemented | [@legal-counsel] | Trust page history | COM-004, COM-005 |
| P18-008 *(Example)* | [27018 control ref] | Accountability | Breach notification to customers | Implemented | [@dpo] | Incident register | COM-006 |
| P18-009 *(Example)* | [27018 control ref] | Accountability | Return and deletion policy applied at contract end | Partial | [@cto] | Deletion certificates | COM-008, RISK-047 |
| P18-010 *(Example)* | [27018 control ref] | Information security | Confidentiality agreements for staff with PII access | Implemented | [@hr-lead] | Signed agreements | COM-003, ISMS A.6.6 |
| P18-011 *(Example)* | [27018 control ref] | Information security | Unique user accounts for staff access to customer PII, reviewed quarterly | Implemented | [@isms-manager] | Access reviews | ISMS A.5.16, A.5.18 |
| P18-012 *(Example)* | [27018 control ref] | Information security | Encryption of PII transmitted over public networks | Implemented | [@cto] | TLS configuration | ISMS A.8.24 |
| P18-013 *(Example)* | [27018 control ref] | Information security | Secure erasure or destruction of media before reuse | Implemented | [@cto] | Sub-processor assurance, disposal record DOC-ISMS-057 | ISMS A.7.14 |
| P18-014 *(Example)* | [27018 control ref] | Privacy compliance | Independent review of PII protection at planned intervals | Implemented | [@isms-manager] | Audit reports | ISMS A.5.35 |
| [P18-NNN] | [27018 control ref] | [Theme] | [Implementation] | [Status] | [@owner] | [Record] | [Link] |

Record the same decisions in the PIMS SoA (DOC-ISMS-101) or the ISMS
SoA (DOC-ISMS-011) as additional controls, so each decision lives in one
approved place.

## 12. Size tiers

<!-- Guidance: Show what changes by size, using the library's working tiers. Pitfall: a small provider copying a hyperscaler's sub-processor regime it cannot run. -->

| Topic | Small: Quillmere Analytics Ltd | Medium: Quillmere Health Systems | Large: Quillmere Group |
|---|---|---|---|
| Position | B2B SaaS analytics, processor for customer data, production on one public cloud provider in two regions (primary and DR), 46 staff | Clinical scheduling managed service, processor for hospitals, two offices and a colocation suite, 320 staff | Group service centre and data centre host some services for group companies and customers; 2,400 staff, 6 sites in 4 countries |
| Applicability | Directly applies: core customer offer | Applies to the hosted service; health data raises sensitivity | Applies only where a public cloud service is offered to others; internal hosting is outside |
| Sub-processors | 4 to 6 *(Example)*, one public list, e-mail notice | 10 to 20 *(Example)*, notice through customer portal, hospital-specific objections | Per service, managed by group procurement |
| Disclosure requests | CEO and external counsel | In-house legal | Group legal with country counsel in 4 countries |
| Assurance route | 27018 controls in scope of the first ISMS audit (certification target 6 months) | Included in the 27001 audit, then in the 27701 audit the year after | Included per service in the phased group programme (15 months) |

## 13. Records and evidence

<!-- Guidance: List the records that prove each commitment. Link them in the control evidence matrix. -->

| Record | Proves | Owner | Location | Retention |
|---|---|---|---|---|
| Signed DPAs and change history | Processing on instructions | [@legal-counsel] | Contract register | Contract term plus [6] years *(Example)* |
| Sub-processor list history and notices | Transparency and change notice | [@legal-counsel] | Trust page archive | [6] years *(Example)* |
| Disclosure request log | Requests handled and recorded | [@legal-counsel] | [Restricted folder] | [6] years *(Example)* |
| Breach notices and incident records | Notification commitments kept | [@dpo] | DOC-ISMS-021 | [6] years *(Example)* |
| Deletion confirmations and job logs | Return and deletion | [@cto] | [Ticketing and job system] | [3] years *(Example)* |
| Rights assistance tickets | Assistance given | [@head-of-support] | [Ticketing system] | [3] years *(Example)* |
| Sub-processor assessments | Flow-down and due diligence | [@isms-manager] | DOC-ISMS-066, DOC-ISMS-067 | Relationship plus [3] years *(Example)* |

Add each record to the control evidence matrix (`isms/control-evidence-matrix`,
DOC-ISMS-033).

## 14. Review and maintenance

<!-- Guidance: Name the triggers that force a review. Auditors compare the review date with recent changes. -->

Review this document at least every 12 months and when:

- a sub-processor, hosting region or data category changes;
- the DPA or customer security addendum template changes;
- a breach, disclosure request or audit finding shows a gap;
- a law or regulator guidance changes processor duties;
- a new edition or amendment of ISO/IEC 27018 is published.

## 15. References

<!-- Guidance: Cite only editions you checked. -->

| Reference | Edition | Use |
|---|---|---|
| ISO/IEC 27018:2025, https://www.iso.org/standard/88150.html | Third edition, 2025 | Guidelines for public cloud PII processors |
| ISO/IEC 27002:2022, https://www.iso.org/standard/75652.html | 2022 | Base information security controls |
| ISO/IEC 29100:2024, https://www.iso.org/standard/85938.html | 2024 | Privacy principles |
| ISO/IEC 27701:2025, https://www.iso.org/standard/85819.html | 2025 | PIMS where the provider runs one |
| ISO/IEC 27001:2022 + Amd 1:2024, https://www.iso.org/standard/82875.html and https://www.iso.org/standard/88435.html | Current | ISMS requirements |
| ISO/IEC 27017:2026, https://www.iso.org/standard/82878.html | 2026; check the control set | Cloud service security controls |
| GDPR, Regulation (EU) 2016/679 | As amended; check the consolidated text | Example of processor duties (Articles 28, 33) |
| Related templates | | `isms/pims-27701-statement-of-applicability`, `isms/cloud-services-security-policy`, `isms/cloud-27017-controls`, `legal-lite/dpa`, `isms/customer-security-addendum`, `isms/supplier-register`, `compliance/supplier-security-assessment`, `compliance/personal-data-breach-assessment`, `isms/cloud-exit-plan`, `isms/control-evidence-matrix` |

## Standard and licence note

Structure aligned with ISO/IEC 27018:2025, ISO/IEC 27002:2022 and
ISO/IEC 29100:2024. The commitments, procedures, tables, diagrams and
examples are original text. No control text, control titles or guidance
from ISO/IEC standards are reproduced; control references are
placeholders that you fill from the official standard, which you need
to implement the practice. Check the current edition of each standard
before use. GDPR is cited as an example only.

Template licence: MIT.