Data Processing Agreement — one2sign and Senots

This Data Processing Agreement (the "DPA") forms part of the agreement between DDR Solutions Inc. ("DDR") and the Customer under the Terms of Service (the "Terms"). It applies whenever DDR processes Customer Personal Data in providing the Services. It takes effect when the Customer accepts the Terms, without a separate signature. A Customer that needs a countersigned copy can request one at hello@one2sign.com.

Capitalized terms not defined here have the meanings given in the Terms. If this DPA conflicts with the Terms or any other part of the Agreement, this DPA prevails for the processing of Customer Personal Data (Terms, Section 2.2).

1. Definitions

• "Data Protection Laws" means all laws on privacy and the protection of personal information that apply to a party's processing of Customer Personal Data under the Agreement, which may include:
  • the Personal Information Protection and Electronic Documents Act (Canada) ("PIPEDA");
  • Quebec's Act respecting the protection of personal information in the private sector, as amended by An Act to modernize legislative provisions as regards the protection of personal information ("Quebec Privacy Act");
  • Alberta's and British Columbia's Personal Information Protection Act;
  • US state consumer-privacy laws, such as the California Consumer Privacy Act as amended by the California Privacy Rights Act ("CCPA");
  • Mexico's Ley Federal de Protección de Datos Personales en Posesión de los Particulares;
  • the EU General Data Protection Regulation 2016/679 ("GDPR"), the UK GDPR and Data Protection Act 2018, and the Swiss Federal Act on Data Protection; as amended or replaced.
• "Controller" means the party that, alone or with others, decides the purposes and means of processing Personal Information, including an "organization" that has "control" of Personal Information under PIPEDA, a "business" under the CCPA, and a responsable under Mexican law. "Processor" means a party that processes Personal Information on behalf of a Controller, including a "service provider" under PIPEDA and the CCPA, a person to whom an enterprise entrusts information under the Quebec Privacy Act, and an encargado under Mexican law.
• "Data Subject" means the identified or identifiable individual to whom Customer Personal Data relates.
• "Security Incident" means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, Customer Personal Data in DDR's or its Subprocessors' systems. It includes a "breach of security safeguards" under PIPEDA and a "confidentiality incident" under the Quebec Privacy Act. It does not include unsuccessful attempts that do not compromise security, such as pings, port scans or blocked sign-in attempts.
• "Subprocessor" means a third party engaged by DDR that processes Customer Personal Data on DDR's behalf to provide the Services.
• "SCCs" means the standard contractual clauses approved by European Commission Implementing Decision (EU) 2021/914. "UK Addendum" means the International Data Transfer Addendum to the SCCs issued by the UK Information Commissioner under section 119A of the Data Protection Act 2018.

2. Roles and scope

2.1 Roles. For Customer Personal Data, Customer is the Controller (or acts as a Processor for its own clients, in which case DDR is its Subprocessor), and DDR is the Processor. DDR is a Controller for Account Data and Service Data, which the Privacy Policy covers and this DPA does not.

2.2 Details of processing. The subject matter, duration, nature and purpose of the processing, and the types of Customer Personal Data and categories of Data Subjects, are in Annex 1.

2.3 Customer's obligations. Customer is responsible for the lawfulness of the Customer Personal Data and of its instructions, and for giving every notice and obtaining every consent or other legal basis required under Data Protection Laws for DDR to process Customer Personal Data under the Agreement. This includes notices to its employees, to Recipients (including that their IP address, approximate location and device appear on the Certificate of Signature shared with every Recipient), and to anyone whose information is in files that Recipients attach.

3. Processing on instructions

3.1 DDR will process Customer Personal Data only on Customer's documented instructions, unless the law requires otherwise; in that case DDR will tell Customer before processing unless the law prohibits it. The Agreement, Customer's configuration of the Services (including roles, access, retention and sharing settings) and the actions of its Authorized Users in the Services are Customer's complete instructions. Additional instructions require written agreement.

