Skip to content

Add end-of-life, data residency, data deletion, and consent management policies #1913

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
RUKAYAT-CODER merged 1 commit into from
Oct 17, 2026
Merged

Add end-of-life, data residency, data deletion, and consent management policies #1913

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
90 changes: 90 additions & 0 deletions Governance/policies/CONSENT_MANAGEMENT.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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. |
105 changes: 105 additions & 0 deletions Governance/policies/DATA_DELETION.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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. |
84 changes: 84 additions & 0 deletions Governance/policies/DATA_RESIDENCY.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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. |
82 changes: 82 additions & 0 deletions Governance/policies/END_OF_LIFE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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. |
Loading