Security & trust

Your business runs on it.
So we protect it like ours.

BOLD OS holds your pipeline, your contacts, your calendar, and your daily brief. This page says plainly who is accountable for keeping that safe, how the platform is built and run, and how to reach us if you find a problem.

Last reviewed October 28, 2026. We update this page when our practices change.

Who is accountable

One name. Not a department.

We are a small company by design. Security is not delegated to a vendor or a title nobody holds. It sits with the founder, who signs off on every change to how customer data is stored, accessed, and shared.

Brian Cristiano is The Bold Way's security lead. He owns the security program for BOLD OS and for every client engagement, approves production access, reviews changes to authentication and data handling, and is the first call when something goes wrong.

Brian Cristiano
Brian Cristiano
Founder & CEO. Security lead.

Accountable executive for information security, incident response, and responsible disclosure at The Bold Way.

Security contact: security@theboldway.com

What this covers

Three things we are responsible for.

01

BOLD OS

The application at app.theboldway.com, including SalesAI, the Command Center, the daily brief, and the data each customer puts into them.

02

This website

theboldway.com, the assessments and forms on it, and the contact details you submit through them.

03

Client engagements

Documents, credentials, and systems that clients share with us during consulting, coaching, and custom build work.

How BOLD OS is built and run

Specific, not aspirational.

These are the controls that exist today. If a control is not on this list, we do not claim it.

We lean on infrastructure providers that carry their own independent attestations, and we keep the part that is ours small enough to actually review.

  • Hosting and data

    BOLD OS runs on Vercel. Customer data lives in a managed Postgres database on Supabase. Both providers maintain SOC 2 Type II attestations for their platforms. Traffic is encrypted in transit with TLS, and data is encrypted at rest by the database provider.

  • Identity and sessions

    Sign-in is handled by Supabase Auth, with Google sign-in, email and password, or a one-time magic link. Sessions are validated server-side on every request. We never see or store Google passwords.

  • Tenant isolation

    Every customer-facing table enforces row-level security in the database itself, so one customer's rows are invisible to another's session even if application code has a bug. Automated audits in the codebase check that every public table has row-level security enabled and probe tenant isolation before changes ship.

  • Application hardening

    A nonce-based Content Security Policy is enforced on every page of BOLD OS. Dependency updates are tracked by Dependabot and gated through continuous integration before they merge.

  • Secrets and access

    Secrets are stored as environment variables on the hosting platform, never in source control, and a repository check scans for leaked provider keys. Production access is limited to the three people on our team, each with their own account, and is reviewed by the security lead.

  • Payments and email

    Card payments are processed by Stripe. Card numbers never touch our servers. Transactional email is sent through Resend.

  • AI processing

    BOLD OS uses AI models from Anthropic through commercial API agreements. Under those terms, your data is not used to train the models. We send a model only what it needs for the task in front of it.

  • Backups

    The database is backed up daily by the provider. Restores are tested when we change the schema in ways that matter.

When something goes wrong

You hear it from us.
Early, and in plain language.

01

Contain

The security lead is paged and owns the incident end to end. First priority is stopping the exposure: revoking credentials, rolling back the change, or taking the affected feature offline.

02

Tell you

If your data was affected, we notify you directly within 72 hours of confirming it, with what happened, what was involved, and what we are doing about it. No vague "security event" emails.

03

Fix the cause

Every incident ends with a written post-mortem and a change to code, access, or process so the same thing cannot happen the same way again.

Found something?

Tell us. We will take it seriously.

If you believe you have found a security vulnerability in BOLD OS or this website, email security@theboldway.com. A person reads it, not a queue.

We do not run a paid bug bounty today. We do commit to acknowledging every good-faith report within two business days, keeping you updated as we work it, and crediting you if you would like credit once it is fixed.

A machine-readable version of this contact is published at /.well-known/security.txt.

Ground rules
  • In scope

    app.theboldway.com, theboldway.com, and the APIs behind them.

  • Out of scope

    Denial of service, social engineering of our team or clients, physical attacks, and findings in third-party services we use but do not operate.

  • What we ask

    Test only against accounts you own. Do not access, modify, or keep anyone else's data. Give us a reasonable window to fix the issue before you talk about it publicly.

  • What you get

    We will not pursue legal action against researchers who follow these rules and act in good faith.

Questions

Need this in writing for your
own vendor review?

Email the security lead directly. We answer security questionnaires ourselves, and we answer them honestly.