From 71d50963eafd37eb4637b6968132818ffc73124f Mon Sep 17 00:00:00 2001 From: Mordy7 Date: Fri, 16 Oct 2026 09:49:49 +0100 Subject: [PATCH] docs(governance): add compatibility, data residency, erasure and consent policies --- Governance/policies/COMPATIBILITY.md | 97 +++++++++++++++++++++++ Governance/policies/CONSENT_MANAGEMENT.md | 81 +++++++++++++++++++ Governance/policies/DATA_DELETION.md | 81 +++++++++++++++++++ Governance/policies/DATA_RESIDENCY.md | 82 +++++++++++++++++++ 4 files changed, 341 insertions(+) create mode 100644 Governance/policies/COMPATIBILITY.md create mode 100644 Governance/policies/CONSENT_MANAGEMENT.md create mode 100644 Governance/policies/DATA_DELETION.md create mode 100644 Governance/policies/DATA_RESIDENCY.md diff --git a/Governance/policies/COMPATIBILITY.md b/Governance/policies/COMPATIBILITY.md new file mode 100644 index 00000000..f1e1555f --- /dev/null +++ b/Governance/policies/COMPATIBILITY.md @@ -0,0 +1,97 @@ +# Compatibility and Support Window Policy + +## Purpose + +This policy states which runtimes, tools, and platforms TeachLink Web supports, +how long each supported version stays supported, and when support is dropped. +Contributors need to know what they may rely on when writing code; users and +integrators need to know how much notice they get before a platform they depend +on stops working. + +## Scope + +This policy applies to the Node.js and package-manager versions used to build +and run the project, the browsers and operating systems the web application +targets, and the major versions of the framework and key runtime dependencies. +It does not set the project's release schedule (see the [release +cadence](../processes/RELEASE_CADENCE.md)) or its API stability rules (see the +[Versioning policy](../policies/VERSIONING.md) and [Deprecation +policy](../policies/DEPRECATION.md)). + +## Supported Versions and Platforms + +The authoritative record of what is supported is kept in the repository, not in +this document, so it cannot drift from what CI actually exercises: + +- **Toolchain.** The Node.js and pnpm versions listed under Prerequisites in the + repository `README.md` and pinned by `packageManager` in `package.json`. CI + runs on those versions. +- **Browsers.** The current and previous major release of the evergreen desktop + and mobile browsers (Chrome, Edge, Firefox, Safari). Older browsers are + best-effort and are not a reason to block a change. +- **Frameworks and runtimes.** The current major version of the application + framework, React, and TypeScript used by the repository, plus the previous + major while a migration is in progress. +- A change that raises or lowers a minimum version updates the authoritative + record in the same pull request. + +## Support Window Length + +Support windows are measured from the date a version becomes the project's +supported baseline: + +- **Runtimes (Node.js).** Supported while the version is in upstream Active LTS + or Maintenance LTS. The project never requires a version that upstream has + already ended. +- **Browsers.** Supported for the current and previous major release; a browser + version leaves the window when it is two majors behind. +- **Frameworks and libraries.** The current major is fully supported. The + previous major is supported for a documented migration period of at least one + release cycle after the new major is adopted. +- **Contributor tooling (pnpm, linters, test runners).** Only the pinned version + is supported; contributors are expected to use it. + +## Drop Criteria + +A version, browser, or platform may be dropped when at least one of the +following holds: + +- Its upstream vendor no longer provides security fixes for it. +- It falls outside the support window defined above. +- Supporting it blocks a security fix, a required dependency upgrade, or a + feature the roadmap commits to, and no reasonable workaround exists. +- Its share of real users, as reported by the project's consented analytics (see + the [Analytics Data Collection](../domains/ANALYTICS_DATA.md)), is too small + to justify the maintenance cost. +- Dropping support is announced at least one release cycle in advance in the + release notes and the pull request, uses the [Deprecation + policy](../policies/DEPRECATION.md) for any user-visible behaviour, and is + recorded through the [RFC process](../processes/RFC_PROCESS.md) when it + affects many contributors or users. + +## Exceptions + +A maintainer may extend support for a version past its window when a documented +downstream user depends on it and the cost is small, or shorten it for an +actively exploited vulnerability. Every exception is recorded on the pull +request or issue with its reason and end date. + +## Ownership and Review + +- Maintainers own this document and are accountable for applying it + consistently. +- The release manager reviews the supported-versions record at the start of each + release cycle and opens a pull request for any version that has left its + window. +- Changes are proposed in a pull request that touches only the `Governance/` + folder and are reviewed like any other governance change (see the [Review + Policy](../policies/REVIEW_POLICY.md)). +- This document is versioned with the repository and describes how the project + actually operates rather than an aspiration. + +## Success + +This policy succeeds when contributors can tell from the repository which +versions they may rely on, when no supported version is one that upstream has +already abandoned, and when users receive advance notice before a platform they +use is dropped. diff --git a/Governance/policies/CONSENT_MANAGEMENT.md b/Governance/policies/CONSENT_MANAGEMENT.md new file mode 100644 index 00000000..b85fb299 --- /dev/null +++ b/Governance/policies/CONSENT_MANAGEMENT.md @@ -0,0 +1,81 @@ +# Consent Management Policy + +## Purpose + +This policy defines when TeachLink Web must ask for consent before processing +personal data, how that consent is recorded, and how a person can withdraw it. +It makes consent specific, provable, and as easy to withdraw as it was to give. + +## Scope + +This policy applies to every feature that processes personal data on the basis +of consent: optional analytics and error reporting, non-essential cookies and +local storage, marketing and notification messages, optional profile data, and +sharing of data with third parties. Cookie categories are detailed in the +[Cookie and Consent governance](../domains/COOKIE_CONSENT.md) and analytics +events in the [Analytics Data Collection](../domains/ANALYTICS_DATA.md). + +## What Requires Consent + +Consent is required before the project: + +- sets or reads non-essential cookies or similar storage (anything outside the + strictly necessary category); +- collects analytics or error-reporting data tied to a person or device; +- sends marketing or optional notification messages; +- shares personal data with a third party for that party's own purposes; +- processes data of a child, which also needs the parental authority described + in the [Privacy Notice governance](../domains/PRIVACY_NOTICE.md) and the + children's data policy. +- Consent is not used where another lawful basis applies (for example data + strictly necessary to provide the service the user asked for), and consent is + never bundled as a condition of using the core service when it is not needed + for it. + +## How Consent Is Recorded + +A valid consent is freely given, specific, informed, and unambiguous. Each time +consent is given the record keeps: + +- a pseudonymous identifier for the user or browser; +- the purpose or category consented to, and the wording and version of the + notice shown; +- the date and time, and the mechanism (for example banner choice or settings + toggle); +- later changes, so the history of grant and withdrawal can be shown. +- Defaults are off. Pre-ticked boxes, scrolling, or continued use do not count + as consent. Declining must be as easy as accepting, and the service works + without optional consent. + +## Withdrawal + +People can withdraw consent at any time: + +- A visible control in the application settings, reachable from every page, + withdraws consent per category without needing an account to be contacted. +- Withdrawal takes effect immediately for new processing: the relevant scripts + stop loading and queued sends stop. +- Data already collected on that basis is deleted or anonymised within 30 days + unless another lawful basis requires keeping it, following the record + retention and legal hold policy. +- Consent is re-requested when the purpose or wording changes materially and + after the expiry period set in the [Cookie and Consent + governance](../domains/COOKIE_CONSENT.md). + +## Ownership and Review + +- Maintainers own this document and are accountable for applying it + consistently. +- Changes to consent wording or categories are reviewed by a maintainer + accountable for privacy before they ship. +- Changes are proposed in a pull request that touches only the `Governance/` + folder and are reviewed like any other governance change (see the [Review + Policy](../policies/REVIEW_POLICY.md)). +- This document is versioned with the repository and describes how the project + actually operates rather than an aspiration. + +## Success + +This policy succeeds when no optional processing starts without a recorded +consent, when withdrawal works immediately from the settings, and when the +project can show on request what a person agreed to and when. diff --git a/Governance/policies/DATA_DELETION.md b/Governance/policies/DATA_DELETION.md new file mode 100644 index 00000000..8b28682c --- /dev/null +++ b/Governance/policies/DATA_DELETION.md @@ -0,0 +1,81 @@ +# Right-to-Erasure Policy + +## Purpose + +This policy explains how TeachLink Web handles requests from people who want +their personal data erased. It gives requesters a clear route and timeline and +gives maintainers one consistent procedure that respects legal obligations and +the limits of what the project can delete. + +## Scope + +This policy applies to erasure and deletion requests for personal data held by +the application, its backups, logs, and third-party processors acting for the +project. It applies whether the request comes through the application, by email, +or through a public channel. Retention periods and legal holds are governed by +the record retention and legal hold policy. + +## How Requests Are Handled + +A request is handled in these steps: + +- **Intake.** A request is accepted through the privacy contact published in the + [Privacy Notice governance](../domains/PRIVACY_NOTICE.md). A request posted in + a public issue is moved to a private channel and the public text is removed, + because it may contain personal data. +- **Triage.** A maintainer acknowledges the request, assigns an owner, and + records it in the request log with the date received. +- **Assessment.** The owner identifies the data held, checks whether a legal + hold or a legal retention duty applies, and decides whether to erase, + partially erase, or refuse with reasons. +- **Action.** Data is erased from live systems and processors, and queued for + removal from backups at the next backup rotation. Data that must be kept is + restricted from further use and the requester is told why. +- **Confirmation.** The requester receives a written confirmation describing + what was erased, what was kept and why, and when backups will be purged. + +## Timelines + +Targets, measured from the date the identity of the requester is verified: + +- acknowledge the request within 3 business days; +- complete erasure from live systems and notify processors within 30 days, + extendable once by up to 60 days for complex requests, with the requester told + of the extension and reason before the first deadline; +- purge backups on their normal rotation and no later than the end of the + documented backup retention period; +- if the request is refused in whole or in part, say so with the reasons within + the same 30 days. + +## Verification + +Erasure is irreversible, so the requester's identity and authority are verified +first: + +- Verify through the account the data belongs to (for example a confirmation + sent to the registered email address), not by trusting the contents of the + request. +- A request from someone acting for another person needs written authority from + that person. +- Ask only for the minimum extra information needed to verify and delete it + after the request closes. +- Never delete on the strength of an unverifiable request; explain what is + needed to proceed. + +## Ownership and Review + +- Maintainers own this document and are accountable for applying it + consistently. +- The privacy owner reviews the request log each quarter to check that deadlines + were met and that confirmation messages were sent. +- Changes are proposed in a pull request that touches only the `Governance/` + folder and are reviewed like any other governance change (see the [Review + Policy](../policies/REVIEW_POLICY.md)). +- This document is versioned with the repository and describes how the project + actually operates rather than an aspiration. + +## Success + +This policy succeeds when every verified request is completed or answered with +reasons within the stated timelines, when no personal data is exposed in the +process, and when requesters always know what was erased and what was kept. diff --git a/Governance/policies/DATA_RESIDENCY.md b/Governance/policies/DATA_RESIDENCY.md new file mode 100644 index 00000000..836a0614 --- /dev/null +++ b/Governance/policies/DATA_RESIDENCY.md @@ -0,0 +1,82 @@ +# Data Residency Policy + +## Purpose + +This policy defines where TeachLink Web data may be stored and processed, and +under what conditions it may cross a regional or national boundary. It lets +maintainers choose hosting and third-party services against a known rule instead +of deciding case by case, and lets users and institutions ask where their data +lives. + +## Scope + +This policy applies to personal data and learner, course, and account data +handled by the application, its databases, backups, logs, analytics, and the +third-party services that process them on the project's behalf. It does not +describe individual vendors (see the [Third-Party Scripts +governance](../domains/THIRD_PARTY_SCRIPTS.md) and the [Third-Party Licenses +policy](../policies/THIRD_PARTY_LICENSES.md)) or the deletion process (see the +record retention and legal hold policy). + +## Where Data May Be Stored + +Data may be stored and processed only in locations that the maintainers have +approved and recorded in the data-location register kept alongside the project's +operational documentation. The register lists, for each data category: + +- the primary storage region and the backup region; +- the service provider that operates it and the legal entity responsible; +- the categories of data held and their classification (public, internal, + personal, sensitive). +- **Default rule.** Personal data stays in the primary region recorded for its + category. Backups stay in the same jurisdiction as the primary copy unless the + register states otherwise. +- **Logs and analytics.** Logs and analytics must not contain personal data + beyond what the [Analytics Data Collection](../domains/ANALYTICS_DATA.md) + allows, and are stored in a region listed in the register. + +## Transfer Restrictions + +Moving data out of its approved region is a transfer and is restricted: + +- A transfer needs a lawful transfer mechanism for the jurisdictions involved + (for example an adequacy decision or approved contractual clauses), recorded + in the register. +- Personal data is not sent to a new sub-processor or region until the vendor + review is complete and the register is updated. +- Support and debugging access from outside the approved region is read-only, + time-limited, logged, and limited to the data needed for the task. +- Contributors never copy production personal data to local machines, forks, + issue trackers, or chat. Use anonymised or synthetic fixtures instead. + +## Exception Process + +When a transfer or new location is needed and the rules above do not allow it: + +- The requester opens a private request describing the data, the destination, + the purpose, and the duration. +- Two maintainers review it, one of them accountable for privacy or security, + and consult counsel if the jurisdiction is new. +- An approved exception is time-limited, recorded in the register with its + reason and expiry, and reviewed again before it is renewed. +- An unapproved transfer found after the fact is treated as an incident under + the [Security Policy](../SECURITY_POLICY.md): it is contained, assessed for + notification duties, and recorded. + +## Ownership and Review + +- Maintainers own this document and are accountable for applying it + consistently. +- The data-location register is reviewed at least once a year and whenever a + provider or region changes. +- Changes are proposed in a pull request that touches only the `Governance/` + folder and are reviewed like any other governance change (see the [Review + Policy](../policies/REVIEW_POLICY.md)). +- This document is versioned with the repository and describes how the project + actually operates rather than an aspiration. + +## Success + +This policy succeeds when every data category has a recorded location, when no +transfer happens without a recorded mechanism and approval, and when exceptions +are rare, time-limited, and reviewed.