Data Processing Addendum

This addendum governs our processing of personal data on a customer’s behalf. It forms part of the Terms of Service and applies whenever a customer uses Largwit to process personal data subject to data protection law.

Where this addendum and the Terms conflict on a question of data protection, this addendum governs. Where a signed agreement conflicts with either, the signed agreement governs.

For customer content (the datasets an organization brings, the work produced from them, and the review history behind that work), the customer is the controller and we are the processor. We act only on documented instructions. Use of the platform is itself such an instruction.

For account data (the names, work addresses and activity records of the people who log in), we are a controller in our own right, because we decide what is needed to run a secure service. That processing is described in the Privacy Policy and sits outside this addendum.

Where a customer staffs work through a talent platform or another organization, that organization is typically a controller of its own people’s data. We do not become the controller of a contributor’s data by routing work to them. What we hold about contributors, and in which capacity, is set out in the Contributor Privacy Notice.

Subject matter. Provision of the Largwit platform.

Duration. The term of the agreement, plus the deletion windows in section 11.

Nature and purpose. Storing, organising, routing and making available data for annotation, evaluation and review; recording the outcome of that work; and producing the outputs and reports the engagement requires.

Categories of data subject. Whoever appears in the data a customer brings, which only the customer can characterise; and the people who use the platform on the customer’s behalf.

Types of personal data. Determined by the customer. We do not require personal data in customer content, and we do not inspect content to find out whether any is present.

Special categories. Only where a customer chooses to bring them, and only where they have told us in writing beforehand, so that the additional measures in Annex II apply.

We will:

• process customer content only on documented instructions, including for transfers, unless law requires otherwise, in which case we tell the customer first, unless that law forbids it;
• ensure everyone we allow near customer content is bound by confidentiality;
• apply the measures in Annex II;
• respect the conditions in section 6 before engaging another processor;
• help the customer respond to data subjects, as in section 8;
• help with security, breach notification and impact assessments, given what we know and what the platform does;
• delete or return customer content as in section 11;
• make available what is needed to show these obligations are met, and allow the audits in section 10.

If we believe an instruction breaches data protection law, we will say so.

We do not sell customer content. We do not share it for advertising. We do not use it to train, fine-tune, evaluate or improve any model, ours or anyone else’s.

We do not use it to improve the Largwit product. Where we need to know how the platform is performing we use operational metadata such as counts, timings and error rates, not the content.

Our people do not access customer content except where a customer asks us to, or where it is strictly necessary to resolve a fault or a security incident. That access is limited, logged, and visible to the customer.

The customer gives general authorisation for us to engage sub-processors. The current list, what each does and where it operates is published at largwit.com/subprocessors.

Before a new sub-processor may touch customer content we give at least ten days’ notice, and a customer may ask to be told directly rather than having to watch the page. A customer may object on reasonable data protection grounds within those ten days. If we cannot resolve the objection, the customer may terminate the affected part of the service without penalty and receive a refund of fees paid for the unused remainder.

We bind each sub-processor to data protection obligations no less protective than these, and we remain liable to the customer for their performance.

We maintain the technical and organisational measures in Annex II. They are measured against the risk to the people whose data it is, not merely the risk to us.

We may change a measure as the platform and the threat landscape change. We will not reduce the overall level of protection during a term.

If a data subject contacts us about customer content, we do not answer for the customer. We pass the request on without undue delay and tell the person it has gone to the organization responsible for it.

Where the platform cannot already do what is asked, we help by appropriate means with access, correction, deletion, restriction, portability and objection, given what we hold and what we can see.

We notify the customer without undue delay after becoming aware of a personal data breach affecting their content, and we aim to do so within seventy-two hours.

The notification describes what happened, the categories and approximate number of records involved so far as known, the likely consequences, what we have done or propose to do, and a contact point. If we do not yet know everything we say what we know and follow up, rather than waiting until the picture is complete.

We help the customer meet their own notification duties. Notifying a regulator or the individuals affected is the customer’s decision, not ours.

We make available what is needed to demonstrate compliance with this addendum, including third-party audit reports and certifications once held.

