Data Processing Agreement

1. Definitions

• Data Protection Laws means the laws that apply to the processing of Personal Data under the Terms, including, where they apply, the EU General Data Protection Regulation ("GDPR"), the UK GDPR and Data Protection Act 2018, the Swiss Federal Act on Data Protection, Canada's Personal Information Protection and Electronic Documents Act ("PIPEDA") and provincial equivalents, and the California Consumer Privacy Act as amended ("CCPA").
• Personal Data means information about an identified or identifiable natural person that we process on your behalf in providing Striff.
• Customer Data means the repository content, pull request information and account information we process on your behalf in providing Striff.
• Sub-processor means a third party we engage to process Personal Data on your behalf.
• Security Incident means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Personal Data.
• "Controller", "processor", "data subject" and "processing" have the meanings given in the GDPR. "Business", "service provider", "sell" and "share" have the meanings given in the CCPA.

2. Roles

You are the controller of Personal Data in Customer Data, and we are your processor (a "service provider" under the CCPA). Where you are yourself a processor for someone else, we are your sub-processor. Personal Data we process for our own purposes, such as billing and account administration, is covered by our Privacy Policy, not this DPA.

3. Processing on your instructions

We process Personal Data only to provide Striff and on your documented instructions. The Terms, this DPA, and your use and configuration of Striff are your complete instructions. If we believe an instruction breaks Data Protection Laws, we will tell you. Annex 1 describes the processing.

We will not sell or share Personal Data, use it for targeted advertising, or retain, use or disclose it outside our direct business relationship with you or for any purpose other than providing Striff. We will not combine it with personal information we receive from others, except as Data Protection Laws allow. We will not use Customer Data to train AI models.

4. Confidentiality

Everyone we authorise to process Personal Data is bound by a duty of confidentiality.

5. Security

We maintain the technical and organisational measures in Annex 2, and keep them appropriate to the risk. We may update them, provided the overall level of protection does not go down.

6. Sub-processors

You authorise us to engage the Sub-processors listed at striff.io/subprocessors. We impose data protection obligations on each one that are at least as protective as this DPA, and we remain responsible for their performance.

We will update that page at least 30 days before a new Sub-processor starts processing Personal Data, and email you if you have asked to be notified. You can object on reasonable data protection grounds within those 30 days. If we cannot reasonably address your objection, you may end your subscription, and we will refund any prepaid fees for the period after it ends.

7. Helping you meet your obligations

Taking into account the nature of the processing, we will help you respond to requests from data subjects exercising their rights, and with data protection impact assessments and consultations with supervisory authorities, where these concern our processing. If a data subject contacts us directly, we will pass the request on to you and will not answer it ourselves unless you ask us to.

8. Security Incidents

If we become aware of a Security Incident, we will notify you without undue delay, and in any case within 72 hours. We will give you the information we have that you need to meet your own notification duties, update you as we learn more, and take reasonable steps to contain the incident and reduce its effects. Notifying you is not an admission of fault.

9. Deletion

Source code is deleted when each analysis ends and is never stored in our database. We delete all other Personal Data in Customer Data within 30 days of your written request, or of the end of your subscription, unless the law requires us to keep it. Backups and logs are deleted in their normal cycle and are protected under this DPA until then.

10. Audits

We will make available the information reasonably needed to show that we comply with this DPA. Usually this means answering your written security questionnaire, which we will do at no charge once a year. If that is not enough for you, or a supervisory authority requires it, you may have us audited once a year by an independent auditor bound by confidentiality, at your expense, with at least 30 days' written notice, during business hours, and in a way that does not disrupt our service or give access to other customers' data.

11. International transfers

We process Customer Data in Canada. The European Commission and the United Kingdom recognise Canada as providing adequate protection for personal data processed by organisations subject to PIPEDA, and Switzerland recognises Canada too. Transfers of Personal Data from the EU, the UK or Switzerland to us therefore rely on those adequacy decisions.

Where Personal Data is transferred onward to a Sub-processor in a country without such a decision, we make sure the transfer is covered by an appropriate safeguard. That is the Sub-processor's certification under the EU-US Data Privacy Framework and its UK and Swiss extensions, or else the European Commission's Standard Contractual Clauses (Module 3, processor to processor), with the UK Addendum where the UK GDPR applies.

If the adequacy decisions stop applying to our processing, the Standard Contractual Clauses (Module 2, controller to processor, or Module 3, processor to processor) are incorporated into this DPA by reference. The relevant details are those in Annexes 1 and 2 and the Sub-processor list, with Option 2 of Clause 9, no optional clause 7, and the governing law and courts of Ireland. For transfers from the UK, the UK Addendum applies in the same way.

12. Liability and precedence

Each party's liability under this DPA is subject to the limitations in the Terms. If this DPA and the Terms conflict on the processing of Personal Data, this DPA prevails. This DPA stays in force for as long as we process Personal Data on your behalf.

Annex 1: Description of the processing

• Controller: the Customer. Processor: HADI Technology, a Canadian corporation. Contact: hi@haditechnology.com.
• Data subjects: your employees, contractors and other people who contribute to your repositories, open pull requests in them, or use Striff on your behalf.
• Categories of Personal Data: GitHub usernames and account identifiers; names and email addresses where they appear in repository content, pull requests or account records; organisation membership; any personal data that happens to appear in source code or documentation Striff reads.
• Sensitive data: none intended. Please do not put special categories of personal data in repositories Striff reads.
• Nature and purpose: analysing pull requests to produce architecture diagrams and review findings, reading documentation to check changes against it, and showing results in the pull request and on the dashboard.
• Frequency: continuous, whenever a pull request is opened or updated in a repository where the Striff App is installed.
• Duration and retention: for as long as you use Striff, then as described in section 9. Source code is deleted when each analysis ends.

Annex 2: Technical and organisational measures

• Data minimisation: source code is held in temporary storage only while an analysis runs, and is never written to the database. Leftover temporary files are removed by a scheduled sweep.
• Encryption: TLS for all traffic to and from the service. Stored data sits on block storage that is encrypted at rest.
• Network isolation: the database and cache run inside a private cluster and cannot be reached from the internet. Only the public entry point accepts outside traffic.
• Access to customer repositories: through the GitHub App, with short-lived tokens limited to the repositories the customer chose. Striff has no write access to code.
• Access to the dashboard: sign-in with GitHub. Results are shown only to people GitHub reports as having access to the organisation or repository.
• Webhook integrity: every webhook from GitHub is verified by its signature before it is acted on.
• Secrets management: credentials are kept in the cluster's secret store, not in source code.
• AI processing: inference only on an allow-list of hosts with zero data retention. No customer data is used to train models.
• Error monitoring: error reports are configured to exclude personal data.
• Personnel: access to production systems is limited to the people who operate Striff, all of whom are bound by confidentiality.
• Incident response: Security Incidents are handled and notified as set out in section 8.
• Vulnerability management: reports are accepted at hi@haditechnology.com and fixed in order of severity.