Data Processing Agreement

Last updated: October 2026

This agreement ("DPA") forms part of the Terms of Service between RunCode Inc ("RunCode", "we") and the organisation that signs up for The Skill Site (the "Customer"). The Customer accepts it when it accepts the Terms. It applies whenever RunCode processes personal data on the Customer's behalf ("Customer Personal Data"). Words such as controller, processor, personal data, processing and personal data breach have the meanings they have in the UK GDPR and the Data Protection Act 2018.

1. Roles

The Customer is the controller of the personal data of its staff and learners that it, its staff or its connected systems (an LMS or its own systems through the API) put into The Skill Site. RunCode is its processor. RunCode is a controller only of the data its Privacy Policy names as its own, such as the account and billing details of the person who signs up, and support conversations.

2. Instructions

• RunCode processes Customer Personal Data only on the Customer's documented instructions, including on transfers outside the UK. The Terms, this DPA and the Customer's use of the platform's features and settings are those instructions.
• If the law RunCode is subject to requires other processing, RunCode tells the Customer first, unless that law forbids it.
• RunCode tells the Customer at once if it believes an instruction breaks data protection law.
• Schedule 1 describes the processing.

3. Confidentiality

Only RunCode employees who need it for their work can access Customer Personal Data, and each is bound to keep it confidential. Platform administrators open an organisation's records only to answer that organisation's support request, deal with a security problem or meet a legal duty.

4. Security

RunCode keeps the technical and organisational measures in Schedule 2, which are appropriate to the risk under Article 32 of the UK GDPR. It may change them as long as the overall level of protection does not fall.

5. Sub-processors

• The Customer authorises RunCode to use the sub-processors in Schedule 3.
• RunCode emails the Customer's organisation admins at least 30 days before it adds or replaces a sub-processor. The Customer may object within that time on reasonable data protection grounds; if the parties cannot resolve it, the Customer may cancel its subscription.
• RunCode puts each sub-processor under a written contract with data protection obligations no weaker than this DPA's, and remains responsible to the Customer for its sub-processors' performance.

6. Helping the Customer

• Requests from data subjects: RunCode passes any request it receives about Customer Personal Data to the Customer without answering it, unless the Customer asks it to. The platform's own tools (editing and removing people, the exports of learners, grades, attendance, submissions and reports) let the Customer answer most requests itself, and RunCode helps with the rest.
• RunCode gives the Customer the information it reasonably needs for its own security, data protection impact assessments and any consultation with the Information Commissioner's Office (ICO), taking into account the nature of the processing and the information RunCode has.

7. Personal data breaches

RunCode notifies the Customer of a personal data breach affecting Customer Personal Data without undue delay, and within 48 hours of becoming aware of it, so the Customer can meet its own 72-hour duty to the ICO. The notice says, as far as RunCode then knows, what happened, the categories and approximate numbers of people and records affected, the likely consequences, and what RunCode has done and proposes to do. RunCode adds what it learns later and takes reasonable steps to contain the breach.

8. When the service ends

When a trial or subscription ends, the Customer's staff keep read-only access for 60 days to export their data. RunCode then deletes the Customer Personal Data, including uploaded files, unless the law requires it to keep some. Accounts that also belong to another organisation keep only what that organisation holds. Copies in database backups are deleted as the backups age out, within 14 days.

9. Showing compliance and audits

RunCode makes available the information needed to show it meets Article 28 of the UK GDPR: its security overview and answers to reasonable security questionnaires. Where that is not enough, the Customer, or an auditor bound to confidentiality that it appoints, may audit RunCode's processing once a year on 30 days' written notice, during business hours and at the Customer's cost, and at any time a regulator requires it or after a personal data breach.

10. Transfers outside the UK

• RunCode Inc is a US company, and the platform is hosted in the United States, so Customer Personal Data is transferred from the UK to the United States. For that transfer the parties enter into the International Data Transfer Agreement issued by the ICO, as Schedule 4 completes it.
• RunCode's engineering and support staff, all RunCode Inc employees, work from India and reach the data through RunCode's systems. Learners' code runs on servers in Finland, in the European Union.
• Schedule 5 gives the Customer the facts it needs for its transfer risk assessment.

11. General

• This DPA lasts as long as RunCode processes Customer Personal Data.
• If this DPA conflicts with the Terms, this DPA wins; if the International Data Transfer Agreement conflicts with either, it wins.
• Each party's liability under this DPA is subject to the limits in the Terms, as far as the law allows.
• This DPA is governed by the laws of England and Wales, and its courts have jurisdiction.
• RunCode may update this DPA to reflect a change in the law or in its services, giving the Customer 30 days' notice by email of any change that reduces the Customer's protection.

Schedule 1: The processing

Subject matter and purpose