Where that is not enough, a customer may audit us, themselves or through an independent auditor who is not a competitor of ours, on thirty days’ written notice, during business hours, without unreasonable disruption, and no more than once in a calendar year. A regulator may require more, and a material breach justifies more; in those cases the annual limit does not apply.

Anything learned in an audit is confidential. An audit may not extend to another customer’s data, and we will refuse the parts that would.

The platform lets a customer export their content at any time during the term, without asking us.

On termination or expiry, a customer may export for thirty days. After that we delete customer content from live systems within a further thirty days, and from backups within ninety days of termination, as backup rotation completes. We confirm deletion in writing on request.

If law requires us to keep something, we keep only that, only as long as required, and only for that purpose, and this addendum keeps applying to it.

Where a customer’s environment is hosted determines where their content lives. The default region is stated in the sub-processor list, and specific regional requirements are agreed in the engagement.

Where transfers out of the EEA, the UK or Switzerland occur, we rely on the European Commission’s Standard Contractual Clauses, incorporated by reference and completed as follows: Module Two (controller to processor) between the customer and us; Module Three (processor to processor) where the customer is itself a processor; the docking clause applies; clause 9(a) operates as general authorisation with the ten-day notice in section 6; governing law and forum are those of the customer’s member state. For the UK, the International Data Transfer Addendum applies. For Switzerland, the Clauses are read with the references adjusted.

Where an onward transfer is needed, the sub-processor is bound to an equivalent standard before it happens.

We give reasonable help with data protection impact assessments and with prior consultation of a regulator, so far as the assessment concerns our processing and the customer cannot reasonably get the information elsewhere.

Exporter. The customer, as controller, or as processor for its own client.

Importer. Largwit, as processor, providing the platform.

Frequency. Continuous for the term.

Categories, data subjects, special categories. As in section 3, determined by the customer.

Retention. The term, plus the windows in section 11.

Sub-processors. As published, with the subject matter, nature and duration of each set out there.

These are the measures the platform enforces.

• Tenant isolation. Each customer’s data is separated at the database level, and that separation is enforced by the database itself rather than only by application code. A query that forgets to scope itself returns nothing, not someone else’s rows.
• Access control. Role-based permissions; what a person can see follows the role they hold and the projects they are on; least privilege for our own staff, granted for a reason and reviewed.
• Authentication. Passwords stored with a modern memory-hard hash; multi-factor authentication available and enforceable across an organization; sessions revocable centrally, and revoked on password change.
• Brute-force protection. Repeated failed authentication against an address is refused for a period, enforced in the database so it holds across every replica.
• Encryption. TLS in transit; encryption at rest for databases, object storage and backups.
• Media handling. Project media served through expiring, access-checked links rather than public URLs.
• Audit logging. Significant actions recorded with actor, time and subject, readable by the customer for their own organization.
• Environment separation. Development and test run on separate infrastructure with separate credentials. Customer content is not copied into either.
• Secret management. Credentials held as platform secrets, injected at runtime, never in source control.
• Monitoring and alerting. Continuous checks on availability, error rates, latency, queue health and mail delivery, with alerts raised and resolved automatically.
• Backup and recovery. Automated database backups with point-in-time restore, and restores exercised rather than assumed.
• Change management. Version control, automated tests, and migrations applied before the code that depends on them.
• Vulnerability management. Dependencies monitored and patched; platform components kept current.
• Personnel. Confidentiality obligations; access scoped to the role on joining and removed on leaving.
• Incident response. A documented procedure covering detection, containment, assessment, notification and review.
• Deletion. Retention and deletion enforced by the platform on the schedule in section 11.

Certifications are described honestly on the security page. Where an audit or certification is in progress rather than held, it is named as in progress.

Each party’s liability under this addendum is subject to the limits in the Terms of Service, except where data protection law does not permit those limits to apply.

We may update this addendum where law, a regulator or a change to the platform requires it. Material changes are notified at least thirty days before they take effect, and a customer who objects may terminate the affected service without penalty.

Questions, objections and audit requests: hello@largwit.com.