1. Parties and scope

This Data Processing Agreement ("DPA") forms part of the Terms of Service between RubySig LLC, a Texas limited liability company ("RubySig", the "Processor") and the customer identified in the account (the "Customer", the "Controller").

It applies whenever RubySig processes personal data on the Customer's behalf in providing the Service. Where it conflicts with the Terms of Service, this DPA prevails.

Roles. The Customer is the controller (or a processor acting for its own controller) of the directory data and message content processed through the Service. RubySig is the processor. Where RubySig acts as a controller in its own right — for account and billing data — its Privacy Policy applies instead, and this DPA does not.

Signature. This DPA is incorporated into the Terms of Service and is binding without signature. A customer whose procurement process requires an executed copy may request one at support@rubysig.com; we will countersign the version on this page unchanged.

2. Definitions

"Personal data", "processing", "controller", "processor", "data subject", "personal data breach" and "supervisory authority" have the meanings given in the GDPR.

"Data Protection Law" means, as applicable: Regulation (EU) 2016/679 ("GDPR"); the GDPR as incorporated into UK law by the Data Protection Act 2018 ("UK GDPR"); the Swiss Federal Act on Data Protection; the California Consumer Privacy Act as amended ("CCPA"); the Texas Data Privacy and Security Act ("TDPSA"); and any other data protection law applicable to the processing.

"SCCs" means the Standard Contractual Clauses annexed to Commission Implementing Decision (EU) 2021/914 of 4 June 2021.

"UK Addendum" means the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses, version B1.0, issued by the UK Information Commissioner under section 119A of the Data Protection Act 2018.

3. Processing on instructions

RubySig processes personal data only on the Customer's documented instructions, including regarding international transfers, unless required to do otherwise by law — in which case RubySig will tell the Customer first, unless the law forbids it on important grounds of public interest.

The Customer's instructions are: the Terms of Service, this DPA, the configuration the Customer sets in the portal, and any further written instruction the parties agree.

RubySig will tell the Customer if, in its opinion, an instruction infringes Data Protection Law.

RubySig will not:

• process the personal data for any purpose other than providing the Service;
• sell or share the personal data, or disclose it for any commercial purpose;
• combine it with personal data from other sources, except as necessary to provide the Service;
• use the contents of the Customer's email, or its directory data, to train machine learning models.

The Customer is responsible for ensuring it has a lawful basis for the processing, for informing its own personnel how their data is used, and for the accuracy of the directory data it instructs RubySig to sync.

4. Confidentiality

RubySig ensures that everyone authorised to process the personal data is bound by an appropriate duty of confidentiality, and that access is limited to those who need it to provide the Service.

5. Security

RubySig implements the technical and organisational measures set out in Annex II, taking account of the state of the art, the costs of implementation, and the nature, scope, context and purposes of the processing.

RubySig may update those measures provided the level of security is not reduced.

6. Subprocessors

The Customer gives RubySig general written authorisation to engage subprocessors. Those currently engaged are listed in Annex III.

RubySig will give the Customer at least 30 days' notice by email before adding or replacing a subprocessor. The Customer may object on reasonable data-protection grounds within that period; if the parties cannot resolve the objection, the Customer may terminate the affected part of the Service without penalty and receive a pro-rata refund of prepaid fees.

RubySig imposes on each subprocessor data protection obligations no less protective than those in this DPA, and remains fully liable to the Customer for its subprocessors' performance.

7. Assisting the Customer

Taking into account the nature of the processing, RubySig will:

• Data subject rights. Assist the Customer by appropriate technical and organisational measures in responding to requests to exercise data subject rights. Because directory data originates in the Customer's own Entra tenant, most such requests are answered at source by the Customer. If RubySig receives a request directly, it will not respond substantively but will forward it to the Customer without undue delay and tell the data subject it has done so.
• Assessments. Assist the Customer with data protection impact assessments and prior consultation with supervisory authorities, so far as the information is available to RubySig.
• Compliance information. Make available the information necessary to demonstrate compliance with Article 28 GDPR.