Providing The Skill Site to the Customer: courses and lessons, cohorts and attendance, quizzes and coding exercises run and graded on a code runner, assignments and their files, progress reports, certificates, notifications, LMS connections (LTI), the API and embedded exercises, and support.

Duration

The term of the Customer's trial and subscription, then the 60 days in section 8.

Nature of the processing

Collecting, storing, organising, displaying, running, grading, exporting, emailing and deleting.

Data subjects

The Customer's staff (admins and instructors) and learners, people who open the platform from the Customer's LMS, and learners the Customer names through the API or embedded exercises.

Personal data

Names, email addresses, usernames and sign-in identifiers (Google, Microsoft, LMS); enrolments, progress, attendance and learning hours; quiz attempts, the code learners write and run and its history, assignment answers and files, grades and feedback; certificates; identifiers the Customer gives through the API; and technical data such as IP addresses used for security and rate limits.

Special category data

None is needed for the service. The Customer should not put health or other special category data into the platform; where it does, it is responsible for having a lawful basis.

Schedule 2: Security measures

• Encryption in transit (TLS) on every connection; uploaded files are stored privately in Amazon S3, encrypted at rest.
• Every organisation's records are kept apart in the application, and an automated test suite with two organisations checks on every change, before deployment, that neither can read or change the other's records.
• Passwords hashed with bcrypt; sign-in attempts rate-limited; single-use, hashed, expiring password links; HTTP-only, secure session cookies stored only as hashes and expiring after seven days without use.
• A content security policy and other browser protections on every page; no scripts from other sites, except the live chat on staff pages.
• Learners' code runs on a separate code runner, never on the application server, so it cannot reach the platform's data.
• Access for RunCode staff on a need-to-know basis, with server access by named personal keys; staff bound to confidentiality.
• A daily database backup, checked and kept for 14 days, with a copy held privately off the server; a restore rehearsed every three months; at most 24 hours of data lost and service back within 4 hours after a failure.
• Every release passes the type check and automated tests first, backs up the database, and checks its own health before it takes over.
• Records are soft-deleted in normal use so mistakes can be undone, and erased as section 8 says.

Schedule 3: Sub-processors

Stripe (through Link, its merchant of record) sells and bills the subscription and receives the billing contact's details, but no learner data; it acts under its own terms, not for the Customer.

Schedule 4: International Data Transfer Agreement

The parties enter into the International Data Transfer Agreement (version A1.0, in force from 21 March 2022) issued by the Information Commissioner under section 119A of the Data Protection Act 2018 (the "IDTA"), including its Mandatory Clauses as the ICO issues or revises them, with Part 1 completed as follows. The Mandatory Clauses are not changed.

Table 1: Parties

Exporter: the Customer, with the details it gave at signup; key contact, its organisation admins. Importer: RunCode Inc, a US company; key contact and contact for data subjects, hello@theskillsite.com.

Table 2: Transfer details

UK country's law that governs the IDTA: England and Wales. Primary place for legal claims: England and Wales. Status of the Exporter: controller. Status of the Importer: processor of the Exporter. Linked agreement: the Terms of Service and this DPA. Term: as long as the linked agreement lasts. Ending the IDTA before the linked agreement ends: neither party may, except as the Mandatory Clauses allow. Onward transfers: the Importer may transfer the data on to the sub-processors in Schedule 3, as section 5 of this DPA allows. Review: each year from the Customer's acceptance, or when the processing changes.

Table 3: Transferred data

The personal data, data subjects and purposes in Schedule 1, updated as the processing changes. No special category or criminal offence data is expected.

Table 4: Security requirements

The measures in Schedule 2, updated as section 4 allows.

Parts 2 and 3

Extra protection clauses: the measures in Schedule 2. Commercial clauses: this DPA and the Terms, as far as they do not conflict with the Mandatory Clauses.

Schedule 5: Facts for the Customer's transfer risk assessment

• The data is learning records about adults and young people in training: names, contact details, coursework, code and grades. It is not special category data, financial data or criminal records, so the harm a person could suffer from its misuse is low.
• United States: RunCode Inc is not certified under the UK Extension to the EU-US Data Privacy Framework, so the transfer relies on the IDTA. The ICO allows exporters to rely on the UK government's published analysis of US law, made for the UK-US data bridge, when assessing transfers under the IDTA: it found that US public authorities' access is limited by law, including Executive Order 14086, which applies to UK data, and that UK data subjects can seek redress through the Data Protection Review Court.
• Protection in practice: data is encrypted in transit and stored files are encrypted at rest; access is limited to RunCode employees who need it; RunCode would challenge a request from a public authority it judged unlawful, and tell the Customer of any request unless the law forbade it.
• India: the staff who reach the data from India are RunCode Inc employees, so no separate company receives it. Finland is in the European Union, which UK law treats as giving adequate protection.

Contact

Questions about this agreement or a signed copy: hello@theskillsite.com