docs(governance): add privacy governance, export control, sanctions and children's data policies

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.

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.

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.

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.