3.2 DDR will tell Customer if, in its opinion, an instruction infringes Data Protection Laws. DDR is not required to carry out such an instruction.

3.3 US state law terms. For the CCPA and similar US state laws, DDR is a service provider or processor and will not: (a) sell or share Customer Personal Data; (b) retain, use or disclose it for any purpose other than the business purposes specified in the Agreement, including any commercial purpose other than providing the Services; (c) retain, use or disclose it outside the direct business relationship with Customer; or (d) combine it with personal information DDR receives from or on behalf of another person, except as the law permits for service providers. DDR will comply with the obligations that apply to it under those laws, provide the same level of privacy protection they require, and notify Customer if it can no longer meet them. Customer may take reasonable and appropriate steps to stop and remediate unauthorized use of Customer Personal Data. DDR certifies that it understands and will comply with these restrictions.

4. Confidentiality of personnel

DDR will make sure that every person it authorizes to process Customer Personal Data is bound by a duty of confidentiality and has access only to the extent needed. DDR personnel access Customer Personal Data inside an Account only under a Support Access Grant, or in the exceptional cases listed in Section 8.3 of the Terms.

5. Security

5.1 DDR will implement and maintain the technical and organizational measures in Annex 2, appropriate to the risk and the nature of the Customer Personal Data, to protect it against Security Incidents.

5.2 DDR may update the measures, but will not materially lower the overall level of security during the Subscription Term.

5.3 Customer is responsible for the security settings and choices under its control (Terms, Section 8.2).

6. Subprocessors

6.1 Authorization. Customer gives DDR general authorization to engage Subprocessors. The current Subprocessors are listed in the Subprocessor list, which forms part of this DPA.

6.2 Obligations. DDR will (a) carry out reasonable due diligence on each Subprocessor's security and privacy practices; (b) bind each Subprocessor by a written contract with data-protection obligations no less protective than those in this DPA, to the extent applicable to the services it provides; and (c) remain responsible for each Subprocessor's performance of those obligations.

6.3 Changes. DDR will give at least 30 days' notice before a new Subprocessor begins processing Customer Personal Data, by updating the Subprocessor list and notifying Owners by email (or in the Services) as described there. In an emergency, for example to replace a failed provider to keep the Services running, DDR may give shorter notice and will explain why.

6.4 Objection. Customer may object on reasonable data-protection grounds by writing to hello@one2sign.com within the notice period. The parties will discuss the objection in good faith. If DDR cannot offer a reasonable alternative, Customer may terminate the affected Services by notice before the change takes effect, and DDR will refund prepaid Fees for the remainder of the Subscription Term for those Services.

7. Assistance

7.1 Data Subject requests. Taking into account the nature of the processing, DDR will help Customer respond to requests from Data Subjects to exercise their rights, mainly by providing features in the Services to find, correct, export and delete Customer Personal Data. If DDR receives a request directly about Customer Personal Data, DDR will forward it to Customer within five business days and will not respond to it, except to direct the Data Subject to Customer, unless Customer authorizes it or the law requires.

7.2 Assessments and regulators. DDR will give Customer reasonable information and help, at Customer's reasonable cost where the effort is material, for privacy impact assessments (including assessments under the Quebec Privacy Act before communicating personal information outside Quebec), data protection impact assessments, prior consultations and inquiries from regulators, to the extent they concern DDR's processing.

8. Security Incidents

8.1 Notice. DDR will notify Customer of a Security Incident without undue delay, and in any case within 72 hours of becoming aware of it, by email to the Owners and, where provided, the Customer's security or billing contact.

8.2 Content. The notice will describe, to the extent then known: the nature of the Security Incident, including the categories and approximate number of Data Subjects and records concerned; when it happened and was discovered; the likely consequences; the measures DDR has taken or proposes to contain it and reduce harm; and a contact person. Where information is not yet available, DDR will provide it in phases as it becomes available.

