Security & Trust Centre — how we protect your data and your documents.
SalesSign treats eSignature security as foundational, following recognised security practices to protect your data and documents. SalesSign is a Salesforce-native proposal and eSignature platform. This page explains, in plain English, how our service is built and operated, where your data lives, and the controls we use to keep it safe — so security, procurement and legal reviewers can assess us with confidence.
Three principles behind how we build and run SalesSign.
Your data stays in your org
Your proposals, signed documents and CRM records live inside your own Salesforce org, under your existing Salesforce controls. SalesSign is native to that org rather than a place we copy your data to.
Encrypted and least-privilege
Data is encrypted in transit and at rest, access is granted on a need-to-know basis, and administrative access uses single sign-on with multi-factor authentication.
Secure by design, tested over time
Security is part of how we ship: dependency and vulnerability scanning in our pipeline, code review, and periodic independent testing rather than a one-off checkbox.
Security at SalesSign — the detail.
The sections below describe our security posture at a high level. Where a figure or status still needs to be confirmed by the business, you will see a clearly marked placeholder rather than an unverified claim.
1. Architecture & data separation
SalesSign is made up of three distinct parts, and it helps to understand how they relate:
- The marketing website (this site, salessign.io) is a standalone website. It does not hold customer proposal content or signed documents.
- The SalesSign application is the service that powers document generation, sending and eSignature workflows. It runs in its own, separately hosted environment.
- Your Salesforce org is where your proposals, signed documents and CRM data live. Because SalesSign is Salesforce-native, that content remains under your own Salesforce org’s security model, sharing rules and audit trail.
These three are operated as separate environments. The marketing site and the application are hosted independently of one another, and neither is a substitute for your own Salesforce org as the system of record for your customer data.
2. Encryption
- In transit: traffic to our application and APIs is encrypted using TLS 1.2 or higher.
- At rest: data stored by the application — including databases and object storage — is encrypted at rest.
3. Access control, least privilege, SSO & MFA
- Access to production systems is restricted to authorised personnel on a least-privilege, need-to-know basis, and is reviewed periodically.
- Administrative and internal-tool access is protected by single sign-on (SSO) with multi-factor authentication (MFA) enforced.
- Within your own data, access is governed by your Salesforce org’s permissions, profiles and sharing rules — SalesSign does not bypass them.
4. Secure development lifecycle
- Changes go through version control and code review before release.
- Our pipeline runs automated dependency scanning to flag known-vulnerable libraries, and vulnerability scanning of our application and infrastructure.
- We commission periodic independent penetration testing. continuously through automated scanning, with penetration testing carried out annually and following significant changes
5. Data retention & deletion
Because your documents and CRM data live in your own Salesforce org, your retention and deletion of that content is governed by your Salesforce data-management policies. For any operational data the SalesSign application holds to deliver the service, we retain it only as long as needed to provide the service and meet legal obligations, and delete or anonymise it after that. Specific retention periods and the deletion process are set out in our Data Processing Agreement: see DPA. for the life of your subscription; on termination it is deleted within 30 days and purged from backups within 90 days
6. Backup & disaster recovery
The application’s data stores are backed up regularly, and we maintain a disaster-recovery process designed to restore service in the event of a major failure. Backups are encrypted and access to them is restricted.
- Recovery Time Objective (RTO): defined in our internal disaster-recovery plan and available to enterprise customers under NDA
- Recovery Point Objective (RPO): minimised through continuous, point-in-time AWS Aurora backups; specific targets available under NDA
7. Incident response & breach notification
We maintain an incident-response process covering detection, triage, containment, remediation and post-incident review. In the event of a personal-data breach affecting your data, we will notify you without undue delay so you can meet your own regulatory obligations, and we will work with you on the facts and remediation. The contractual specifics — including notification timeframes — are set out in our DPA.
8. Compliance & eSignature validity
SalesSign eSignatures are designed to comply with ESIGN and UETA in the United States, and eIDAS and the UK Electronic Communications Act 2000 in the UK and EU. For our wider compliance posture and certifications status, see Compliance.
Last updated: 3 June 2026
Everything a reviewer needs, in one place.
Data Processing Agreement
Controller/processor terms, sub-processor handling, breach notification and data-subject rights.
Read more →LegalSub-processors
The third parties we use to deliver the service, and what each is used for.
Read more →SecuritySecurity Policy
Our internal security policy and responsible-disclosure process for reporting issues.
Read more →TrustCompliance
Standards, frameworks and certifications status relevant to procurement and legal review.
Read more →TrustAccessibility
How we approach accessibility across the SalesSign product and this website.
Read more →StatusSystem Status
Live uptime and incident history. https://salessign.instatus.com/
View status →Security contact
For security questions, vulnerability reports or to request our security documentation, contact our security team at admin@salessign.io. Procurement and legal reviewers are welcome to request the DPA and supporting materials through the same address.
Frequently asked questions.
Where does our data actually live?
Your proposals, signed documents and CRM records live in your own Salesforce org, under your existing Salesforce security model. SalesSign is native to that org rather than a separate place we copy your data to. The SalesSign application holds only the operational data needed to deliver the service.
Is data encrypted in transit and at rest?
Yes. Traffic is encrypted with TLS 1.2 or higher in transit, and data stored by the application is encrypted at rest, including backups.
Do you use SSO and MFA internally?
Yes. Administrative and internal-tool access uses single sign-on with multi-factor authentication enforced, and production access is granted on a least-privilege, need-to-know basis and reviewed periodically.
Have you passed the Salesforce AppExchange Security Review?
SalesSign is currently undergoing Salesforce’s AppExchange Security Review. We will update this page once that review is complete.
Do you carry out penetration testing?
We commission periodic independent penetration testing alongside automated dependency and vulnerability scanning in our pipeline. The exact cadence and most recent test date are noted as items to confirm above.
What happens if there is a data breach?
We maintain an incident-response process and, in the event of a personal-data breach affecting your data, will notify you without undue delay so you can meet your own regulatory obligations. The contractual specifics are set out in our DPA.
Can we get a copy of your DPA and security documentation?
Yes. Request them from our security contact above, or start with the DPA, Sub-processors register and Compliance pages.
See SalesSign in your own Salesforce org.
The best way to assess fit — security included — is to see it work where your data already lives. Book a walkthrough and bring your security questions.