// April 29, 2026

Security & Trust Center

Snap2Deploy connects to your Microsoft Intune and Jamf Pro tenants and handles installer files for the apps you deploy to your fleet. That makes us part of your endpoint-management control plane — a position we take seriously. This page is the single source of truth for how we protect that trust.

For more depth on specific topics: data handling & retention, required Intune/Jamf permissions, and how we use AI.

Encryption

  • In transit: All connections to Snap2Deploy use HTTPS with TLS 1.2 or higher. HTTP requests are automatically redirected to HTTPS. Connections to Microsoft Graph, the Jamf Pro API, Stripe, and our managed-database provider all use TLS.
  • At rest: Customer secrets that we store on your behalf (Intune client secrets, Jamf Pro API credentials) are encrypted with AES-256-GCM using a per-deployment encryption key managed by our application. The Postgres database itself is encrypted at rest at the cloud-provider level (Neon).
  • Passwords: User passwords are hashed with bcrypt (work factor 12). We never store, log, or transmit plaintext passwords.

Hosting

  • Application: Vercel, US region. Vercel is SOC 2 Type II audited and provides DDoS protection, edge caching, and automatic HTTPS via Let’s Encrypt.
  • Database: Neon Postgres, US region. Neon is SOC 2 Type II audited and provides encryption at rest, automated continuous backup, and point-in-time recovery.
  • Email delivery: Resend (transactional email provider). We use it for invitations, billing notices, and alerts only — never for sending marketing email without consent.
  • Payments: Stripe. Snap2Deploy does not see, store, or process credit card numbers; we receive only Stripe’s customer and subscription identifiers. Stripe is PCI DSS Level 1 certified.

Tenant isolation

Every customer is an Organization in Snap2Deploy — the unit of billing, integrations, and data ownership. Every record in the database is tagged with the organization it belongs to, and every API request is scoped to the caller’s organization on the server side. There is no path through the API that lets one organization read or modify another organization’s data.

Database queries are scoped at the application layer rather than via Postgres row-level security; this is a deliberate trade-off (it lets us use connection pooling efficiently). The scoping rule is enforced in our shared data-access library, audited route by route, and covered by integration tests.

Authentication

  • Email + password (the default), with email verification required before first login.
  • Session tokens: JSON Web Tokens (JWT), signed with HS256 and a rotated secret. Sessions expire automatically.
  • Password rules: minimum length, bcrypt-hashed server-side. Passwords are never logged.
  • Multi-factor authentication (MFA): available for all users on all plans. TOTP-based (RFC 6238) — works with Google Authenticator, Authy, 1Password, Microsoft Authenticator, and any standards-compliant authenticator app. Enrollment is self-serve from Settings → Security. Ten single-use recovery codes are issued at enrollment time for lost-authenticator situations.
  • SSO (SAML / OIDC): on the roadmap for the Enterprise plan; not yet generally available. If your organization requires SSO before purchase, email security@snap2deploy.com and we will discuss timing — typical lead time once an Enterprise contract is in place is one onboarding week.

Authorization & RBAC

Within each organization, users hold one of three roles:

  • Owner — the person who created the workspace. One per org. Can do everything an admin can do, plus transfer ownership and delete the workspace.
  • Admin — can manage integrations, billing, team members, Auto-Pilot configuration, and packages.
  • Member — can create and deploy packages, but cannot modify integrations, billing, or other team members. Members can disable a misbehaving Auto-Pilot monitor as a safety valve, but cannot re-enable or reconfigure it.

Destructive or org-shared actions (disconnecting MDM credentials, deleting a monitor, changing the subscription) are explicitly gated to admin and owner roles at the API layer. Ownership is transferable: an owner can promote any admin to owner and step down to admin, so a workspace survives employee turnover.

Audit logging

Sensitive actions write an entry to a per-organization audit log. Logged events include user invitations and removals, role changes, ownership transfers, MDM credential connections and disconnections, Auto-Pilot enable/disable, package deployments, and subscription changes. Audit logs include actor, action type, timestamp, IP address, and target resource. They are visible to admins via the Settings page and retained for the life of the organization.

Backups & recovery

  • Continuous backup: Neon’s Postgres engine provides point-in-time recovery (PITR) within a rolling window. Any point in that window can be restored to a new branch in seconds.
  • Recovery objective: our recovery point objective (RPO) is under five minutes; our recovery time objective (RTO) for a full database restore is under thirty minutes.
  • Disaster recovery: a written rollback playbook covers application rollbacks, database restores, single-customer data restoration, billing-sync issues, and environment-variable incidents.

Vulnerability disclosure

If you believe you have found a security vulnerability in Snap2Deploy, please email security@snap2deploy.com with a description of the issue and steps to reproduce.

  • Acknowledgement: we will acknowledge your report within two business days.
  • Triage: we will respond with our initial assessment and expected remediation timeline within five business days.
  • Disclosure: we ask that you give us a reasonable opportunity to remediate before publicly disclosing the issue. We will credit you (with your permission) when we publish a fix.
  • Safe harbor: we will not pursue legal action against good-faith researchers who follow this policy and avoid impacting other customers’ data.

Incident response

If we detect or are notified of a security incident affecting customer data, we will:

  • Investigate, contain, and remediate the incident as a top priority.
  • Notify affected customers without undue delay — and in any case within seventy-two (72) hours of confirming the incident — via the email address on file for your organization owner. The notification will describe what we know, what we don’t yet know, and what we’re doing about it.
  • Publish a post-incident report once root cause and remediation are confirmed.

AI & data use

Snap2Deploy uses AI to detect silent-install command-line switches from public installer metadata and to suggest detection rules. We do not send your installer binaries, your tenant data, your deployment history, or your packages to any AI provider for training. AI suggestions are always reviewable and require human approval before deployment. See /security/ai for the full disclosure.

Compliance roadmap

Snap2Deploy is currently a small, recently-launched company. We are not yet SOC 2 audited. Our compliance roadmap is:

  • Phase 1 — Today: security controls documented (this page), point-in-time backups in place, audit logging shipping, vulnerability disclosure published, incident response playbook written.
  • Phase 2 — SOC 2 Type I: formal control design audit, targeted within twelve months of our first paying enterprise customer.
  • Phase 3 — SOC 2 Type II: operating effectiveness audit over a continuous observation window, after Type I.

If your organization needs to see a security questionnaire response or a vendor due diligence packet before the SOC 2 audit completes, email security@snap2deploy.com and we will share what we have.

Subprocessors

Snap2Deploy uses a small number of third-party subprocessors to operate the service. The current list is published at /subprocessors and updated when we add or remove a vendor.

Contact