Security overview

1. Infrastructure

TrendSuite runs on Vercel (edge runtime and serverless functions) and Supabase (managed PostgreSQL and authentication). Both providers hold SOC 2 Type II certifications and publish transparency reports. We do not operate any self-managed servers; the infrastructure layer is fully managed by providers whose security posture we have evaluated.

Application deployments are immutable and go through a CI gate (typecheck, lint, unit tests, build) on every push. Production deployments require the gate to pass. Rollbacks to any prior deployment are available instantly via Vercel without a re-deploy.

2. Encryption

In transit.All traffic between clients and TrendSuite servers is encrypted with TLS 1.3. We enforce HTTPS on every route via Vercel’s edge network, with HSTS preload enabled so that browsers never make a plain-HTTP request even on first visit.

At rest — database. Supabase Postgres uses pgsodium for transparent column-level encryption on sensitive fields. All data at rest in Supabase is encrypted at the storage layer by the underlying cloud provider.

At rest — application layer. OAuth access tokens and refresh tokens for connected social accounts receive an additional layer of AES-256-GCM encryption applied at the application layer before being written to the database. The ENCRYPTION_KEY used for this is stored as a Vercel environment secret, is never committed to source control, and is rotated on a schedule. Even in the event of a database dump, social tokens are not recoverable without the application-layer key.

Key rotation policy. Encryption keys are rotated on an as-needed basis, or at minimum annually. Key rotation triggers a re-encryption of affected columns. The rotation schedule and procedures are documented in our internal incident response runbook.

3. Authentication

Identity management is handled by Supabase Auth. Passwords are hashed using bcrypt with a work factor tuned to current hardware capability. Email verification is mandatory before an account becomes active; unverified accounts cannot access any data-bearing endpoints.

Multi-factor authentication (MFA) via TOTP is available on all account tiers. We recommend but do not yet mandate MFA for Agency accounts; mandatory MFA for Agency-tier accounts is on the roadmap.

Google OAuth is supported as an alternative to password-based login. OAuth tokens from Google are used solely to identify the user; we do not request write access to any Google service at the authentication step.

4. Authorization

Row-Level Security (RLS) is enforced at the PostgreSQL layer on every user-scoped table. This means that even if an application bug were to issue a query without a user filter, the database would return only the rows that the authenticated user is permitted to see. RLS is not an optional enhancement — it is the primary access control boundary.

For Agency accounts, brand workspaces are scoped to explicit brand-member relationship rows. A user cannot access a brand workspace they are not explicitly a member of, regardless of application-layer logic. Agency workspace isolation is covered by automated tests that run on every CI push.

5. Application Security

The entire codebase is written in TypeScript with strict mode enabled. The use of as any, @ts-ignore, and @ts-expect-error is prohibited by project policy — a CI lint check enforces this. The goal is that type errors are eliminated at compile time, not suppressed.

ESLint is configured with Next.js recommended rules plus security-oriented rules (no eval, no dangerouslySetInnerHTML without review). Sentry is instrumented for both server-side errors and client-side exceptions. All unhandled errors surface in real time to the engineering team.

Content Security Policy (CSP) headers are on the roadmap; specific directives are being finalised ahead of the public launch. HTTP security headers currently in place include X-Frame-Options, X-Content-Type-Options, and Referrer-Policy.

6. Vendor Security

All sub-processors that handle personal data are listed in the Privacy Policy sub-processors table, along with their certifications and the data shared with each. We require sub-processors that handle EEA/UK personal data to operate under Standard Contractual Clauses or equivalent transfer mechanisms.

We evaluate sub-processor security posture before onboarding them and review it annually or upon significant changes to their terms. Providers with SOC 2 Type II certifications are preferred; alternatives must demonstrate equivalent controls.

7. Monitoring & Response

Application errors and performance anomalies are monitored in real time via Sentry. Vercel provides access logs and edge function execution traces. Alert thresholds are configured for error rate spikes, latency regressions, and unusual traffic patterns.

An on-call rotation is being established for the period surrounding public launch. Prior to launch, the engineering team monitors alerts directly. Our incident response playbook covers detection, containment, eradication, recovery, and post-mortem steps. Incidents affecting user data trigger the breach notification procedures described in the Privacy Policy.

8. Compliance Roadmap

Is TrendSuite SOC 2 certified?

Not yet. SOC 2 Type I is planned for approximately 6 months post-public launch. The foundational controls — access control, change management, availability monitoring, incident response — are being implemented ahead of that audit.

Is TrendSuite GDPR-ready?

We have designed the architecture for GDPR compliance from day one: data minimisation, purpose limitation, RLS-enforced access control, sub-processor DPAs, 72-hour breach notification procedures, and rights-request workflows. Full GDPR readiness (including EU representative appointment) is targeted before EU general availability.

Is TrendSuite HIPAA compliant?

No. TrendSuite is not designed or intended to process Protected Health Information (PHI) and does not currently offer a Business Associate Agreement (BAA). HIPAA compliance is not in scope.

Is there a pen test report available?

A third-party penetration test is scheduled for Q4 2026. An executive summary will be available to Agency and enterprise customers under NDA after the test is complete.

9. Responsible Disclosure

We welcome responsible disclosure from security researchers. If you have found a vulnerability in any production-exposed TrendSuite surface, we want to know about it.

10. Audit History

• CVEs publicly attributed to TrendSuite: none to date.
• Last third-party penetration test: scheduled Q4 2026 (pre-launch).
• SOC 2 Type I target: approximately 6 months post-public launch.