Security posture. Last updated 2026-05-19
Security posture
This page states, plainly, how Marrow secures customer data, who can access it, how it is backed up, where it physically lives, and what the path to SOC 2 looks like. It is written so an operations director at a gym or a coach can read it and decide. It does not claim a certification or an audit Marrow does not have.
The honest posture, stated first.
Marrow is a pre SOC 2 company. Marrow does not have a SOC 2 report. Marrow has not completed a SOC 2 audit. Marrow has not engaged a SOC 2 auditor. Any vendor questionnaire that asks for a SOC 2 report gets the honest answer.
What Marrow does have: a security model built on top of infrastructure providers that are themselves audited, row level security at the database, encryption in transit and at rest, a minimal access footprint because the team is one person, a documented incident response runbook, and a documented backup posture.
1. Infrastructure and providers
Marrow does not run its own servers. Marrow runs on managed infrastructure providers, each of which maintains its own security program and compliance attestations. This is a deliberate choice. A founder operation cannot out secure Cloudflare or Supabase, so Marrow builds on them.
| Provider | Role | What Marrow relies on |
|---|---|---|
| Cloudflare | Website and API hosting, DNS, edge network, Worker compute, KV storage, R2 object storage. | Cloudflare's edge security, DDoS protection, and its own compliance program. |
| Supabase | Application database (PostgreSQL), authentication, object storage for videos. | Supabase's managed Postgres, encryption, and its own compliance program. |
| Stripe | Payment processing and coach payouts via Stripe Connect. | Stripe's PCI DSS Level 1 certification. Marrow never handles raw card numbers. |
| Kit, Postmark | Marketing and transactional email. | Their email infrastructure and their own security programs. |
| Sentry | Production error monitoring. | Used to detect problems, with PII redaction configured at source. |
Marrow's security posture inherits the strength of these providers and adds Marrow's own controls on top. The full list of every provider that touches customer data, with what data each one sees, lives at /legal/subprocessors/.
2. Encryption in transit and at rest
In transit
All traffic to and from Marrow is encrypted with TLS. The website, the APIs, and every connection between Marrow and its providers use HTTPS. There is no unencrypted path for customer data over the network.
At rest
Customer application data is stored in Supabase's managed PostgreSQL, which encrypts data at rest. Object storage for form videos and program videos is encrypted at rest. Operational data in Cloudflare KV and R2 is stored on Cloudflare's encrypted infrastructure. Marrow does not store customer data in any unencrypted location.
Payment data
Marrow never sees, stores, or transmits raw payment card numbers. Card data is handled entirely by Stripe, which is PCI DSS Level 1 certified. Marrow stores only Stripe tokens and identifiers, never the card itself.
Secrets
Application secrets, including the Supabase service role key, Stripe keys, Cloudflare tokens, and email provider tokens, are stored as Cloudflare Worker secrets and are server side only. They are never shipped to the browser and never committed to source control.
3. Authentication and access control
Inside the application
Marrow enforces access control at the database layer using PostgreSQL row level security in Supabase. Row level security policies are enabled on the application tables and govern who can read and write each row. The policies enforce that:
- A member can read and write only their own data.
- A coach can read and write only the data of members on their own roster.
- A coach cannot see members assigned to a different coach.
- A gym administrator can see only the coaches and members at their own location.
- The public, unauthenticated role has access only to data that is intentionally public, for example a public coach profile.
Because these checks run at the database, they apply no matter which surface or API path makes the request. This is the structural enforcement behind the Marrow Promise that one coach cannot see another coach's athletes. The row level security policies are audited periodically against an attack model.
Who on the Marrow side has admin access
As of 2026-05-19, one person, Edwin Grant, the founder, has administrative access to Marrow's production infrastructure. That includes the Cloudflare account, the Supabase project, the Stripe account, and the email providers. There is no other person with production admin access today.
This is a real characteristic of a founder operation and it cuts both ways. The access footprint is as small as it can possibly be, one person, which is a smaller attack surface than a company with a large operations team. The honest risk: it is also a single point of failure and a single point of trust. Marrow's commitment as it hires is that production admin access is granted only to named individuals, only when the role requires it, and is documented.
Authentication
Members and coaches authenticate through Supabase Auth using magic link email sign in. There are no shared accounts. Marrow's commitment is to add multi factor authentication to administrative access as the team grows beyond one. See open items.
4. Sub-processor program
Marrow publishes a complete list of every third-party service that touches customer data. The list says what each provider does, what data they see, where they are based, and a link to their own privacy policy.
When Marrow adds a new sub-processor, removes one, or makes a material change to how an existing one processes data, we notify coaches 30 days in advance via the email on file. Routine vendor sub-changes that do not materially change where data is stored are not announced.
See the full list at /legal/subprocessors/.
5. Incident response
Marrow has a written incident response runbook that governs how a security incident is detected, escalated, contained, and communicated. The runbook covers triage criteria, severity levels, the on-call decision tree, customer notification rules, and post-incident review.
A tabletop exercise was run on 2026-05-18 against the runbook. Findings from the exercise were folded back into the runbook the same week. The runbook is reviewed quarterly and after every real incident.
If a customer or a researcher reports a vulnerability, the report is handled under the runbook. The customer-facing security contact lives at /.well-known/security.txt.
The honest posture on incident communications. When a real incident affects a customer's data, the customer hears from us directly. We do not hide behind a status page. We do not let the news break elsewhere first.
6. Vulnerability handling
Marrow's application is built on managed providers that handle the patching and security maintenance of the underlying infrastructure. For Marrow's own application code, the commitment is: dependencies are kept current, security relevant updates are applied promptly, and a security review is run on security relevant code changes before they ship.
Marrow does not yet run a formal third party penetration test. A penetration test is part of the compliance roadmap and a named gap below.
If you found a security issue in Marrow, see the published security contact at /.well-known/security.txt. We read every report. Please do not run tests that could affect real members.
7. Backup and disaster recovery
Database backups
The Marrow application database runs on Supabase's managed PostgreSQL. Supabase performs automated backups as part of its managed service. Marrow's backup posture rests on that managed backup capability.
Object storage
Form videos and program videos in Supabase object storage are part of the same managed environment.
Configuration and code
Marrow's application code and infrastructure configuration are kept in version control. The platform can be redeployed from source.
Disaster recovery, honestly stated
Marrow's disaster recovery today rests on three things: the managed backups of the providers, the ability to redeploy the application from version controlled source, and the incident response runbook that governs how a recovery is executed. Marrow does not yet have a formally tested, time bounded disaster recovery plan with a stated recovery time objective and recovery point objective. That is a named gap in the open items below.
8. Data residency
Application data lives primarily in the United States. The Marrow application database stores customer application data in the United States. Customer reads and writes route to United States based origin servers.
Cloudflare's edge network is global. Cloudflare caches static website assets at edge locations worldwide for performance. Application reads and writes route to the United States based origin.
One provider is in the European Union. Plausible Analytics, the privacy friendly page view analytics on marrowfitness.com, is hosted in the European Union. Plausible receives only aggregated, anonymized page view counts. No individual identifiers and no application data.
Payment data is handled by Stripe in the United States.
9. Logging and monitoring
Marrow uses Sentry for production error monitoring on the web app and the iOS app. Sentry captures stack traces and error context, with personal information redacted at the source per the Sentry SDK configuration.
Cloudflare provides edge level request logging and abuse protection. Supabase provides database level logs.
What Marrow commits to as it matures: a clearer audit logging story for administrative actions on customer data, so an enterprise buyer can be told what is logged and for how long. This is a named gap.
10. Compliance roadmap
Marrow does not have a SOC 2 report and does not claim one. SOC 2 is a real audit by an independent licensed auditor, against the Trust Services Criteria, and it takes months. It is not a checkbox.
SOC 2 Type II is on the trigger-based roadmap, not yet engaged. The trigger is a named enterprise customer pipeline that justifies the months and the cost.
The path, in order:
- Close the named gaps below. A clean security posture comes before a clean audit.
- Adopt and write down the security policies a SOC 2 audit will look for: access control, change management, incident response (which exists), vendor management, and data handling.
- Establish the evidence trail. SOC 2 is largely about being able to show that the controls operated over a period of time.
- Engage a SOC 2 readiness assessment to find the gaps before the auditor does.
- Engage an independent licensed auditor for a SOC 2 Type 1 report.
- Operate the controls for a period, typically 6 to 12 months, and then pursue a SOC 2 Type 2 report.
The honest answer to the question "what is your SOC 2 status" is: Marrow is pre SOC 2. Here is the posture in writing. Here is the path. SOC 2 is pursued when the enterprise pipeline justifies it. Marrow never claims it before it has it.
11. Open items and known gaps
These are the real gaps. Marrow does not hide them.
- Multi factor authentication on administrative access. Enforced on every provider account that holds production access: Cloudflare, Supabase, Stripe, the email providers.
- A backup retention check. Confirm the backup frequency and retention on the current Supabase plan against Marrow's recovery requirement.
- A tested disaster recovery plan. Marrow has the pieces but not a formally tested recovery with a stated recovery time objective and recovery point objective. Write it and test it once before scale.
- A backup contact for production access. A single point of trust is a single point of failure. Document who else can access production as the team grows.
- An audit logging story for administrative actions on customer data. Decide what is logged, and for how long, so the question can be answered precisely.
- A penetration test. Not done. Part of the SOC 2 path.
12. Security contact
Write to security@marrowfitness.com with security questions, vulnerability reports, or enterprise questionnaire requests. The published contact also lives in /.well-known/security.txt.
For privacy and data questions, privacy@marrowfitness.com. We read every message. We answer as soon as we can.
Questions about security?
Read enough? Bring your questions to a real conversation. Book a consultation and we will walk the posture with you, gap by gap, answer by answer.