1. Security philosophy
Paravane builds the smtpRS API, dashboard, billing flows, and related Services for developers and businesses that rely on reliable risk signals, secure APIs, and responsible data handling. This Security Overview summarizes the safeguards Paravane uses and continues to mature to protect customer data and maintain service reliability.
Security is a shared responsibility. Paravane protects the Services and its infrastructure; customers are responsible for protecting their accounts, API keys, systems, integrations, logs, downstream data, and decisions based on Service outputs.
2. Data handled by the Services
Depending on configuration, Paravane may process account data, email verification and password reset metadata, session metadata, API key metadata, billing and subscription metadata, support communications, API request metadata, usage events, submitted identifiers such as email addresses, domains, IP addresses, user-agent strings, and scoring outputs. Customers should submit only the data needed for their permitted use case.
Unless separately agreed in writing, the Services are not designed to process protected health information, full payment card data, government ID numbers, financial account numbers, precise geolocation, children's data, or special-category/sensitive personal data.
3. Technical and organizational controls
| Control area | Summary |
|---|---|
| Encryption in transit | Paravane uses HTTPS/TLS for traffic to the Services. Customers should call APIs only over HTTPS and should not transmit API keys or personal data over insecure channels. |
| Encryption at rest | Paravane uses infrastructure-supported encryption or equivalent protections for production systems that store Customer Personal Data where supported by the relevant provider and configuration. |
| Access controls | Production access is intended to be limited to authorized personnel with a business need. Administrative access should follow least-privilege principles. |
| Authentication | Customer accounts use email/password authentication, email verification, password reset flows, and server-side session handling where the dashboard is enabled. Administrative systems should use strong authentication and MFA where available. Customer-facing MFA and SSO/SAML are not available unless separately offered or agreed. |
| API key management | Customers can be issued API keys or tokens for integration. Keys are generated server-side, shown only when appropriate, stored in hashed or otherwise protected form where feasible, kept secret by customers, rotated periodically, and revoked immediately if exposed. |
| Logging and monitoring | Paravane uses logs, usage events, and operational monitoring for reliability, debugging, billing/entitlement enforcement, abuse prevention, security, and performance. Logs may include request metadata, API key identifiers or prefixes, and account/session events. |
| Abuse prevention | Rate limits, usage monitoring, suspicious activity detection, WAF/CDN controls, email verification, Turnstile checks, and account reviews may be used to prevent abuse and protect availability. |
| Backups and recovery | Paravane maintains backups and recovery procedures appropriate to the Services, with retention generally targeted at approximately 30 to 90 days unless otherwise required. |
| Dependency and patch management | Paravane tracks dependencies, applies security updates based on severity and exposure, and monitors for vulnerabilities in third-party components. |
| Secure development | Code review, secrets management, environment separation, migration review, webhook signature verification, configuration review, and deployment controls are used based on risk and company maturity. |
| Vendor management | Subprocessors are reviewed for security and privacy fit and bound by appropriate data protection terms. |
| Incident response | Paravane maintains a process for triaging, investigating, mitigating, documenting, and notifying customers of security incidents. |
4. Customer security responsibilities
Customers should:
- Keep API keys, passwords, tokens, and credentials secret and out of client-side code, public repositories, logs, screenshots, and support tickets unless redacted.
- Use separate API keys for environments and rotate keys when employees leave, vendors change, or exposure is suspected.
- Restrict dashboard and API access to users with a legitimate need.
- Validate and sanitize data submitted to and received from the Services.
- Apply appropriate human review and downstream controls before taking action based on risk scores or outputs.
- Monitor usage for anomalies, unexpected spikes, integration errors, and failed requests.
- Delete or minimize exported data, logs, and outputs when no longer needed.
- Report suspected vulnerabilities or unauthorized access promptly to Paravane.
5. Incident reporting
Report suspected vulnerabilities, exposed API keys, unauthorized access, abuse, or security concerns to security@paravane.io. Include relevant timestamps, endpoints, account identifiers, request IDs, logs, and reproduction steps where safe to provide. Do not include secrets or sensitive personal data unless necessary and encrypted.
Paravane will review reports, prioritize based on severity and exploitability, and take appropriate remediation steps. Paravane may contact customers if a confirmed security incident affects their Customer Personal Data or Account.
6. Data retention and deletion
Paravane aims to retain data only as long as needed for service operation, security, billing, support, compliance, and legitimate business purposes. API request log retention, payload retention, security log retention, backups, and support-ticket retention are reviewed as the Services mature.
| Data area | Retention note |
|---|---|
| API request metadata | Approximately 90 days by default for ordinary API request metadata and usage events, unless a different period is required for security, abuse prevention, debugging, billing, legal claims, compliance, or a customer agreement. |
| Full API payloads | Not stored by default where feasible. Temporary storage should be limited to debugging, support, security investigation, or customer-enabled features, with minimization, redaction, and deletion controls where practicable. |
| Security logs | Approximately 1 year by default for security logs and abuse investigation records, with longer retention where needed for active investigations, legal claims, compliance, or enforcement. |
| Backups | Approximately 30 to 90 days, after which backups are overwritten or deleted in the ordinary course unless longer retention is required. |
| Support tickets | Approximately 3 years after resolution or account closure, unless a shorter period applies, deletion is requested, or retention is needed for legal, security, or compliance reasons. |
| Billing records | 7 years, or another legally required accounting, tax, audit, or compliance period. |
| Authentication/session records | Retained for the active session or operational security period, with longer retention only where needed for abuse prevention, account recovery, investigation, legal claims, or compliance. |
| API key records | Retained while active and for a reasonable audit period after revocation or account closure. Secret key material should not be stored in plaintext where avoidable. |
7. Compliance status
Paravane is building its security program with reference to common SaaS security practices and customer needs. Paravane has not completed SOC 2, ISO 27001, HIPAA, PCI DSS, or similar formal certifications unless expressly stated in a signed agreement or updated public notice. Formal certifications will be listed here if and when available.
8. Security roadmap
| Item | Status |
|---|---|
| Customer MFA | Not currently available for customer accounts; planned for a later dashboard release. |
| SSO/SAML | Not currently available unless separately agreed for an enterprise engagement. |
| Role-based access control | Planned and expected to be plan-specific as the dashboard matures. |
| SOC 2 Type I/II | Not currently completed; no public completion date. |
| Independent penetration test | No independent penetration test is published unless separately documented. |
| Vulnerability disclosure policy | Contact-only initially through security@paravane.io; a public vulnerability disclosure policy may be added later. |
| Regional data hosting | Not currently offered as a standard self-service feature; may be discussed for enterprise engagements. |
| Customer-configurable retention | Available on request / contact-only initially; broader self-service controls may be added as enterprise readiness matures. |
9. Contact
Security questions and vulnerability reports: security@paravane.io. Privacy questions: privacy@paravane.io. Legal notices: legal@paravane.io. General information requests: contact@paravane.io. Mailing address: 11166 Fairfax Blvd Suite 500 #1378, Fairfax, VA 22030, United States; Phone: (703) 972-1286.