Security
Last updated: August 20, 2026
Go Custom Merch stores inventory, order and recipient data on behalf of business clients through our Client Portal. This page describes how that data is protected, who can reach it, and where our compliance program currently stands. We would rather be accurate than impressive — where something isn’t in place yet, it says so.
Infrastructure
The Portal is a hosted application running on Vercel, backed by a managed PostgreSQL database at Neon in a US East region. We operate no on-premise servers and no self-managed databases. Both providers maintain their own independent security programs and third-party audits.
Database backups are managed by Neon, including point-in-time recovery. Application deployments are automated from version control, so every change is attributable to a commit.
Encryption
All traffic to and from our sites is encrypted with TLS. HTTP Strict Transport Security is enforced with a two-year max-age, applied across subdomains and submitted for preloading, so browsers refuse to connect over plain HTTP.
Data at rest — including the Portal database and its backups — is encrypted by our infrastructure providers using industry-standard algorithms.
Access control
Portal access is role-based. Each client organization is isolated: a user authenticated to one client cannot read or modify another client’s catalog, inventory, orders or recipients. Authorization is enforced server-side on every action, not merely hidden in the interface.
Within a client, admins manage the catalog, team and settings; members can place orders and see only their own. Optional approval routing lets a client require an admin’s sign-off before a member’s order enters fulfillment.
Internal Go Custom Merch administrative access is limited to staff who need it to operate the service, and is granted through the same authenticated system rather than direct database access.
Payment data
We never collect, transmit or store payment card data. The Portal contains no card fields and no payment processor. Clients are invoiced directly and pay outside the platform, so cardholder data never touches our systems.
What we hold, and why
For Portal clients we store business contact details, product and inventory records, orders, and the shipping details required to deliver them — recipient name, address, and where a client supplies one, an email address for delivery notifications. We collect what is needed to fulfill and support orders, and nothing further.
Recipient data supplied by a client is processed on that client’s behalf and is never sold, rented, or used to market to those recipients. Shipping addresses are shared with the carrier selected for that shipment, which is what allows the package to be delivered.
Order and shipment records are retained for as long as the client relationship continues, because they form the client’s own order history and billing record. Clients may request export or deletion of their data at any time — see our privacy policy. We do not currently operate an automated retention-expiry schedule; deletion is performed on request.
Application security
Security response headers are enforced across the site, including a Content Security Policy, X-Content-Type-Options, X-Frame-Options, a restrictive Permissions-Policy, and Referrer-Policy. The Portal is served under its own stricter policy and is excluded from search indexing.
Database access uses parameterized queries throughout, and operations that move inventory or money run inside transactions with row-level locking so concurrent actions cannot corrupt stock counts or billing records. Secrets are held in environment configuration, never in source control.
Dependency and vulnerability management
Third-party packages are the most common way a web application inherits a vulnerability, so we treat them as part of the attack surface rather than an implementation detail. Automated dependency scanning runs against the repository and opens a pull request when a package we depend on is affected by a published advisory. Non-breaking security updates are applied promptly.
Where an advisory can only be resolved by a major framework upgrade, we track it rather than silently carry it, and we distinguish between packages that execute in the live application and those used only in local build tooling — the two carry very different risk. We are happy to walk a prospective client through our current dependency posture, including what is outstanding and why.
Attack surface
The application is serverless. There are no long-running servers we administer, no SSH access, and no shell for an attacker to reach — application code runs in short-lived, isolated execution environments managed by our hosting provider, and the database is a managed service. This removes whole categories of risk that come with self-hosted infrastructure: unpatched operating systems, exposed management ports, and long-lived credentials sitting on a box.
Application errors are captured by Sentry, giving us visibility into failures in production rather than relying on a client to report them.
Subprocessors
These are the third parties that may process client or recipient data on our behalf. We publish the full list rather than summarizing it.
| Provider | Purpose |
|---|---|
| Vercel | Application hosting and content delivery for the marketing site and Portal. |
| Neon | Managed PostgreSQL database (US East region) storing Portal records. |
| Clerk | Authentication and session management for Portal accounts. |
| EasyPost | Carrier rating, shipping labels, tracking and address verification. |
| Resend | Transactional email (order, shipping and approval notifications). |
| Sentry | Application error monitoring. Captures diagnostic data on failures. |
| Sanity | Content management for the public marketing site. No Portal data. |
Compliance posture
We do not currently hold a SOC 2 Type II report. We are a small, owner-operated company, and we would rather state that plainly than imply otherwise. Our infrastructure providers — the systems that actually store and transmit client data — maintain their own independent audits, and we are happy to walk any prospective client through our controls, complete a security questionnaire, or sign a Data Processing Agreement.
For clients subject to GDPR we act as a data processor, handling personal data only on documented instructions from the client. For clients subject to the CCPA we act as a service provider and do not sell or share personal information. We will support data subject requests forwarded by a client.
If a formal certification is a requirement for your program, tell us during evaluation rather than after — we will give you a straight answer about where we are and what we can commit to.
Reporting a vulnerability
If you believe you have found a security vulnerability in our site or Portal, email security@gocustommerch.com with enough detail to reproduce it. We will acknowledge your report, investigate, and keep you informed. Please give us a reasonable opportunity to remediate before disclosing publicly. We do not currently run a paid bug bounty, but we are genuinely grateful for reports and will credit you if you would like.
If we become aware of a breach affecting client or recipient personal data, we will notify affected clients without undue delay and provide what we know about scope and remediation.
Questions
Security or privacy questions, questionnaires, and DPA requests go to security@gocustommerch.com. A real person answers.