DPIA template

Submitting controller details

The processor, for your records. Wingsuit is a trading name of A2x Development Ltd, a company registered in England and Wales, number 17455293, registered office 82a James Carter Road, Mildenhall, Bury St. Edmunds, England, IP28 7DE. It has one director, Alexander Colville, and no other staff; he is the contact for data protection matters, at support@usewingsuit.co.uk. The company has not appointed a data protection officer and is not required to.

Step 1: Identify the need for a DPIA

Explain broadly what project aims to achieve and what type of processing it involves. You may find it helpful to refer or link to other documents, such as a project proposal. Summarise why you identified the need for a DPIA.

Wingsuit’s answer. Wingsuit is a set of teaching tools built for a sixth form college: an infinite-canvas whiteboard that a teacher can write on, import images, PDFs, Word documents and PowerPoint decks into, and keep synchronised across her own devices; view-only share links; persistent broadcast “rooms” whose link a teacher posts once to somewhere like Google Classroom and reuses each lesson. The processing it involves is storing and displaying teaching content, plus the account and session data needed to sign a teacher in and keep her work with her.

Wingsuit does not need student personal data and does not ask for it. Students have no accounts, no profiles, no way to write or comment, and no way to message anyone. Student personal data only enters Wingsuit if a teacher writes or uploads it onto a board.

[School to complete]: why your institution identified the need for a DPIA, or its record of deciding one is not required. Relevant to that decision: this is not systematic monitoring, not profiling or automated decision-making, not large-scale special category data, and there is no advertising, analytics or AI in the product. It does involve children’s data where a teacher chooses to put it on a board, and it involves a new supplier, so a screening exercise is worth recording either way. In the ICO’s own vocabulary, the criterion that plainly applies is “data concerning vulnerable data subjects”: students, some of whom are children. That single factor is the one most likely to push a school into doing a DPIA, and the ICO’s threshold is a combination of two.

Step 2: Describe the processing

Describe the nature of the processing: how will you collect, use, store and delete data? What is the source of the data? Will you be sharing data with anyone? You might find it useful to refer to a flow diagram or other way of describing data flows. What types of processing identified as likely high risk are involved?

Wingsuit’s answer. Data comes from the teacher: she creates an account (name, email, and either a password, stored only as a hash, or a Google sign-in, or an Apple sign-in in the iPhone and iPad app), then draws, types and uploads onto boards. Sessions record a token, an expiry, an IP address and a user agent. Boards, folders, uploaded images, PDFs and rooms are stored in a Postgres database and an object store; uploaded files are keyed by the SHA-256 of their own bytes. Support tickets, any screenshot attached to them, and audit records of sensitive actions (who did what and when, never board content) are stored too, as are aggregate daily usage counts.

Content is shared only when a teacher chooses: a view-only share link, or a broadcast to a room. A viewer is an anonymous websocket connection, held in memory and counted; nothing about a viewer is written to the database. A broadcast lapses at the next midnight, Europe/London, and turning sharing off closes viewers’ connections at once.

Deletion is enforced in code by an hourly sweep. Deleted boards sit in a recycle bin for 7 days (Wingsuit Starter) or 90 days (Wingsuit Pro); uploaded files go once nothing has referenced them for a day; support screenshots go after 30 days, resolved tickets and their messages after 180 days, audit events after 365 days, daily usage counts after 90 days; temporary quick whiteboards expire 8 hours after their last change. Account deletion is self-service: asking freezes the account at once, and it is deleted 14 days later unless the teacher signs in and restores it in the meantime; boards in an organisation’s or a team’s space pass to another member of it rather than going with the account. A teacher can also ask for a copy of everything held about her, which is built in the background and removed 7 days after it is ready. The published schedule is at usewingsuit.co.uk/data.

Data is shared with sub-processors only as needed to run the service: hosting, database, file storage and backups; a document-conversion server for Word and PowerPoint import, which receives the file, returns a PDF and keeps nothing; card payments on the web, taken by Stripe directly; and three kinds of email to a teacher’s own address, a link to confirm it, a link to reset her password and a confirmation when she cancels a subscription, plus reports a teacher makes about something shared with her, sent to Wingsuit’s own support address with the names and email addresses of the people involved; Resend sends them all, and never receives what is drawn on a board. Errors are reported to no one: a failure is written to the server’s own logs and nowhere else. Each sub-processor is named at usewingsuit.co.uk/subprocessors. Wingsuit sends no other email (Stripe sends payment emails on its behalf), runs no analytics, and uses no CDN, third-party fonts or AI provider. Billing itself is run by Wingsuit rather than a billing supplier: subscriptions, grants of a plan or raised limits, redeemable codes, school email-domain rules, a credit ledger in pence, orders with the consent wording the teacher was shown, and a content-free 90-day log of provider events are all held in Wingsuit’s own database, and all of it goes when the account does.

