Legal

GSF-E Data Processing Agreement

---

Version: 1.0

This Data Processing Agreement ("DPA") is between [CUSTOMER NAME], [CUSTOMER ADDRESS] ("the Customer"), and Arjun Sharma, sole proprietor, trading as AI for Products, of Gwalior, Madhya Pradesh, India ("the Provider"). It is part of the GSF-E Terms of Service ("the Terms") that the Customer accepted, and applies whenever the Provider processes Customer Personal Data to provide the GSF-E service ("the Service").

1. Definitions

• Customer Personal Data: personal data the Provider processes for the Customer, described in Annex 1: in the records and document outlines of the Customer's projects while each call runs, and in the team membership of its projects (which accounts may act on which project), which the Provider keeps (7.1). The records themselves live in the Customer's repositories, not with the Provider.
• Data Protection Law: every law on personal data that applies to the processing, including India's Information Technology Act, 2000 and its rules, the Digital Personal Data Protection Act, 2023 and its rules when in force, the EU GDPR, the UK GDPR and the Swiss Federal Act on Data Protection.
• SCCs: the standard contractual clauses annexed to European Commission Implementing Decision (EU) 2021/914, Module Two (controller to processor).
• "Controller", "processor", "Data Fiduciary", "Data Processor", "personal data breach" and "data subject" or "Data Principal" have their meaning in Data Protection Law.

2. Roles

2.1 For Customer Personal Data, the Customer is the controller (Data Fiduciary) and the Provider is its processor (Data Processor). 2.2 For data the Provider needs to run its own business (accounts, sign-in, acceptance records, security logs, abuse prevention), the Provider is a controller, as described in the GSF-E Privacy Notice.

3. The Customer's responsibilities

The Customer:

• has a lawful basis for the Customer Personal Data and gives its people any notice the law requires;
• does not send code, document text, secrets or sensitive personal data to the Service, which needs only its projects' records and document outlines (each document's file path, label, headings and count of blanks), and keeps secrets and sensitive personal data out of names, display names, file names, labels and headings;
• decides how long its projects' records are kept and who can read them: they live in the Customer's repositories, where anyone who can read a repository sees its team's display names, roles and sign-offs.

4. The Provider's obligations

The Provider will:

• process Customer Personal Data only on the Customer's documented instructions, which are the Terms, this DPA and the Customer's use of the Service, unless the law requires otherwise, and then tell the Customer first unless the law forbids it;
• tell the Customer if it believes an instruction breaks Data Protection Law;
• make sure anyone who processes the data is bound to keep it confidential;
• apply the security measures in Annex 2, and not reduce their overall protection;
• not sell the data, use it for advertising, or use it to train AI models;
• help the Customer, as far as the nature of the processing allows, to answer data subject requests, to meet its security and breach-notification duties, and with data protection impact assessments and consultations with authorities.

5. Sub-processors

5.1 The Customer gives general authorisation for the Provider to use sub-processors. Those used today are listed in Annex 3. 5.2 The Provider will tell the Customer at least 30 days before adding or replacing a sub-processor. The Customer may object on reasonable data protection grounds; if the parties cannot resolve the objection, the Customer may close its account (section 9). 5.3 The Provider puts each sub-processor under data protection terms that protect the data at least as well as this DPA, and remains responsible to the Customer for them.

6. Personal data breaches

6.1 The Provider will notify the Customer without undue delay, and within 24 hours, after becoming aware of a personal data breach affecting Customer Personal Data. The notice will describe what happened, the data and people affected, the likely consequences, the steps taken and proposed, and a contact; information not yet known will follow as soon as it is. 6.2 The Provider will take reasonable steps to contain the breach and reduce its effects. 6.3 The Customer decides whether to notify authorities and people affected about Customer Personal Data, except where the law puts that duty on the Provider itself (for example reporting cyber incidents to CERT-In within 6 hours).

7. Transfers out of the EU, UK and Switzerland

7.1 The Provider stores no Customer Personal Data except team membership: which accounts may act on which of the Customer's projects, held with the accounts by WorkOS in the United States (Annex 3), so that, once that sign-in is in place, a teammate taken off a project is cut off at once (before then, an older signed record put back from a repository's history can bring them back, which the GitHub checks in that repository report). It processes the rest during each call in India (Google Cloud region asia-south1, Mumbai), and the records stay in the Customer's repositories. Account data, which the Provider holds as a controller (section 2.2), is held by WorkOS in the United States. 7.2 Where the Customer's use of the Service involves a transfer of personal data from the European Economic Area to the Provider, the SCCs (Module Two) are incorporated into this DPA, with the Customer as data exporter and the Provider as data importer, and with these choices:

