Compliance

eViva is built so that the most sensitive data it handles, video recordings of students, never sits on eViva’s own servers. Recordings upload directly from the student’s browser to the school’s own cloud storage: Google Drive for Google Workspace schools, OneDrive for Microsoft 365 schools. eViva’s own application database holds the surrounding assessment metadata: names, email addresses, question text, timestamps, and session events. Infrastructure providers also process technical logs needed to deliver and secure the service. This is the single most important fact for a DPO evaluating eViva, and the page below is organised around it.

This page is the operator-side compliance directory. It identifies who runs eViva, where data is held, who else processes it, and which documents to request for a DPIA. Everything linked here is available without sales contact.

Operator

eViva is operated by Copeland Digital Ltd, a company incorporated in England and Wales.

For a UAE school’s procurement, eViva can also be licensed through LearnIT, a UAE-based reseller. The reseller route changes only the invoicing path. The operator of the service, the controller/processor relationship in the DPA, and the data handling described on this page do not change.

Architecture in one paragraph

A teacher creates an assignment in eViva and adds students. Each student receives a unique browser link. When the student records, the video bytes upload via the storage platform’s resumable upload protocol directly into the teacher’s own school cloud storage (Google Drive on Google Workspace tenancies; OneDrive on Microsoft 365 tenancies). eViva’s own database, hosted on Supabase in Frankfurt, records only the metadata: which student, which question, which stored file, the start and end times, and timestamped session events (focus loss, fullscreen exit, copy and paste, tab switch). No screenshots, no screen contents, and no analysis of video frames are captured at any point. The teacher reviews submissions on a dashboard; video plays back from the school’s own storage.

A fuller written description is in the Data Processing Overview, prepared as factual source material for a school’s DPIA.

Data residency

UK or UAE regional residency for the metadata store is available for whole-school customers on request. The default is EU (Frankfurt).

Sub-processors

This is the current informational list. It is kept up to date, but it does not override a signed agreement: where a signed DPA and this list differ, the DPA governs unless the school has approved the change under the DPA’s sub-processor procedure.

The two storage platforms are mutually exclusive per school: a Google Workspace school’s data is never processed by Microsoft, and a Microsoft 365 school’s data is never processed by Google. The platform follows the school’s own identity provider and does not change unless the school changes platform.

Changes to this list are notified to active customers in accordance with the sub-processor change procedure in the DPA (30 days written notice; 15 business days to object).

Documents

The following documents are available for direct download or by email to admin@eviva.tech.

Schools are encouraged to read the Data Processing Overview before requesting the DPA, because the overview sets out the factual basis the DPA relies on.

Google OAuth verification

eViva’s Google OAuth consent screen was verified by Google in May 2026. The consent screen uses a limited scope set: drive.file, classroom.courses.readonly, classroom.rosters.readonly, and classroom.profile.emails. None of these is a restricted scope, so Google’s annual security assessment (CASA) does not apply.

Any addition of a new sensitive or restricted scope, or any material change to the consent screen, triggers a fresh verification submission. Active customers are notified at least four weeks in advance of any such change, so they can plan around the re-verification window.

Microsoft Entra consent and scopes

For Microsoft 365 schools, eViva signs teachers in through Microsoft Entra ID and requests the delegated Graph scopes User.Read, Files.ReadWrite, and offline_access. Unlike Google’s drive.file, Microsoft Graph offers no per-app-file scope suitable for this workload, so Files.ReadWritegrants access to the signed-in teacher’s whole OneDrive. eViva’s conduct is narrower than the grant: it only ever creates and addresses folders and files under the eViva folder it makes, and every uploaded file is validated against the folder eViva created for that student. Schools that restrict user consent can pre-approve eViva tenant-wide through their admin-consent process.

Microsoft publisher verification for the eViva app registration is in progress; until it completes, the consent screen shows the publisher as unverified. This page will be updated when verification is granted.

Backup and recovery

The metadata database is backed up daily with point-in-time recovery, provided by Supabase Pro on enterprise infrastructure in Frankfurt. Recovery is exercised through a full restore-from-backup rehearsal at least once a year, and on any change to the Supabase plan or the schema migration tooling.

Restore rehearsal log: A full restore rehearsal is scheduled ahead of production onboarding; this log records the date and outcome of each rehearsal once performed, updated within five working days. The governing procedure is in the Incident Response Procedure, §7.

Incident response in brief

The full procedure is available on request. The headline commitments:

• 24 hours from awareness to the first notification to an affected school’s named breach-routing contact, if a Personal Data Breach is confirmed or strongly suspected. This matches the contractual notification window in the DPA.
• 48-hour update cadence thereafter, until closure.
• Severity classification at acknowledgement (S1 to S4), with target acknowledgement times of 1 hour (S1), 4 hours (S2), 1 working day (S3), 5 working days (S4).
• Post-incident review within 5 working days of closure (S1, S2) or 15 working days (S3, S4), with lessons learned and follow-up actions recorded.

The procedure is reviewed annually and after any S1 or S2 incident.

Reporting a vulnerability

If you have found a security issue in eViva, please write to admin@eviva.tech with the details. We acknowledge reports within two working days. Please give us a reasonable period to remediate before any public disclosure. We do not currently operate a paid bug bounty.

Please do not test for vulnerabilities against production data. If you need a test environment, ask first.

Assurance and certifications

The foundations eViva is built on are independently audited. Student recordings never leave the school’s own Google Workspace or Microsoft 365 tenancy, and the metadata eViva holds runs on platforms that hold SOC 2 Type IIreports (Supabase for the database, Vercel for hosting), in the EU (Frankfurt), encrypted in transit and at rest, with row-level security isolating every school’s data. eViva is built directly on the substantive controls those audited platforms already enforce.

eViva’s identity and storage layers are the schools’ own enterprise platforms: Google Workspace and Microsoft 365, each certified to the standards their own procurement teams have already accepted. Sign-in uses the school’s existing identity provider and its multi-factor policies; recordings live in the school’s existing storage under its existing agreement with Google or Microsoft.

Independent certification of eViva’s own controls, to SOC 2 and ISO/IEC 27001, is on the roadmap and progresses with the school customer base. A KCSIE-aligned safeguarding statement for UK schools is in preparation for publication here. Procurement-specific assurances, including the current insurance position and a completed security questionnaire, are provided in the school agreement and on request from admin@eviva.tech.

Last updated: 4 July 2026. For questions about anything on this page, email admin@eviva.tech.