docs(governance): add compatibility, data residency, erasure and consent policies

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.

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.

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.

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.