None of the types of processing the ICO lists as likely high risk (profiling, automated decision-making with legal effect, systematic monitoring, biometric or genetic data, tracking, invisible processing) is involved. The ICO’s children bullet is wider than marketing: it also covers a service you “intend to offer online services directly to children”. Wingsuit is offered to teachers and schools, and a student who opens a view-only link is not registered, counted individually, tracked or stored, but that limb is one your DPO should record their own view on rather than take ours.

Describe the scope of the processing: what is the nature of the data, and does it include special category or criminal offence data? How much data will you be collecting and using? How often? How long will you keep it? How many individuals are affected? What geographical area does it cover?

Wingsuit’s answer. The data is account data (name, email, optional profile image, role, credential), session technical data, and teaching content (whatever a teacher puts on a board). No special category or criminal offence data is intended or needed, and Wingsuit asks that none be uploaded; a board is a teaching surface, not a record system. Processing is continuous while the tools are in use, at whatever volume the teacher’s own lessons generate. Retention is as set out above. Geographically, all application data (database, uploaded files and backups) is stored in the Netherlands (Railway’s EU West region, Amsterdam); the United Kingdom’s adequacy regulations cover the EEA.

[School to complete]: how many staff will hold accounts, how many students are likely to view broadcasts, and whether your own policies permit any special category data near a board (Wingsuit’s instruction is that they should not).

Describe the context of the processing: what is the nature of your relationship with the individuals? How much control will they have? Would they expect you to use their data in this way? Do they include children or other vulnerable groups? Are there prior concerns over this type of processing or security flaws? Is it novel in any way? What is the current state of technology in this area? Are there any current issues of public concern that you should factor in? Are you signed up to any approved code of conduct or certification scheme (once any have been approved)?

Wingsuit’s answer. The teacher holds an account and controls it: she can delete any board, empty the recycle bin, turn sharing off, and delete her account and everything it owns from Settings. A student is a viewer, not a user; she is shown a board and can do nothing else, so her control is the control the teacher exercises on her behalf. Students at a sixth form college are mostly 16 to 18, and some will be children; that is the main reason to be careful about what goes on a board.

The processing is not novel (a shared whiteboard is ordinary classroom technology) and Wingsuit is deliberately narrower than most of its alternatives: no chat, no student accounts, no analytics, no AI. Wingsuit is signed up to no approved code of conduct or certification scheme. It holds no ISO 27001 or Cyber Essentials certification and has had no penetration test, and A2x Development Ltd has one director and no other staff. Those are stated plainly rather than dressed up.

[School to complete]: your relationship with the students and staff affected, any prior concerns at your institution about classroom broadcast tools, and whether your procurement rules expect supplier certifications Wingsuit does not hold.

Describe the purposes of the processing: what do you want to achieve? What is the intended effect on individuals? What are the benefits of the processing — for you, and more broadly?

Wingsuit’s answer. The purpose is teaching: to let a teacher write on a surface her class can see, in the room or at home, and to keep her materials where she can find them next year. The intended effect on a student is that she can see the board; on a teacher, that she stops losing work to a wiped whiteboard or a lost file. Wingsuit uses the data for nothing else: no advertising, no profiling, no training of models, no analytics.

[School to complete]: the educational purpose your institution is pursuing and the benefits it expects, in its own terms.

Step 3: Consultation process

Consider how to consult with relevant stakeholders: describe when and how you will seek individuals’ views — or justify why it’s not appropriate to do so. Who else do you need to involve within your organisation? Do you need to ask your processors to assist? Do you plan to consult information security experts, or any other experts?

[School to complete.] Consultation is the controller’s to run: with staff who will teach on it, with students or their parents if you judge that appropriate, and with your own IT and safeguarding leads.

What Wingsuit can offer. Section 6.2 of the data processing agreement at usewingsuit.co.uk/dpa commits Wingsuit to reasonably assist with a mandated DPIA or transfer impact assessment. In practice: email support@usewingsuit.co.uk and questions about how something works get a direct answer. Wingsuit has not commissioned an independent security expert, so if you want one consulted, that is yours to arrange.

Step 4: Assess necessity and proportionality

Describe compliance and proportionality measures, in particular: what is your lawful basis for processing? Does the processing actually achieve your purpose? Is there another way to achieve the same outcome? How will you prevent function creep? How will you ensure data quality and data minimisation? What information will you give individuals? How will you help to support their rights? What measures do you take to ensure processors comply? How do you safeguard any international transfers?

