Updated 14 days ago

Data Workflows#

This document defines when your tool needs sign-off from the Data team, what triggers a penetration test, and how to handle backups. These rules protect Springpod's students, schools, and employer partners.

Data classification#

Every piece of data your tool touches falls into one of four categories. The category determines your build path and what approvals you need.

Data type	Examples	Build path	Data team sign-off?
Public	Marketing copy, published course descriptions, public event listings	Green	No
Business	Internal metrics, team KPIs, pipeline reports, anonymised aggregates	Yellow	Only if connecting to DWH
Personal	Names, email addresses, school names linked to individuals, employer contacts	Orange	Yes
Protected	Student data (under-18s), assessment results, health information, safeguarding records	Red	Yes — mandatory review

Springpod works with students aged 13+. Data about minors carries the highest legal obligations under UK GDPR, DPA 2018, and the ICO's Children's Code (a statutory code of practice under the DPA). Getting the classification wrong can mean building a Green-path tool when you actually need Red-path protections — putting students at risk.

List every piece of data your tool will read, write, display, or send
For each item, ask: "Could this identify a real person?" If yes, it is at least Personal
Then ask: "Could this person be under 18?" If yes, it is Protected
If you are unsure about any item, treat it as the higher category and flag it in your Review Request

When to involve the Data team#

You must get Data team sign-off before you ship if your tool does any of the following.

All build paths#

Connecting to any database or data warehouse

This includes read-only connections. Even viewing data requires approval because it creates a new access point.

Every connection to a database is a potential entry point. The Data team needs to know who and what is connecting so they can monitor access and revoke it if something goes wrong.

Does your tool use a database URL, connection string, or API endpoint that points to a Springpod database?
Does it connect to the data warehouse (DWH) — even through a dashboard tool like Metabase or Looker?
If the answer to either is yes, contact the Data team before going further. See ROLES for who to reach.

Importing or exporting data files (CSVs, spreadsheets, JSON)

Moving data between systems via files is one of the most common ways data leaks happen. A CSV on someone's laptop is unencrypted and untracked.

Files downloaded from one system and uploaded to another bypass all the access controls built into those systems. Once data is in a spreadsheet, you have lost control of who copies it, emails it, or leaves it on a shared drive.

Using external APIs that receive Springpod data

If your tool sends any Springpod data to an external service (including AI APIs like OpenAI or Anthropic), the Data team must review what data is being sent and where.

When you send data to an external API, you are sending it outside Springpod's control. The Data team checks that the service is approved, the data is appropriate to share, and a data processing agreement is in place. See also Security Standard — third-party services.

Orange and Red paths#

Any tool that reads, writes, or displays student data

Student data includes names, emails, enrolment records, school affiliations, programme progress, and anything else tied to a student account. No exceptions.

Springpod's students are predominantly under 18. Their data has the highest protection requirements under UK law. The Data team must verify that your tool collects only what it needs, stores it correctly, and restricts access appropriately.

Search your tool for any reference to students, enrolments, schools, or programmes
Check whether your tool displays any information that could identify a student
If your tool shows aggregated numbers (e.g., "450 students enrolled"), confirm the numbers cannot be narrowed down to identify individuals (e.g., filtering by school + programme + date could reveal a single student)
If any of these apply, raise a Review Request and tag the Data team

Any tool that creates new data stores or tables

If your tool creates a new database table, a new spreadsheet, or a new collection of records, the Data team needs to know. New data stores must follow Springpod's data architecture standards.

Penetration testing triggers#

A penetration test (pen test) is a controlled attempt to break into your tool, performed by a specialist. You do not run it yourself — but you need to know when one is required.

Your tool needs a pen test if any of these are true#

Your tool is external-facing and has a login

If someone outside Springpod (students, schools, employers) can access your tool and it requires authentication, a pen test is required before launch.

A login page is the most common target for attackers. External-facing tools are discoverable by anyone on the internet. A pen test finds weaknesses before an attacker does.

Your tool processes personal or protected data

