Version 1.0 · Effective 2026-07-11

Security overview

BloomOS is built and operated by SOBO Consulting LLC, a California limited liability company. This page describes how the system actually works. It's written for an executive director, not a security auditor, but every claim on it is one we can show you.

Where your data lives

Your data lives in a PostgreSQL database hosted by Supabase, running on Amazon Web Services in Northern Virginia, United States (AWS us-east-1). The application runs on Vercel. Both are US-hosted. We do not replicate your data outside the United States.

We use a single production database with strict per-organization isolation, not a separate database per customer. The next section explains why we think that's safe, and what we did to make it so.

How your organization is separated from every other one

This is the question that matters most, so here's the mechanism rather than a reassurance.

Every row in every table carries an org_id. Postgres row-level security is enabled on all 144 tables in the application schema. Every policy checks has_permission(org_id, ...) against the identity of the person making the request. If you query for a record that belongs to another organization, the database returns nothing. Not an error page, not a filtered list. Nothing.

This is enforced in the database, below the application. That distinction is the whole point. A bug in a page, an API route, or a report can't leak another organization's data, because the database itself will not hand it over. The same enforcement applies to every database view, so a summary or a rollup can't route around it either.

There are a small number of internal system processes (a scheduled job that refreshes metrics, a payment webhook) that run with elevated database privileges because they have no user session to check against. These paths are narrow, they are the exception, and they don't accept input from the public internet without verifying its origin.

Encryption

Data is encrypted in transit with TLS 1.2 or higher, everywhere, with no unencrypted fallback. Data is encrypted at rest by the underlying storage layer (AES-256). Backups are encrypted.

Third-party credentials that BloomOS holds on your behalf (for example, an OAuth token for your Google Calendar) are stored encrypted and are never displayed back to you or to us in plain text.

Who can access your data

Your team. Access is by invitation only, controlled by you. Each person has a role, and roles carry explicit permissions (read fundraising, write operations, manage the organization, and so on). A person on your team who doesn't have the fundraising permission cannot see gift records, and that's enforced by the same database rules described above, not by hiding a menu item.

One person at SOBO Consulting. Remi Sobomehin, the founder, holds the administrative credential for the production database. That access exists so that support requests can be answered, data can be repaired, and migrations can be applied. It is used when you ask for help, or when something is broken and needs fixing. It is not used to browse.

We're not going to pretend there's a review board. There's one person, and we're telling you exactly who it is and exactly what he can reach, which is more than most vendors your size will tell you.

Nobody else. We don't sell your data, we don't share it with advertisers, and we don't use it to build anything for another customer.

The audit log

Meaningful changes in BloomOS are written to an append-only audit log: what changed, who changed it, and when. The log is partitioned by month and retained for the life of your account. If you ever need to answer "who edited this gift record," the answer is in the system.

Backups and recovery

The production database is backed up automatically once per day. Backups are encrypted and retained for 7 days. We restore from the most recent nightly snapshot, not to an arbitrary point in time.

In plain terms: a catastrophic database failure could cost you up to 24 hours of data. That's the honest number, and it's the one you should plan around. We'd expect to be back up within a few hours of discovering the failure.

Backups are the wrong tool for undoing a human mistake, so BloomOS doesn't rely on them for it. Destructive actions require confirmation, deletion is soft wherever we can make it soft, and the audit log records who changed what and when. If someone on your team deletes a donor record on Thursday, the fix is the audit trail, not a restore that would also erase Thursday.

Application and code

BloomOS is a Next.js application written in TypeScript, deployed on Vercel. Every change goes through a pull request and review before it reaches production. Database schema changes are applied manually and deliberately, never automatically on merge. Dependencies are monitored for known vulnerabilities.

Sessions are managed by Supabase Auth. Passwords are hashed, never stored in readable form, and we cannot see yours.

If something goes wrong

If we discover a security incident that affects your data, we will notify you without undue delay and in any case within 72 hours of becoming aware of it. The notice will tell you what happened, what data was involved, what we've done, and what you should do. It will not be a vague statement about taking security seriously.

Reporting a vulnerability

If you find a security problem in BloomOS, email security@bloomos.org. Tell us what you found and how to reproduce it. We'll acknowledge within one business day and keep you updated until it's resolved.

We won't pursue legal action against anyone who reports a vulnerability in good faith, doesn't access or modify data belonging to others, and gives us reasonable time to fix it before disclosing.

What we don't have yet

We would rather you learn this here than discover it later.

  • No SOC 2 report. We haven't been through the audit. If you're a nonprofit under $2 million, you almost certainly aren't being asked for one either. If you are, tell us, and we'll talk about the timeline.
  • No ISO certification.
  • No third-party penetration test yet. We plan to commission one. It hasn't happened.
  • One region, one primary database. No multi-region failover. A prolonged AWS us-east-1 outage would take BloomOS down with it.
  • No point-in-time recovery. Backups are nightly, so the worst case is 24 hours of lost data. We're planning to close this gap.
  • One person on call. That's the honest shape of the company today.

If you need any of the above to buy, we're not the right vendor yet, and we'd rather tell you now than six months into a contract.

Questions: security@bloomos.org.