Digital Shields holds information about children, families and school staff. This page explains how we protect it, what happens if something goes wrong, and how to tell us if you find a security problem.
1. How we protect your data
We protect it in layers, so that no single mistake or weakness exposes it. This is what each layer does today.
Who can sign in
- Passwords must be at least 10 characters, common passwords are refused, and we store them only as one-way hashes.
- Two-step sign-in, with a code from an authenticator app, is required for every member of our team and every school admin. A school can require it for all its staff, and parents can turn it on.
- Repeated wrong passwords lock the account from that address for 15 minutes. Guessing spread across many networks doesn't lock the real person out: it makes the right password need confirming by email too.
- Sessions end on their own: staff after 8 hours without use, our team after 30 minutes. Changing a password ends every other session, and signing out ends that session even if someone copied it.
Who gets an account
- A school's access code never creates an account on its own. Staff ask to join, confirm their email, and a school admin approves them (or the school allows its own email domain). Only then do they choose a password.
- Access codes change automatically when a member of staff is removed.
- We never email a password. Accounts set up for someone get a one-time link to choose their own, and links in our emails only act when you press a button on the page they open.
What each person can see
- Every school's data is kept apart from every other school's. Automated tests sign in as different schools and roles and check that nothing crosses over, on every route that takes an id, every time the code changes.
- Roles are checked on our server for every request, not just hidden in the page.
- We hold as little about pupils as we can: names and an MIS id, never UPNs, dates of birth, ethnicity or religion. SEND, pupil premium and EAL flags are off unless a school turns them on, are seen by senior leaders only, and figures for groups of fewer than 6 pupils are never shown.
- Tracking which member of staff did what is off unless the school turns it on.
- Our own team has two roles. Only owners can take whole-school actions or download a family's data, and every owner is alerted to each one. When we view a parent's account to help them, it is read-only unless we record a reason.
Protecting the data itself
- Everything travels over encrypted HTTPS connections, and browsers are told never to use anything else.
- Our database isn't reachable from the internet. Only our application can reach it, over a private network.
- Two-step sign-in secrets and any MIS connection tokens are encrypted again on their own (AES-256-GCM).
- Card details never reach us: payments are handled by Stripe.
Protecting the website
- Every page runs under a strict Content Security Policy that only lets our own scripts run, so a script hidden in data would not.
- Requests that are too big, nested too deeply or arriving too fast are refused before any of our code acts on them.
- The signed-in portals load no third-party analytics at all; the public pages only use analytics if you accept cookies.
- Sign-up is protected against bots.
Watching for problems
- Every change made by our team and by school admins goes into an audit trail. Each entry is chained to the one before, so any change or deletion would show, and a signed summary is emailed to our owners every day.
- Our owners are alerted at once to anything risky: a new team account, two-step sign-in being turned off, data exports, bursts of failed sign-ins and failed backups.
- We're enrolled in the NCSC's Early Warning service.
Backups and keeping lessons running
- The database is backed up every night, encrypted before it leaves our systems, and each backup is kept for 30 days. Restoring a backup is tested every quarter, starting this term.
- The service is built to run as more than one copy and to restart safely, and we have a written plan for moving to another host if we ever need to.
- Lesson packs a teacher has opened keep working offline, so a lesson can go ahead even if the internet or our service drops.
Your data, your rules
- Every kind of personal data we hold has a set retention period, enforced every night. A school's data is deleted 30 days after its licence is cancelled, and pupils who leave are deleted on the school's own schedule.
- A school admin can download everything held about a pupil to answer a subject access request. Parents can download or delete their own account at any time.
- Schools get a data processing agreement, a DPIA and our full list of sub-processors, with 30 days' notice before we add one or move where your data is held.
How we build it
- Every change is reviewed and must pass automated checks before it goes live, including the school separation tests and a check for known vulnerabilities in the software we use.
- Our keys and passwords are kept out of our code, and we can replace every one of them in a single planned change.
- We're certified to the UK government's Cyber Essentials scheme. An independent penetration test is being arranged.
Schools can find more detail in our schools privacy notice, our data processing agreement and, inside the schools portal, the DPIA template and the security overview. A school's data protection officer or IT lead can ask for our full security overview at security@digitalshields.co.
2. If something goes wrong
If we find that personal data has been lost, exposed or misused, we act at once to contain it. For a school's data we are the school's processor, so we tell the school's admins without undue delay and in any case within 72 hours of becoming aware, with what we know and what we've done, so the school can decide what it needs to report. For parents' data we are the controller: we report to the ICO within 72 hours where the law requires it, and tell you directly if there's a high risk to you.
3. Report a security problem
Email security@digitalshields.co. Please include:
- what you found and where (the page or address, and the account type you were using: parent, school staff or pupil);
- the steps to see it happen, and what an attacker could do with it;
- how we can contact you, and whether you'd like to be credited.
Please don't put other people's personal data in your report. If you came across any, describe it ("a pupil's name and year group") rather than copying it, and delete anything you saved.
Our contact details are also published, in the standard format, at /.well-known/security.txt. If you're a school or parent worried that your own account has been used by someone else, email support@digitalshields.co straight away, and change your password.
4. What's in scope
In scope: www.digitalshields.co and everything served from it, including the parent portal, the schools portal, the pupils' careers area, the admin sign-in and the APIs behind them.
Out of scope:
- denial of service, load testing, or anything that degrades the service for others;
- social engineering or phishing of our team, schools, parents or pupils, and physical attacks;
- services we use but don't run (for example Stripe, Resend, Railway, Cloudflare or GitHub): please report those to the provider;
- reports from automated scanners with no demonstrated impact, missing best-practice headers with no exploit, and self-XSS;
- email spoofing settings (SPF, DKIM, DMARC) unless you can show a real message being delivered as us.
5. Rules for testing
- Only use accounts you own or have been given permission to use. Never use a real school's, parent's or pupil's account.
- Never access, change, copy or delete data that isn't yours. If you reach someone else's data by accident, stop there, don't keep it, and tell us.
- Keep automated requests to a minimum, and stop if you see errors or slowdowns.
- Don't use what you find to go further into our systems than you need to show the problem.
- Give us a reasonable time to fix the problem before you tell anyone else: we ask for 90 days, or sooner once it's fixed. We'll agree the details with you.
- Don't ask for payment in return for not disclosing a problem.
6. Safe harbour
If you make a good-faith effort to follow these rules, we will treat your research as authorised. We will not take legal action against you, or ask the police to, for that research, including under the Computer Misuse Act 1990, and we will not complain to anyone about it. If someone else takes action against you for research done under this policy, we will make it known that you were acting with our permission.
This covers our own systems only. We can't give permission to test services run by other companies.
If you're unsure whether something is allowed, ask us first at security@digitalshields.co.
7. What we do with your report
- We'll acknowledge it within 3 working days.
- We'll tell you what we think of it, and what happens next, within 10 working days.
- We'll fix serious problems as fast as we can (the most serious within days) and keep you updated until it's fixed.
- If it affected anyone's personal data, we follow our incident process: we tell the schools whose data it was, report to the Information Commissioner's Office where the law requires, and tell the people affected where there's a high risk to them.
- With your permission, we'll credit you once it's fixed. We don't run a paid bug bounty at the moment.