8.3 Help. DDR will take reasonable steps to contain, investigate and mitigate the Security Incident, and will give Customer the information and help it reasonably needs to (a) assess whether the incident creates a real risk of significant harm to individuals under PIPEDA and Alberta's and British Columbia's laws, or a risk of serious injury under the Quebec Privacy Act, or meets the notification thresholds of other Data Protection Laws; (b) notify regulators and affected individuals; and (c) keep the record of incidents those laws require.

8.4 Who notifies. Customer, as Controller, decides whether to notify regulators and Data Subjects about a Security Incident affecting Customer Personal Data. DDR will not notify them on Customer's behalf without Customer's approval, unless the law requires DDR to.

8.5 No admission. DDR's notice of a Security Incident is not an admission of fault or liability.

9. Government requests

If a government authority asks DDR for Customer Personal Data, DDR will (a) direct the authority to request it from Customer; (b) if compelled to disclose, notify Customer promptly before disclosing, unless the law prohibits it; (c) challenge the request where DDR reasonably believes it is unlawful or overbroad; and (d) disclose only the minimum required. DDR has not built any back door or similar way for an authority to access Customer Personal Data.

10. Audits

10.1 Information. DDR will make available to Customer the information reasonably necessary to demonstrate compliance with this DPA, including the Security Overview and written answers to a reasonable security questionnaire, no more than once in any 12-month period.

10.2 Audits. If that information is not enough to demonstrate compliance, or a regulator requires it, or after a Security Incident, Customer may audit DDR's compliance with this DPA, once in any 12-month period, on at least 30 days' notice, during business hours, without disrupting DDR's operations, and under a confidentiality agreement. Customer may use an independent auditor that is not a competitor of DDR. Customer bears the cost of the audit and will reimburse DDR for the time its personnel spend at DDR's then-current professional-services rates, unless the audit reveals a material breach of this DPA by DDR. Audits of a Subprocessor are carried out by reviewing the reports, certifications or other information that Subprocessor makes available.

10.3 DDR does not hold SOC 2, ISO 27001 or similar certifications. DDR will tell Customer if it obtains one.

11. Return and deletion

11.1 During the Subscription Term, and during a Trial, on the Free Plan or while the Account is read-only (Terms, Section 4.9), Customer can export and delete Customer Personal Data using the features of the Services, including the one2sign retention setting (E-Signature Terms, Section 9).

11.2 When the Account closes, DDR will make Customer Personal Data available for export and then delete it as described in Section 11 of the Terms: an export period of 30 days, deletion from active systems within 90 days after closure, and removal from the database's point-in-time recovery on its normal cycle (currently up to 30 days after that). DDR will confirm deletion in writing on request.

11.3 DDR may keep Customer Personal Data longer where the law requires it, and the minimal records described in Section 9.3 of the E-Signature Terms. DDR will keep any retained data confidential and process it only for the purpose that requires its retention.

12. International transfers

12.1 Location. DDR processes Customer Personal Data in Canada and the United States, and its Subprocessors process it in the locations shown in the Subprocessor list. DDR asks its hosting provider to place stored Customer Data in eastern North America; this is a placement request, not a guarantee that data stays in a particular country (Annex 2, item 1).

12.2 Canada and Quebec. Customer acknowledges that Customer Personal Data may be processed outside its province and outside Canada. DDR's contracts with Subprocessors require protection comparable to that required by PIPEDA and the Quebec Privacy Act. DDR will give Customer the information it needs for any assessment required before communicating personal information outside Quebec.

12.3 EU/EEA. To the extent the GDPR applies to a transfer of Customer Personal Data to DDR in a country without an adequacy decision, or onward from DDR, the SCCs are incorporated into this DPA by reference, with Customer as data exporter and DDR as data importer, completed as follows: Module 2 (controller to processor) where Customer is a Controller, and Module 3 (processor to processor) where Customer is a Processor; Clause 7 (docking clause) applies; in Clause 9, Option 2 (general written authorization) applies with the notice period in Section 6.3; the option in Clause 11 does not apply; in Clause 13, the supervisory authority is the one competent for Customer; in Clauses 17 and 18, the law and courts are those of Ireland; and Annexes I and II of the SCCs are completed by Annexes 1 and 2 of this DPA and Annex III by the Subprocessor list. Transfers from the EU to DDR in Canada are also covered by the European Commission's adequacy decision for Canada, to the extent it applies.

