Trust & security
Your organization trusts Voyager with donor records, beneficiary details, and the day to day work of your mission. Here is how we protect that data, in plain language, with no overclaiming. Where something is on our roadmap rather than done, we say so.
Tenant isolation
Every customer lives in its own workspace, and that boundary is enforced twice: once in the application, and again inside the database.
Separation between workspaces is enforced by PostgreSQL, not only by our application code. 205 of our 207 database tables have row-level security enabled with policies attached, and workspace-scoped queries run through a restricted database role that those policies confine to the current workspace.
That means isolation does not rest on a developer remembering to add a filter to a single query. For a query running under that restricted role, the database itself refuses to return another workspace's rows. It is the strongest place to put this boundary, so we put it there.
We test it rather than assume it. Every proposed code change runs an isolation test suite against a real PostgreSQL instance, and a change that would let one workspace read another's rows fails the build before it can ship.
The honest detail, because it matters. Row-level security is a second line of defense layered on top of application-level workspace filters, not a single connection-level wall. Administrative and system operations, such as billing webhooks, scheduled jobs, and database migrations, run as the database owner and are not constrained by these policies; those paths carry their own workspace checks in code and are reviewed as security-sensitive. One table, the internal product-feedback queue, does not yet have a policy attached and is on our fix list. We would rather you know exactly where the line sits than take "every table, always" on faith.
Encryption
Your data is encrypted while it travels and while it sits at rest.
All traffic to Voyager, and between Voyager and its data stores, runs over TLS. Strict Transport Security is enforced, so browsers only ever connect over a secure channel.
Our managed database (Neon) and our file storage encrypt data at rest as part of their platform. That layer is theirs, not ours, and we rely on it. The most sensitive stored secrets, such as a workspace's outbound email password and connected-service tokens, get a second layer that is ours: they are encrypted in the application with AES-256-GCM before they are written, so the plaintext never lands in the database.
Payments
Payments are handled by Stripe, a PCI DSS Level 1 certified provider and one of the most trusted names in online payments.
When a card is entered, it goes directly into Stripe's own hosted, secure fields and on to Stripe. Full card numbers are never stored, processed, or transmitted by Voyager's servers. We keep only Stripe's tokens, which cannot be turned back into a card number.
Because all card handling is outsourced this way, Voyager falls under the lightest PCI scope (SAQ A). See our compliance posture below.
Access
People see only what their role allows, and important actions are recorded.
Inside your workspace, you decide who can do what. Every member holds one of three account roles (owner, admin, member) plus a job-shaped preset such as manager, finance, fundraiser, staff, or viewer, and those together gate which modules and actions a person reaches. Donors and portal users get a separate, far narrower kind of access that never touches your admin tools, and sensitive areas can be restricted further to users who meet your own requirements.
Behind the scenes, access to production infrastructure is limited to the two founders using strong, unique credentials. There are no shared infrastructure logins, and secrets are never stored in code.
Voyager records an audit event for sensitive actions in several areas of the product, so you can see what happened and who did it. Covered today: sign-in and sign-out, password changes and resets, member invitations and role changes, contact and company record changes, task and project changes, phone and voicemail activity, in-kind donation intake and approval, and gift acknowledgment.
Not yet covered, and you should know it. Creating, editing, and voiding a monetary gift are not written to the audit log today. Each gift record does store who entered it and when, plus a last-changed timestamp, and nightly backups let us reconstruct what a record looked like on a given day. What we cannot yet hand you is a single per-edit log showing who changed a donation amount and when. If your board or auditor expects that, we do not have it today. It is our top audit-coverage priority, and we will not describe it as done until it is.
Resilience
Your data is backed up every night to a separate provider, and we have tested that we can restore it.
Responsible AI
Voyager's AI features help with tasks like grant writing and intake. They are careful with your data.
AI features run only when you trigger them. When you use one, it processes only the data from your own workspace, and only the specific information needed for the action you asked for. AI does not roam across your data or across other customers, and nothing is sent to an AI provider in the background.
We do not sell your data and we do not use it to train models. Our AI provider is Anthropic, reached through their commercial API, whose business terms state that customer inputs and outputs are not used to train their models. That commitment is Anthropic's and we rely on it; we can share their current terms on request.
Who else touches your data
Voyager is built on a small set of established providers. These are the companies that can hold or process your data on our behalf, and what each one sees.
| Provider | What it does | What it can see |
|---|---|---|
| Vercel | Application hosting, CDN, TLS termination | Application traffic, and uploaded files stored in Vercel Blob |
| Neon | Managed PostgreSQL, the primary database | All customer records held in Voyager |
| Cloudflare | R2 object storage, used as the independent backup and file-mirror store | Nightly database backups, per-workspace exports, mirrored files |
| Stripe | Payment processing and subscription billing | Card data, which is collected by Stripe directly and never reaches our servers, plus donor name, email, and amount |
| Twilio | Workspace phone numbers, calling, SMS, and voicemail | Phone numbers, call and message metadata, voicemail recordings and transcripts for workspaces that enable phone features |
| Anthropic | The AI model behind grant writing, in-kind intake, and drafting features | Only the specific workspace content included in a request you trigger |
| ImprovMX | Outbound SMTP relay for system email (nodemailer over smtp.improvmx.com) | Recipient addresses and the contents of transactional email we send on your behalf |
| Sentry | Error monitoring | Error traces and diagnostic context, which can incidentally include identifiers such as a record id |
| GitHub | Source control and the scheduled job that runs the nightly backup | No customer records are stored in GitHub; the backup job handles the database dump in transit |
Some workspaces also enable optional integrations (for example Google Workspace for calendar, Microsoft, Shopify, Printful, or Apple and Google Wallet passes). Those only receive data when your workspace connects them, and only the data that integration needs. We will tell you before we add a subprocessor that touches customer data.
Where we stand
We would rather tell you exactly where we are than claim a badge we have not earned.
Payments (PCI): because all card handling is outsourced to Stripe, we operate under the lightest PCI scope (SAQ A). Card data never touches our servers. Stripe holds PCI DSS Level 1 certification; we do not, and under SAQ A we do not need to.
SOC 2: Meridian Group holds no SOC 2 report and no third-party security certification of any kind. Our infrastructure providers do: Neon, Vercel, Cloudflare, and Stripe each maintain SOC 2 or equivalent audited programs, and we inherit those controls for the layers they run. That is not the same as us being audited, and we will never present it as though it were. We run the underlying practices today (database-enforced isolation tested in CI, reviewed changes, off-provider backups with a written restore runbook, an incident response process), and we will pursue a formal audit when a customer's requirements call for it.
Independent testing: we have not commissioned a third-party penetration test. Our security testing today is automated: an isolation test suite that runs against a real database on every change, plus dependency and code review. If your organization requires an independent test, tell us and we will scope one rather than talk around it.
Uptime: we do not publish a formal uptime SLA or a measured availability figure, because we do not yet run the third-party monitoring that would make such a number honest. Our hosting and database providers publish their own status pages and availability commitments.
Health data (PHI): Voyager is not sold as a HIPAA system, and our posture is no PHI. Please do not upload protected health information unless we have a specific written agreement in place first.
Company size: Meridian Group is a two-founder company. That is a real difference from an enterprise vendor, and it cuts both ways: you get direct access to the people who write the code and fast fixes, and you do not get a dedicated security team, a 24/7 on-call rotation, or an audit department. We would rather you weigh that openly than discover it later.
If your organization has a security questionnaire, a board requirement, or a specific control you need, send it over. We will answer it line by line and mark anything we do not have as not having it.
Get in touch
Reach us directly. We respond to security reports and questions promptly, and acknowledge coordinated disclosures within 3 business days.
soo@meridian-group.ai