Security at SDRclose

At a glance

• All traffic between your browser, our service and the providers we use is encrypted in transit.
• Mailbox credentials and access tokens are encrypted at rest and are never shown back in plain text.
• Passwords are stored only as salted hashes, and every new email address is verified before an account opens.
• Production data stores are not exposed to the public internet and are reachable only by the application.
• Payment card data is handled entirely by our payment processor and never touches our systems.
• Security issues can be reported through the contact form; we acknowledge and investigate every report.

What we hold and our role

SDRclose processes two kinds of data, and our role differs for each. Account data is the information you give us to run your workspace: your name, sign-in email, billing record, settings and usage. For this data we are the controller. Prospect data is the information you mine, import or research through the service, and the drafts, sent mail and replies that flow from it. For this data you are the controller and we are the processor, acting on your instructions under the Data Processing Addendum.

We also hold the credentials for the sending mailboxes you connect, such as Gmail or Google Workspace, Outlook or Microsoft 365, Zoho, and other IMAP/SMTP providers. Mail is sent from your own mailboxes; there is no shared sending pool, so no other customer's activity is ever attributed to your domain.

The controls described below apply to all of this data. The Privacy Policy explains what we collect and why, and the GDPR page covers the controller and processor split in more depth.

Encryption and credential protection

Every connection to SDRclose is encrypted in transit, including traffic from your browser, connections to your mailboxes, and calls to the providers that support the service. We do not accept unencrypted connections.

Mailbox passwords, app passwords and access tokens are encrypted at rest with keys that are held separately from the data they protect. Once saved, a credential is never displayed back in the interface, and it is redacted from the data export available in Settings > Privacy & Data. Personal data such as email addresses is masked in operational logs, so log output does not become a second copy of your prospect list.

Account passwords are never stored. We keep only a salted hash, which is excluded from the data export along with any other secret material.

Authentication and account security

You can sign in with a Google or Microsoft account, or with an email address and password. Social sign-in uses standard OpenID sign-in and receives only your name, email address and profile picture; we never see the password for that account, and the protections your identity provider enforces, such as multi-factor authentication, apply to your SDRclose sign-in.

Creating an account with an email address requires a one-time verification code sent to that address, so an account cannot be opened on an address you do not control. Sign-in, password and verification endpoints are rate limited and protected against repeated failed attempts. Sessions expire automatically after seven days or when you sign out.

Deleting an account requires you to re-enter your password. Deletion is irreversible and removes Customer Data from the live service, with the exceptions described in the Privacy Policy for opt-out records that we are required to retain.

The service currently provides one set of sign-in credentials per account. If you share access with colleagues, you remain responsible for controlling who can use it and for changing the password when someone should no longer have access.

Application and infrastructure security

Production data stores are not exposed to the public internet and are reachable only by the application. Administrative access to production systems is limited to authorized personnel over authenticated, encrypted channels.

Every endpoint validates its input against a defined schema before acting on it, and requests are scoped to the authenticated account so that one customer cannot read or modify another customer's data. Error responses returned to the browser do not reveal internal detail.

The web application ships with modern browser security headers that restrict where scripts and other content may load from and limit what the page may do in the browser.

Tokens issued for a specific purpose, such as the one-click unsubscribe link in an outbound email, are valid only for that purpose and cannot be used to sign in to an account.

Backups and operational resilience

We take routine encrypted backups of production data and retain them on a rolling basis so that the service can be restored after a failure. When you delete your account, the data is removed from the live service immediately; residual copies in backups are overwritten on a rolling basis and fall out of retention within 30 days.

The Status page runs a live check of the production service and its database connectivity. We do not yet publish uptime history. Support is provided by the SDRclose team by written message during business hours, in English. We do not currently offer a contractual SLA.

If we confirm a personal data breach affecting Customer Data, we notify affected customers without undue delay and, where feasible, within 72 hours after confirmation, with the detail set out in the Data Processing Addendum.

Payments

Card details are entered on our payment processor's hosted checkout and never touch SDRclose systems. We store only the information needed to run your subscription: your plan, billing status, and a reference to your customer record at the processor.

You manage or cancel your subscription from Settings > Billing, which opens the processor's hosted billing portal. Billing notifications we receive from the processor are authenticated before they change any account's plan or credit balance, so a forged or repeated event cannot alter your entitlements.

Personnel and access

Access to production systems and customer data is restricted to authorized personnel who need it to operate the service. That access is protected by strong authentication, granted on a least-privilege basis, and removed when it is no longer needed. Customer data is accessed for support only when necessary to resolve a request you have raised, or to protect the security and integrity of the service.

Before we engage a sub-processor, we review its security and privacy posture and its contractual commitments, and we bind it to data protection terms no less protective than those in our Data Processing Addendum. Those terms include confidentiality obligations and, for AI providers, a prohibition on using submitted data to train their models.

Sub-processors and AI providers

We use a small number of third parties to deliver the service. They fall into the following categories: infrastructure and hosting provider; payment processor; language-model and research providers; prospect data provider; scheduling and calendar provider; transactional email provider; professional advisers. The canonical list is maintained on the Sub-processors page, and the named list is available on request and as a schedule to the DPA.

We give at least 30 days' notice by email to the account address before a new sub-processor processes Customer Data, and you may object on reasonable data-protection grounds within that period. The full process, including your termination right, is set out in the Data Processing Addendum.

SDRclose uses language-model and research providers to research prospects from public web sources and to draft outreach. We use these providers only on terms under which submitted data is not used to train their models, and SDRclose does not train models on customer or prospect data. Generated drafts are held in your review queue until you approve them, unless you have switched on autopilot for that sequence.

Certifications and assurance

We do not currently hold third-party certifications. We answer security questionnaires and share our security documentation with prospective customers on request, under NDA where appropriate.

Our security documentation covers the controls described on this page in more detail, together with our data flows, sub-processor list and incident response process. To request it, or to send us a vendor assessment to complete, use the contact form and describe what your procurement process needs.

Vulnerability disclosure

We welcome reports from security researchers and customers. If you believe you have found a vulnerability in SDRclose, report it through the contact form and choose Security report as the topic so that it is routed to the right people. Please include:

• A description of the issue and the URL, feature or endpoint it affects.
• Steps to reproduce it, including any sample requests or screenshots.
• Your assessment of the impact: what an attacker could do with it.
• Whether the issue has been shared or published anywhere else.