12.4 UK. To the extent the UK GDPR applies, the UK Addendum is incorporated by reference: its Table 1 is completed with the parties' details in this DPA, Table 2 with the SCCs modules and options in Section 12.3, Table 3 with Annexes 1 and 2 and the Subprocessor list, and in Table 4 either party may end the UK Addendum as its Section 19 allows.

12.5 Switzerland. To the extent the Swiss Federal Act on Data Protection applies, the SCCs apply with the Swiss Federal Data Protection and Information Commissioner as supervisory authority, and references to EU law read as references to Swiss law.

12.6 Onward transfers. DDR will make sure that a valid transfer mechanism is in place for each transfer to a Subprocessor that Data Protection Laws require, such as the SCCs or the EU-U.S. Data Privacy Framework (with its UK Extension and the Swiss-U.S. framework) where the Subprocessor is certified.

13. Liability

Each party's liability under this DPA is subject to the limitations and exclusions in Section 15 of the Terms, except to the extent Data Protection Laws or the SCCs do not allow them.

14. Term

This DPA lasts as long as DDR processes Customer Personal Data under the Agreement.

Annex 1. Details of the processing

Parties. Data exporter: the Customer, as identified in its Account, acting as Controller (or as Processor for its clients). Data importer: DDR Solutions Inc., 120 Adelaide St W, Suite 2500, Toronto, ON M5H 3V1, Canada, Privacy Officer Deivis Diaz, CEO, hello@one2sign.com, acting as Processor.

Subject matter. Providing the Services under the Agreement: the Senots Suite and one2sign.

Duration. While the Account is open (including any Trial, Free Plan or read-only period), plus the export and deletion periods in Section 11.

Nature of the processing. Hosting, storage, retrieval, organization, display, transmission (including email delivery to Recipients and Authorized Users), generation of PDFs and Certificates of Signature, computation (such as tax, payroll and accounting calculations), search, export, deletion, and security monitoring.

Purpose. To provide, secure and support the Services as Customer instructs, as described in the Agreement and the Documentation.

Frequency. Continuous.

Categories of Data Subjects.

• Customer's Authorized Users;
• Customer's employees, former employees, job candidates and contractors, and their dependants and emergency contacts;
• Customer's customers, prospects, suppliers and business contacts, and their staff;
• Recipients of Documents (signers, approvers, people who receive a copy, and in-person signers), who may be consumers or representatives of businesses;
• individuals named or shown in documents and files Customer uploads, or in files Recipients attach.

Categories of Customer Personal Data. Depending on the apps Customer uses and what it chooses to store:

• identification and contact data: names, email addresses, phone numbers, postal and home addresses, job titles, company names;
• employment data: department, manager, employment type and status, start and end dates, work location, time off, training, one-on-one notes, checklists, devices and app access;
• compensation and payroll data: pay rates, payroll runs, pay lines, deductions, benefits elections;
• dependants' names, relationships and dates of birth (benefits);
• headshots (photographs);
• commercial data: opportunities, quotes, invoices, payments, expenses and receipts, purchase orders, bank-statement lines and accounting entries;
• e-signature data: Documents and their content, field values, signature and initials images, consent records, Audit Trail events, IP addresses, IP-derived approximate location (city, region, country), keyed IP hashes, browser and device descriptions, time zones, access-code hashes and, if and when made available, mobile numbers for SMS codes;
• files Recipients attach, which may include identity documents and cheques or other banking details;
• any other Personal Information Customer includes in free-text fields or files.