• Clause 7 (docking clause): not used;
• Clause 9(a): Option 2, general written authorisation, with 30 days' notice as in section 5.2;
• Clause 11(a): the optional independent dispute resolution body is not used;
• Clause 13: the competent supervisory authority is the one that Clause 13(a) points to for the Customer;
• Clause 17: Option 1, the law of Ireland;
• Clause 18(b): the courts of Ireland;
• Annex I.A: the parties above; Annex I.B: Annex 1 of this DPA; Annex I.C: as in Clause 13; Annex II: Annex 2; Annex III: Annex 3.

7.3 For transfers from the United Kingdom, the UK International Data Transfer Addendum to the EU Commission Standard Contractual Clauses (version B1.0) applies to the SCCs as set out in 7.2. Its Table 1 to 3 details are as in 7.2 and the Annexes, and for Table 4 either party may end it as allowed by its Section 19. 7.4 For transfers from Switzerland, the SCCs as set out in 7.2 apply, with references to the GDPR read as references to the Swiss Federal Act on Data Protection where it applies, and the Federal Data Protection and Information Commissioner as the competent authority for those transfers. 7.5 If the SCCs and this DPA conflict, the SCCs prevail.

8. Audits

The Provider will make available the information reasonably needed to show that it meets this DPA, by answering the Customer's written security questionnaire once a year and after any breach. Where Data Protection Law or the SCCs give the Customer a right to an audit, it takes place on at least 30 days' notice, during business hours, at the Customer's cost, under confidentiality, and no more than once a year unless a breach or an authority requires it.

9. End of processing

The Provider keeps no Customer Personal Data after each call, other than team membership (7.1), and has no backups of it, so when the Customer's account ends there is nothing to return: the records are in the Customer's repositories, and the Customer can save a copy of any of them at any time, on its own computers, without the Service. A project's team membership is deleted when the project is closed. Closing an account hands each project it owns to that project's tech lead (or, with none, another teammate), and closes a project only when nobody else is on its team; a project's owner can also hand it to a teammate at any time. An owner who leaves the Customer but keeps their account keeps the project until they hand it over: the Service has no administrator route for the Customer yet. In the cloud, an administrator of the Customer's organisation in WorkOS will be that route. A project whose owner closed their account is handed on at its next use; one nobody uses in the year the closed account's mark is kept is left with an owner nobody can sign in as, and then nobody can change its team, hand it over or close it. Data the Provider holds as a controller (account data, acceptance records and logs) is kept for the periods in the Privacy Notice, locked away where the law requires it to be kept, then deleted.

10. Liability

Each party's liability under this DPA is subject to the limits in the Terms, to the extent Data Protection Law allows. Nothing in this DPA limits either party's liability to data subjects under the SCCs or Data Protection Law.

11. Law and precedence

This DPA is governed by the laws of India, and disputes go to the courts with jurisdiction over Gwalior, Madhya Pradesh, India, except where the SCCs or Data Protection Law require another law or court. If this DPA and the Terms conflict on data protection, this DPA prevails.

Signed

---

Annex 1: Description of the processing

Annex 2: Security measures

• Data minimisation: the Service is built to receive projects' records and document outlines only (each document's file path, label, headings and count of blanks), never code, document text or other repository contents, and to keep neither after the call: each call works in a temporary folder that is deleted when it ends. There is no database. The outline is made on the Customer's computer, and lines inside code blocks are never sent.
• No customer code is run: the Service never runs the Customer's commands, tests or scripts on its servers.
• Encryption: TLS 1.2 or later in transit; Google Cloud encryption at rest.
• Access control: production access only for the Provider, with multi-factor authentication; each call is checked against the project's signed record, so only the accounts on a project's team can use it, and one project's record is refused under another project's ID.
• Authentication: each person signs in through WorkOS; every call to the Service carries that person's sign-in, which the Service checks.
• Signing: every record the Service returns is signed (Ed25519), so a change made by hand is caught, and the Safety Kit's locks check the signature on the Customer's computers. The Safety Kit is signed with a separate key the Service never holds, and the plugin checks that signature before writing any file.
• Abuse protection: per-account and per-address usage limits.
• Logging and monitoring: request and security logs kept for 1 year in Google Cloud Logging (asia-south1), facts only, with clocks synchronised to a trusted time source.
• No backups of project data: the Service holds none.
• Changes: every change to the Service is reviewed by the Provider and passes the Service's automated tests before release.
• Incidents: a written incident procedure, with notification as in section 6.

Annex 3: Sub-processors