Any tool handling personal data (Orange path) or protected data (Red path) must pass a pen test before going live.

Check your data classification from the table above
If your tool is Orange or Red path, flag it for pen testing in your Review Request
The reviewer will coordinate with the security team to schedule the test
Do not schedule a launch date until the pen test is complete

Your tool connects to production databases

Any tool with a direct connection to a production database — not a copy, not a staging environment, the real thing — must be pen tested.

A vulnerability in a tool connected to production means an attacker could access real user data. There is no "we can restore from backup" when personal data has been exposed — the damage is the exposure itself.

What happens during a pen test#

You do not need to do anything technical. The process:

You flag the requirement in your Review Request
The designated reviewer coordinates with the security team
The security team tests your tool (typically 1–3 days)
You receive a report with findings rated Critical / High / Medium / Low
Critical and High findings must be fixed before launch
Medium findings should be fixed within 30 days of launch

Backup requirements#

All build paths#

You know where your tool's data lives and who is responsible for backing it up

Before you launch, you must be able to answer: "If this tool lost all its data right now, how would we recover?" If you cannot answer that, stop and sort it out.

List every place your tool stores data (database, file storage, spreadsheet, third-party service)
For each one, confirm: is it backed up? How often? Who manages the backups?
If your tool uses a managed service (Supabase, Firebase, Airtable), check the provider's backup policy in their documentation
If your tool uses Springpod's DWH, the Data team manages backups — but you must confirm your data is included

Yellow path and above#

Automated backups run at least daily

Manual backups are not reliable enough for business data. Your data store must have automated daily backups at minimum.

People forget. People leave. Automated backups happen whether or not anyone remembers to run them. A day of lost data is recoverable. A month of lost data can be catastrophic.

Orange and Red paths#

Backups are encrypted and access-controlled

Backups of personal or protected data must be encrypted. Only authorised personnel should be able to access or restore them.

An unencrypted backup is a copy of all your sensitive data sitting in a second location with potentially weaker security. If someone accesses your backups, they access everything.

Backup restoration has been tested at least once

A backup you have never tried to restore is not a backup — it is a hope. Before launch, restore from a backup to confirm it works.

Ask the Data team or your hosting provider to perform a test restore
Verify the restored data is complete and correct
Document when the test was performed and the result
If the restore fails, fix the backup process before launching

Data warehouse (DWH) considerations#

Any tool writing to the DWH has been reviewed by the Data team

Reading from the DWH requires sign-off (covered above). Writing to the DWH has stricter requirements because bad data flowing in can corrupt reports and dashboards used across the company.

The DWH feeds Springpod's reporting, analytics, and business decisions. A tool that writes incorrect or duplicated data to the DWH can cause wrong numbers in board reports, inaccurate school dashboards, or broken partner metrics. The Data team must validate your data schema, transformation logic, and write frequency.

DWH backup schedule confirmed with Data team

The DWH has its own backup schedule managed by the Data team. If your tool depends on DWH data, confirm the backup frequency meets your tool's recovery requirements.

Quick reference#

What your tool does	Data classification	Build path	Data team sign-off	Pen test required	Backup requirement
Displays public content only	Public	Green	No	No	Provider default
Reads internal metrics from DWH	Business	Yellow	Yes	No	Daily automated
Imports employer contact CSVs	Personal	Orange	Yes	Yes (if external)	Daily, encrypted
Shows student enrolment data	Protected	Red	Yes — mandatory	Yes	Daily, encrypted, tested
Writes to production database	Depends on data	Orange or Red	Yes	Yes	Daily, encrypted, tested
Sends data to external AI API	Depends on data	Orange or Red	Yes	Depends on data type	Depends on data type

What to do if you are unsure#

If you are not sure how to classify your data, whether you need a pen test, or what backup approach to use — ask. It is always safer to check than to guess.

Start with When to Escalate for guidance on who to contact
Raise a Review Request and describe what your tool does with data
The Data team and your designated reviewer will help you get it right

Was this page helpful?