Data processing addendum

This addendum (“DPA”) forms part of the terms of service between Mersoft Corporation (“Mersoft”, “processor”, “we”) and the customer that operates a Pealboard workspace (“customer”, “controller”, “you”). It applies wherever we process personal data on your behalf.

No signature is needed. Accepting the terms of service accepts this addendum. If your organization requires a countersigned copy, email privacy@pealboard.com and we will provide one.

Where this addendum and the terms of service conflict about the processing of personal data, this addendum prevails.

1. Definitions

“GDPR” is Regulation (EU) 2016/679, and where the customer is in the United Kingdom it includes the UK GDPR and the Data Protection Act 2018. “Controller”, “processor”, “data subject”, “personal data”, “processing” and “supervisory authority” have the meanings the GDPR gives them. “Standard contractual clauses” or “SCCs” means the clauses in Commission Implementing Decision (EU) 2021/914 of 4 June 2021.

“Customer personal data” is personal data we process on your behalf through Pealboard, which is principally the personal data of your portal customers and of the people named in the issues and comments your workspace reads from GitHub.

2. Roles

You are the controller of customer personal data. We are the processor.

We are an independent controller of the personal data of your workspace members — their account, sessions and notification preferences — and that processing is governed by the privacy policy, not by this addendum.

3. Subject matter, duration, nature and purpose

4. Our obligations

We will:

1. Process only on your instructions. Your instructions are the terms of service, this addendum, and your configuration of the product. We will tell you if we believe an instruction breaches data protection law, unless the law forbids us from telling you.
2. Keep it confidential. Everyone we authorize to process customer personal data is bound by confidentiality and is granted access only to what their work requires.
3. Apply the security measures in section 8, and keep them at least as protective as they are on the effective date of this addendum.
4. Engage sub-processors only under section 7.
5. Help you meet data subject requests, as described in section 5.
6. Help you with data protection impact assessments and prior consultations, taking into account the nature of the processing and the information available to us.
7. Notify you of a personal data breach without undue delay, and in any event within 48 hours of becoming aware of one, with the information available to us at that point and updates as we learn more.
8. Delete or return customer personal data at the end of the service, as described in section 11.
9. Make available the information needed to show compliance, and allow audits under section 10.

5. Data subject requests

Pealboard gives a data subject two rights directly, without asking you or us to act:

• Download my data returns a portal customer’s requests, comments and votes as JSON.
• Delete my account removes their portal account and rewrites every attribution line Pealboard authored in GitHub to “a former customer”.

For anything else, we will pass a request we receive directly to you rather than answering it, and we will help you answer it. Where a request cannot be satisfied inside the product, we will act on your written instruction.

One limit, stated plainly. An issue or comment in GitHub belongs to your GitHub organization, not to us. We can rewrite the text Pealboard itself authored, and we cannot delete an issue: GitHub’s API provides no way to delete an issue, and content a member of your organization wrote is not ours to change. If a data subject asks for erasure of something a person in your organization wrote into GitHub, you have to do that in GitHub.

6. Your obligations

You will:

• have a lawful basis for the personal data you put into or through Pealboard, including a basis for inviting your portal customers and for emailing them;
• give your data subjects the information the law requires about the processing, including that Mersoft is your processor;
• configure the product’s visibility settings so that personal data is exposed only to the people you intend, and in particular decide deliberately whether to turn on the portal setting that shows every GitHub comment to customers;
• not put special-category data into a portal, a request or an issue.

7. Sub-processors

You give general written authorization for us to engage the sub-processors below. Each is bound by written terms no less protective than this addendum.

We will announce a new or replacement sub-processor on the changelog and by email to every workspace owner at least 30 days before it begins processing. You may object on reasonable data protection grounds within those 30 days; if we cannot resolve the objection, you may terminate the affected part of the service and receive a pro-rata refund of any prepaid, unused fees.

We remain liable to you for a sub-processor’s performance of its data protection obligations.

8. Security measures

These are the technical and organizational measures required by Article 32. They are the measures actually in place, described in more detail at /security.

Isolation and access control

