Security 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.

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. Files people add, such as progress photos, body scan photos, lab report files and meal plan documents, are stored in Cloudflare R2, which encrypts them at rest. Private files, such as progress photos, body scan photos and lab reports, are given out only by Marrow's server to a person allowed to see them, through a signed in request or a short lived signed link. Operational data in Cloudflare KV is stored on Cloudflare's encrypted infrastructure.

Wearable sign in tokens. When a member connects an outside wearable account, its sign in token is kept in a server only store, never in the database, and is encrypted with AES-GCM before it is stored. If the encryption key is not set, the token is not stored at all and the connection does not complete. Apple Health, including Garmin data that reaches Apple Health, goes through the member's phone, and Marrow holds no sign in token for it.

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 in two places, and both matter. Row level security policies in Supabase are enabled on the application tables and govern what a signed in person's own token can read and write directly. The policies are written so 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.

Many website and app screens do not read the database with the person's own token. They call Marrow's server, and the server reads the database with a service role key, which row level security does not restrict. On those paths the server does the checking: every route confirms who is signed in from their token, and every coach read of a member goes through one roster check that confirms an active link between that coach and that member, and fails closed if the check cannot be answered. Other screens, including parts of a coach's client page and dashboards, read the database directly with the signed in person's own token, and on those reads the database rules above are what protect the data. A member who asks to close their account leaves every coach's roster at that moment on the server. In the database rules, the same closing fence covers member messages, the member's profile, programs and sessions, meal plans and nutrition targets, video assignments, form grade drafts, wearable readings and the shared coach access checks those rules go through, for coaches and for gym owners and managers alike, so a coach's own token, a head coach's included, reaches none of those records for a closing member. Some older coach rules, such as those on form checks, progress photos, body scans, food logs and a coach's own bookings, still reach a closing member's rows until the 30 day removal, and some coach screens read those tables directly. Reads of a member's records through Marrow's server on its member data routes are written to an access log; a few roster wide server views and all direct database reads are not logged yet, and moving the coach screens that read a member's records behind the server is planned. The service role key is a server secret and never reaches a browser or the app. The row level security policies and the server checks are both reviewed 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 sign in with a password they set when they created their account. There is no emailed sign in link. A person who is locked out can reset their own password by email: we send a one time link that lasts 30 minutes and only lets them set a new password, after which they sign in with it as normal. The reply to a reset request is the same whether or not the account exists, so it cannot be used to find out who has an account. There are no shared accounts. Two step sign in for Marrow's own admin tools is built into the code and is switched on by a single setting; on 2026-10-28 it is not yet switched on. 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.

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

Files in Cloudflare R2 (photos, body scan photos, lab report files and meal plan documents) are not part of the database backup. Cloudflare stores them durably, and a separate copy of them is not yet made. This is a named gap below.

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.

In the iOS app, Sentry also records a screen replay for about 1 in 10 sessions and for any session where an error happens. Every recording masks all text, all images and all icons and drawn graphics, so names, numbers, messages and photos are hidden; it shows the layout of the screen and the steps taken. Our privacy policy describes it in full.

On the website, Sentry records nothing but errors unless a visitor chooses Accept in Your privacy choices. After Accept, and only when the browser sends no Global Privacy Control, it keeps a replay of a page where an error happens, with all text masked and all images and media blocked. No session without an error is recorded.

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. An audit table records sensitive account actions today, such as account closes and their undo. A complete record of who opened a member's data, readable by that member, is not finished yet.
• Two step sign in on Marrow's admin tools. Built, not yet switched on as of 2026-10-28.
• A copy of stored files. Files in Cloudflare R2 are not in the database backup and no separate copy is made yet.
• A penetration test. Not done. Part of the SOC 2 path.

12. Security contact

Use the contact form with security questions, vulnerability reports, or enterprise questionnaire requests. The published contact also lives in /.well-known/security.txt.

For privacy and data questions, the contact form. We read every message. We answer as soon as we can.

Questions about security?

Read enough? Bring your questions to a real conversation. Join now and we will walk the posture with you, gap by gap, answer by answer.