From 2548ac20f2cebd4bb342de82d2de1fb775f713ea Mon Sep 17 00:00:00 2001 From: zainab Date: Sat, 17 Oct 2026 02:51:34 +0100 Subject: [PATCH] Add end-of-life, data residency, data deletion, and consent management policies Closes #1852 Closes #1855 Closes #1856 Closes #1857 --- Governance/policies/CONSENT_MANAGEMENT.md | 90 +++++++++++++++++++ Governance/policies/DATA_DELETION.md | 105 ++++++++++++++++++++++ Governance/policies/DATA_RESIDENCY.md | 84 +++++++++++++++++ Governance/policies/END_OF_LIFE.md | 82 +++++++++++++++++ 4 files changed, 361 insertions(+) create mode 100644 Governance/policies/CONSENT_MANAGEMENT.md create mode 100644 Governance/policies/DATA_DELETION.md create mode 100644 Governance/policies/DATA_RESIDENCY.md create mode 100644 Governance/policies/END_OF_LIFE.md diff --git a/Governance/policies/CONSENT_MANAGEMENT.md b/Governance/policies/CONSENT_MANAGEMENT.md new file mode 100644 index 00000000..d599dbfa --- /dev/null +++ b/Governance/policies/CONSENT_MANAGEMENT.md @@ -0,0 +1,90 @@ +# Consent Management Policy + +| Field | Value | +| --- | --- | +| Document | `Governance/policies/CONSENT_MANAGEMENT.md` | +| Status | Active | +| Version | 1.0.0 | +| Owner | Maintainer Team | +| Last reviewed | 2026-10-17 | +| Review cadence | Every 6 months | +| Applies to | Any processing activity that relies on consent as its legal basis | +| Related | [`policies/DATA_DELETION.md`](DATA_DELETION.md) · [`domains/DATA_CLASSIFICATION.md`](../domains/DATA_CLASSIFICATION.md) · [`policies/DATA_RESIDENCY.md`](DATA_RESIDENCY.md) | + +This policy defines what requires consent, how consent is recorded so the project +can prove it was given, and how consent is withdrawn. Consent is one legal basis +among several; this policy applies only where the project relies on it. + +## 1. What requires consent + +Consent is required before the project: + +- sends **marketing or product emails** that are not transactional; +- uses **optional analytics, telemetry, or tracking** beyond what is strictly + necessary to operate the service; +- publishes a user's **content, name, or affiliation** beyond the purpose they + gave it for; +- processes **special-category or sensitive data** (for example, health or + biometric data) or children's data, where applicable; +- shares data with a **third party for a purpose other than operating the + service**. + +Consent is **not** required for processing that is necessary to perform a +contract, to comply with a legal obligation, to protect vital interests, or for +a legitimate interest that has been assessed and documented. Do not use consent +as a fallback for processing that another basis already covers — bundling +optional consent into the core service is not consent. + +## 2. How consent is recorded + +- **Opt-in, never pre-ticked.** Consent is an affirmative action. Pre-ticked + boxes, "by continuing you agree" for optional processing, and silence are not + consent. +- **Separate and specific.** Each distinct purpose has its own consent; do not + bundle marketing consent with terms acceptance or with another purpose. +- **Record the evidence.** For each consent, store: + - the identity of the data subject (or a stable, non-sensitive reference); + - the **purpose** consented to; + - the **version** of the notice shown at the time; + - the **timestamp**; + - **how** it was given (channel or UI surface); + - the **withdrawal** state and, once withdrawn, when. +- **Access-limited storage.** Consent records are themselves personal data, + classified per [`domains/DATA_CLASSIFICATION.md`](../domains/DATA_CLASSIFICATION.md), + access-restricted, and not used for any other purpose. +- **Retention.** Keep consent records only as long as needed to demonstrate + compliance; retain the fact of withdrawal even after the underlying data is + deleted. + +## 3. How consent is withdrawn + +- **As easy to withdraw as to give.** Withdrawing consent uses a channel at least + as simple as the one used to give it — an unsubscribe link, a settings toggle, + or a support request — with no extra steps and no dark patterns. +- **Withdrawal stops future processing promptly.** Optional processing that + relied on consent stops within a reasonable operational window, and always by + the next processing cycle. +- **No penalty.** Withdrawing optional consent does not degrade access to the + core service the user is entitled to. +- **Record the withdrawal.** Update the consent record with the withdrawal time + and the processing it affects. Where the data has no other lawful basis, + withdraw-and-delete follows [`policies/DATA_DELETION.md`](DATA_DELETION.md). +- **No retroactive erasure under consent alone.** Withdrawal stops future + processing; erasure of data processed before withdrawal is governed by the + deletion policy and any applicable rights. + +## 4. Review and enforcement + +- Before a new processing activity launches, the owner confirms the basis and, + where it is consent, that §1–§3 are implemented. +- The maintainers review this policy and the active consent purposes at least + **every 6 months**, and whenever a purpose or processor changes. +- A processing activity found running on invalid consent is paused until it is + fixed, and the incident is documented per + [`SECURITY_POLICY.md`](../SECURITY_POLICY.md) where personal data was exposed. + +## 5. Change log + +| Date | Version | Change | +| --- | --- | --- | +| 2026-10-17 | 1.0.0 | Initial release. | diff --git a/Governance/policies/DATA_DELETION.md b/Governance/policies/DATA_DELETION.md new file mode 100644 index 00000000..ab35f6b8 --- /dev/null +++ b/Governance/policies/DATA_DELETION.md @@ -0,0 +1,105 @@ +# Data Deletion and Right-to-Erasure Policy + +| Field | Value | +| --- | --- | +| Document | `Governance/policies/DATA_DELETION.md` | +| Status | Active | +| Version | 1.0.0 | +| Owner | Maintainer Team | +| Last reviewed | 2026-10-17 | +| Review cadence | Every 6 months | +| Applies to | Requests to delete personal data held by the platform | +| Related | [`domains/DATA_RETENTION.md`](../domains/DATA_RETENTION.md) · [`policies/CONSENT_MANAGEMENT.md`](CONSENT_MANAGEMENT.md) · [`domains/BACKUP_POLICY.md`](../domains/BACKUP_POLICY.md) | + +This policy defines how a deletion or erasure request is handled, the timelines +that apply, and how the identity of the requester is verified before data is +removed. It covers data the project controls; data a customer controls in their +own tenancy follows the agreement with that customer. + +## 1. How requests are handled + +1. **Receive.** A request may arrive through the published privacy contact or + the in-product mechanism named in the privacy policy. Log it with the date + and time of receipt. +2. **Acknowledge.** Confirm receipt **within 3 business days**, without yet + confirming that the data exists. +3. **Verify identity** per §3 before acting. +4. **Locate.** Identify every system that holds the requester's data — the + primary store, caches, search indexes, logs, backups, and any processor + recorded in [`compliance/DPA_TEMPLATE.md`](../compliance/DPA_TEMPLATE.md). +5. **Assess exceptions.** Determine whether any data must be retained for a + legal, accounting, security, or contractual reason (see §5). Retain only what + is required, and say what is retained and why. +6. **Delete or anonymise.** Remove the data, or irreversibly anonymise it where + deletion is not possible. +7. **Confirm.** Tell the requester the outcome and, where data was retained, the + reason and the retention period. + +## 2. Timelines + +| Stage | Target | +| --- | --- | +| Acknowledgement of receipt | 3 business days | +| Identity verification (requester's side) | as soon as the requester responds | +| Substantive response / completion | 30 calendar days from verified receipt | +| Extension for complex requests | up to 60 further days, with notice and reason | +| Propagation to backups | within the next backup rotation, not later than the retention window | +| Propagation to processors | within 30 calendar days, or per the processor DPA | + +An extension is communicated before the original deadline passes, with the +reason and the expected completion date. The default is to complete early, not to +use the full window. + +## 3. Verification + +- **Verify before deleting.** A deletion request is not actioned on the word of + an unauthenticated sender, because deletion is irreversible and could be used + to destroy another person's data. +- **Proportionate proof.** Confirm control of the account or email on file. For + data the requester can see in-product, an authenticated session may be enough; + for a request that would delete a whole account, re-authenticate. +- **No over-collection.** Do not ask for more identity documents than the + verification needs; the minimum to confirm control is the rule. +- **Agents.** A request from an authorised agent is verified as if from the data + subject, plus evidence of the agent's authority. +- **Failed verification.** If identity cannot be verified, do not delete; explain + what is needed and keep the request open. + +## 4. What deletion means + +- **Deletion is real.** Removing a row from the primary store is not enough if a + cache, index, or log still holds it. "Deleted" means the data is no longer + retrievable by the project through ordinary means. +- **Backups.** Data in immutable backups is not surgically edited; instead it is + excluded from restores and expires on the backup retention schedule in + [`domains/BACKUP_POLICY.md`](../domains/BACKUP_POLICY.md). The requester is told + this is how backup copies are handled. +- **Anonymisation.** Where a record must be kept for aggregate analytics, remove + the identifiers so the record can no longer be linked to a person. +- **Derived data.** Recompute or remove derived datasets (reports, exports, + caches) so the deletion is not undone by a stale copy. + +## 5. Lawful retention and exceptions + +A request may be refused or partially fulfilled where retention is required: + +- to comply with a legal or regulatory obligation; +- to establish, exercise, or defend legal claims; +- to prevent fraud or preserve the integrity of a security investigation; +- where deletion would infringe another person's rights. + +A refusal states the specific basis and the retention period, and is reviewed by +a maintainer who is not the original handler. Retained data is minimised, access- +restricted, and deleted as soon as the basis ends. + +## 6. Records + +Every request and its outcome are recorded (date received, verification method, +systems touched, decision, and retention basis) in a restricted record for +audit. Personal detail is not put in a public issue or pull request. + +## 7. Change log + +| Date | Version | Change | +| --- | --- | --- | +| 2026-10-17 | 1.0.0 | Initial release. | diff --git a/Governance/policies/DATA_RESIDENCY.md b/Governance/policies/DATA_RESIDENCY.md new file mode 100644 index 00000000..7bc6ba1e --- /dev/null +++ b/Governance/policies/DATA_RESIDENCY.md @@ -0,0 +1,84 @@ +# Data Residency Policy + +| Field | Value | +| --- | --- | +| Document | `Governance/policies/DATA_RESIDENCY.md` | +| Status | Active | +| Version | 1.0.0 | +| Owner | Maintainer Team | +| Last reviewed | 2026-10-17 | +| Review cadence | Every 6 months, and before adding any new region or processor | +| Applies to | All personal and project data processed by or for the platform | +| Related | [`domains/DATA_CLASSIFICATION.md`](../domains/DATA_CLASSIFICATION.md) · [`compliance/DPA_TEMPLATE.md`](../compliance/DPA_TEMPLATE.md) · [`domains/BACKUP_POLICY.md`](../domains/BACKUP_POLICY.md) | + +This policy states where project data may be stored and processed, the +restrictions on moving it between regions, and the process for approving an +exception. It exists so that a database, backup, or log file never lands in a +jurisdiction we have not deliberately approved. + +## 1. Where data may be stored + +- **By default, in the primary region.** Production data is stored and processed + in the project's **primary region**, which is recorded in the platform's + infrastructure configuration and referenced in the deployment runbooks. +- **Approved regions only.** A region is "approved" only after the maintainers + have assessed its legal and operational suitability and recorded it in the + region register below. Processing outside an approved region is a policy + breach. +- **Region register.** + + | Region | Status | Approved for | Notes | + | --- | --- | --- | --- | + | Primary region (see deployment config) | Approved | All classified data up to the highest sensitivity handled there | Default for production and backups. | + + New rows are added by the process in §3; the register is the authoritative list. +- **Data classification constrains residency.** Data classified as restricted in + [`domains/DATA_CLASSIFICATION.md`](../domains/DATA_CLASSIFICATION.md) may only + live in an approved region, and never in a region marked for lower-sensitivity + data only. + +## 2. Transfer restrictions + +- **No cross-border transfer without a basis.** Personal data may only be moved + to another region when there is a lawful transfer mechanism and a recorded + risk assessment. "The provider defaults to it" is not a basis. +- **Encrypted in transit and at rest.** Any transfer between regions uses + transport encryption and the destination stores data encrypted, per + [`policies/ENCRYPTION.md`](ENCRYPTION.md). +- **Minimise the move.** Transfer the least data necessary; prefer aggregate or + pseudonymised data when the purpose allows. +- **Sub-processors count.** A processor's own region counts as a storage + location; new sub-processors are recorded under + [`compliance/DPA_TEMPLATE.md`](../compliance/DPA_TEMPLATE.md) before use. +- **Backups and logs follow the data.** Backups and log archives inherit the + residency rules of the data they contain; see + [`domains/BACKUP_POLICY.md`](../domains/BACKUP_POLICY.md) and + [`domains/LOGGING_RETENTION.md`](../domains/LOGGING_RETENTION.md). + +## 3. Exception process + +1. **Open an issue** describing the data, its classification, the source and + destination region, the reason, and the proposed safeguards. +2. **Assess the transfer** — the lawful mechanism, the risk, and the retention. + A maintainer who is not the requester reviews it. +3. **Approve or decline in writing**, recording the decision and any conditions + on the issue and in the region register. +4. **Time-box the exception.** An exception is scoped and reviewed; it does not + silently become the default. +5. **Emergency transfers** for incident response may proceed under + [`processes/ESCALATION_PATH.md`](../processes/ESCALATION_PATH.md) and are + documented retrospectively within **5 business days**. + +## 4. Monitoring and review + +- The maintainers review this policy and the region register at least **every 6 + months**, and whenever a new region, processor, or classification is added. +- Any processing found outside an approved region is treated as an incident: + contain it, document it, and remediate, in line with + [`SECURITY_POLICY.md`](../SECURITY_POLICY.md). + +## 5. Change log + +| Date | Version | Change | +| --- | --- | --- | +| 2026-10-17 | 1.0.0 | Initial release. | diff --git a/Governance/policies/END_OF_LIFE.md b/Governance/policies/END_OF_LIFE.md new file mode 100644 index 00000000..56bd0327 --- /dev/null +++ b/Governance/policies/END_OF_LIFE.md @@ -0,0 +1,82 @@ +# End-of-Life Policy + +| Field | Value | +| --- | --- | +| Document | `Governance/policies/END_OF_LIFE.md` | +| Status | Active | +| Version | 1.0.0 | +| Owner | Maintainer Team | +| Last reviewed | 2026-10-17 | +| Review cadence | Every 12 months | +| Applies to | Major versions of the platform and its public API surfaces | +| Related | [`policies/DEPRECATION.md`](DEPRECATION.md) · [`domains/API_DEPRECATION.md`](../domains/API_DEPRECATION.md) · [`policies/VERSIONING.md`](VERSIONING.md) | + +This policy defines how a supported version reaches end of life (EOL), how EOL +is announced, the stages by which support is reduced, and the migration guidance +users are given. It covers whole major versions and major API surfaces; the +removal of an individual endpoint is governed by +[`domains/API_DEPRECATION.md`](../domains/API_DEPRECATION.md). + +## 1. How EOL is decided and announced + +- **Decided by the maintainers.** EOL for a major version is decided by the + maintainer team and recorded on a public issue linked from this document. +- **Driven by supportability, not caprice.** Drivers include security risk from + unpatched dependencies, the cost of maintaining multiple lines, a new major + that supersedes the old, or an upstream end of support. +- **A minimum support window.** A major version is supported for at least + **12 months** from its release, and at least **6 months** after a successor + major is released, whichever is longer — unless a security or legal reason + forces an earlier EOL. +- **Announced early and often.** EOL is announced at least **90 days** before + the final support date, through the release notes, the repository README, and + the product notice channel. The announcement names the final support date and + the replacement version. +- **Recorded.** The EOL date and the decision are recorded in + [`Governance/CHANGELOG.md`](../CHANGELOG.md) and on the version's release notes. + +## 2. Support-reduction stages + +| Stage | What still happens | What stops | +| --- | --- | --- | +| **Active** | Full support: features, bug fixes, security fixes, and releases. | — | +| **Maintenance** | Security fixes and critical bug fixes only; no new features. | New features; non-critical fixes. | +| **Deprecated** | Security fixes only, with a published EOL date. | Bug fixes; documentation improvements beyond migration notes. | +| **End of life** | No further fixes or releases of any kind. | All support; the version is archived. | + +- A version moves Active → Maintenance when its successor ships, or earlier if + the maintainers say so. +- A version moves to Deprecated when the EOL date is set; the deprecation notice + follows the period and channels in [`policies/DEPRECATION.md`](DEPRECATION.md). +- At EOL the version is archived: releases stop, and any open issues or pull + requests against it are closed or migrated to the current version. + +## 3. Migration guidance + +- **Publish a migration path before EOL.** At least 90 days before the final + support date, publish a migration guide that names the replacement version and + the breaking changes between them. +- **Make the change mechanical where possible.** Prefer a documented + configuration or code change over a forced rewrite; ship codemods or examples + when they materially reduce effort. +- **Provide a compatibility bridge when feasible.** If a shim can keep old + clients working through the transition, offer it and document its own removal + date. +- **Keep the guide in the release notes**, linked from the EOL announcement, so + it is discoverable after the announcement scrolls away. +- **Answer migration questions** in the repository's support channels for the + duration of the support window. + +## 4. Emergency EOL + +If a version must be retired faster than §1 allows — for example, a critical +unpatched upstream vulnerability — the maintainers may shorten the window. In +that case they publish the reason, the new final support date, and any interim +mitigation as soon as it is safe to do so, and follow +[`SECURITY_POLICY.md`](../SECURITY_POLICY.md). + +## 5. Change log + +| Date | Version | Change | +| --- | --- | --- | +| 2026-10-17 | 1.0.0 | Initial release. |