SurgeTK Security Overview

Encrypted everywhere: All traffic between your browser and SurgeTK uses HTTPS, and we enforce modern browser protections to block unsafe content and framing.

Strong account security: Email verification is required, two‑factor authentication (2FA) is enforced for ongoing access, and we throttle login and code‑entry attempts to stop brute‑force attacks.

Locked‑down storage: Customer files live in private Amazon S3 buckets with default server‑side encryption. Files are shared through short‑lived, expiring links; only basic profile photos are publicly readable.

Restricted database access: Our database is hosted on MongoDB Atlas and only reachable from approved network locations over encrypted connections. It is not open to the public internet.

Trusted infrastructure & vendors: We run on Heroku and rely on a short list of vetted providers — AWS (storage), MongoDB Atlas (database), Heroku Data for Redis (sessions and background jobs), Stripe (payments), Intercom (support), SendGrid (transactional email), and Sentry and New Relic (monitoring). Only Stripe and Intercom load within the customer's browser; the rest operate server-to-server only.

Email verification: New accounts must verify ownership of the email address using a short‑lived code before they can use the platform.

Two‑Factor Authentication (2FA): After your initial access, we require an authenticator‑app code in addition to your password for ongoing sign‑ins. This reduces the risk of account takeover even if a password is guessed or phished.

Smart rate limiting: We limit how often someone can try passwords, 2FA codes, or verification codes. This slows down attackers without getting in your way during normal use.

Protected cookies: Sign‑in cookies are set to be sent only over HTTPS and are not readable by scripts, and we automatically end sessions after a period of time.

Always‑on HTTPS: Connections to SurgeTK are encrypted in transit, and we tell browsers to only ever use secure connections when talking to our site.

Strict website rules: We limit what can run on our pages and which sites our app can connect to. In plain terms: the app only loads scripts and frames from a small list of trusted providers, which sharply reduces the risk of malicious content.

Private by default: Customer documents and exports are stored in private Amazon S3 buckets and are not directly accessible. When the app needs to show a file, it uses a short‑lived, expiring link that only works for a few minutes.

Encryption at rest: S3 applies server‑side encryption to your files by default. We also require secure (HTTPS) access to these buckets.

Tight sharing rules: Only basic profile/avatar and logo images are publicly readable—and only in a specific, limited folder. We also restrict which websites are allowed to load files from our storage.

Approved‑only access: Our MongoDB Atlas database is reachable only from allow‑listed network locations (e.g., our app’s egress) and requires encrypted connections. There is no broad “open to the world” access.

Hardened hosting: SurgeTK runs on Heroku. Outbound traffic uses fixed, known IPs to keep our database access rules precise.

Sign‑in awareness: When you sign in, we record basic details (like device and approximate location) to help detect unusual activity and respond quickly if something looks off.

Noise‑free logging: If someone exceeds our allowed number of attempts (login, 2FA, or code verification), we both block the request and record a high‑severity event for review.

Explicit opt-in: CRM integrations are disabled by default and only activate when an authorized user connects them.

Scoped access: We request only the permissions required to read the client and account data needed for SurgeTK features.

Encrypted transport: All data pulled from Redtail and Zoho is transmitted over encrypted HTTPS connections.

Encrypted credentials at rest: Zoho uses OAuth, so we never see or store your password — only short-lived access tokens we can refresh on your behalf. Redtail requires a username and password to authenticate; those credentials are encrypted at rest using AES-256-GCM, an authenticated encryption standard, and are never visible to SurgeTK personnel in plain text.

Read-focused usage: CRM data is used to populate and update records inside SurgeTK. We do not push changes back to your CRM.

Revocable at any time: You can disconnect Redtail or Zoho at any point from your settings, immediately stopping further syncs.

Meeting title, date, time, duration, and basic metadata

Host and invitee identifiers needed to associate meetings correctly

No payment details, messages, or unrelated Calendly data

Limited scope: Calendly access is restricted to reading meeting and scheduling data required for Surge features.

Encrypted connections: All Calendly data is fetched over secure HTTPS connections.

Isolation from CRM data: Calendly data is handled independently and is not mixed with CRM credentials or permissions.

User-controlled: You can disable Calendly syncing at any time, which immediately stops new meeting imports.

No card data stored by SurgeTK: Payment information is collected and processed directly by Stripe. SurgeTK never sees or stores full credit card numbers.

Tokenized payment flow: Stripe returns short-lived, non-sensitive tokens to represent payment methods.

Encrypted transport: All payment activity occurs over encrypted HTTPS connections.

Allow-listed resources only: Stripe scripts and endpoints are allowed to load only where required for secure checkout and billing management.

Industry-standard compliance: Stripe maintains PCI-DSS compliance for payment processing.

Secure mode enabled: Intercom runs in secure mode, meaning SurgeTK generates a signed, time-limited identity token so Intercom can verify the user without accessing passwords or session cookies.

No credential sharing: Intercom never receives your SurgeTK password or authentication secrets.

Scoped data exposure: Only basic account and workspace identifiers are shared so support can assist you effectively.

Allow-listed loading: Intercom is one of a very small number of third-party services permitted to load inside the SurgeTK application.
​

Scoped data: Only the recipient address, subject, and message content needed to deliver each email are sent to SendGrid.

Encrypted transport: All email content is transmitted to SendGrid over encrypted HTTPS connections.

Transactional only: SendGrid is used solely for transactional messages — never for marketing, promotional, or unrelated communications.

Industry-standard compliance: SendGrid (owned by Twilio) maintains SOC 2 Type II and ISO 27001 attestations for its infrastructure.

Scrubbed at source: Personally identifiable information is scrubbed from error data before it is sent to Sentry.

Telemetry only: Sentry receives application error context and stack traces — never customer records, uploaded files, or report content.

Encrypted transport: All error data is sent to Sentry over encrypted HTTPS connections.

Industry-standard compliance: Sentry maintains SOC 2 Type II attestation for its infrastructure.

Metrics only: New Relic receives performance metrics such as response times, throughput, and infrastructure health — never customer records, uploaded files, or report content.

No personal data: Personally identifiable information is not transmitted to New Relic.

Encrypted transport: All telemetry is sent to New Relic over encrypted HTTPS connections.

Industry-standard compliance: New Relic maintains SOC 2 Type II and FedRAMP attestations for its infrastructure.

Operational use only: Redis holds ephemeral session, queue, and coordination data — not the authoritative copy of any customer record.

Approved-only access: Our Redis instance is reachable only from our application's allow-listed network locations.

Encrypted transport: All connections to Redis are encrypted in transit.

Short-lived data: Session and queue entries expire automatically once their purpose is served.

Blocked by default: SurgeTK blocks third-party scripts, frames, and resources unless they are explicitly approved.

Short allow-list: Only vetted providers (including Stripe and Intercom) are permitted to load, and only in the contexts where they are required.

Ongoing review: We periodically review third-party integrations to ensure they continue to meet our security and privacy standards.