Trust Center
Every claim WorkFreq makes about how we secure your data, satisfy your auditors, and behave when something goes wrong lives on this page. If a control or commitment is not listed here, treat it as not yet in place and ask us about the roadmap.
Security Posture
What we do at the platform level to keep your data safe.
Encryption at rest
AES-256 on all customer data via Supabase managed Postgres + S3-compatible object storage.
Encryption in transit
TLS 1.3 enforced on all client→server and server→server connections. HSTS headers on all public surfaces.
Multi-factor authentication
TOTP-based MFA via Supabase Auth. Self-enrollment in Profile Settings; required for super_admin and producer roles.
Enforcement for HQ roles via frontend gate + database helper function. SMS factor and WebAuthn (passkeys) on roadmap.
Single sign-on (SSO)
OIDC / OAuth2 federation. Okta, Microsoft Entra ID, and Ping Federate supported via Supabase Auth third-party providers.
Framework live; per-customer Okta provisioning available on request. SCIM provisioning in scope for Q3 2026.
Tenant isolation
Row-level security (RLS) enforced on all 38 application tables. Tenant scoping via org_id with no cross-tenant query path.
Split-key authentication architecture
WorkFreq uses Supabase's split-key model. The publishable anon key visible in client-side code carries only the JWT-bearer baseline — every database read and write is gated by row-level security policies that enforce tenant + role + state-machine constraints. The privileged service-role key (which can bypass RLS) lives only in server-side Edge Functions and is never embedded in the published Framer code components. Equivalent to Auth0's public clientId vs. management API token model, or AWS Cognito's identity-pool ID vs. admin SDK credential split.
If a TPRM reviewer asks 'why is the anon key in plain text in your source?' — the answer is that it's the equivalent of a public API base URL. Authorization happens at every query via RLS, not via key secrecy.
Privileged write operations via SECURITY DEFINER RPCs
State-changing operations that cross trust boundaries (DAM staging/publishing, role promotion, guest-token mint, etc.) are implemented as Postgres functions with SECURITY DEFINER and explicit role + org assertions inside the function body. The function writes the activity_log row inside the same transaction as the state mutation, making the audit trail unbypassable. Two flagship examples: stage_asset_to_dam() (producer-tier only) and publish_asset_to_dam() (executive-tier client only).
Storage isolation
Three-tier bucket pattern: vault (originals, private), delivery (optimized, private signed URL), thumbnail (preview, private signed URL). Avatars bucket public-read with owner-only write enforced via storage RLS path-segment match.
Privilege escalation controls
BEFORE UPDATE trigger on users table prevents non-admin self-modification of role, client_tier, org_id, lob_id, is_active, email. Defense-in-depth alongside RLS.
Guest credential hashing
Guest-link tokens and optional PINs are stored only as SHA-256 hex digests (enforced by CHECK constraint on guest_tokens.token_hash and pin_hash). A leaked database snapshot reveals no usable credentials; client hashes the URL parameter before any comparison.
Tier 10 C1 — migrated 2026-04-22. Raw token never persists in the database; it lives only in the URL that the producer shares with the named reviewer.
Server-gated asset downloads
Every download request is re-authorized by the issue-download-url Edge Function which re-verifies the caller identity, the asset's rights_expiry_date window, and (for guests) the token hash + download_enabled flag. A 60-second signed URL is minted per request; no long-lived download URL sits in memory.
Tier 10 C2 — shipped 2026-04-22. Rights-expired assets return a hard-gate 403 reason 'rights_expired' that surfaces to the user as a blocked download.
Audit trail
Every save / upload / approval / project create / milestone create / client edit / LOB change / guest token use / profile update / MFA action writes to immutable activity_logs with user_id, org_id, project_id, action_type, structured details JSON, and UTC timestamp.
3,400+ historical events available for replay and CSV export. Retention currently indefinite; formal retention policy on Q3 roadmap.
Tamper-evident export
Multi-scope CSV export with SHA-256 manifest and optional digital signature for evidentiary use.
Plain CSV export shipped today. Signed-export bundle targeted for SOC 2 Type II window.
Compliance Roadmap
What we have today, what's in observation, what's planned.
SOC 2 Type I
Point-in-time security assessment covering Security, Availability, and Confidentiality Trust Services Criteria.
Audit kicked off Q2 2026. Type I report targeted for Q3 2026.
SOC 2 Type II
Operating-effectiveness assessment over a continuous observation window of 6+ months.
Observation window started 2026-04-22. Type II report targeted for Q4 2026 / Q1 2027.
FFIEC IT Handbook alignment
Audit logging, access management, third-party oversight controls mapped to FFIEC supervisory expectations for marketing technology vendors serving regulated financial institutions.
FINRA Rule 2210 record-keeping
Asset approval chain, reviewer identity, timestamp, and disclosure metadata captured in activity_logs to support FINRA record-retention requirements for member-firm marketing communications.
WORM-grade non-rewriteable storage attestation for Rule 17a-4(f) on Q3 roadmap.
SEC Marketing Rule 206(4)-1
Reviewer attestation, pre-publication approval state, and audit-trail immutability designed to support investment adviser compliance with the Marketing Rule.
OCC Bulletin 2013-29 / 2024-11 readiness
Documentation prepared for Tier 1 bank third-party risk management reviews: control inventory, sub-processor disclosure, BCDR commitments, exit-clause language.
GLBA Safeguards Rule
Administrative, technical, and physical safeguards documented for handling customer information at financial institution clients.
PIPEDA / Quebec Law 25 (Canadian operations)
Cross-border transfer impact assessment, data residency disclosure, and DSAR fulfillment runbook in preparation for TD Bank onboarding (target June 2026).
Production data resides in AWS us-east-1 (Virginia). Per-customer Canadian-region residency available on enterprise plans; discussions with TD Bank counsel on cross-border DPA terms in progress.
Published security policies
Information Security Policy, Acceptable Use Policy, and Incident Response Plan published and maintained under a one-year review cadence. Available on request via security@netfreq.tv.
First-version ISP / AUP / IRP effective 2026-04-22. Annual review owned by the CTO.
ISO 27001
ISMS certification.
Evaluating after SOC 2 Type II delivery.
Sub-processors
Every third party with access to customer data, what they do, and where they sit.
Data Handling
DPA, retention, residency, business continuity, exit.
Data Processing Agreement (DPA)
Standard DPA template available on request, GDPR Article 28 compliant. Custom DPAs negotiable for enterprise contracts.
Email security@netfreq.tv to request the current DPA template.
Retention policy
Active customer data retained for the duration of the contract plus 90 days post-termination. Audit logs retained for 7 years to satisfy FINRA Rule 17a-4 retention requirements. Backup snapshots retained for 30 days rolling.
Data residency
Production data resides in AWS US-East (Virginia) via Supabase. Per-customer regional residency (EU, Canada, AU) available on enterprise plans on request.
Business continuity (BCDR)
RTO 4 hours, RPO 1 hour. Daily automated backups via Supabase Point-in-Time Recovery. Disaster recovery runbook tested quarterly.
Exit & data portability
Customers may export all org-scoped assets, project metadata, audit trail, and user records in a structured format (JSON + S3-compatible bucket dump) within 90 days of contract termination, at no additional cost.
Sub-processor change notification
Customers will be notified at least 30 days before any new sub-processor is added or the region of an existing sub-processor changes. Right-to-object reserved per DPA.
Contact
Security incidents, responsible disclosure, evaluation questions.
Suspected breach, exposed credential, vulnerability disclosure.
Email security →Encrypted reports welcome — request our PGP key in your initial email.
DPA requests, security questionnaires (SIG / SIG-Lite / CAIQ), TPRM intake.
Email vendor desk →Typical response time 2 business days. Custom DPA negotiation supported.
Security researchers reporting vulnerabilities under good-faith terms.
Submit report →We do not pursue legal action against good-faith researchers. Expect acknowledgement within 72 hours.