This overview describes the technical and organizational measures that DDR Solutions Inc. ("DDR") uses to protect Senots and one2sign (the "Services") and Customer Data. It supports Annex 2 of the Data Processing Agreement. Capitalized terms have the meanings given in the Terms of Service.
We describe only what we do today. Where something is planned, we say so.
What we do not claim
DDR does not hold SOC 2, ISO 27001 or other security certifications, and has not had a third-party audit of the Services. one2sign does not apply a certificate-based (PKI) digital seal to signed PDFs. We will update this page if that changes.
1. Infrastructure and data location
- The Services run on Cloudflare: Workers for the application, D1 for the database, and R2 for files. Cloudflare's network provides content delivery, TLS termination and protection against denial-of-service attacks.
- We ask Cloudflare to place stored data in eastern North America. This is a placement request, not a residency guarantee. Requests are handled at the Cloudflare data centre nearest to the person connecting.
- Staging and production are separate environments, with separate databases and file storage. Changes are tested on staging before production.
2. Encryption
- All connections use HTTPS (TLS). HTTP Strict Transport Security is set for one year, including subdomains.
- Cloudflare encrypts the database and file storage at rest.
- Signing links and public template links are never stored in plain text in our database. We store a hash of each link to look it up, plus an encrypted copy (AES-256-GCM, with a key derived from a secret kept in Cloudflare's secret store, not in the database) so the sender can see and resend the link. Signing emails necessarily contain the link itself, so anyone who can read the recipient's mailbox can open it; an optional access code adds a second check.
- Email sign-in links are stored only as hashes, and email sign-in codes and access codes only as keyed hashes.
3. Keeping each company's data separate
- Customer data is separated by company. Requests from a signed-in person are limited to their company, using the company identifier from the signed-in session, never one supplied in 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 link itself identifies the record), the public Verify page, signed webhooks from our payment and email providers (Stripe and Resend), 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, so its existence is not revealed.
- Files are stored privately, with no public address, under company-specific keys. Every file read goes through the application's access checks.
4. Access inside a company
- Roles: owner, admin and member.
- Access per person and per app: for each app, no access, user, or (on most apps) admin.
- Built-in limits: salespeople see only their own opportunities unless they are CRM admins. Pay and personal details stay with HR admins and the employee. Managers and admins cannot approve their own time off or pay (owners can, so a small company never gets stuck). HR admins who are not owners cannot change their own pay or status.
- Search, timelines and notifications follow the same rules as the apps.
- Exports (downloading lists or reports as files) are limited to owners and admins, unless an owner or admin grants export to a named person.
5. Signing in
- No passwords. People sign in with a six-digit code or link we email them, or with Google or Microsoft.
- Email codes expire after 10 minutes, are stored only as keyed hashes, and are tied to the browser that asked for them. Attempts are limited.
- Google and Microsoft sign-in use OpenID Connect with state and PKCE protections.
- Session cookies are HttpOnly, Secure and SameSite=Lax, and last up to 30 days. People can sign out of all sessions.
- Two-step verification inside the Services is not offered today. Customers that use Google or Microsoft sign-in can require it in those accounts.
6. Application security
- State-changing requests are protected against cross-site request forgery.
- The web app builds pages from data as text, without inserting raw HTML, to prevent script injection.
- Uploads are checked for type and size, and PDFs are processed within fixed limits.
- Rate limits apply to sign-in, to the public signing pages and to the Verify page, per network and overall.
- Daily and hourly limits apply to e-signature sending, to protect Recipients and email deliverability.
- Secrets (keys and signing secrets) are kept in Cloudflare's secret store, never in source code.
7. one2sign
- Personal signing links. Each Recipient gets a random, secret link. A link that is handed on, corrected or canceled stops working.
- Optional access codes, stored as keyed hashes. The link locks after five wrong attempts until the sender unlocks it. SMS codes are planned, and will be offered if and when made available.
- Server-side rules. Signing order, roles (signer, approver, receives a copy, in person) and field rules are enforced on our servers, not only in the browser.
- Evidence. Each Document has an audit trail and, when completed, a Certificate of Signature that shows the SHA-256 fingerprint of the Document as sent. The fingerprint of the signed copy is kept in our records so the Verify page can check it. The signed copy carries a Verification Code, and the Certificate a QR code that opens the Verify page.
- Verify page. Anyone can check a signed PDF on the public Verify page. The file is fingerprinted in the person's own browser and never uploaded, and the answer names no people.
- Retention. Customers can delete closed Documents and set automatic deletion after 1 to 10 years, with a 7-day wait after the setting is turned on or shortened.
8. Our access to your data
- By default, our team cannot see inside your company.
- An owner or admin can grant support access for 1 to 72 hours, and withdraw it at any time.
- Each support session lasts at most 30 minutes within the granted window. A banner shows while support is inside, and support actions are recorded in your audit log.
- Without a grant, our operators see only account-level information, such as the company name, plan, status and usage counts. The operator console is limited to named DDR personnel and protected by Cloudflare Access.
9. Logging and monitoring
- An audit log in each company records changes to HR records, settings, access, tax settings, billing, support sessions and e-signature deletions. Owners and admins can see it.
- Sign-in history is kept for 90 days, with email addresses and IP addresses stored as keyed hashes.
- Scheduled jobs record each run, and failures are kept for review.
10. Change management
- Every release goes through a documented security gate review against a written checklist. The review is done separately from the work that built the change, and its findings and outcome are recorded before deployment. This is part of our own development process; it is not a third-party audit.
- Database changes are additive, numbered and applied once, in order.
11. Backups and recovery
- The database has point-in-time recovery for up to 30 days.
- Files rely on Cloudflare R2's built-in durability. Files are not copied to a separate backup, so a file deleted at a Customer's request cannot be recovered.
12. Incident response
We investigate suspected security incidents, contain them, and notify affected Customers without undue delay and within 72 hours of becoming aware of an incident affecting their Customer Personal Data, as described in Section 8 of the DPA.
13. Subprocessors
The third parties that process Customer Personal Data are listed in our Subprocessor list.
14. Our websites
Our marketing websites use no trackers, analytics or cookies, and load no fonts or scripts from other sites.
15. Reporting a vulnerability
Write to hello@one2sign.com with the subject line "Security report". The rules for good-faith research are in Section 7 of the Acceptable Use Policy.