• The tenant is the workspace, and isolation is enforced by the database rather than by the application: row-level security is enabled and forced on every tenant table, with restrictive policies keyed on the workspace.
• The application connects as a database role that cannot bypass row-level security and does not own the tables.
• Portal-scoped tables carry a second restrictive policy on the portal, so data from one portal cannot reach another even inside the same workspace.
• Every route declares who may call it, and every identifier from a path or a body is checked against the caller’s scope before use.
• Roles are owner, admin, member and viewer, and an API key can never do more than the role of the member who created it.

Authentication

• Workspace and portal authentication are separate systems with separate storage; a portal session can never become a workspace session.
• Session cookies are host-only, SameSite=Lax, and every cookie-borne state change is checked against the request origin.
• Portal sign-in is a 6-digit code with a ten-minute life and five attempts, or a single-use link.
• API keys are stored as SHA-256 digests and shown once.

Encryption

• In transit: TLS on every connection, including to the database, to GitHub, to Stripe and to the email sender.
• At rest: encryption provided by the storage platforms named in section 7.

Integrity and availability

• Webhook signatures are verified before any payload is parsed, and deliveries are idempotent by delivery id.
• Every write is recorded in an audit log with the actor and the kind of credential used, and every response carries a request id.
• Attachments are stored separately from the database and served through signed URLs with a 30-day life.
• Backups are taken by the database provider and retained on a rolling 30-day cycle.
• Unauthenticated paths are rate limited, and every unauthenticated form carries a bot check.

Organizational

• Secrets exist only as server secrets, never in a committed file, a log line or a response.
• Access to production is limited to the people who operate the service.

What is not in place. There is no SOC 2 report, no ISO 27001 certificate and no third-party penetration test. Nothing in this addendum claims otherwise.

9. International transfers

Processing takes place in the United States.

For personal data transferred from the European Economic Area, the standard contractual clauses are incorporated into this addendum and take effect on the terms below:

• Module Two (controller to processor) applies.
• Clause 7 (docking) applies.
• Clause 9: Option 2, general written authorization, with the 30-day notice period in section 7.
• Clause 11: the optional independent dispute-resolution body is not selected.
• Clause 17: the clauses are governed by the law of Ireland.
• Clause 18(b): disputes go to the courts of Ireland.
• Annex I is section 3 of this addendum (parties, categories, processing) and section 7 (sub-processors); Annex II is section 8; Annex III is section 7.

For transfers from the United Kingdom, the SCCs apply as modified by the UK Information Commissioner’s International Data Transfer Addendum (the “UK Addendum”), with Tables 1 to 3 completed by the sections named above and Table 4 selecting the importer.

For transfers from Switzerland, references to the GDPR are read as references to the Swiss Federal Act on Data Protection, and the Swiss Federal Data Protection and Information Commissioner is the competent authority.

Government access. We have received no national security or law enforcement demand for customer personal data. If we receive one, we will tell you unless the law forbids it, and we will challenge a demand we believe is unlawful.

10. Audit

On written request, and not more than once in a twelve-month period unless a supervisory authority requires otherwise, we will provide the information reasonably necessary to demonstrate compliance with this addendum.

Where that is not sufficient for you to meet an obligation under Article 28(3), you or an independent auditor you appoint — who must not be our competitor and must be bound by confidentiality — may audit our processing on at least 30 days’ written notice, during business hours, without unreasonably disrupting the service. You bear the cost, unless the audit reveals a material breach of this addendum.

11. Deletion and return

On termination of the service, or on your written instruction, we delete customer personal data within 30 days, including from backups within the rolling backup cycle described in section 8.

Two exceptions, both narrow:

• Records we must keep by law, such as billing and tax records, which we retain for the period the law requires and process for no other purpose.
• Content in GitHub. Issues, comments, labels, milestones and project field values are in your GitHub organization and are not ours to delete. We remove our copy; GitHub’s is yours.

Before deletion you may export what Pealboard holds through the API. Nothing you need to keep is only in Pealboard: the work itself is in GitHub.

12. Liability

Each party’s liability under this addendum is subject to the limitations in section 12 of the terms of service, except where the GDPR provides otherwise.

13. Contact

Data protection questions, audit requests, sub-processor objections and countersigned copies: privacy@pealboard.com.

Mersoft Corporation is the processor named in this addendum. We have not appointed a data protection officer, because our processing does not meet the Article 37 threshold; privacy@pealboard.com reaches the people responsible.