From 3c79272ac685360f404d5c741c7439b647bbfc60 Mon Sep 17 00:00:00 2001 From: Essence Date: Sat, 17 Oct 2026 18:04:48 +0100 Subject: [PATCH 1/3] fix: Add a data access matrix for TeachLink Mobile (#1453) --- Governance/matrices/DATA_ACCESS_MATRIX.md | 74 +++++++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 Governance/matrices/DATA_ACCESS_MATRIX.md diff --git a/Governance/matrices/DATA_ACCESS_MATRIX.md b/Governance/matrices/DATA_ACCESS_MATRIX.md new file mode 100644 index 0000000..596bc2d --- /dev/null +++ b/Governance/matrices/DATA_ACCESS_MATRIX.md @@ -0,0 +1,74 @@ +# Data Access Matrix -- TeachLink Mobile + +## Purpose + +This document is the versioned, authoritative reference for who may access which classes of data within TeachLink Mobile. It closes the governance gap identified in the issue tracker and is scoped to the `Governance/` folder. + +This matrix applies to all data stored, processed, or transmitted by the TeachLink Mobile application, including on-device storage, backend services, and any third-party integrations. + +## Data Classifications + +Data is classified into four levels. Classification determines the minimum controls required for access. + +| Classification | ID | Description | Examples | +| --- | --- | --- | --- | +| Public | `P-0` | Data intended for open distribution; no confidentiality impact if disclosed. | Course catalog, marketing content, public profiles | +| Internal | `I-1` | Operational data restricted to the organization; minor impact if disclosed. | Aggregated usage metrics, content drafts, internal notes | +| Confidential | `C-2` | Personally identifiable information (PII) and business-sensitive data; moderate to significant impact if disclosed. | Names, email addresses, enrollment records, grades, payment metadata | +| Restricted | `R-3` | Highly sensitive data requiring strict need-to-know access; severe impact if disclosed or misused. | Authentication secrets, payment credentials, guardian-student messages, special-category data | + +## Roles + +Access is granted to roles, not individuals, and follows the principle of least privilege. + +| Role | ID | Description | +| --- | --- | --- | +| Student | `ROLE STUDENT` | End user enrolled in courses; accesses their own records and publicly available content. | +| Guardian | `ROLE PUARDAIN` | Parent or legal guardian of a student; accesses the linked student's records. | +| Teacher | `ROLE TEACHER` | Educator responsible for courses and assessments. | +| Administrator | `ROLE ADMIN` | Operational staff managing enrollments, support, and configuration. | +| Support Engineer | `ROLE SUPPORT` | Engineering staff providing break-fix support under break-glass procedures. | +| Service Account | `ROLE SERVICE` | Automated systems and background jobs operating with scoped credentials. | + +## Access Matrix + +Legend: `:white_check_mark:` = full access; `:large_blue_circle:` = access limited to own or linked records; `:x:` = no access. + +| Data Classification | Student | Guardian | Teacher | Administrator | Support Engineer | Service Account | +| --- | --- | --- | --- | --- | --- | --- | +| Public (`P-0`) | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | +| Internal (`I-1`) | :x: internal metrics only | :x: | :large_blue_circle: course-scoped | :white_check_mark: | :large_blue_circle: break-glass only | :large_blue_circle: job-scoped | +| Confidential (`C-2`) | :large_blue_circle: own records | :large_blue_circle: linked student | :large_blue_circle: assigned courses | :white_check_mark: | :large_blue_circle: break-glass only | :large_blue_circle: job-scoped | +| Restricted (`R-3`) | :x: | :x: | :x: | :large_blue_circle: audited need-to-know | :x: | :large_blue_circle: job-scoped, audited | + +## Access Conditions + +- All access to Confidential and Restricted data MUST be authenticated and authorized server-side; client-side checks are not sufficient. +- Guardian access requires a verified guardian-student link and MUST be limited to the linked student's records. +- Support Engineer access MUST occur under a time-bounded, audited break-glass procedure with explicit approval. +- Service Account access MUST be scoped to the minimum permissions required by the job and rotated on a schedule. +- Access to Restricted data MUST be logged with actor, timestamp, resource, and justification. +- Data MUST be transmitted over TLS 1.2+ and encrypted at rest using the project-approved encryption standard. + +## Review Cadence + +| Review Activity | Cadence | Owner | +| --- | --- | --- | +| Full matrix review and re-approval | Annually, and on any material change to data classifications or roles | Governance lead | +| Access grants for Confidential and Restricted data | Quarterly re-certification | Security lead | +| Break-glass access logs | Monthly review | Security lead | +| Service Account credential rotation and scope audit | Quarterly | Platform lead | + +Reviews MUST be recorded in the governance changelog with the reviewer, date, and any approved deviations. + +## Change Management + +- Any change to this matrix MUST be submitted as a pull request scoped to the `Governance/` folder. +- Changes MUST include a description of the rationale and the affected classifications or roles. +- Changes MUST be reviewed by the Governance lead and the Security lead before merge. + +## Version History + +| Version | Date | Description | +| --- | --- | --- | +| 1.0.0 | 2024-01-01 | Initial data access matrix for TeachLink Mobile. } From 3422b375be930dbfa1589a7d80ab6c494e3bccf5 Mon Sep 17 00:00:00 2001 From: Essence Date: Sat, 17 Oct 2026 19:56:22 +0100 Subject: [PATCH 2/3] fix: Add a data access matrix for TeachLink Mobile (#1453) --- Governance/README.md | 14 +++- Governance/matrices/DATA_ACCESS_MATRIX.md | 99 ++++++++++++----------- 2 files changed, 61 insertions(+), 52 deletions(-) diff --git a/Governance/README.md b/Governance/README.md index 5b2b334..f24a700 100644 --- a/Governance/README.md +++ b/Governance/README.md @@ -27,14 +27,14 @@ The governance documents are organised into the following areas. Individual documents are added and refined over time (tracked as issues): - **Templates** — contributor and maintainer starting points, including the - [`templates/BUG_REPORT_TEMPLATE.md`](templates/BUG_REPORT_TEMPLATE.md) for + [`Templates/BUG_REPORT_TEMPLATE.md`](templates/BUG_REPORT_TEMPLATE.md) for reporting app defects. - **Foundations** — charter, mission, values, principles, and glossary. - **Roles & membership** — contributor ladder, maintainer/reviewer roles, and the onboarding/offboarding lifecycle. The moderator role — duties, powers and limits, and appointment and removal — is defined in [`roles/MODERATOR.md`](roles/MODERATOR.md). -- **Decision-making** — consensus and voting rules, the RFC/proposal process, and +- **Decision-making** — consensus and voting rules, the RRC/proposal process, and decision records. - **Community & conduct** — code of conduct, enforcement, moderation (see [`roles/MODERATOR.md`](roles/MODERATOR.md)), and conflict resolution. @@ -53,7 +53,7 @@ self-contained and versioned with the repository: - `domains/APP_REVIEW_COMPLIANCE.md` — store guideline checklist, pre-submission review, and rejection handling for app store submissions. -- `domains/APP_VERSION_BUMP.md` — build-number and version-name rules. +- `domains/APP_VERSION_BUMP_md` — build-number and version-name rules. - `domains/BACKGROUND_TASK_GOVERNANCE.md` — background task ownership and limits. - `domains/BIOMETRIC_AUTH.md` — biometric authentication requirements. - `domains/DEVICE_SUPPORT.md` — supported device tiers and testing matrix. @@ -63,6 +63,14 @@ self-contained and versioned with the repository: - `domains/MOBILE_TELEMETRY.md` — telemetry consent, PII exclusion, and crash reports. - `domains/STORYBOOK_GOVERNANCE.md` — Storybook usage and maintenance. +## Matrices + +Cross-cutting reference matrices live in `Governance/matrices/`. Each matrix is +self-contained and versioned with the repository: + +- `matrices/DATA_ACCESS_MATRIX.md` — data classifications, roles, allowed + access per role, and review cadence for TeachLink Mobile data. + ## Contributing to governance Proposals to add or change governance are made by opening an issue or a pull diff --git a/Governance/matrices/DATA_ACCESS_MATRIX.md b/Governance/matrices/DATA_ACCESS_MATRIX.md index 596bc2d..a375ff0 100644 --- a/Governance/matrices/DATA_ACCESS_MATRIX.md +++ b/Governance/matrices/DATA_ACCESS_MATRIX.md @@ -1,74 +1,75 @@ -# Data Access Matrix -- TeachLink Mobile +# Data Access Matrix -## Purpose +This document defines the data classifications used in TeachLink Mobile, the roles that interact with that data, and the allowed access for each role. It is the versioned reference for data access governance and is self-contained within the `Governance/` folder. -This document is the versioned, authoritative reference for who may access which classes of data within TeachLink Mobile. It closes the governance gap identified in the issue tracker and is scoped to the `Governance/` folder. +## Scope -This matrix applies to all data stored, processed, or transmitted by the TeachLink Mobile application, including on-device storage, backend services, and any third-party integrations. +This matrix applies to all data processed, retained, or transmitted by the TeachLink Mobile application and its supporting infrastructure. It covers development, staging, and production environments. ## Data Classifications -Data is classified into four levels. Classification determines the minimum controls required for access. +Data is classified into four tiers. Each tier implies a different level of sensitivity and thus a different default access posture. -| Classification | ID | Description | Examples | -| --- | --- | --- | --- | -| Public | `P-0` | Data intended for open distribution; no confidentiality impact if disclosed. | Course catalog, marketing content, public profiles | -| Internal | `I-1` | Operational data restricted to the organization; minor impact if disclosed. | Aggregated usage metrics, content drafts, internal notes | -| Confidential | `C-2` | Personally identifiable information (PII) and business-sensitive data; moderate to significant impact if disclosed. | Names, email addresses, enrollment records, grades, payment metadata | -| Restricted | `R-3` | Highly sensitive data requiring strict need-to-know access; severe impact if disclosed or misused. | Authentication secrets, payment credentials, guardian-student messages, special-category data | +| Classification | Description | Examples | +| --- | --- | --- | +| **Public** | Data intended for open disclosure. | Marketing content, public course catalog, release notes. | +| **Internal** | Non-sensitive operational data limited to the team. | Aggregated usage metrics, build logs, feature-flag state. | +| **Confidential** | Personally identifiable information (PII) and account data. | Name, email, role in course, device identifiers, auth tokens. | +| **Restricted** | Highly sensitive data whose disclosure carries legal or significant operational risk. | Credentials, payment details, audit trails, security incident records. | ## Roles -Access is granted to roles, not individuals, and follows the principle of least privilege. +Roles are defined by the governance model in this repository. For the purpose of this matrix, the relevant roles are: -| Role | ID | Description | -| --- | --- | --- | -| Student | `ROLE STUDENT` | End user enrolled in courses; accesses their own records and publicly available content. | -| Guardian | `ROLE PUARDAIN` | Parent or legal guardian of a student; accesses the linked student's records. | -| Teacher | `ROLE TEACHER` | Educator responsible for courses and assessments. | -| Administrator | `ROLE ADMIN` | Operational staff managing enrollments, support, and configuration. | -| Support Engineer | `ROLE SUPPORT` | Engineering staff providing break-fix support under break-glass procedures. | -| Service Account | `ROLE SERVICE` | Automated systems and background jobs operating with scoped credentials. | +| Role | Description | +| --- | --- | +| **Public / Anonymous** | Unauthenticated users of the app. | +| **Learner** | Authenticated end user accessing their own account and course data. | +| **Instructor** | Authenticated user who manages courses and learner progress. | +| **Contributor** | Anyone with merge access to the repository via a pull request. | +| **Maintainer** | Reviewers with merge and release authority. | +| **Security Officer** | Responsible for vulnerability handling and incident response. | +| **System / Service** | Automated services and background jobs operating with scoped credentials. | ## Access Matrix -Legend: `:white_check_mark:` = full access; `:large_blue_circle:` = access limited to own or linked records; `:x:` = no access. +The table below specifies the allowed access per role for each data classification. Legend: -| Data Classification | Student | Guardian | Teacher | Administrator | Support Engineer | Service Account | -| --- | --- | --- | --- | --- | --- | --- | -| Public (`P-0`) | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | -| Internal (`I-1`) | :x: internal metrics only | :x: | :large_blue_circle: course-scoped | :white_check_mark: | :large_blue_circle: break-glass only | :large_blue_circle: job-scoped | -| Confidential (`C-2`) | :large_blue_circle: own records | :large_blue_circle: linked student | :large_blue_circle: assigned courses | :white_check_mark: | :large_blue_circle: break-glass only | :large_blue_circle: job-scoped | -| Restricted (`R-3`) | :x: | :x: | :x: | :large_blue_circle: audited need-to-know | :x: | :large_blue_circle: job-scoped, audited | +- **Read** — can view the data. +- **Write** — can create or modify the data. +- **Delete** — can remove the data. +- **None** — no access is permitted. -## Access Conditions +| Role | Public | Internal | Confidential | Restricted | +| --- | --- | --- | --- | --- | +| Public / Anonymous | Read | None | None | None | +| Learner | Read | None | Read (own records only) | None | +| Instructor | Read | Read | Read (assigned learners) | None | +| Contributor | Read | Read (dev/staging) | None | None | +| Maintainer | Read | Read, Write | Read (dev/staging), Write (dev/staging) | None | +| Security Officer | Read | Read | Read | Read, Write | +| System / Service | Read | Read, Write | Read, Write (scoped) | Read (scoped), Write (audit only) | -- All access to Confidential and Restricted data MUST be authenticated and authorized server-side; client-side checks are not sufficient. -- Guardian access requires a verified guardian-student link and MUST be limited to the linked student's records. -- Support Engineer access MUST occur under a time-bounded, audited break-glass procedure with explicit approval. -- Service Account access MUST be scoped to the minimum permissions required by the job and rotated on a schedule. -- Access to Restricted data MUST be logged with actor, timestamp, resource, and justification. -- Data MUST be transmitted over TLS 1.2+ and encrypted at rest using the project-approved encryption standard. +## Enforcement Rules -## Review Cadence +- Access to **Confidential** and **Restricted** data must be mediated by authentication and authorization checks in the application and backend services. +- **Restricted** data access must be logged to an audit trail that is itself classified as **Restricted**. +- System / service accounts use the principle of least privilege and must be scoped to the minimum data needed for their function. +- No role may read or write data outside its assigned scope, even within a permitted classification. +- **Confidential** data must not be copied into **Internal** or **Public** systems without anonymization or aggregation. -| Review Activity | Cadence | Owner | -| --- | --- | --- | -| Full matrix review and re-approval | Annually, and on any material change to data classifications or roles | Governance lead | -| Access grants for Confidential and Restricted data | Quarterly re-certification | Security lead | -| Break-glass access logs | Monthly review | Security lead | -| Service Account credential rotation and scope audit | Quarterly | Platform lead | +## Review Cadence -Reviews MUST be recorded in the governance changelog with the reviewer, date, and any approved deviations. +This matrix is reviewed on a schedule and on event: -## Change Management +- **Quarterly review** — the Security Officer and Maintainers confirm the matrix still reflects the app and infrastructure. +- **Event-driven review** — any change that introduces a new data classification, role, or data flow must update this document in the same pull request. +- **Annual attestation** — Maintainers attest that access grants in production match this matrix. -- Any change to this matrix MUST be submitted as a pull request scoped to the `Governance/` folder. -- Changes MUST include a description of the rationale and the affected classifications or roles. -- Changes MUST be reviewed by the Governance lead and the Security lead before merge. +Review outcomes are recorded in the pull request or issue that triggered the review. -## Version History +## Change Log -| Version | Date | Description | +| Date | Change | Author | | --- | --- | --- | -| 1.0.0 | 2024-01-01 | Initial data access matrix for TeachLink Mobile. } +| 2025-01-01 | Initial data access matrix. | Governance } From 9c238481fc3e673d45092a5d46eb0421be51103a Mon Sep 17 00:00:00 2001 From: Essence Date: Sat, 17 Oct 2026 19:57:10 +0100 Subject: [PATCH 3/3] fix: Add a data access matrix for TeachLink Mobile (#1453) --- Governance/README.md | 28 ++++---- Governance/matrices/DATA_ACCESS_MATRIX.md | 87 +++++++++++------------ 2 files changed, 55 insertions(+), 60 deletions(-) diff --git a/Governance/README.md b/Governance/README.md index f24a700..8bc1a3d 100644 --- a/Governance/README.md +++ b/Governance/README.md @@ -34,7 +34,7 @@ documents are added and refined over time (tracked as issues): onboarding/offboarding lifecycle. The moderator role — duties, powers and limits, and appointment and removal — is defined in [`roles/MODERATOR.md`](roles/MODERATOR.md). -- **Decision-making** — consensus and voting rules, the RRC/proposal process, and +- **Decision-making** — consensus and voting rules, the RFC/proposal process, and decision records. - **Community & conduct** — code of conduct, enforcement, moderation (see [`roles/MODERATOR.md`](roles/MODERATOR.md)), and conflict resolution. @@ -47,29 +47,29 @@ documents are added and refined over time (tracked as issues): - **Community & on-chain governance** — treasury, grants, and proposal governance. ## Domain documents - -Domain-specific policies live in `Governance/domains/`. Each document is +Domain-specific policies live in `Governance/domains/`. Each document ir self-contained and versioned with the repository: - `domains/APP_REVIEW_COMPLIANCE.md` — store guideline checklist, pre-submission review, and rejection handling for app store submissions. -- `domains/APP_VERSION_BUMP_md` — build-number and version-name rules. +- `domains/APP_VERSION_BUMP.md` — build-number and version-name rules. - `domains/BACKGROUND_TASK_GOVERNANCE.md` — background task ownership and limits. -- `domains/BIOMETRIC_AUTH.md` — biometric authentication requirements. -- `domains/DEVICE_SUPPORT.md` — supported device tiers and testing matrix. -- `domains/EAS_BUILD_GOVERNANCE.md` — EAS build profiles, secrets, and promotion. -- `domains/MOBILE_ACCESSIBILITY.md` — accessibility targets and merge gate. -- `domains/MOBILE_FEATURE_FLAGS.md` — feature-flag lifecycle and ownership. -- `domains/MOBILE_TELEMETRY.md` — telemetry consent, PII exclusion, and crash reports. -- `domains/STORYBOOK_GOVERNANCE.md` — Storybook usage and maintenance. +- `domains/BIOMETRIC_AUTN.md` — biometric authentication requirements. +- `domains/DEVICE_SUPPORT.md` — supported device tiers and testing matrix. +- `domains/EAS_BUILD_GOVERNANCE.md` — EAS build profiles, secrets, and promotion. +- `domains/MOBILE_ACCESSIBILITY.md` — accessibility targets and merge gate. +- `domains/MOBILE_FEATURE_FLAGS.md` — feature-flag lifecycle and ownership. +- `domains/MOBILE_TELEMETRY.md` — telemetry consent, PII exclusion, and crash reports. +- `domains/STORYBOOK_GOVERNANCE.md` — Storybook usage and maintenance. ## Matrices -Cross-cutting reference matrices live in `Governance/matrices/`. Each matrix is -self-contained and versioned with the repository: +Matrices live in `Governance/matrices/`. Each matrix is a versioned, +self-contained reference that maps a governance area to concrete roles and +access rules: - `matrices/DATA_ACCESS_MATRIX.md` — data classifications, roles, allowed - access per role, and review cadence for TeachLink Mobile data. + access per role, and review cadence for TeachLink Mobile. ## Contributing to governance diff --git a/Governance/matrices/DATA_ACCESS_MATRIX.md b/Governance/matrices/DATA_ACCESS_MATRIX.md index a375ff0..0eaa26b 100644 --- a/Governance/matrices/DATA_ACCESS_MATRIX.md +++ b/Governance/matrices/DATA_ACCESS_MATRIX.md @@ -1,75 +1,70 @@ # Data Access Matrix -This document defines the data classifications used in TeachLink Mobile, the roles that interact with that data, and the allowed access for each role. It is the versioned reference for data access governance and is self-contained within the `Governance/` folder. +This document defines the data classifications used by TeachLink Mobile, the roles that interact with that data, and the allowed access for each role. It is the versioned reference for data access governance and is self-contained within the `Governance/` folder. ## Scope -This matrix applies to all data processed, retained, or transmitted by the TeachLink Mobile application and its supporting infrastructure. It covers development, staging, and production environments. +This matrix applies to data handled by the TeachLink Mobile application, its build and release pipelines, and the supporting operational processes described in this folder. It does not grant access by itself; it defines what access is allowed for each role and must be enforced through tooling, review, and operational procedures. ## Data Classifications -Data is classified into four tiers. Each tier implies a different level of sensitivity and thus a different default access posture. +Data is classified into the following categories. Classification determines the minimum controls and the maximum access any role may hold. -| Classification | Description | Examples | -| --- | --- | --- | -| **Public** | Data intended for open disclosure. | Marketing content, public course catalog, release notes. | -| **Internal** | Non-sensitive operational data limited to the team. | Aggregated usage metrics, build logs, feature-flag state. | -| **Confidential** | Personally identifiable information (PII) and account data. | Name, email, role in course, device identifiers, auth tokens. | -| **Restricted** | Highly sensitive data whose disclosure carries legal or significant operational risk. | Credentials, payment details, audit trails, security incident records. | +| Classification | Description | Examples | Handling requirements | +| --- | --- | --- | --- | +| **Public** | Information intended for open distribution. | Marketing content, public docs, open-source code. | No special handling. | +| **Internal** | Non-sensitive operational data restricted to the project team. | Internal roadmaps, build logs without PII, non-production configuration. | Access on a need-to-know basis. | +| **Confidential** | Sensitive business or technical data whose disclosure could harm the project or its users. | Private keys for signing, secrets, unreported security issues, contract terms. | Encrypted at rest, least privilege, audited access. | +| **Restricted / PII** | Personally identifiable information and other data subject to privacy obligations. | User names, email addresses, device identifiers, telemetry that can be linked to a person. | Explicit authorization, minimization, retention limits, audit trail. | + +Any data that cannot be confidently classified is treated as the highest applicable classification until a decision is recorded. ## Roles -Roles are defined by the governance model in this repository. For the purpose of this matrix, the relevant roles are: +Roles are defined consistently with the rest of the governance documents in this folder. | Role | Description | | --- | --- | -| **Public / Anonymous** | Unauthenticated users of the app. | -| **Learner** | Authenticated end user accessing their own account and course data. | -| **Instructor** | Authenticated user who manages courses and learner progress. | -| **Contributor** | Anyone with merge access to the repository via a pull request. | -| **Maintainer** | Reviewers with merge and release authority. | -| **Security Officer** | Responsible for vulnerability handling and incident response. | -| **System / Service** | Automated services and background jobs operating with scoped credentials. | +| **Contributor** | Anyone who submits issues or pull requests to the repository. | +| **Reviewer** | Contributor trusted to review and approve changes in a designated area. | +| **Maintainer** | Responsible for merging changes, releases, and overall project health. | +| **Security team** | Handles vulnerability reports, embargoes, and advisories. | +| **Release manager** | Owns build and release pipelines and signing material. | +| **Operations / support** | Handles runtime operations and user support requests. | +| **Moderator** | Applies community and conduct policies (treated as a contributor for data access purposes). | ## Access Matrix -The table below specifies the allowed access per role for each data classification. Legend: - -- **Read** — can view the data. -- **Write** — can create or modify the data. -- **Delete** — can remove the data. -- **None** — no access is permitted. +Legend: **F = Full** (allowed without additional approval), **R = Read-only**, **W = Write with review** (allowed with review/approval), **N = No access**. -| Role | Public | Internal | Confidential | Restricted | -| --- | --- | --- | --- | --- | -| Public / Anonymous | Read | None | None | None | -| Learner | Read | None | Read (own records only) | None | -| Instructor | Read | Read | Read (assigned learners) | None | -| Contributor | Read | Read (dev/staging) | None | None | -| Maintainer | Read | Read, Write | Read (dev/staging), Write (dev/staging) | None | -| Security Officer | Read | Read | Read | Read, Write | -| System / Service | Read | Read, Write | Read, Write (scoped) | Read (scoped), Write (audit only) | +| Data classification | Contributor | Reviewer | Maintainer | Security team | Release manager | Operations / support | Moderator | +| --- | --- | --- | --- | --- | --- | --- | --- | +| **Public** | F | F | F | F | F | F | F | +| **Internal** | R | F | F | R | F | R | R | +| **Confidential** | N | N | W | F | W | N | N | +| **Restricted / PII** | N | N | W | W | N | R | N | -## Enforcement Rules +### Notes on the matrix -- Access to **Confidential** and **Restricted** data must be mediated by authentication and authorization checks in the application and backend services. -- **Restricted** data access must be logged to an audit trail that is itself classified as **Restricted**. -- System / service accounts use the principle of least privilege and must be scoped to the minimum data needed for their function. -- No role may read or write data outside its assigned scope, even within a permitted classification. -- **Confidential** data must not be copied into **Internal** or **Public** systems without anonymization or aggregation. +- **Full** access is still subject to the handling requirements for the classification. +- **Write with review** means the change must be approved by a second person holding at least the same access for that classification. +- **Security team** access to Restricted / PII data is limited to incident response and is subject to the disclosure process in this folder. +- **Operations / support** access to Restricted / PII data is read-only and must be justified by an open support request. +- No role has access to data outside the scope defined above; any exception requires a decision record in this folder. ## Review Cadence -This matrix is reviewed on a schedule and on event: - -- **Quarterly review** — the Security Officer and Maintainers confirm the matrix still reflects the app and infrastructure. -- **Event-driven review** — any change that introduces a new data classification, role, or data flow must update this document in the same pull request. -- **Annual attestation** — Maintainers attest that access grants in production match this matrix. - -Review outcomes are recorded in the pull request or issue that triggered the review. +- This matrix is reviewed at least **every six months** by the maintainers and security team. +- An **ad-hoc review** is triggered by any of the following: + - a new data classification is introduced; + - a new role is added or an existing role's responsibilities change; + - a security incident or privacy complaint is resolved; + - a relevant regulatory or platform requirement changes. +- Review outcomes are recorded by updating this document in a pull request that touches only the `Governance/` folder. +- If no changes are needed, the review is recorded in the relevant issue or pull request history. ## Change Log | Date | Change | Author | | --- | --- | --- | -| 2025-01-01 | Initial data access matrix. | Governance } +| 2025-01-01 | Initial data access matrix for TeachLink Mobile. | Governance }