Security & Trust

Built for buyers who read the security questionnaire.

Most maritime SaaS treats security as paperwork. We treat it as product. Here's exactly what we do today, and what's still on the roadmap.

SOC 2 — in progressSource code reviewable under NDA

This is a living document. Last reviewed by the founder before each material change to production controls.

13. Compliance documentation

We maintain a full SOC 2 + ISO 27001 readiness pack. Procurement reviewers can request:

Email security@binnacleai.com for the policy pack + control map. Most security questionnaires answer themselves with these docs.

Vulnerability disclosure

Found a security issue? Email security@binnacleai.com — we acknowledge within 2 business days. Safe-harbor terms + full scope at /.well-known/security.txt per RFC 9116.

The differentiator

Our own preview site is locked down with seven defenses.

If we cut corners on the public preview, you'd be right to wonder where else. We don't. After we discovered and closed a test/test backdoor on the preview surface, we shipped a seven-layer lockdown. Every layer is independent. Any one of them, alone, would have closed the door.

  1. Layer 1 of 7

    Environment flag

    What it does. ALLOW_DEMO_LOGIN is hard-set to false in production. The demo sign-in surface refuses to render unless that flag is true.

    Why it matters. If a buyer audits the production environment variables, this is the first thing they should see — and it should always be off.

    Receipts: .env.production

  2. Layer 2 of 7

    Database-level password removal

    What it does. Demo accounts are seeded with a NULL password column. Even if the env flag were flipped, no credential exists to validate against.

    Why it matters. Defense in depth: the auth path can't accept a password that was never stored. This is the layer that closes the backdoor against config drift.

    Receipts: prisma/seed-demo-tug.ts

  3. Layer 3 of 7

    Source-removed credential literal

    What it does. The test/test literal that previously short-circuited NextAuth's authorize() callback has been deleted from src/lib/auth.ts and replaced with a documented LOCKDOWN comment.

    Why it matters. A common pattern in early-stage SaaS is a hard-coded developer backdoor. We had one. We removed it. The diff is in the repo.

    Receipts: src/lib/auth.ts

  4. Layer 4 of 7

    Endpoint hard-disabled

    What it does. The /api/demo/sign-in route returns HTTP 503 on production unconditionally, before any input is parsed.

    Why it matters. Even if every prior layer were bypassed, the endpoint itself refuses to do work. POSTs are rejected at the route boundary, not deep in business logic.

    Receipts: src/app/api/demo/sign-in/route.ts

  5. Layer 5 of 7

    Container entrypoint guard

    What it does. docker-entrypoint.sh refuses to boot the application if NODE_ENV=production and ALLOW_DEMO_LOGIN=true are observed together. The container exits non-zero with a logged error.

    Why it matters. This is the layer that prevents an accidental redeploy from re-opening the door. A misconfigured CI/CD pipeline cannot ship a vulnerable container — the container refuses to start.

    Receipts: docker-entrypoint.sh

  6. Layer 6 of 7

    Seed file regeneration safety

    What it does. The Prisma seed that creates the demo organisation no longer imports bcrypt. Re-running prisma db seed cannot re-introduce a password on the demo user.

    Why it matters. Many SaaS shops re-seed demo data on a schedule. Ours is structurally incapable of restoring the backdoor — the code to hash a password isn't there anymore.

    Receipts: prisma/seed-demo-tug.ts

  7. Layer 7 of 7

    Nightly reset cron removed

    What it does. The previous demo-reset.sh cron entry that re-ran the seed every night has been removed from the production crontab. The seed cannot run unattended.

    Why it matters. Closes the time-travel attack: even a clean codebase is unsafe if an automated job replays an old seed file. The cron is gone, and the seed it would have called is already safe.

    Receipts: production crontab (available on request under NDA).

“If the public preview can be brute-forced, the production tenant might be too. Buyers deserve to know exactly which defenses are in place.”

— John Thomas, Ikena Design & Build Group LLC

Encryption & residency

Where your data lives, and how it travels.

Five data classes, five answers. If your questionnaire asks about a class we haven't listed, email hello@binnacleai.com and we'll add the row.

