Security at Brandmerch

Customers trust Merch OS with their brand assets, their people’s addresses, and their spending. This page describes the controls we operate to protect that data. It reflects what is in place today, not what is planned.

Last updated: August 2026

Hosting and infrastructure

Merch OS is a hosted service running entirely on managed cloud platforms. Brandmerch operates no physical servers, data centers, or office networks. Our application runs on Render, our frontend on Vercel, and we use Amazon Web Services for object storage, content delivery, and audit logging. Each of these providers maintains its own independent security attestations, which we review at least annually as part of vendor management.

  • One supported version — the one running in production. Security fixes reach all customers at once; there are no self-hosted or legacy releases.
  • Production databases are on private networking and are not exposed to the public internet.
  • Object storage buckets are private. Files are served only through our CDN using origin access control; direct storage access is denied.

Encryption

  • All traffic to and from our applications is encrypted in transit using TLS. Plain HTTP requests are redirected to HTTPS, and we publish a two-year HTTP Strict Transport Security policy covering subdomains.
  • Customer data is encrypted at rest by our database and object storage providers.
  • Employee workstations use full-disk encryption, verified continuously through device monitoring.

Payments

Card payments are processed entirely by Stripe, a PCI DSS Level 1 service provider. Card numbers are never transmitted to or stored on Brandmerch systems. Payment webhooks are cryptographically signature-verified before they are processed.

Access control

  • Access to customer data is role-based and granted on a least-privilege basis; administrative functions are restricted to platform administrator roles.
  • Two-factor authentication is required for all members of our source code organization.
  • Access is provisioned at hire based on role and revoked the same business day on departure, following a documented termination checklist.
  • Workstations require a password on wake and lock automatically after a period of inactivity.

Secure development

Every production change is made through a pull request into a protected branch. No one — including administrators — can push directly to production code.

  • Eight automated checks must pass before a change can merge: backend and frontend builds, linting, type checking, automated tests, and a dependency security audit.
  • Static application security testing runs on every pull request using GitHub CodeQL.
  • Dependencies are continuously scanned for known vulnerabilities with GitHub Dependabot, and security updates are applied on severity-based timelines.
  • Secret scanning with push protection is enabled, which blocks credentials from being committed to our repositories.
  • Development and testing run in environments logically separated from production, with separate databases.

Independent security testing

In August 2026 we commissioned an external, unauthenticated black-box security assessment of brandmerch.com by an independent offensive security firm. The assessment crawled 285 URLs across 76 test classes and 179 detected injection points. It returned no critical, no high, and no medium severity findings, and one low-severity configuration finding. We repeat independent testing periodically and expand scope over time.

Monitoring and logging

  • Infrastructure API activity is recorded to an immutable audit log.
  • Application errors and anomalies are captured through continuous error monitoring.
  • Access logs record application requests in production.

Resilience and backups

Our production database is backed up continuously by our hosting provider with point-in-time recovery. Restore procedures are documented in an internal runbook, and our recovery capability has been exercised against real production data rather than assumed.

Incident response

We maintain a documented incident response plan covering identification, containment, resolution, and post-incident root cause analysis. Where an incident affects customer data, we notify affected customers in line with our contractual commitments and applicable law.

Compliance

Brandmerch is actively working toward SOC 2 Type II. We use continuous compliance monitoring to track our controls, and our subprocessors maintain their own independent security attestations. We are happy to discuss our current status and share available documentation with prospective customers under NDA.

Reporting a vulnerability

We welcome reports from security researchers and treat them seriously. Our full vulnerability disclosure policy — including scope, ground rules, and our commitment not to pursue good-faith researchers — is published in the Legal Center, and our machine-readable contact file is at /.well-known/security.txt.

Security questions from customers or prospects, and vulnerability reports, both go to security@brandmerch.com.