TEMPLATE — have legal counsel review before production launch. This page is original placeholder content written for engineering purposes; it is not legal advice and is not a substitute for review by a qualified attorney in your jurisdiction.

Privacy Policy

Template — effective date to be set when this document is finalized for production launch.

1. Overview

This Privacy Policy describes how NegoDocs collects, uses, and retains personal data when you use the Service — whether as a registered account holder or as a recipient asked to review or sign a document sent through it.

2. What we collect

  • Account data: name, email address, hashed password, workspace membership.
  • Document content: the documents you create, upload, or send, and their contents.
  • Recipient/signer data: the name and email address of anyone added as a recipient, their signing status, IP address and timestamp at each step, and the signature image or typed signature they provide.
  • Usage & audit data: login history, feature usage, and the audit trail attached to each document.
  • Technical data: device/browser information and log data needed to operate and secure the Service.

3. How we use it

  • To provide the Service — building, sending, and signing documents;
  • To maintain the audit trail and certificate of completion that make a signed document trustworthy;
  • To send transactional email (signing invitations, reminders, receipts, verification);
  • To secure accounts and detect abuse; and
  • To comply with legal obligations, including record-keeping expectations for signed documents.

4. Legal basis for processing

Where applicable data-protection law requires a stated legal basis, we rely on: performance of a contract (providing the Service to the account holder who added you as a recipient), legitimate interests (security, fraud prevention, and the evidentiary integrity of a signed document), consent (where you affirmatively agree to sign electronically), and compliance with a legal obligation (record-keeping for completed signatures).

5. Retention

While a document is in progress (draft, sent, viewed, or partially signed) it is retained as part of the normal working set and can be deleted, voided, or have its recipient data corrected or removed on request.

Once a document is fully signed (“completed”), its final record — the signed PDF, the certificate of completion, and the audit trail — is written to write-once/read-many (WORM) object storage under a compliance-mode retention lock for the workspace’s configured retention period (by default, several years). During that window the record cannot be altered or deleted, by us or by the account holder. This is a deliberate design choice: a signed contract or agreement is exactly the kind of record that ESIGN/UETA- style electronic-signature frameworks expect to remain unaltered and available as evidence, and the retention lock is what makes that guarantee technically credible rather than just a policy promise. After the retention period expires, workspaces may configure automatic purging (only the document’s cryptographic hash is kept afterward, so authenticity can still be verified even once the underlying file is gone).

6. Your rights (including erasure requests)

Depending on where you live, you may have rights to access, correct, or request deletion of your personal data, and to object to certain processing.

If you have your own account (a registered user of the Service, not merely a recipient added to someone else’s document), you can close your account and erase your data yourself, at any time, from Settings → Security → “Close account / erase my data” — no need to contact us. Doing so anonymizes your name and email, removes your saved signature and two-factor setup, signs out every active session, and anonymizes your own recipient records (see below) on documents that have not yet been completed, across every workspace you appear in. If you are the only administrator of a workspace that has other members, you’ll be asked to transfer admin rights (or remove those members) first, so closing your account never strands your teammates without anyone able to manage that workspace.

If you were only added as a recipient (a signer or CC on someone else’s document, with no account of your own), contact the organization that sent you the document (the workspace account holder) or use the contact details below and we will route the request to them. That workspace administrator can also generate a copy of what we hold about you (an access request) directly from the product, alongside the erasure tooling described below. In practice, an erasure (“right to be forgotten”) request is handled like this:

  • For any document that has not reached the completed state, the workspace administrator can anonymize your recipient record (your name and email are replaced, and your signing link is disabled) — this is available to them directly, without engineering support.
  • For a document that has reached the completed state, the signed record cannot be deleted before its retention period expires, for the reasons explained in “Retention” above — this is the same reason a bank or notary cannot shred a signed, completed contract on request. We will confirm this in writing and explain when the retention period ends. If you believe you are legally entitled to earlier deletion in your specific circumstances, tell us and we will review it as a manual, individually-assessed exception rather than a self-service action.

7. Sub-processors & third parties

We use third-party providers to help operate the Service — for example, transactional email delivery and cloud object storage. These providers process data only on our instructions and under confidentiality obligations. Placeholder — list your production sub-processors here before launch.

8. International transfers

Placeholder — describe where data is hosted and, if applicable, the safeguards used for cross-border transfers (e.g. Standard Contractual Clauses) before production launch.

9. Security

We use industry-standard safeguards, including encrypted transport, hashed/salted passwords, hashed session tokens, per-workspace access controls, and rate-limited authentication. No method of transmission or storage is perfectly secure, and we cannot guarantee absolute security.

10. Children's privacy

The Service is not directed to children and is not intended for use by anyone under 16.

11. Changes to this policy

We may update this Privacy Policy from time to time. Material changes will be posted here with an updated effective date.

12. Contact

Privacy questions or data-subject requests can be sent to privacy@example.invalid (placeholder — replace with your organization’s real contact before launch).