8. Personal data breach

RubySig will notify the Customer without undue delay, and in any event within 48 hours, after becoming aware of a personal data breach affecting the Customer's personal data.

The notification will describe the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact point — to the extent known. Where the information is not all available at once, RubySig will provide it in phases without further undue delay.

RubySig will not notify the Customer's data subjects or any supervisory authority on the Customer's behalf unless the Customer instructs it to, or the law requires it.

9. Deletion and return

On termination of the Service, and at the Customer's choice, RubySig will delete or return the personal data it processes on the Customer's behalf, and delete existing copies — unless law requires storage.

In practice:

Data	What happens
Directory data (directory_users and aliases)	Deleted within 30 days of termination
Company details, templates, uploaded banner artwork	Deleted within 30 days of termination
Message content	Nothing to delete — never stored. Processed in transit only
Portal accounts	Deleted within 30 days of termination
Invoices, payments, ledger entries, invoice send records	Retained for 7 years, as tax and accounting law requires

The retention of billing records is a legal obligation, not a business choice. Those records contain the billing contact's name, email address and address, and the amounts invoiced. They contain no directory data and no message content. RubySig processes them as a controller for that purpose, under Article 6(1)(c) GDPR.

The Customer may export its data through the portal at any time before termination takes effect.

10. Audit

RubySig will make available to the Customer the information necessary to demonstrate compliance with this DPA, and will allow for and contribute to audits, including inspections, conducted by the Customer or an auditor it mandates.

To keep this workable for both parties: the Customer will give at least 30 days' notice, audits will take place no more than once in any 12 months (unless required by a supervisory authority or following a personal data breach), during business hours, without unreasonably disrupting the Service, and subject to confidentiality. RubySig will first offer any relevant documentation and answers to a written questionnaire, which will often resolve the request without an on-site audit.

11. International transfers

RubySig is established in the United States. Its infrastructure is described in Annex III; personal data at rest is stored in the United States, and the signature relay that processes message content in transit is located in Germany.

11.1 EEA transfers — the SCCs

Where the Customer transfers personal data subject to the GDPR to RubySig, the SCCs apply and are incorporated into this DPA by reference, with the elections set out below.

A note on why the clauses are incorporated rather than retyped. The SCCs are a fixed-form instrument: their text may not be varied, and any deviation puts the transfer mechanism at risk. Retyping roughly twelve thousand words of Official Journal text into this page would create the possibility of a transcription error that invalidates it, with no benefit to the reader. What is specific to RubySig — the module, the elections, and Annexes I to III — is set out here in full, and that is the part that requires review. The authoritative text is Commission Implementing Decision (EU) 2021/914, available in the Official Journal at eur-lex.europa.eu/eli/dec_impl/2021/914/oj. RubySig will provide a complete executed copy, including the clause text, on request.

Elections:

Clause	Election
Module	Module Two (controller to processor). Where the Customer is itself a processor, Module Three (processor to processor) applies instead, and references to the Customer's controller are to its own controller.
Clause 7 (docking)	Included
Clause 9(a) (subprocessors)	Option 2 — general written authorisation. Notice period: 30 days, per section 6 above
Clause 11(a) (independent dispute resolution)	Not included
Clause 13 (supervisory authority)	The supervisory authority of the EEA state in which the data exporter is established. Where the exporter is not established in the EEA but falls within Article 3(2) GDPR, the authority of the state in which its Article 27 representative is established
Clause 17 (governing law)	Option 1 — the law of Ireland
Clause 18(b) (forum)	The courts of Ireland
Annex I, II and III	Annexes I, II and III of this DPA, below

11.2 UK transfers — the UK Addendum

Where personal data is subject to the UK GDPR, the UK Addendum applies to the SCCs, completed as follows:

Table 1 — Parties. The Customer is the Exporter; RubySig LLC is the Importer. Contact details are as given in the account and in Annex I.A.