Lawful basis: [School to complete.] Wingsuit cannot choose the school’s lawful basis. For a college this is commonly public task, or legitimate interests for staff account data; your DPO decides and records it, along with any Article 9 condition if special category data could ever be involved.

Does it achieve the purpose, and is there another way? Wingsuit stores what a teacher draws so she can show it and reopen it. There is no way to provide a synchronised, shareable whiteboard without storing its contents. What can be avoided is storing anything about the audience, and Wingsuit does avoid it: viewers are anonymous connections, never database rows.

Function creep. The permitted purposes are fixed by the DPA: processing is limited to providing and maintaining the service. Wingsuit runs no advertising, no analytics, no AI features and no profiling, and does not use teaching content for any purpose of its own. Any new sub-processor is published at usewingsuit.co.uk/subprocessors and emailed to a school with a signed DPA at least 10 business days before it begins, with a right to object and, if the objection is not resolved, to end the agreement.

Data quality and minimisation. The teacher controls the content and can correct or delete it at any time. Minimisation is built in: no student accounts, no student profiles, no names asked for, nothing recorded about viewers, speaker notes from imported decks stored apart from the board so viewers never receive them, and retention periods enforced in code by an hourly sweep rather than left to good intentions.

Information to individuals. Wingsuit publishes a privacy policy at usewingsuit.co.uk/privacy and a residency and retention page at usewingsuit.co.uk/data. [School to complete]: your own privacy notice to staff and students has to cover this use; a supplier’s policy is not a substitute for it.

Supporting rights. A teacher can export, correct and delete her own content and delete her account from Settings. For a request that reaches Wingsuit rather than the school, Section 6.1 of the Standard Terms requires Wingsuit to notify the school and not to respond without its instruction. The same applies to complaints: since 19 June 2026, section 164A of the Data Protection Act 2018 requires a controller to facilitate complaints, acknowledge them within 30 days, investigate without undue delay and report the outcome. Where the school is the controller that duty is the school’s, and a complaint that arrives at Wingsuit is passed on with help answering it; Wingsuit handles complaints about its own processing (teachers’ accounts) itself, at support@usewingsuit.co.uk, and the route is set out in the privacy policy.

Ensuring processors comply. Sign the DPA at usewingsuit.co.uk/dpa; it incorporates the Common Paper DPA Standard Terms v1.1, which flow the Article 28(3) obligations down to sub-processors and keep Wingsuit fully liable for them, and its Cover Page requires notification of a personal data breach within 72 hours and gives the school audit and due diligence rights. Wingsuit publishes no third-party audit report because it has none; written security questions to the contact address are the route instead.

International transfers. Application data is stored in the Netherlands, and so is the document-conversion service used for Word and PowerPoint import, which runs on Railway in the same region. The Netherlands is an EEA state, which the United Kingdom’s regulations under Article 45A of the UK GDPR cover, so this is not a restricted transfer (Data Protection Act 2018, Schedule 21, paragraphs 4 and 5). Storage location is not the whole test, though: several suppliers are companies established in the United States whose staff can reach the systems, which is a transfer in itself. Checked against the Data Privacy Framework list on 19 September 2026: Railway Corporation and Stripe, LLC are active under its UK Extension for HR and non-HR data. Resend, which sends Wingsuit’s account emails and stores them in the United States, is active under the UK Extension for non-HR data, checked on 13 October 2026, and its agreement also carries the EU Standard Contractual Clauses with the UK Addendum. Every recipient in the United States therefore has a named safeguard, and the certifications and agreements are re-checked every year and whenever a supplier is added. The full position is set out at usewingsuit.co.uk/subprocessors. Railway’s own platform logs and service metadata are not confined to the pinned EU West region and may be processed in the United States; that transfer is covered by Railway Corporation’s participation in the UK Extension to the EU-US Data Privacy Framework, as above.

Step 5: Identify and assess risks

Wingsuit has pre-filled the risks it can see and scored them as a supplier would. The scores are a starting point for your DPO, not a verdict: a school that puts more student data on boards should score the first row higher.

Likelihood of harm: remote, possible or probable. Severity of harm: minimal, significant or severe. Overall risk: low, medium or high.

Step 6: Identify measures to reduce risk

Identify additional measures you could take to reduce or eliminate risks identified as medium or high risk in step 5. The options below are measures that exist in Wingsuit today, plus the school-side measures that go with them. Residual risk and approval are the controller’s to judge, so they are left blank.

Effect on risk: eliminated, reduced or accepted. Residual risk: low, medium or high. Measure approved: yes/no.

Step 7: Sign off and record outcomes

This step is the controller’s alone. Wingsuit has filled in nothing here and cannot.