Security Overview

Security at BerthRight

BerthRight is marina management software trusted with sensitive information: your team’s data, and your boaters’ names, contact details, vessel information, and payment activity. Security isn’t a feature we bolted on — it’s a condition of being allowed to hold that information at all. This page describes, in plain language, how we protect it.

We’d rather this page say less and be true than say more and be aspirational. If something below is marked as “in progress,” that’s because it is — not because we’re hiding it.

1. Infrastructure and Hosting

BerthRight runs on established, professionally operated infrastructure rather than servers we manage ourselves:

• Vercel hosts the application and serves it through a global content delivery network.
• Supabase provides our managed PostgreSQL database, file storage, and automated backups.
• Cloudflare delivers video content and provides network-level protections.

Using managed infrastructure means the physical security, network hardening, and platform patching of the underlying servers are handled by providers whose full-time job is exactly that — rather than by a small team trying to do it as a side responsibility.

2. Encryption

All data moving between your browser, your boaters’ browsers, and BerthRight’s servers is encrypted in transit using TLS. There is no unencrypted path into the application.

Data stored in our database and in backups is encrypted at rest.

3. Tenant Isolation — How We Keep Marinas Separate

BerthRight is multi-tenant software: many marinas share the same application, but each marina’s data must be completely invisible to every other marina. This is the single most important technical property of the platform, and we treat it that way.

In plain English: every query BerthRight runs against its database is scoped to the marina that made the request. That scoping is enforced in the application layer, on reads and on writes alike — a request made on behalf of one marina cannot ask for another marina’s rows. It is the mechanism that keeps marinas separate today.

We test this specifically. Automated tests verify that one marina’s account cannot retrieve another marina’s data, and those tests run as part of our development pipeline — so a change that broke isolation would fail before it shipped, rather than after.

We are adding a second, database-enforced lock. PostgreSQL offers a feature called Row-Level Security (RLS) that pushes the same rule down into the database itself, so that even a bug in application code that forgot to filter by marina could not cause the database to return the wrong rows. RLS is a planned additional layer of defense; it is not in place today, and we will update this page when it is. We would rather tell you which lock is currently doing the work than let you assume there are two.

4. Authentication and Multi-Factor Authentication

Sign-in for marina staff and boaters is handled by Clerk, a dedicated identity platform, rather than a homegrown login system. Clerk supports and we enable multi-factor authentication (MFA) for accounts that require it, secure session management, and modern password requirements.

Administrative access to BerthRight’s own infrastructure is protected by multi-factor authentication; we are completing verification that it is enforced on every administrative account.

5. Payment Security

BerthRight never stores your boaters’ full card numbers. Card details are entered directly into payment fields hosted by Stripe — a PCI DSS Level 1 validated payment processor, the highest level of PCI validation — whether through our checkout flow or a staff-facing payment screen. Those fields are controlled by Stripe, not by BerthRight, and card data goes directly from the browser to Stripe. It never passes through BerthRight’s servers.

What we do store: a Stripe-issued token, the card brand (e.g., “Visa”), the last four digits, and the expiration date — enough to show “Visa ending in 4242” on an invoice, and to charge a saved card through our Stripe integration, and not enough to be used as a payment credential anywhere else.

Each marina using BerthRight is the merchant of record for its own transactions through Stripe Connect, meaning the marina, not BerthRight, holds the direct relationship with Stripe for processing its sales. A detailed breakdown of PCI DSS responsibility across Stripe, BerthRight, and each marina is available in our PCI DSS Responsibility Matrix, provided on request.

6. Access Control and Least Privilege

Access to systems containing your data is granted only to the extent needed for a specific role, and reviewed regularly. BerthRight is a small team — its founder, plus a contracted software development partner — and every individual with system access is individually named and credentialed; there are no shared logins. Access for anyone who no longer needs it is revoked promptly.

Our contracted development partner works under individually named credentials, never a shared account. That access is scoped to the work being done, is logged, and is monitored through an internal oversight dashboard that shows us what was accessed and when. Written confidentiality and security terms are being put in place to formalize that scope, the logging requirement, and BerthRight’s right to suspend the access immediately if ever needed.

