Data processing agreement
Version dpa-1, published 2026-11-10, effective 2026-11-10. Each version is fixed once published; a change is a new version. SHA-256 ac2ec44dac3b2af21a337f2b458bf2af03243fd5984cac1e618e19fa8e25d36a. This version's fixed copy.
Sovrasign Data Processing Agreement. Version dpa-1, effective 10 November 2026.
Key points (a summary to help you read; the clauses below are the agreement):
- For the documents and recipients you put into Sovrasign, you are in charge (the "controller") and we process the data only for you and on your instructions (as your "processor").
- This agreement is part of our terms on every plan, Free included. You do not need to sign anything else.
- We never sell your data, never use it for marketing or profiling, and never use it to train AI models. Support, human or AI, never sees your documents.
- We tell you 30 days before a new subprocessor starts, and you can object.
- We tell you within 48 hours after we become aware of a personal data breach affecting your data.
- Your data is stored in the region you choose; today that is the United States. For data from the EU, EEA, UK and Switzerland, the standard contractual clauses apply.
- You can export your data at any time. When you close your account, we delete it after the 14-day undo period; destroying its document keys then makes the document copies in our backups unreadable, and other backup data expires within 35 days.
1. About this agreement
1.1 What this is. This data processing agreement (the "DPA") is between you, the customer named in the account, and Sovrasign LLC, a Washington limited liability company ("Sovrasign", "we", "us"). It sets out how we process personal data for you when you use the Sovrasign service. It meets the requirements for a contract between a controller and a processor under the EU and UK General Data Protection Regulations (Art. 28), the Swiss Federal Act on Data Protection, and the US state privacy laws that require a contract with a service provider or processor.
1.2 How it applies. The DPA is part of our terms of service on every plan, including Free and the beta. When you accept the terms, you accept the DPA in the version shown, and we record that version with the time of acceptance. The same acceptance counts as your signature of the standard contractual clauses and the UK Addendum where clause 11 makes them apply. If you need a copy signed by us, see clause 16.6.
1.3 If documents conflict. For your personal data, the order is: first the standard contractual clauses and the UK Addendum, where they apply (nothing in any other document limits them); then this DPA; then a signed order form; then the terms of service. A signed order form may add to this DPA or make it stricter for you, but not weaker.
1.4 Versions. Each version of the DPA has an id (dpa-N) and an effective date, shown at the top. We keep every version on our legal page. Clause 16.2 explains how a new version applies to you.
2. Words we use
Words such as "controller", "processor", "personal data", "processing", "data subject", "personal data breach" and "supervisory authority" have the meanings that data protection law gives them. Words defined in the terms of service (such as "account", "envelope", "recipient", "sender", "your content" and "signing page") have the same meaning here. In addition:
| Word | Meaning |
|---|---|
| Customer personal data | Personal data in your content that we process for you: everything you or your members put into envelopes, templates and contacts, what your recipients add when they sign, and the records the service creates about your envelopes (Annex 1) |
| Data protection law | Every law on the protection of personal data that applies to the processing, including the EU General Data Protection Regulation (GDPR), the UK GDPR and the UK Data Protection Act 2018, the Swiss Federal Act on Data Protection (FADP), and US state privacy laws such as the California Consumer Privacy Act (CCPA) |
| Instructions | What clause 5.1 lists: your documented instructions to us |
| Subprocessor | A company we engage that processes customer personal data for us (clause 8) |
| Security measures | The technical and organisational measures in Annex 2 |
| Standard contractual clauses (SCCs) | The standard contractual clauses for transfers to third countries adopted by the European Commission in Implementing Decision (EU) 2021/914 of 4 June 2021 |
| UK Addendum | The International Data Transfer Addendum to the EU Commission Standard Contractual Clauses, issued by the UK Information Commissioner under section 119A of the UK Data Protection Act 2018 |
| Restricted transfer | A transfer of personal data that data protection law allows only with a safeguard, such as a transfer from the EU, EEA, UK or Switzerland to the United States |
| Region | Where your account's data is stored, chosen at sign-up (clause 11.1) |
3. Roles
3.1 You are the controller, we are your processor. For customer personal data, you decide why and how it is processed, and we process it for you. Under the GDPR you are the controller and we are your processor. Under the CCPA and similar US state laws you are the business and we are your service provider or processor.
3.2 When you act for someone else. If you use the service for another organization, for example as an agency or an outsourced team, you may be a processor yourself. Then we are your subprocessor, you confirm that the controller has authorised you to engage us on the terms of this DPA, and you pass on to the controller what we tell you under this DPA. We take instructions only from you.
3.3 Personal use. If you use the service only for personal or household purposes, data protection law may not apply to you as a controller. We still treat your data as this DPA says.
3.4 What we do as a controller. Some personal data we process for our own purposes, and for it we are the controller, under our privacy policy, not this DPA: your account, members and sign-in, billing, our emails to account holders, security logs, abuse and fraud prevention (such as a sender's risk score and our decisions to hold a send), the email-code identity service and its issuance log, the signer's own "Remember my choice on this device" setting, support for account holders, the record without names or content that we keep after an envelope is deleted (clause 12.5), and records the law makes us keep. We do not use customer personal data for these purposes, except as clause 12.5 and the privacy policy describe.
4. Your responsibilities
4.1 Lawful basis and notices. You are responsible for having a lawful basis to give us customer personal data and to send documents to your recipients, and for giving your recipients the privacy information the law requires from you. You can link your own privacy notice on the signing page. Section A4 of our privacy policy tells recipients that you are in charge of their data.
4.2 Your instructions must be lawful. Your instructions to us must comply with data protection law.
4.3 Sensitive data. The service does not need special categories of personal data (such as health data) or data about criminal convictions, and we do not ask for them. If your documents or fields contain such data, you are responsible for having the basis and the safeguards the law requires, and you decide whether the protection in Annex 2 is enough for your use. When a recipient tells you through the signing page that they need help to sign, they may share a health condition or a disability; you use that only to help them. Do not use the service for protected health information under the US HIPAA rules unless you have a business associate agreement with us (Part A, item 6 of Schedule 1 to the terms).
4.4 Minors. Accounts are for adults, but you may send documents to a minor aged 13 or older. If you do, you are responsible for any consent of a parent or guardian that the law requires, and for whether the minor can sign. You must not send documents to anyone you know is under 13 (clause 11.6 of the terms): the service has no process for the parental consent that the US Children's Online Privacy Protection Act requires. If we learn that a recipient is under 13, we tell you, and we may stop the envelope for that recipient or void it and delete that recipient's personal data.
4.5 Accurate addresses. You are responsible for entering your recipients' email addresses correctly. We send invitations and completed documents to the addresses you give us.
5. How we process your data
5.1 Only on your instructions. We process customer personal data only on your documented instructions. Your instructions are: the terms of service and this DPA; your use of the service and the settings you choose in it (for example whom you send a document to, your plan's retention rules, and the envelopes you delete); and any other written instruction that we agree to. We may also process customer personal data where a law that applies to us requires it; then we tell you before we do, unless that law forbids it on important grounds of public interest.
5.2 If an instruction breaks the law. If we think an instruction breaks data protection law, we tell you at once. We stop following that instruction until you change it or we are satisfied that it is lawful.
5.3 What we never do. We never sell customer personal data or share it for cross-context behavioral advertising. We never use it for marketing, to build profiles for other purposes, or to train or improve AI models, and our subprocessors may not either. Our only own uses are the records of clause 12.5 and the security signals of clause 3.4 of this DPA and section A6.7 of the privacy policy, as far as data protection law allows. We never combine it with personal data we receive from other customers or from other sources, except for the security checks of Annex 1 (the business purpose of detecting security incidents and protecting against malicious, deceptive, fraudulent or illegal activity) or as data protection law allows. We may create anonymous, aggregated statistics about how the service is used (such as counts and timings) that identify no one and contain no content.
5.4 Who can see it. Only people who need it to run the service can access customer personal data, and only as much as they need. Everyone who can access it, including our staff and contractors, is bound by confidentiality, by contract or by law. Access is personal, granted just in time, and logged (Annex 2).
5.5 Looking at document contents. Support, human or AI, never sees the contents of your documents: not the pages, field values, messages or attachments, even with your approval. Our staff may open an envelope's contents in three cases only: to review an envelope held or reported as phishing, fraud or illegal content under section 15 of the terms; when a court order or other binding legal process requires it (clause 5.6); or when a security incident cannot be handled otherwise. Two people approve each access under a written procedure (while one person runs the service, the access waits 24 hours and is reported to an independent mailbox that is reviewed every month), every access is logged, and we tell you unless the law forbids it.
5.6 Requests from authorities. If an authority asks us for customer personal data, we first point it to you where we can. We disclose only on valid legal process, to make a report the law requires of us, or in an emergency the law allows (a danger of death or serious injury); only the narrowest data that answers it, and we tell you unless the law forbids it. We challenge requests that conflict with the law where we can. Sovrasign is a US company, so US legal process can reach data we hold, including data stored outside the United States. Clause 11.8 adds the duties of the standard contractual clauses.
5.7 If we can no longer comply. If we can no longer meet our obligations under this DPA or data protection law, we tell you without undue delay. You may then stop the affected processing and end the affected service under clause 8.5.
6. Description of the processing
Annex 1 describes the processing: the subject matter, duration, nature and purposes, the types of personal data and the categories of people concerned. It also serves as Annex I.B of the standard contractual clauses and as the description of the processing that US state laws require.
7. Security
7.1 Our measures. We protect customer personal data with the security measures in Annex 2, which take into account the state of the art, the cost, the nature of the processing and the risks to people. They include encryption in transit and at rest, a separate key for each customer's documents, tenant isolation, access control with no standing access, logging, backups, tested recovery and incident response.
7.2 Changes to the measures. Security improves, so we may update the measures. We never reduce the overall level of protection of Annex 2 during the term of this DPA.
7.3 Your part. You are responsible for the security of your own accounts and devices: who you invite as members, the sign-in methods they use, links and documents you share outside the service, and copies you download.
8. Subprocessors
8.1 Your authorisation. You give us a general authorisation to engage subprocessors. The subprocessors in use on the date of this DPA are those in the published subprocessor list, summarised in Annex 3.
8.2 Our contracts with them. Before a subprocessor processes customer personal data, we bind it by a written contract with data protection obligations at least as protective as this DPA, including security measures, confidentiality, assistance and deletion, and safeguards for any restricted transfer. We check its security before we use it and every year after. We remain fully responsible to you for what each subprocessor does with customer personal data.
8.3 Notice before a change. At least 30 days before a new subprocessor starts processing customer personal data, we tell you who it is, what it will do, which data it will process, where, and the transfer safeguard. The same applies when an existing subprocessor starts processing a new kind of customer personal data, for a new purpose, or in a new country.
8.4 How we tell you. We email the notice to the owner of every account and to everyone who subscribed to changes, show it in the app to owners and admins, and publish it on the subprocessor list with its date. An owner may turn off the email; the in-app notice and the list still inform the account.
8.5 Objecting. Within those 30 days, you may object to the change, in writing to privacy@sovrasign.com, for reasons relating to data protection. We will discuss your objection in good faith and, where we can, offer a way to avoid the change for you, for example a setting or keeping your data away from the new subprocessor. If we cannot resolve your objection within the 30 days, you may end the affected service, or close your account, before the change applies to your data, by telling us in writing. We then refund the fees you prepaid for the unused period of the affected service and your unused pack envelopes at the price paid. This is in addition to your other rights under the terms.
8.6 Emergencies. If we must replace a subprocessor at short notice to keep the service running or secure (for example because it fails, stops its service or suffers a breach), we may do so with a shorter notice. We tell you as soon as possible, and your 30 days to object under clause 8.5 run from that notice.
8.7 Copies. On request, we give you a copy of the data protection terms of a subprocessor contract. We may remove commercial terms and confidential information first; where we cannot share a term, we summarise it.
9. Helping you meet your duties
9.1 Requests from people. The service lets you find, export, correct where the law allows, and delete the customer personal data of a recipient, or you can ask us to do it for you. If a recipient or another person asks us about customer personal data, we do not answer for you: we forward the request to you within 5 business days, tell the person that we did, and help you answer it. Signed documents cannot be changed, because they are evidence; you decide, as controller, whether to keep or delete them.
9.2 Assessments and consultations. We give you the information we have that you reasonably need for a data protection impact assessment and for a prior consultation with a supervisory authority about the service: this DPA, the security information of clause 13.1, and summaries of our own assessments.
9.3 Information. We give you the information you reasonably need to show that you and we meet data protection law for the processing (clause 13).
9.4 Cost. This help is free. If a request is clearly unfounded or excessive, for example the same audit asked for repeatedly, we tell you the cost first and you decide.
10. Personal data breaches
10.1 Notice within 48 hours. We tell you without undue delay, and within 48 hours after we become aware, of a personal data breach affecting customer personal data, at Sovrasign or at a subprocessor.
10.2 What we tell you. As far as we know it: what happened and when; the categories and the approximate number of people and records concerned; the likely consequences; the measures we took or propose, including to limit harm; and whom you can contact. If we do not know everything at first, we tell you what we know and add the rest as we learn it.
10.3 How we tell you. By email to the owner and admins of the account and to any security contact you give us, and in the app.
10.4 What we do. We investigate, contain the breach and limit its effects, keep the evidence, and give you the information you need for your own notices to authorities and to the people concerned. Telling you about a breach is not an admission of fault.
10.5 Notices to others. You decide whether to notify authorities and the people concerned about customer personal data. We do not notify them on your behalf unless you ask us to or the law requires us to. This does not stop us from meeting our own duties as a controller for our own data, or from informing other customers affected by the same breach.
11. Where data is processed and international transfers
11.1 Regions. We store customer personal data in the region chosen for your account at sign-up. Today we offer the United States (Microsoft Azure, East US 2, with backups and copies in Central US). An EU region (Sweden Central, with copies in Germany West Central and Sweden South, all in the EU) is planned to open later; when it does, new accounts can choose it, and existing accounts can ask us to move. Annex 3 says where each subprocessor processes data. Email we send for you reaches your recipients' mail servers wherever they are.
11.2 Sovrasign is a US company. Our staff and contractors may access customer personal data from the United States to run and support the service, under clause 5.4 and Annex 2, including when the data is stored in the EU region. Such access is a transfer, and the safeguards of this clause cover it.
11.3 Transfers from the EU and EEA. For each restricted transfer of customer personal data from the EU or EEA to Sovrasign that no adequacy decision covers, the standard contractual clauses apply and are part of this DPA, with you as data exporter and Sovrasign as data importer: Module Two (controller to processor) where you are a controller, and Module Three (processor to processor) where you are a processor. Annex 4 completes them: the options chosen, the parties, the description (Annex 1), the security measures (Annex 2) and the subprocessors (Annex 3).
11.4 Transfers from the UK. For a restricted transfer from the United Kingdom, the UK Addendum applies to the standard contractual clauses of clause 11.3, completed as Annex 4 says.
11.5 Transfers from Switzerland. For a restricted transfer from Switzerland, the standard contractual clauses of clause 11.3 apply with the adjustments for Swiss law in Annex 4.
11.6 The Data Privacy Framework. Sovrasign is not certified under the EU–US Data Privacy Framework, its UK Extension or the Swiss–US Data Privacy Framework. Transfers to Sovrasign rely on the standard contractual clauses, with the UK and Swiss terms of clauses 11.3 to 11.5.
11.7 Onward transfers. We transfer customer personal data to a subprocessor in another country only with a safeguard that data protection law accepts: an adequacy decision (such as the Data Privacy Framework, where the subprocessor is certified) or the standard contractual clauses (Module Three) with an assessment of the transfer. Annex 3 names the safeguard for each subprocessor.
11.8 Government access. For data transferred under the standard contractual clauses, we keep the duties of Clause 14 and Clause 15 of those clauses: we assess the laws that apply to us, tell you if we receive a legally binding request or learn of direct access by public authorities, review each request, challenge it where there are reasonable grounds, disclose the minimum, and keep a record of requests. The redress mechanism of US Executive Order 14086 applies to transfers to the United States.
11.9 Transfer assessments. On request, we give you the information you reasonably need for your own transfer impact assessment, including a summary of ours.
12. Deleting and returning data
12.1 While you use the service. You can export your data at any time, free, in the formats that clause 17.1 of the terms lists, and delete envelopes, templates and contacts. You can also ask us to do either for you. Deleted envelopes stay in Trash for 30 days, so you can restore them, and are then purged.
12.2 Retention you choose. The retention rules of your plan in section 18 of the terms (for example, on Free, cloud copies of completed documents are removed 12 months after completion, with notices) and the settings you choose are your instructions to us. A legal hold (for example one that a court orders) stops the deletion of what it covers until it is released.
12.3 When your account closes. When you close your account, you have 14 days to undo it. Then we delete customer personal data and destroy your account's encryption keys. You may export your data before you close the account, and switching to another provider follows clause 17.2 of the terms. If we end the service, clause 17.3 of the terms applies.
12.4 Backups. Our backups expire within 35 days. Because the keys of a closed account are destroyed, the copies of its documents in backups become unreadable at once. If we ever restore a backup, we re-apply deletions made after it, so deleted data does not come back.
12.5 What remains and why. After deletion we keep only:
- data that a law requires us to keep, for as long as it requires, and data under a legal hold, protected as this DPA says until it is deleted;
- a record of each deleted envelope with no names, email addresses or content (the envelope id, the document's fingerprint, its dates and the internal id of the person who deleted it), for 10 years, so we can confirm whether a file was completed through Sovrasign. We keep this record as controller (clause 3.4);
- the email-code identity service's issuance log, which holds fingerprints and the domain of the email address, never names or full addresses in clear, for 10 years, as evidence in case a signature is disputed (controller data).
We cannot recall the signed documents that we delivered to you and your recipients: they belong to them, and deleting your account does not remove them.
12.6 Proof of deletion. When an account closes, we send its owner a deletion receipt that lists what we deleted, what we keep and why, and when the backups expire. On request, we confirm in writing that customer personal data has been deleted.
13. Audits
13.1 Information we provide. To show that we meet this DPA, we make available: this DPA and its annexes; our security page; our answers to a standard security questionnaire; a summary of our most recent penetration test (it says whether the test was done in-house and how) under a confidentiality agreement; and, once we have one, our SOC 2 report under a confidentiality agreement.
13.2 Audits. If that information is not enough to show that we meet this DPA, or if a supervisory authority requires it, or after a personal data breach affecting your data, you may audit our compliance with this DPA, yourself or through an independent auditor who is not our competitor and who is bound by confidentiality.
13.3 How audits run. You give us at least 30 days' written notice with the scope, unless an authority or a breach requires sooner. We agree a plan together. Audits take place during business hours, remotely where possible, at most once in any 12 months unless an authority or a breach requires another. An audit may not give access to other customers' data or weaken the security of the service, and auditors follow our security rules. Each of us bears its own costs. You give us a copy of the audit report, which is confidential.
13.4 Enterprise. A signed Enterprise order form may agree other audit terms, including visits.
13.5 Supervisory authorities. We cooperate with the supervisory authorities that are competent for the processing, and we accept their audits as data protection law requires.
14. US state privacy laws
14.1 Service provider and processor. For customer personal data that is personal information under the CCPA or similar US state laws, we are your service provider or processor. We process it only for the business purposes in Annex 1, which are the purposes of our contract with you.
14.2 What we never do. We do not sell or share it; retain, use or disclose it for any purpose other than those business purposes, or outside our direct business relationship with you; or combine it with personal information from other sources, except as those laws allow.
14.3 Same protection. We comply with the obligations of those laws that apply to us, give the customer personal data the same level of privacy protection they require of you, and tell you if we can no longer meet them (clause 5.7).
14.4 Your rights. You may take reasonable and appropriate steps to make sure we use customer personal data in a manner consistent with your obligations, through the information and audits of clause 13, and, after notice, to stop and remedy any unauthorised use.
14.5 Requests and subcontractors. We help you answer consumers' requests as clause 9.1 says, and we engage subcontractors only under clause 8, with the notice and objection rights there.
14.6 Health data. If customer personal data includes consumer health data under Washington's My Health My Data Act or a similar law, we process it only on your instructions under this DPA.
15. Liability
Each party's liability under this DPA is subject to the limits and exclusions of section 20 of the terms, as far as the law allows. Nothing in this DPA limits either party's liability to data subjects under the standard contractual clauses or data protection law, where the law does not allow it to be limited.
16. Duration, changes and general terms
16.1 Duration. This DPA applies as long as we process customer personal data for you, including after the terms end, until the data is deleted under clause 12.
16.2 Changes. We may update this DPA, for example when the law changes or we add a feature. Each update is a new version (clause 1.4). If a change affects you materially, we tell you at least 30 days before it takes effect, as clause 23.2 of the terms says, and you may end the affected service with a refund of prepaid amounts for the time after that date. A change never reduces the protection of customer personal data, the security measures (clause 7.2) or the transfer safeguards of clause 11, unless the law requires it. A change to the subprocessors follows clause 8 instead.
16.3 Rights of data subjects. Under clause 24.6 of the terms, the terms give no rights to anyone else. As an exception, data subjects may enforce the standard contractual clauses and the UK Addendum as third-party beneficiaries, as those clauses provide.
16.4 Governing law. The law and courts of section 22 of the terms govern this DPA, except that the standard contractual clauses and the UK Addendum are governed by the law and courts that Annex 4 names.
16.5 Contacts. Our privacy contact is privacy@sovrasign.com; our security contact for breaches is security@sovrasign.com. We appoint our representatives in the EU (Article 27 of the GDPR) and in the UK before EU and UK sign-ups open, and name them here then. We send notices under this DPA to the owner of the account, as clause 24.1 of the terms says.
16.6 Signed copies. If you need a copy of this DPA signed by both of us, for example for your records of processing, an owner or admin can sign it in the app (Settings, Privacy and data): you sign it electronically with Sovrasign, and we countersign the signed copy with our seal. You can also write to privacy@sovrasign.com. A signed copy has the same content as the version you accepted and does not replace that acceptance.
Annex 1. Description of the processing
This annex is the description of the processing for Art. 28(3) GDPR, Annex I.B of the standard contractual clauses, and the business purposes for US state laws.
| Item | Description |
|---|---|
| Subject matter | Providing the Sovrasign electronic signature service to you under the terms |
| Duration | The term of the terms of service, and after it until deletion under clause 12 |
| Frequency | Continuous, as you use the service |
| Categories of data subjects | Your recipients (signers, approvers and people who receive copies); people whose details appear in your documents, templates and contacts; your senders and members as they appear in envelopes and their activity logs |
| Categories of personal data | (1) Contact data: names and email addresses of recipients, as you enter them. (2) Your content: any personal data in documents, attachments, fields and messages, including what recipients fill in, attach or write (field values, signature images, questions to you, a reason for declining). (3) Identity evidence of each signature: the sign-in method used (for example "Google" or "email code"), the token the provider or our email-code service issued (with the email address, the provider's identifier for the account and possibly the name the person has there), the time, and the version and fingerprint of the e-sign disclosure accepted. (4) The envelope's activity log: delivered, opened, consented, signed, declined, with the time, IP address, browser and device, and an approximate location derived from the IP address (never GPS). (5) Email delivery events for each recipient (delivered, bounced). (6) The sign-in hint and the repeat-signer memory described below |
| Special categories | Not required by the service. They may appear in your content where you choose to put them there (clause 4.3) |
| Nature of the processing | Storage, encryption and backup; rendering pages; preparing, sending and routing envelopes; sending invitations, reminders, notices and completed documents by email; recording identity evidence and the activity log; sealing and verifying signatures; requesting trusted timestamps (only a fingerprint of the document is sent); scanning uploads for malware and checking links against our own lists (an outside link-checking service only after notice under clause 8.3); support lookups (Annex 5) once the support assistant is in use; export, deletion and the other actions you take in the service |
| Purposes (business purposes) | (1) Providing the service to you and your recipients as the terms describe. (2) Keeping the service, its users and the data secure, including the malware and link checks. (3) Support at your request (Annex 5). (4) Meeting legal obligations that apply to us (clause 5.1). (5) Following your other documented instructions |
| Retention | As clause 12 says: until you delete the data or your plan's retention rules remove it (section 18 of the terms), then up to 35 days in backups, unreadable once your account's keys are destroyed |
| Subprocessors | Annex 3 |
Choosing the first sign-in button. We check the mail host of each recipient's address to choose the first sign-in button. We look up the domain of the address only (for example, whether example.com receives its mail at Microsoft or Google), never the full address, and never ask a provider whether an account exists. We store the result ("probably Microsoft"), how we found it and when, on the recipient's record in your account. It is in the service's audit trail, never in the signed document, and never shown to another customer. The other ways to sign in are always offered.
Recipient access through an account. You instruct us to let a recipient who creates an account see the completed documents they signed for you, for as long as you keep them. We check the same signing identity before linking them and show them nothing else of yours. Their account may list documents from several senders; each sender's retention and access rules still apply.
Remembering how a recipient signed. When a recipient signs more than once for you, your contact record remembers which provider they used last (the provider's name and a keyed hash of its identifier for their account), so that button comes first next time, and you see, as information, when they signed with a different account. This memory is kept for you only: no other customer learns how your recipients signed, and there is no memory across Sovrasign.
Annex 2. Security measures
This annex is Annex II of the standard contractual clauses. It describes the measures in place for the service; our security page gives more detail.
| Area | Measures |
|---|---|
| Encryption in transit | TLS 1.2 or higher (1.3 preferred) with modern cipher suites on every public connection and every internal connection; HSTS on our domains; database connections with verified certificates; data services reachable only through private network endpoints |
| Encryption at rest | Platform encryption (AES-256) for databases, storage, queues and disks. Documents and attachments are also encrypted by the application: each object with its own data key (AES-256-GCM), wrapped by a key for each customer, itself wrapped by a regional root key held in a hardware security module (Azure Key Vault Premium) |
| Tenant isolation | Each customer's data is tagged and separated by database row-level security set for each transaction; the application cannot query without a customer context; storage paths and keys per customer; workers that convert or render documents have no database access; automated tests check that one customer cannot reach another's data |
| Access control for our staff | No standing access to production data: roles are activated just in time with a reason, for at most 4 hours (Microsoft Entra Privileged Identity Management); phishing-resistant multi-factor sign-in; two break-glass accounts with hardware keys, whose use raises an alert; access reviews every quarter; access removed within 24 hours when someone leaves |
| Support and content | Support (human or AI) sees account details and diagnostics only, never document contents; access to contents only under clause 5.5 and logged; while one person runs the service, that person uses the 24-hour delay and independent-mailbox review of clause 5.5 instead of two-person approval |
| Logging and monitoring | Security events, sign-ins, administrative actions and key operations are logged and alerted on; application logs never contain names, document titles or content, email addresses only as keyed hashes, and IP addresses shortened (a test fails the build if personal data appears in logs); security logs kept 3 years in total, 1 year searchable then 2 years archived; every operator action recorded in an operator audit log |
| Integrity of signed documents | Each signature is sealed into the PDF with its identity evidence and activity record, so any change is detectable by anyone with the open-source verifier, without us; every signed revision is re-verified by the server; completed documents are delivered to every party |
| Signing page | Served from its own origin as static, versioned files with a strict content security policy, subresource integrity, no third-party code and no service worker; each release is published with a signed manifest, and an external monitor compares the served files with it |
| Secure development | Code review; automated tests; dependency and vulnerability scanning on every change; secret scanning; builds from version control with no stored cloud credentials (federated sign-in for deployments); production deployments only through the release pipeline |
| Vulnerability management | Penetration test of the web app, signing page, API, identity service and cloud configuration before the public launch, then every year and after major features, with high and critical findings fixed before release; a vulnerability disclosure policy with a published security contact |
| Availability and recovery | Compute spread over availability zones; database point-in-time restore for 35 days and backups copied to a second region in the same geography (United States or EU); document storage replicated within the geography; recovery targets for losing a region of 1 hour of data and 24 hours of downtime; a monthly test restore of the latest backup with verification of a sample of restored documents |
| Deletion | Deletion reaches indexes, caches and replicas; destroying a closed account's keys makes its documents in backups unreadable at once; a deletion ledger stops a restore from bringing deleted data back |
| Incident response | A written incident process with playbooks; an incident response firm engaged when needed; breach notice to customers within 48 hours (clause 10) |
| Abuse prevention | Malware scanning of every upload; checks of links in documents and messages against our own lists and checks (no outside link-checking service during the private beta; one added later receives only the links and is a subprocessor under clause 8); limits for new senders; a report button in every email; review by a person of every automatic hold |
| Subprocessors | Security review before use and every year; written contracts with data protection terms, including notice to us of a breach without undue delay; an exit plan for each critical vendor |
| Organisation | A named person responsible for privacy and security; written policies; confidentiality agreements; security and privacy training for anyone with access; a review of these measures at least every year |
| Physical security | The service runs in Microsoft Azure data centres, whose physical and environmental controls Microsoft certifies (for example ISO/IEC 27001 and SOC 2). We operate no data centres or servers of our own |
Annex 3. Subprocessors
This annex is Annex III of the standard contractual clauses. It summarises the published subprocessor list, version sp-1, which names each subprocessor's data, location and transfer safeguard; the published list, with the changes made under clause 8, governs.
| Subprocessor | What it does for us | Where |
|---|---|---|
| Microsoft Corporation (Microsoft Azure) | Hosts the whole service; malware scanning of uploads; sends email (Azure Communication Services) until Mailgun replaces it | Your region (United States today); EU–US Data Privacy Framework |
| Stripe, LLC | Billing and payments for account holders | United States and other countries; EU–US Data Privacy Framework, standard contractual clauses as fallback |
| Timestamp authorities: DigiCert, Inc. during the private beta | Trusted timestamps. They receive only a fingerprint (hash) of the document, never the document or its contents; a fingerprint can still be personal data when someone can link it to a person | United States; no transfer safeguard needed (no customer content) |
| Mailgun Technologies, Inc. | Sends email for the service. Not used during the private beta; from a date we announce with the notice of clause 8.3 | United States for the US region, EU for the EU region; Data Privacy Framework (EU and UK), standard contractual clauses for Swiss data |
| Microsoft Corporation (Microsoft Foundry) and Anthropic, PBC | The AI support assistant (Annex 5) | United States; Microsoft: Data Privacy Framework; Anthropic: standard contractual clauses |
The list also has places for an incident response firm and a continuity operator, neither retained yet, and the subprocessors planned for later features. None of them receives customer personal data until it is named on the list with notice under clause 8.3 (or clause 8.6 in an emergency).
Annex 4. Transfer clauses: the details
This annex completes the standard contractual clauses (clause 11.3), the UK Addendum (clause 11.4) and the Swiss adjustments (clause 11.5). The official texts are published by the European Commission and the UK Information Commissioner; they are not reproduced here.
Modules. Module Two where you are a controller; Module Three where you are a processor (clause 3.2). Where the standard contractual clauses allow it, references to them include both modules.
Options chosen.
- Clause 7 (docking clause): included. Another entity may accede with our written agreement.
- Clause 9(a) (subprocessors): Option 2, general written authorisation. The time period is 30 days, with the notice and objection process of clause 8.
- Clause 11(a) (redress): the optional independent dispute resolution body is not used.
- Clause 13 (supervision): the supervisory authority set by Clause 13(a): where you are established in an EU member state, its authority; where you are not established in the EU but have a representative under Article 27 of the GDPR, the authority of the member state where your representative is established; otherwise the authority of the member state where the data subjects whose data is transferred are located, as Clause 13(a) provides.
- Clause 17 (governing law): Option 2, the law of the EU member state where you are established; where that law does not allow third-party beneficiary rights, or you are not established in the EU, the law of Ireland.
- Clause 18 (courts): the courts of the member state whose law governs under Clause 17.
Parties (Annex I.A).
- Data exporter: you, with the name, address and contact person in your account (or your billing details where you gave them); your activities are your use of the service; your role is controller (Module Two) or processor (Module Three); your acceptance of the terms is your signature and its date.
- Data importer: Sovrasign LLC, 522 W Riverside Ave #10903, Spokane, WA 99201, USA; contact privacy@sovrasign.com; activities: providing the service under the terms; role: processor; signature: our publication of this DPA counts as our signature, on the date you accept it.
Description, measures and subprocessors (Annex I.B, II and III). Annex 1, Annex 2 and Annex 3 of this DPA. Transfers are continuous; the retention is in Annex 1.
Competent supervisory authority (Annex I.C). As chosen for Clause 13 above.
Where the clauses conflict with this DPA, the clauses win (clause 1.3). Nothing in this DPA is meant to contradict them or limit the rights of data subjects under them; the audit and subprocessor terms of clause 8 and clause 13 are how we meet Clause 8.9 and Clause 9 of the clauses.
UK Addendum. The UK Addendum (version B1.0, in force from 21 March 2022, or a later version the Information Commissioner issues) applies to restricted transfers from the UK. Table 1: the parties as in Annex I.A above. Table 2: the approved EU SCCs with the modules and options above. Table 3: Annex 1, Annex 2 and Annex 3 of this DPA. Table 4: either party may end the UK Addendum as its Section 19 allows. Where the UK Addendum applies, references in the clauses to the GDPR, the EU and its member states, and the EU courts are read as the UK Addendum says.
Switzerland. For transfers subject to the FADP: the Swiss Federal Data Protection and Information Commissioner is the competent supervisory authority for those transfers; references to the GDPR are read as references to the FADP as far as those transfers are concerned; the term "member state" may not be read so as to stop data subjects in Switzerland from suing for their rights in their place of habitual residence; and Clause 17 and Clause 18 are as above.
Annex 5. The AI support assistant
This annex sets out the processing of customer personal data by the AI support assistant, on every plan, from when the assistant is in use (not during the private beta, when a person answers support by email). The terms for AI features that work on documents will be a separate annex, added under clause 16.2 before those features are switched on.
| Item | Rule |
|---|---|
| What it does | Answers questions from you, your members and your recipients about the service, in the app, the help center and the signer help pages. It tells people that it is an AI before they start |
| Customer personal data it may process | What users type into the chat, and what its read-only tools return about your account, for a signed-in user who may see it in the service: envelope ids and states, delivery status and error codes. Neither is used to train models. Recipient names, email addresses and document titles are replaced by codes before anything reaches the model, and the user's screen shows the real values. For a recipient, only the status of the envelope they hold a link to |
| What it never processes | Document contents from stored envelopes: its tools cannot retrieve pages, field values, messages, attachments or titles. What a user types into the chat does reach it, so users should not paste document contents there. It cannot change anything; any action it proposes needs the user's own click |
| Masking | Where the app can detect them, email addresses, phone numbers and card or bank numbers in a user's message are masked before the model sees them. The chat asks users not to paste document text or other people's data |
| Model and location | Claude models made by Anthropic, accessed through Microsoft Foundry and run on Anthropic's infrastructure. Every conversation from an account in the EU, EEA, UK or Switzerland is processed in Microsoft's United States Data Zone, never routed elsewhere. Other conversations: also the United States Data Zone. Not used during the private beta |
| Transfers | To Microsoft: the EU–US Data Privacy Framework and its UK and Swiss parts. To Anthropic: the standard contractual clauses, with our transfer assessment (clause 11.7) |
| No training | Neither we nor the model providers use conversations or tool results to train or improve models |
| Retention | Conversations 90 days, and a user can delete one at any time; a conversation attached to a support case, the life of the case plus 2 years. The AI action log (which tool, when, for whom, without the text) 13 months |
| Ask, our internal analytics assistant | Not a processing of customer personal data. Our staff use Ask to query statistics about how the service is used. It reaches only a statistics layer that holds no names, email addresses, document titles, content or free text, never your documents or your recipients' data; a person checks every query before it runs; and the model receives only the question, the definitions of those statistics and, at most, 200 rows of anonymous totals. It runs on the same models and platform as the assistant |