Table 2 — Selected SCCs. The SCCs as incorporated at §11.1 above, Module Two (or Module Three as applicable), with the elections in that table.

Table 3 — Appendix information. Annexes I, II and III of this DPA.

Table 4 — Ending the Addendum when the Approved Addendum changes. Neither party.

11.3 Switzerland

Where personal data is subject to Swiss law, the SCCs apply with these adjustments: references to the GDPR are to the Swiss Federal Act on Data Protection; the competent authority is the Federal Data Protection and Information Commissioner; and the term "member state" does not exclude Swiss data subjects from enforcing their rights in their place of habitual residence.

11.4 Government access

RubySig has never received a government or law enforcement request for a customer's personal data. If it receives one it will, unless legally prohibited: tell the Customer without undue delay; challenge any request that appears unlawful or overbroad; and disclose only the minimum required.

RubySig does not provide any government with direct or unrestricted access to personal data, and has installed no back door into its systems.

12. US state privacy law

This section applies where the CCPA, the TDPSA, or a comparable US state law governs the processing.

RubySig acts as a "service provider" under the CCPA and a "processor" under the TDPSA. It:

• processes personal information only to perform the Service specified in the Terms, and for no other purpose;
• does not sell or share personal information as those terms are defined in the CCPA;
• does not retain, use or disclose personal information outside the direct business relationship between the parties;
• does not combine it with personal information from other sources, except as permitted;
• will notify the Customer if it determines it can no longer meet these obligations;
• grants the Customer the right to take reasonable steps to stop and remediate unauthorised use.

RubySig certifies that it understands and will comply with these restrictions.

13. Liability

Each party's liability under this DPA is subject to the limitations in section 13 of the Terms of Service, except that nothing in this DPA or the Terms limits either party's liability to a data subject under the SCCs or under Data Protection Law.

14. Term

This DPA takes effect when the Customer accepts the Terms of Service and continues until RubySig has ceased all processing of the Customer's personal data in accordance with section 9.

---

Annex I

A. Parties

Data exporter (controller): the Customer, as identified in its RubySig account. Contact: the administrator email addresses on the account. Activities: receiving email signature management for its own personnel.

Data importer (processor): RubySig LLC, a Texas limited liability company. Address: [[TO BE COMPLETED: legal address]]. Contact: support@rubysig.com. Activities: providing the RubySig email signature service.

Signature and date: by entering into the Terms of Service.

Role: exporter — controller; importer — processor. (Where Module Three applies: exporter — processor; importer — subprocessor.)

B. Description of the transfer

Categories of data subjects. The Customer's personnel whose accounts are enabled in its Microsoft Entra ID tenant, and the senders and recipients of email passing through the signature relay.

Categories of personal data.

Synced from the Customer's Entra ID directory (enabled accounts only):

• Entra object identifier
• user principal name
• email address
• display name, given name, surname
• job title
• department
• mobile telephone number, or the first listed business telephone number
• proxy addresses (email aliases)
• account enabled status

Entered by the Customer in the portal:

• a per-mailbox signature address, where the Customer sets one, overriding the company address
• company name, primary domain, website and address
• signature and banner templates, and any artwork the Customer uploads

Processed in transit by the signature relay:

• the content, headers, sender and recipient addresses of outbound email passing through the relay, for the sole purpose of inserting the signature and forwarding the message. This data is not stored, not logged and not retained at any point.

Sensitive data. None is requested, required or knowingly processed. The Customer must not configure signature fields to contain special-category data.

Frequency. Directory sync: periodic and on demand. Relay: continuous, for each message sent.

Nature and purpose. Reading directory attributes; storing them to render signature templates; inserting a rendered signature into outbound email and forwarding it.

Retention. As set out in section 9. Message content is retained for no period at all.

Subprocessors. As in Annex III; same subject matter, nature and duration.

C. Competent supervisory authority

As elected at §11.1.

---

Annex II — Technical and organisational measures

These are the measures actually implemented, not aspirations.

Data minimisation by architecture

