Phoenix EmberA PECTECH product

Trust, Security and Compliance

Last updated 27 July 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

Carbon and environmental impact

Phoenix Education Consultancy Limited (registered in England and Wales, number 11373727) reports the greenhouse gas emissions associated with operating Phoenix Ember. We publish this so that schools and trusts can complete supplier carbon assessments without requesting a bespoke document from us.

Emissions

Baseline year: 2026, covering 1 January to 31 December 2026.

  • Scope 1 — direct: 0 tCO2e
  • Scope 2 — purchased energy: 0 tCO2e
  • Scope 3 — value chain: 1.55 tCO2e
  • Total: 1.55 tCO2e

Scope 1 and Scope 2 are zero because the company holds no premises or vehicles under its operational control and purchases no energy directly. Our footprint is therefore entirely Scope 3, arising from cloud hosting, business travel, purchased goods and services, and our outsourced development supplier.

Cloud hosting

Phoenix Ember runs entirely in AWS Europe (London), `eu-west-2`. No pupil data leaves the United Kingdom.

Hosting emissions are measured using AWS's Customer Carbon Footprint Tool (methodology Model 3.0, October 2025), which is prepared under the GHG Protocol Corporate Accounting and Reporting Standard, ISO 14064-1, the GHG Protocol Product Life Cycle Standard with ICT sector guidance, and ISO 14040/14044. Amazon's underlying corporate footprint is subject to third-party assurance, and the emission factors used are third-party reviewed annually.

For the period measured, hosting emissions were 0.040 tCO2e on the location-based method and 0.013 tCO2e on the market-based method.

We report against the location-based figure. The market-based figure depends on the contractual instruments our hosting supplier holds. Amazon's global renewable energy claim has been publicly challenged over its use of unbundled renewable energy certificates and is the subject of an ongoing inquiry by a group of US state attorneys general. Our hosting region is supplied under genuine contracted generation — the East Anglia THREE and Chirmorie wind projects — but we cannot evidence a bundled-versus-unbundled split for the London region specifically, so we report the conservative figure rather than rely on a claim under scrutiny.

AWS's methodology excludes end-of-life treatment of IT hardware, non-IT equipment and data centre buildings, and excludes AWS facilities beyond data centres. AWS also states that current-month Scope 1 data is unassured and may under-estimate, and is corrected when data is recast.

Expected growth

Cloud hosting is currently a small share of our total footprint. That will change as the number of schools using Phoenix Ember grows, and we expect hosting to become the dominant line. A future year showing materially higher cloud emissions reflects that growth rather than any deterioration in efficiency, and it is why our reduction effort is focused on the hosting region.

Targets and reduction

Phoenix Education Consultancy Limited commits to achieving Net Zero emissions in the UK by 2034, ahead of the 2050 target set out in Procurement Policy Note 006.

Measures already in place:

- All production infrastructure runs in AWS `eu-west-2` (London), supplied under Amazon's UK renewable power purchase agreements, rather than self-managed or co-located hardware. - Application compute autoscales to demand rather than running fixed provisioned capacity around the clock. - Non-production environments are placed into an out-of-hours maintenance tier outside working hours rather than running continuously.

From 2028 we intend to neutralise residual emissions through the UK Woodland Carbon Code — UK-based, government-backed removals rather than avoidance credits, and independently verifiable. We have deliberately not chosen the cheapest available credits.

From 2035 our intention is to shift neutralisation towards carbon projects within the communities Phoenix Ember serves, rather than purchasing credits on the open market.

Basis of preparation

Prepared under the GHG Protocol Corporate Accounting and Reporting Standard, using the 2026 UK Government (DESNZ) Greenhouse Gas Conversion Factors for Company Reporting. Consolidation approach: operational control. Reported in tonnes of CO2 equivalent.

This disclosure is self-reported and has not been independently verified. The cloud hosting figures within it derive from AWS's Customer Carbon Footprint Tool, whose underlying corporate footprint is subject to third-party assurance. Supporting calculations are available to an appointed assurance provider.