7. Secure Development

Changes to the BerthRight codebase go through review before being deployed. We use automated testing (including the tenant-isolation tests described in Section 3) and automated scanning for known vulnerabilities in the open-source components we depend on, both integrated into our development pipeline. Secrets and credentials are managed through our infrastructure providers’ secure configuration systems, not stored in source code.

8. Backups and Recovery

Your data is backed up automatically. We target a Recovery Point Objective (RPO) of 24 hours — meaning, in the event of a serious data loss, we expect to be able to restore to a state no more than 24 hours prior — and a Recovery Time Objective (RTO) of 8 hours — meaning we expect to be able to restore service within 8 hours of a decision to restore. We are instituting periodic tests of our ability to restore from backup, not just take one.

9. Logging and Audit Trails

We maintain application, authentication, and infrastructure logs sufficient to investigate suspicious activity and to support incident response. Authentication events — sign-ins, sign-outs, and multi-factor enrollment — are logged through our identity provider, Clerk.

10. Subprocessor Transparency

We publish a complete, current list of the third-party providers who may process data on our behalf, what each one does, and what data it can access, at our Subprocessors page. We commit to giving advance notice before adding a new one. We don’t believe you should have to take our word for who touches your data — you should be able to see the list.

11. Incident Response and Notification

We maintain a written incident response plan covering detection, containment, investigation, and notification. If a security incident affects your data, our contractual commitment is to notify you without undue delay after confirming the incident, and where feasible within 72 hours of confirmation, consistent with the notification terms in our Data Processing Addendum. Because each marina controls its own customer relationships, the marina — not BerthRight — determines whether, when, and how to notify its own boaters or regulators, and we provide the technical detail needed to support that decision.

12. Data Export and Deletion

Marinas can obtain an export of their data at any time, and, upon termination of service, request return or deletion of their data consistent with the terms of the Master Services Agreement and Data Processing Addendum.

Export is request-based today, not self-service. Write to info@berthright.app and we will produce your marina’s data in a structured, machine-readable format. A self-service export feature is something we intend to build; until it exists, the email address above is the way to get your data out.

13. Written Information Security Program

BerthRight is formalizing a Written Information Security Program (WISP) — a formal internal document covering risk assessment, access control, encryption, vendor oversight, incident response, and more, to be reviewed at least annually — built to the standard of the Massachusetts data security regulations (201 CMR 17.00). That is one of the most detailed state security frameworks in the country, and we chose it on the theory that meeting a detailed standard by default covers the more general “reasonable safeguards” standards that apply elsewhere. A summary will be available on request under NDA once it is complete.

14. What We Don’t Have Yet

We’d rather tell you this directly than have you wonder.

BerthRight does not currently hold a SOC 2 report. We are a small company, and a formal SOC 2 audit is a significant undertaking we have not yet completed.

In the meantime, here’s what we can offer a customer or their security reviewer instead:

• This page, kept current and specific rather than generic.
• Our PCI DSS Responsibility Matrix, which explains exactly how payment data is handled and by whom.
• Our Data Processing Addendum, with contractual security, breach notification, and subprocessor-oversight commitments.

If your own security review process requires something specific not listed here, ask — we would rather have that conversation directly than leave you guessing.

Responsible Disclosure

If you’re a security researcher and you believe you’ve found a vulnerability in BerthRight, we want to hear about it before anyone else does.

Report it to: info@berthright.app

Please include enough detail for us to reproduce the issue, and give us a reasonable opportunity to investigate and remediate before any public disclosure.

Safe harbor. If you make a good-faith effort to comply with this policy — you don’t access, modify, or exfiltrate data beyond what’s needed to demonstrate the issue, you don’t degrade service for others, and you report the issue to us promptly rather than exploiting it — we will not pursue legal action against you for that research, and we’ll work with you in good faith to understand and fix the issue.

Questions

General security questions, or requests for any of the materials described in Section 14:

Related pages: Subprocessors · Privacy Policy · Terms of Service · Acceptable Use Policy