• Email content is never persisted. The relay parses the message, inserts the signature, DKIM-signs it and forwards it. There is no write to disk, no queue that retains content, and no logging of message bodies, subjects, or sender and recipient addresses.
• Relay logs contain only connection metadata: source IP addresses, SMTP protocol errors, and the domain — never the address — of a message that could not be signed or delivered. Local parts are stripped from third-party library errors before they are written, and the libraries that would otherwise log full addresses are held below the level at which they do so. Logs run under a size-capped rotating driver (10 MB × 3 files).
• Directory sync requests only the attributes listed in Annex I.B, and only for enabled accounts. Disabled accounts are never retrieved.

Access control

• Access control is enforced in the database itself, by row-level security policies and triggers, rather than only in application code. These constraints hold even for privileged service connections, so an application-layer defect cannot bypass them.
• Role-based access with least privilege across six defined roles. A protection rule prevents privileged staff from altering or removing account owners.
• Customer data is scoped by company identifier at the database layer; a request for another company's record returns not-found, not the record.
• Portal authentication is per-person with individual credentials and no shared accounts. Passwords are stored only as salted hashes.

Encryption

• All connections use TLS. Outbound mail submission uses STARTTLS with full certificate verification — the relay rejects an unverified certificate rather than downgrading.
• Data at rest is encrypted by the underlying platform providers.
• Outbound mail is signed with DKIM; SPF and DMARC are published for the sending domains.

Integrity and auditability

• Issued invoices and their lines, and all double-entry journal entries and lines, are immutable by database trigger once posted.
• Invoice email delivery is recorded in an append-only table, one row per attempt including failures, with the mail server's message identifier. There is no insert policy for customers, so a record of delivery cannot be manufactured.
• Administrative actions in the portal are recorded with the acting account and a timestamp.

Operational security

• Infrastructure access is by SSH key only; password authentication is disabled. Administrative credentials are held in access-restricted stores, never in source control.
• Mail server SSH is rate-limited against brute force.
• Secrets are held as write-only environment variables in the hosting platform.
• Dependencies are kept deliberately few, reducing supply-chain exposure.
• No analytics, advertising or third-party scripts run in the portal or on the website, so no personal data is exposed to any party not listed in Annex III.

Organisational

• Personnel with access to personal data are bound by confidentiality obligations.
• Access is granted on a need-to-know basis and reviewed when roles change.
• A documented breach procedure supports the 48-hour notification commitment in section 8.

Measures for subprocessors

Subprocessors are engaged only under written contract with data protection terms no less protective than this DPA, and are selected with regard to their security posture and, for EEA and UK data, their transfer arrangements.

---

Annex III — Subprocessors

Subprocessor	Purpose	Location of processing	Personal data involved
Supabase, Inc. (on Amazon Web Services)	Database, authentication and object storage	United States — AWS us-west-2, Oregon	Directory data, portal accounts, billing records, uploaded artwork
Vercel, Inc.	Hosting for the web portal and its serverless functions	United States	Transient request data only; no persistent storage
Hetzner Online GmbH	Signature relay server	Germany — Falkenstein	Email content, in transit only; never at rest
Hetzner Online GmbH	Mail server for RubySig's own transactional and support mail	United States — Ashburn, Virginia	RubySig's outbound notifications; inbound correspondence
Cloudflare, Inc.	Authoritative DNS resolution only	Global anycast network	None

On Cloudflare. RubySig's DNS records are not proxied through Cloudflare's network. Cloudflare answers name-resolution queries and is at no point in the path of portal traffic or email. It therefore receives no personal data. It is listed for completeness rather than because it processes personal data on RubySig's behalf.

On Microsoft. Microsoft is not a RubySig subprocessor. Microsoft Entra ID and Microsoft Graph are the Customer's own tenant and are operated under the Customer's own agreement with Microsoft. RubySig reads from that tenant on the Customer's instruction; it does not engage Microsoft.

Changes. RubySig will give at least 30 days' notice before adding or replacing a subprocessor, as set out in section 6.