Phoenix EmberA PECTECH product

Trust, Security and Compliance

Last updated 5 June 2026

This page sets out how Phoenix Wellbeing Tracker ("the Service", provided by Phoenix Education Consultancy, trading as PECTECH) is built and operated to meet our obligations to schools, parents, and children under the UK GDPR, the Data Protection Act 2018, and the Keeping Children Safe in Education guidance. It complements our Privacy Policy and Terms of Service with the technical and operational detail that buyers, DPOs, and IT teams typically need.

Roles under UK GDPR

When a school or trust uses the Service:

  • The school (or trust) is the data controller for the pupil and staff data it enters. The controller decides why and how the data is used.
  • PECTECH is the data processor, acting only on the school's documented instructions under a written Data Processing Agreement (DPA) that meets the requirements of UK GDPR Article 28.

For PECTECH's own business contacts (sales enquiries, marketing site analytics) PECTECH is the controller. Schools and trusts can request our standard DPA from compliance@pectech.org; it is issued under the school's existing contract and does not require separate negotiation.

Data hosting and residency

  • All school and pupil data is hosted in the United Kingdom, specifically the AWS London (eu-west-2) region.
  • No production data is processed or stored outside the UK. Backups, logs, and replicas all remain in-region.
  • The Service runs on AWS managed services (ECS Fargate, RDS PostgreSQL 17, S3, CloudFront, WAF). AWS holds independent assurance certifications (ISO 27001, ISO 27017, ISO 27018, SOC 1/2/3) covering the underlying infrastructure.

Encryption

  • In transit: every connection to the Service is TLS 1.2 or higher. We do not accept unencrypted HTTP. Internal service-to-service traffic stays inside a private VPC.
  • At rest: customer data in the PostgreSQL database and in S3 file storage is encrypted with AES-256, using AWS KMS-managed keys. Encryption is enforced at the storage layer — there is no way to write unencrypted data.
  • Passwords: never stored. We hash with Argon2id (memory-hard) and verify at sign-in. A password reset is the only path to recover an account; we cannot read a user's password.

Tenant isolation

The Service is a multi-tenant SaaS — every school's data shares the same database schema as every other school's. We rely on PostgreSQL row-level security (RLS) to keep one school's data from ever reaching another:

  • Every row in every tenant table carries a school identifier (or for trust-level rows, a trust identifier).
  • Application connections set the active tenant context per request before any query runs. The database itself enforces the filter — a query that tries to read another school's rows returns zero rows, regardless of how the application code is written.
  • Platform-admin escape clauses are explicit, audited, and used only for operational tasks (migrations, projections, customer-support tickets with consent).

This means a bug in application code cannot leak data across schools — the boundary lives in the database, not the application layer.

Role-based access within a school

Within a school, access is scoped to the user's role and their caseload:

  • Teaching assistants and teachers see only the pupils on their caseload.
  • SENCOs, senior leaders, and school admins see the school-wide picture.
  • Parents see only their own children, and only data the school has chosen to make on-record.
  • Platform admins (PECTECH staff) have no default access to school data. Access is granted per ticket, time-boxed, and audit-logged.

Mutations across the Service are recorded in an immutable audit log with the actor, the action, and the timestamp.

Backups, retention, and recovery

  • Backups: daily database snapshots are retained in AWS Backup for 35 days in warm storage and 7 years in cold storage. File uploads are versioned and replicated across multiple AWS availability zones.
  • Retention: customer data is retained for as long as the school's subscription is active and the school instructs us to hold it. On termination, data is deleted or returned in line with the DPA.
  • Recovery objectives: RPO of up to 24 hours (the last good daily snapshot) and an RTO target of 4 hours for a region-internal failure. We test our recovery procedures on a regular cadence.

Sub-processors

We use a small set of infrastructure sub-processors. Each is bound by a written contract that imposes equivalent data-protection obligations.

  • Amazon Web Services — cloud hosting, eu-west-2 (UK).
  • Stripe — billing and subscriptions; processes payment card and account-holder data only.
  • Amazon SES — transactional email delivery (account invites, password resets, notification digests).

We will notify schools at least 30 days before adding or replacing a sub-processor that processes pupil or staff data.

Operational security

  • Source code: held in a private repository with mandatory peer review on every change.
  • Deployments: continuous integration via GitHub Actions, with cross-account deploy roles assumed via short-lived OIDC tokens — no long-lived AWS keys are held in CI. Production and staging run in separate AWS accounts.
  • Secrets: stored in AWS Secrets Manager, never in source. Rotation is automated where supported.
  • Network: app servers and the database live in private subnets behind a WAF-protected CloudFront edge; the database is not reachable from the public internet.
  • Patching: dependencies are tracked by Dependabot; security advisories are triaged within one business day.
  • Logging and monitoring: structured JSON logs to CloudWatch with retention controls; alarms on error rates, latency, and failed-deploy signals.

Safeguarding stance

The Service is a wellbeing tracker, not a safeguarding system. Where the Service prompts staff to consider a safeguarding concern, that prompt is never stored, logged or exported — it exists only to direct staff to the school's own DSL and safeguarding process (typically CPOMS or equivalent).

Children's data

Because the Service processes special category data about children, we apply data minimisation strictly:

  • We do not use pupil data for advertising, profiling, or any purpose beyond delivering the Service to the school.
  • We do not sell personal data, ever.
  • We do not transfer pupil data outside the UK.
  • We do not retain pupil data beyond what the school's instructions and retention policy permit.

Incident response

If we detect a personal-data breach involving school data, we will notify the affected schools (the data controllers) without undue delay and within 72 hours of becoming aware, providing the information schools need to meet their own ICO notification obligations under UK GDPR Article 33.

To report a suspected security issue, email security@pectech.org. We will acknowledge within one business day.

Standards alignment

  • UK GDPR and the Data Protection Act 2018 — the regulatory floor; we operate on the assumption that the school is the controller and we are the processor under Article 28.
  • Keeping Children Safe in Education — informs the safeguarding-out-of-the-tool stance described above.
  • ISO 27001 / SOC 2 — the underlying AWS infrastructure is certified to both standards. PECTECH does not yet hold its own organisation-level certification; this is on our roadmap.

Contact

  • Data Protection and DPA requests — compliance@pectech.org
  • Security issues and disclosures — security@pectech.org
  • General enquiries — hello@pectech.org