From 604ecc348464e723742dde4c27ec21d62d09c59b Mon Sep 17 00:00:00 2001 From: NteinPrecious Date: Fri, 16 Oct 2026 09:55:34 +0100 Subject: [PATCH] docs(governance): add privacy governance, export control, sanctions and children's data policies --- Governance/compliance/CHILDRENS_DATA.md | 97 +++++++++++++++++++ Governance/compliance/EXPORT_CONTROL.md | 83 ++++++++++++++++ .../compliance/PRIVACY_POLICY_GOVERNANCE.md | 89 +++++++++++++++++ Governance/compliance/SANCTIONS.md | 86 ++++++++++++++++ 4 files changed, 355 insertions(+) create mode 100644 Governance/compliance/CHILDRENS_DATA.md create mode 100644 Governance/compliance/EXPORT_CONTROL.md create mode 100644 Governance/compliance/PRIVACY_POLICY_GOVERNANCE.md create mode 100644 Governance/compliance/SANCTIONS.md diff --git a/Governance/compliance/CHILDRENS_DATA.md b/Governance/compliance/CHILDRENS_DATA.md new file mode 100644 index 00000000..b2d9fe19 --- /dev/null +++ b/Governance/compliance/CHILDRENS_DATA.md @@ -0,0 +1,97 @@ +# Children's Data Policy + +## Purpose + +This policy sets how TeachLink Web handles personal data about children. As an +education-focused project, it may be used by or on behalf of young learners, and +children deserve extra care. The policy defines the age thresholds, how parental +consent is handled, and how data collected about children is kept to a minimum. +This document is a governance statement, not legal advice; maintainers consult +qualified counsel before relying on it for a legal decision. + +## Scope + +This policy applies to any feature or integration that collects, processes, or +shares personal data from or about people under the age of majority or digital +consent in their jurisdiction. It is applied together with the [Privacy Notice +governance](../domains/PRIVACY_NOTICE.md), the [Cookie and Consent +governance](../domains/COOKIE_CONSENT.md) and the [Analytics Data +Collection](../domains/ANALYTICS_DATA.md). + +## Age Thresholds + +The project uses age thresholds that follow the applicable law: + +- **Under 13** is treated as a child everywhere; no personal data is collected + from these users without verifiable parental consent, in line with laws such + as COPPA. +- **13 to 15** is treated as a child in jurisdictions where the age of digital + consent is higher (for example up to 16 under the GDPR, which member states + may lower to 13), and parental consent is required there. +- **16 and over** is treated as an adult for consent purposes unless local law + says otherwise. +- Where the user's location is not known, the stricter threshold applies. The + product does not target children under 13 for general use; features designed + for children are introduced only through the project's [RFC + process](../processes/RFC_PROCESS.md) with a privacy review. +- Age is asked for in a neutral way, without encouraging users to misstate it, + and the answer is used only to apply this policy. + +## Parental Consent Handling + +Where parental consent is required: + +- Consent is requested from a parent or guardian, not the child, in plain + language that explains what is collected and why, and how to refuse or + withdraw. +- The method of verifying the parent is proportionate to the risk (for example a + confirmation sent to a parent email address for limited data, stronger checks + for riskier uses). Verification data is used only for verification and deleted + afterwards. +- Consent is recorded as set out in the consent management policy, and a parent + can review the child's data, ask for it to be deleted, and withdraw consent at + any time. The right-to-erasure policy applies, and the deletion is completed + promptly. +- Where a school or institution gives consent on behalf of parents, the + agreement says so and limits the use to the educational purpose. +- If it comes to light that data was collected from a child without valid + consent, collection stops, the data is deleted unless the law requires + otherwise, and the family is told. + +## Data Minimisation + +Children's data is held to a higher standard: + +- Collect only what is strictly needed to provide the educational feature; no + profiling, behavioural advertising, or sale of children's data. +- No optional analytics, third-party trackers, or public profiles for children + by default (see the [Third-Party Scripts + governance](../domains/THIRD_PARTY_SCRIPTS.md)), and default settings are the + most private ones. +- Do not publish children's names, photos, or contributions with identifying + details without parental consent, and never display contact information. +- Retention is as short as possible, and data is deleted when the purpose ends + or when the account is closed, following the record retention and legal hold + policy. +- Maintainers must not copy children's data into issues, chats, or test + fixtures; use synthetic data. +- A privacy review is required before any feature that could be used by children + is released. + +## Ownership and Review + +- Maintainers own this document and are accountable for applying it + consistently. +- The privacy owner reviews this policy once a year and whenever laws on + children's data change. +- 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 personal data is collected from a child without the +consent the law requires, when parents can see and control what is held, and +when the project holds as little about children as it can. diff --git a/Governance/compliance/EXPORT_CONTROL.md b/Governance/compliance/EXPORT_CONTROL.md new file mode 100644 index 00000000..2708ac69 --- /dev/null +++ b/Governance/compliance/EXPORT_CONTROL.md @@ -0,0 +1,83 @@ +# Export Control Policy + +## Purpose + +This policy explains how TeachLink Web handles export control laws, which +restrict transferring certain technology, software, or services across borders +or to certain parties. It helps the project and its contributors stay within the +law without hindering open collaboration. This document is a governance +statement, not legal advice; maintainers consult qualified counsel before +relying on it for a legal decision. + +## Scope + +This policy applies to the software, documentation, and any encryption or other +controlled technology published by the project, and to maintainers and +contributors who handle project releases, distribution, and contracts. It +applies alongside the sanctions compliance policy in this folder +([SANCTIONS.md](SANCTIONS.md)). + +## Applicable Restrictions + +The project aims to understand and respect the restrictions that may apply: + +- Laws such as the US Export Administration Regulations and the equivalent rules + of the EU and other jurisdictions where maintainers or infrastructure are + located. +- Controls on cryptography and security software: the project's use of standard + encryption in a web application, and any publicly available open-source source + code, is generally treated as eligible for broad release, but this is + confirmed with counsel when the code changes materially. +- Controls on destinations, end users, and end uses (for example embargoed + regions and military end uses). +- A classification note for the project is kept by the maintainers, stating what + was assessed, by whom, and when, and is reviewed whenever new cryptographic + functionality or a new distribution channel is added. + +## Screening Process + +Screening is risk-based and proportionate: + +- Open publication of source code on a public repository is not individually + screened; the project does not collect enough information to do so. +- Before entering a contract, accepting a sponsorship, or providing private + services or support, a maintainer screens the counterparty against the lists + named in the sanctions compliance policy and records the result. +- Before a release or change that adds or modifies cryptographic features, a + maintainer checks the classification note and asks counsel when unsure. +- Maintainers who suspect that a transfer, contribution, or request would breach + export controls stop and raise it with the lead maintainers before proceeding. + +## Exception Handling + +When a restriction applies or may apply: + +- The lead maintainers decide how to proceed, usually after consulting counsel: + for example restricting a service for a party, applying for a licence, or + changing a release. +- An exception to the usual practice (for example proceeding while a + classification is pending) needs written approval from two maintainers and + counsel's advice, and is recorded with its reason and expiry. +- No exception permits a transfer that is prohibited by law. +- Possible violations are reported privately to the lead maintainers, who + investigate, contain the issue, assess any duty to disclose to authorities, + and record the outcome. People who report in good faith are protected from + retaliation under the [Code of Conduct](../CODE_OF_CONDUCT.md). + +## Ownership and Review + +- Maintainers own this document and are accountable for applying it + consistently. +- The classification note and screening records are reviewed at least once a + year and at every change in cryptographic functionality. +- 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 the project can show what it assessed and when, when +screening happens before private transfers, and when concerns are raised early +and resolved on the advice of counsel. diff --git a/Governance/compliance/PRIVACY_POLICY_GOVERNANCE.md b/Governance/compliance/PRIVACY_POLICY_GOVERNANCE.md new file mode 100644 index 00000000..f7cc3839 --- /dev/null +++ b/Governance/compliance/PRIVACY_POLICY_GOVERNANCE.md @@ -0,0 +1,89 @@ +# Privacy Policy Governance + +## Purpose + +This document governs the privacy policy that TeachLink Web publishes to its +users: who owns it, how it is updated and reviewed, and how its versions are +tracked. It ensures the published policy always matches what the project +actually does with personal data, and that users are told when it changes. This +document is a governance statement, not legal advice; maintainers consult +qualified counsel before relying on it for a legal decision. + +## Scope + +This document applies to the user-facing privacy policy and to any notice that +describes how personal data is collected, used, shared, or retained. The content +rules for the notice are in the [Privacy Notice +governance](../domains/PRIVACY_NOTICE.md); consent rules are in the [Cookie and +Consent governance](../domains/COOKIE_CONSENT.md); and what data may be +collected is in [Analytics Data Collection](../domains/ANALYTICS_DATA.md). + +## Ownership + +Responsibility for the privacy policy is clear: + +- A maintainer is named **privacy owner**, is responsible for the accuracy of + the published policy, and acts as the contact for privacy questions. +- A second maintainer is named **deputy** so the role is never vacant; both are + recorded in the maintainer records. +- Counsel or an external privacy adviser is consulted for material changes, new + jurisdictions, and legal requests. +- The privacy owner does not approve their own changes; another maintainer + reviews every edit. +- If no owner is in place, the lead maintainers act as owners until one is + appointed within 30 days. + +## Update and Review Process + +The policy changes only through a controlled process: + +- **Trigger.** A change to what data is collected, why, who receives it, where + it is stored, or how long it is kept requires an update before the change + ships. Legal changes, a new vendor, or an incident can also trigger one. +- **Draft.** The privacy owner proposes the change in a pull request that + explains what changed and why, with a plain-language summary of the effect on + users. +- **Review.** At least two maintainers review it, one of them independent of the + change. Material changes also get input from counsel and are open to community + comment for at least 14 days, unless an urgent legal or security reason + shortens it. +- **Publication.** The approved policy is published with its version and + effective date, and users are notified of material changes at least 30 days + before they take effect where the law or the change makes this appropriate. +- **Scheduled review.** The policy is reviewed at least once a year even if + nothing has changed, and the review is recorded. + +## Versioning + +Every published policy has a version and an archive: + +- Versions use `MAJOR.MINOR`: a **major** version changes what is collected, the + purposes, or users' rights; a **minor** version corrects wording without + changing meaning. +- Each version shows its number, effective date, and a short change log at the + top of the published policy. +- Earlier versions are kept in an accessible archive so a user can see what + applied when they signed up or consented, which supports the consent records + described in the consent management policy. +- Changes that need new consent trigger a new consent request instead of relying + on the earlier one. +- The version in the product, the repository, and any translation must match; + mismatches are fixed as defects. + +## Ownership and Review + +- Maintainers own this document and are accountable for applying it + consistently. +- The privacy owner reports to the maintainers each year on reviews done, + changes made, and open privacy questions. +- 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 document succeeds when the published privacy policy is accurate, owned, and +versioned, when users are told about material changes in time, and when every +past version can be retrieved. diff --git a/Governance/compliance/SANCTIONS.md b/Governance/compliance/SANCTIONS.md new file mode 100644 index 00000000..d81baf94 --- /dev/null +++ b/Governance/compliance/SANCTIONS.md @@ -0,0 +1,86 @@ +# Sanctions Compliance Policy + +## Purpose + +This policy sets out how TeachLink Web complies with economic and trade +sanctions: the screening that is required, how dealings with a prohibited party +are handled, and how doubts are escalated. It protects the project, its +maintainers, and its funders from inadvertently breaching sanctions law. This +document is a governance statement, not legal advice; maintainers consult +qualified counsel before relying on it for a legal decision. + +## Scope + +This policy applies to financial and contractual dealings of the project: +receiving donations or sponsorship, paying vendors or contributors, entering +agreements, hosting events, and granting paid or privileged access to services. +It does not restrict participation in the public open-source repository, which +follows the [Code of Conduct](../CODE_OF_CONDUCT.md) and legal advice on open +publication, and it complements the export control policy in this folder +([EXPORT_CONTROL.md](EXPORT_CONTROL.md)). + +## Screening Requirement + +Before a financial or contractual relationship starts: + +- A maintainer, usually the [Treasurer role](../roles/TREASURER.md), screens the + individual or organisation, and any known beneficial owners, against the + consolidated sanctions lists of the jurisdictions that apply to the project, + such as those of the US Treasury (OFAC), the UN, the EU, and the UK. +- Screening is repeated at least once a year for recurring relationships, and + whenever the lists change in a way that may affect an existing partner. +- Results and the lists checked are recorded with the date and the person who + screened them; a match, a partial match, or an inability to complete screening + is recorded as such. +- The project does not rely on a counterparty's own assurances alone for + relationships of significant value. + +## Prohibited Parties Handling + +If a party is on a sanctions list, or the dealing would involve a sanctioned +country or party: + +- The relationship is not started, or is paused at once if already under way. + Funds are not accepted or sent, and no services are provided. +- If funds have been received from a prohibited party, they are not used or + returned without legal advice, as returning them can also be prohibited; the + funds are held and counsel is consulted. +- The party is told only as much as is necessary and legally permitted. The + matter is kept confidential and not discussed in public channels. +- Contributors do not circumvent sanctions on behalf of anyone, for example by + routing payments through intermediaries. +- Ordinary open-source participation, such as reading the public code or filing + issues, is not blocked by this policy unless counsel advises that the law + requires it. + +## Escalation + +Anyone who suspects a sanctions issue acts promptly: + +- Raise it privately with the treasurer or the lead maintainers; do not + investigate on your own or tip off the party. +- The lead maintainers decide on the response, consult counsel, and decide + whether authorities or banks must be notified. +- Decisions and their reasons are recorded, and the screening process is + reviewed afterwards for gaps. +- Retaliation against someone who raises a concern in good faith is a conduct + matter under the [Code of Conduct reporting](../COC_REPORTING.md). +- This policy is reviewed once a year and after any sanctions incident. + +## Ownership and Review + +- Maintainers own this document and are accountable for applying it + consistently. +- The treasurer keeps the screening log and reports on screenings and matches to + the maintainers each year. +- 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 screening is done and recorded before relationships +begin, when prohibited dealings are stopped and escalated early, and when the +project never has to explain a breach it could have prevented.