Sensitive data. Customer may store sensitive information, such as compensation, benefits and dependants' information, photographs, identity documents and financial information. The Services do not provide dedicated fields for Social Insurance Numbers, government health-card numbers or bank-account numbers. The safeguards in Annex 2 apply, including per-app access controls and exports limited to Owners and Admins.

Subprocessors. As listed in the Subprocessor list.

Annex 2. Technical and organizational security measures

The Security Overview describes these measures in more detail.

1. Hosting and location. The Services run on Cloudflare Workers, with data in Cloudflare D1 (database) and Cloudflare R2 (file storage). DDR requests the "eastern North America" location for stored data. Cloudflare's network serves requests globally.
2. Encryption. All traffic uses HTTPS (TLS). HTTP Strict Transport Security is set for one year, including subdomains. Cloudflare encrypts D1 and R2 data at rest.
3. Tenant isolation. Each Customer's data is separated by company. Requests from a signed-in person are limited to their company by a company identifier taken from the signed-in session, never from the request. Some functions work across companies by design, for example: opening a signing link, a public template link, or a public quote or invoice link, the Verify Page, signed webhooks from DDR's payment and email providers, scheduled background jobs and DDR's operator console. A record belonging to another company gets the same "not found" answer as a record that does not exist. Files are stored under company-specific keys.
4. Access control. Roles (owner, admin, member) and per-person, per-app access (no access, user or admin). Salespeople see only their own opportunities unless they are CRM admins. Pay and personal details are limited to HR admins and the employee. Search, timelines and notifications follow the same rules. Exports are limited to Owners and Admins, unless an Owner or Admin grants export to a named person.
5. Authentication. No passwords. Sign-in by six-digit email code or link (valid for 10 minutes, stored only as hashes, the code as a keyed hash, with attempt limits), or by Google or Microsoft (OpenID Connect with state and PKCE). Session cookies are HttpOnly, Secure and SameSite=Lax. Sign-in attempts are rate-limited.
6. Request protection. State-changing requests require a CSRF check. The web app builds pages from data without inserting raw HTML. Uploads are type- and size-checked.
7. Private files. Files have no public address. Every read goes through the API's access checks. Documents are shared only through secret links created by Customer.
8. E-signature controls. Signing links are random secrets. Each is stored as a hash, used to look it up, and as an encrypted copy so the sender can see and resend it; it is never stored in plain text in the Services' database. Signing emails necessarily contain the link. Optional access codes are stored as keyed hashes, with lockout after five wrong attempts. Signing order, roles and field rules are enforced on the server. Documents are fingerprinted with SHA-256, and completed copies carry a Verification Code checked on the Verify Page.
9. DDR personnel access. No access to Customer Data inside an Account without a Support Access Grant (1 to 72 hours, revocable, each session at most 30 minutes, with an in-app banner and audit-log entries). The operator console is restricted to named DDR personnel and protected by Cloudflare Access. Secrets are kept in Cloudflare's secret store and never in source code.
10. Logging. An audit log records changes to HR records, settings, access, tax, billing, support sessions and e-signature deletions. Sign-in events are kept for 90 days, with email addresses and IP addresses hashed.
11. Change management. Every release is reviewed against a written security checklist, separately from the work that built it, and the outcome is recorded before deployment. Database changes are additive and applied once, in order. Changes are tested on a separate staging environment before production.
12. Resilience and recovery. Cloudflare's distributed infrastructure. Database point-in-time recovery for up to 30 days. Scheduled jobs are designed to be safely re-run.
13. Abuse prevention. Daily and hourly sending limits for Documents and invitations, rate limits on sign-in, signing and Verify endpoints, and Cloudflare network protections.
14. Incident response. Security Incidents are handled and notified under Section 8.
15. Data minimization and retention. Only keyed hashes are stored for most IP addresses and for sign-in history. Expired sign-in data is purged hourly. Customer-controlled retention and deletion apply to one2sign Documents.
16. Personnel. Personnel with access to Customer Personal Data are bound by confidentiality obligations and receive access only as needed.