In short
- Encryption in transit and at rest, and access limited to people who need it.
- Every completed document carries a SHA-256 hash and an event record.
- We notify customers of a personal data breach within 48 hours of confirming it.
- We welcome good-faith security research and will not take legal action against it.
Our approach
Security at inSigner is built into how the service is hosted, how access is granted, and how signatures are recorded. This page describes our measures in plain language. It is not a certification, and it lists the claims we do not make.
Infrastructure
inSigner runs on Cloudflare’s global network, with support from Amazon Web Services for some infrastructure and message delivery. These providers operate physically secured data centers and maintain their own independent security certifications. Cloudflare also protects the service against denial-of-service attacks and automated abuse.
Encryption
Connections to insigner.co, the workspace, the API, and signing pages use HTTPS with modern TLS. Documents and databases are encrypted at rest by the storage providers. Secrets and API keys are kept in managed secret storage, not in source code.
Access control
Access to production systems follows the principle of least privilege. People who operate the service use individual accounts, administrative access is protected with multi-factor authentication, and access is removed promptly when it is no longer needed. Staff see customer content only when their work requires it, for example to answer a support request the customer opened.
Application security
We review code before it ships, keep dependencies up to date, validate input, and use bot challenges and rate limits to protect sign-in, signing, and the API. Workspace roles let customers limit who can send, view, and manage documents.
Document integrity
A completed agreement carries a SHA-256 hash of the file and an ordered record of events, such as when it was sent, opened, and signed, with IP addresses and timestamps. A later reader can compare the file with the record to detect changes. That record is evidence of what the service observed. It is not a qualified certificate and not a statement that a particular law has been satisfied.
Monitoring and backups
We log security-relevant events, monitor for errors and abuse, and keep backups on a rolling cycle so the service can recover from a failure. Backups are overwritten within 90 days.
Providers
Before we use a provider that processes customer data, we review its security and sign written data protection terms. The current list is on the subprocessors page.
Incidents and breach notification
We follow an incident response process to contain, investigate, and fix security incidents. If a personal data breach affects customer data, we notify the affected customers without undue delay and within 48 hours of confirming it. Where Nubesti is the controller, we notify the competent authority within 72 hours where the GDPR requires it, and we tell the people affected when the risk to them is high or when another law requires it.
Claims we do not make
Nubesti does not claim SOC 2, ISO 27001, HIPAA, or PCI DSS certification for inSigner, and does not offer a finished regional data residency program. Payment card data is handled by PayPal and never reaches our systems. A standard signature is not a qualified electronic signature, and QES for Europe is an Enterprise option. We do not publish an uptime credit or a bug bounty amount.
Reporting a vulnerability
Send reports to [email protected] with the subject “Security”. Describe the issue, the page or endpoint involved, and the steps to reproduce it. Our security.txt file is at insigner.co/.well-known/security.txt. We confirm receipt, keep you informed, and credit you if you want once the issue is fixed.
If you act in good faith, respect these rules, and give us reasonable time to fix the issue before disclosing it, we will not take legal action against you or ask the authorities to. Please do not:
- Access, change, or delete another person’s documents or data. Use your own test accounts.
- Run denial-of-service tests, spam, or automated scans that degrade the service.
- Use social engineering or physical attacks against Nubesti, its staff, or its providers.
- Keep data you obtained beyond what is needed to show the issue.