Technical Security Practices

This page is a good-faith effort to inform you about our security posture. It is not a comprehensive disclosure of all controls, and some details are intentionally omitted to avoid exposing implementation specifics that could be exploited. Nothing on this page constitutes a warranty or guarantee.

1. Organizational Security

Security starts with the people who operate the Service. Dispatch maintains the following organizational controls:

• Principle of least privilege — Team members are granted only the minimum access needed to perform their role. Internal systems enforce role-based access controls, and access is reviewed when roles change.
• Multi-factor authentication — MFA is required on all internal administrative systems, cloud provider consoles, and third-party services where the feature is available.
• SSH key authentication — Password-based SSH login is disabled on all servers. Access requires cryptographic key pairs, and keys are rotated when personnel leave or change roles.
• Encrypted devices — All company devices capable of accessing production systems or customer data use full-disk encryption.
• Security training — All team members with access to customer data or production systems receive annual security and data-privacy training covering phishing, social engineering, and incident reporting.
• Access logging and auditing — Administrative access to production data is logged. Logs are retained and reviewed periodically.
• Off-site key storage — Credentials, certificates, and secret keys are stored in dedicated secrets management systems, not on individual machines or in source code.
• Policy reviews — Security and data handling policies are reviewed at least annually and updated as threats or regulations evolve.

2. Application Security

The Dispatch application is built with security as a design requirement, not an afterthought:

• HTTPS everywhere — All pages, API endpoints, and asset URLs are served over HTTPS. HTTP requests are redirected to HTTPS, and HTTP Strict Transport Security (HSTS) is enforced.
• CSRF protection — All state-mutating requests (forms, API calls) require a verified CSRF token. This prevents cross-site request forgery attacks.
• Input validation and sanitization — All user-supplied input is validated server-side before processing or storage. We rely on parameterized queries and ORM abstractions to prevent SQL injection.
• Output encoding — User-supplied content is context-appropriately encoded before rendering to prevent cross-site scripting (XSS) attacks.
• Secure session management — Sessions use cryptographically random identifiers, are invalidated on logout, and expire after periods of inactivity. Session cookies are set with HttpOnly, Secure, and SameSite attributes.
• Dependency scanning — Third-party libraries are regularly reviewed for known vulnerabilities. We track security advisories for all dependencies and apply patches promptly.
• Rate limiting — Authentication endpoints, API routes, and other sensitive actions are rate-limited to reduce the impact of brute-force and credential-stuffing attacks.
• Content Security Policy — We implement Content Security Policy headers to restrict what resources browsers may load, reducing the surface area for injection attacks.

3. Infrastructure Security

Our server and cloud infrastructure is hardened and actively monitored:

• Minimal attack surface — Network firewall rules restrict inbound traffic to only the ports and protocols required by the Service. Administrative ports are not exposed to the public internet.
• Timely patching — Operating systems and server software receive security updates as soon as they are available. We subscribe to vulnerability notification feeds for all components we operate.
• DDoS mitigation — The Service is protected by Cloudflare's global anycast network, providing distributed denial-of-service mitigation, bot management, and web application firewall (WAF) capabilities.
• Monitoring and alerting — Infrastructure metrics, error rates, and security events are monitored continuously. Automated alerts notify on-call staff of anomalies in real time.
• Stateless architecture — Application servers are stateless by design. This limits data exposure in the event of a server compromise and enables rapid failover without data loss.
• Environment separation — Production, staging, and development environments are isolated. Production data is never used in non-production environments.
• Backup infrastructure — Critical configuration and infrastructure definitions are maintained as code and can be redeployed across multiple cloud providers if necessary.

4. Data Security

We apply layered controls to protect data at rest and throughout its lifecycle:

• Encryption at rest — Databases, file storage volumes, and backup archives are encrypted at rest using industry-standard algorithms (AES-256 or equivalent).
• Encrypted backups — All backups are encrypted before being written to storage. Backup integrity is tested periodically through restoration drills.
• Data minimization — We collect only the data necessary to operate the Service. Data no longer needed is deleted or anonymized in accordance with our Privacy Policy.
• Access controls — Database access is restricted to application service accounts with scoped permissions. Direct human access to production databases requires additional authentication and is logged.
• Secure deletion — When you delete your account or content, data is removed from active systems and purged from backups within the retention windows described in our Privacy Policy.
• Payment card data — Dispatch does not store, process, or transmit raw payment card data. All payment processing is handled by Stripe, which is PCI DSS Level 1 certified.

5. Data in Transit

All data moving between your browser, our application servers, and our infrastructure is encrypted in transit:

• TLS 1.2 and 1.3 — We support only modern TLS versions. Legacy protocols (SSLv3, TLS 1.0, TLS 1.1) are disabled. Cipher suites are configured to prefer forward-secrecy key exchanges.
• Valid certificates — TLS certificates are issued by trusted certificate authorities, auto-renewed before expiry, and monitored for validity.
• Internal service communication — Traffic between internal services and databases travels over encrypted connections, even within the same private network.
• Audio file delivery — Podcast audio files are served over HTTPS. We do not serve content over unencrypted HTTP connections.

6. Third-Party Providers

We rely on a small number of carefully selected third-party providers. We evaluate each provider's security posture before integration and periodically thereafter:

• Stripe (payment processing) — PCI DSS Level 1 Service Provider. Stripe handles all cardholder data; Dispatch never receives raw card numbers. Stripe Security
• Cloudflare (CDN, DDoS protection, WAF) — SOC 2 Type II certified. Processes traffic at the network edge before it reaches our origin infrastructure. Cloudflare Compliance
• Amazon Web Services (cloud infrastructure) — ISO 27001 certified, SOC 1/2/3 audited. Our infrastructure runs in AWS regions with physical and logical security controls documented in the AWS Shared Responsibility Model.
• AssemblyAI (AI transcription) — Audio submitted for transcription is transmitted over encrypted channels. Data handling is governed by our Data Processing Agreement with AssemblyAI.

We do not sell, share, or rent your data to third parties for advertising or marketing purposes. See our Privacy Policy for details on data sharing.

7. Incident Response

Despite best efforts, security incidents can occur. Dispatch maintains a documented incident response process:

• Detection — Automated monitoring and alerting surfaces anomalous activity to on-call staff around the clock.
• Containment — Upon identifying a confirmed incident, we act immediately to isolate affected systems and prevent further exposure.
• Notification — If a security incident results in unauthorized access to your personal data, we will notify affected users and, where required by law, the relevant regulatory authorities within the timeframes required by applicable law.
• Post-incident review — After each incident we conduct a root-cause analysis, implement corrective controls, and update our procedures to prevent recurrence.

8. Vulnerability Disclosure

We welcome reports from security researchers who discover potential vulnerabilities in the Service. If you believe you have found a security issue, please contact us before disclosing it publicly:

• Email: [email protected]
• Please include a clear description of the vulnerability, steps to reproduce it, and the potential impact.
• We will acknowledge your report within 3 business days and keep you informed of our progress toward a fix.
• We will not take legal action against researchers who report vulnerabilities in good faith, follow responsible disclosure practices, and do not access, modify, or delete user data beyond what is necessary to demonstrate the issue.

We ask that you refrain from public disclosure until we have had a reasonable opportunity to investigate and remediate the issue.

9. Contact Us

For security-related questions or concerns, contact us at:

• Email: [email protected]
• Web: dispatch.fm/contact
• Mail: Dispatch FM, LLC, c/o Legalinc Corporate Services Inc., 131 Continental Dr Suite 305, Newark, Delaware 19713