Data classAt restIn transitAuditResidency
User credentials (login)bcrypt cost 12TLS 1.3NextAuth event logVultr us-east (New Jersey)
Crew records (MMC, TWIC, medical)PostgreSQL row-level, shared-pg clusterTLS 1.3Per-row CRUD audit logVultr us-east (New Jersey)
Document uploads (sea-service letters, certs)Cloudflare R2 (AES-256, provider-managed)TLS 1.3Object access logCloudflare global
Email correspondence (Resend)Provider-managed by ResendTLS 1.3 to recipient MXResend dashboard delivery logResend us-east
Audit logsImmutable PostgreSQL table, append-onlyN/A (internal)Self (append-only)Vultr us-east (New Jersey)

Footnote. The PostgreSQL cluster has weekly encrypted backups stored in the same Vultr region. Backup retention is 30 days. Off-region replication is on the SOC 2 roadmap.

SOC 2 roadmap

Type 1 in progress. Type 2 targeted for 2026 Q4.

We don't claim certifications we don't have. Below is an honest split of what's in production today, what's in flight, and what's explicitly not done yet.

Done

  • Documented security policies

    29 written policies covering access control, change management, incident response, vendor risk, and acceptable use.

  • Employee acceptable-use policy

    Every contributor signs the AUP before code-write access is provisioned.

  • Incident response runbook

    Triage, escalation, customer-notification, and post-mortem steps written down — not improvised at 2am.

  • Data classification matrix

    Every field we collect is tagged Public, Internal, Confidential, or Sensitive PII. MMC and SSN are Sensitive PII.

In progress

  • Continuous control monitoring

    Audit log + PostHog event stream feed a control-evidence dashboard. Replaces a once-a-quarter screenshot exercise.

  • Quarterly access reviews

    Owner reviews every role grant each quarter. Next review due 2026 Q3.

  • Third-party penetration test

    Scoped engagement targeting the multi-tenant boundary and the demo lockdown. Vendor shortlist in progress; no contract signed yet.

Not yet

  • External auditor selected

    Shortlisting now. We won't pay for a certificate before the underlying controls are real.

  • Type 2 observation window

    Plan is to run the 90-day window 2026 Q3 → Q4 once Type 1 design is signed.

Why this honesty. We won't pay for a certificate before the controls are real. Type 1 is for when the design is complete; Type 2 is for when 90 days of evidence backs it up. We're targeting Type 1 by end of 2026 H2.

Maritime-specific

Crew data is mariner data. We treat it that way.

Most generic SaaS security pages don't mention MMC numbers, 46 CFR, or USCG Subchapter M. We do — because every fleet using Binnacle is already obligated to handle this data correctly, and we exist to make that easier, not harder.

USCG Subchapter M alignment

The data we collect (mariner credentials, drug-test records, drills, work/rest hours) is data Subchapter M operators are already required to maintain. We are a recordkeeping platform for those obligations — not a substitute for them, and not a certifier of compliance.

46 CFR data classification

MMC numbers are classified internally as Sensitive PII — handled in the same encryption tier as SSN. Medical certificate scans and TWIC numbers carry the same classification.

Multi-tenant crew privacy

Per-mariner data is strictly org-scoped. Operators using Binnacle cannot see another operator's crew, vessels, or documents — enforced at the query layer, not the UI layer.

Mariner right to deletion Coming Q3 2026

Any mariner can request removal from a fleet. The self-serve workflow is scheduled for Q3 2026; until then, deletion requests are processed manually within 30 days via privacy@binnacleai.com.

Reporting & contact

Found something? Tell us.

Coordinated disclosure works. We answer security mail before sales mail.

Vulnerability disclosure

Email security@binnacleai.com. Plain text or PGP both fine. We acknowledge within 48 hours and follow coordinated disclosure with a 90-day embargo from date of report.

Bug bounty

No formal program yet. We will pay case-by-case for impactful reports — explain the impact and we'll respond with a number. Public thanks (with your permission) on this page.

Security questionnaires

Send yours to security@binnacleai.com with the doc attached. Typical turnaround is 3 business days for CAIQ-Lite and 5 for full SIG.

Want to dig deeper?

Three ways to go from this page to a real conversation. The first is what most procurement teams ask for.

Most popular

See the actual code under NDA

Tokenized preview with full source-code review. Approved by the founder.

Request access

For security teams

Get the SOC 2 readiness pack

Policy index, control matrix, and current evidence list. Emailed within one business day.

Email security@binnacleai.com

For the curious

Read the public lockdown post-mortem

Timeline, root cause, and the seven-layer fix. Written for engineers, not lawyers.

Read post-mortem

Security mail: security@binnacleai.com · Privacy + DSAR: privacy@binnacleai.com · See also our DPA and Privacy Policy.

Built for evaluation-grade trust