Sign InGet Started
● SECURITY — BOATCHECKIN
ST. PETERSBURG · FLORIDA
CAPTAIN'S LOG — TODAY
Security

The record is only
worth keeping if it's
still intact.

Boatcheckin holds the kind of documentation operators need to produce two years after a trip sometimes longer. That's only useful if the record is still what it was the day it was signed. Here is how we protect it, how we restrict access to it, how we handle the parts we get wrong, and how to tell us when you find something we missed.

Our posture, up front
Designed to recognized security principles. Not yet independently certified.

Boatcheckin is a young product. The practices on this page reflect how the system was built from the beginning least privilege, defense in depth, cryptographic record integrity, and minimal data retention and they map cleanly to the principles behind common independent frameworks such as SOC 2 Type II and ISO 27001.

We do not currently hold an independent audit certification. Operators with a formal vendor-review process should treat this page as a statement of practice, not an attestation and should contact security@boatcheckin.com to request the most current security questionnaire responses. We'd rather tell you that plainly than imply a certification we haven't earned.

Principles we build to

Six decisions made on day one.

These are the structural commitments that shape every feature we ship. They are not aspirational they are how the code gets reviewed.

Principle I
Least privilege, by default.
Every operator account sees only their own trips, vessels, and guests. Every guest session sees only their own record for their own trip. Database-level access rules enforce these boundaries, not just application code so a bug in one layer can't expose data across another.
Principle II
Record integrity is non-optional.
Waivers and safety attestations are cryptographically hashed (SHA-256) at the moment of signing. Any modification to a stored record is detectable on re-verification. The trip's audit log is sealed at trip completion no row can be silently altered after the fact.
Principle III
Encryption everywhere, at all times.
Data in transit is protected with TLS 1.3. Data at rest is encrypted with modern symmetric cipher standards (AES-256 class). Authentication tokens and shareable links are signed with HMAC and have explicit expiry. No cleartext storage of credentials, tokens, or guest PII, ever.
Principle IV
Minimize what we collect.
We collect the guest data the operator's statute requires, and the operator data needed to run the account. No silent telemetry on guests. No behavioral profiling. No lookalike-audience exports. What isn't collected can't be exposed.
Principle V
Every action is attributable.
State changes on a trip record creation, signature, start, completion, export produce an audit trail with actor, timestamp, method, and client metadata. When a question comes two years later, the answer to "who did this, and when" is already in the record.
Principle VI
No security through obscurity.
We don't rely on secret URLs as an access control, unguessable IDs as a privacy boundary, or undocumented endpoints as a security layer. Public surfaces are rate-limited, authenticated, validated, and logged as if every request were adversarial, because some of them are.
Protecting the record

How the trip record
is kept intact.

This is the layer that matters most: what stops a waiver from being quietly altered, a manifest from being retroactively rewritten, or a safety attestation from being manufactured after the fact.

Data · Transport
Encrypted in transit, modern cipher suites only.
All traffic between guests, operators, and Boatcheckin is protected by TLS 1.3. Older TLS versions are disabled. HSTS is enforced across our domains so a downgrade attack cannot coerce a session to an older protocol.
No feature of Boatcheckin has ever required an operator or guest to transmit credentials or PII over an unencrypted channel, and none ever will.
Data · Storage
Encrypted at rest, minimal privilege inside the database.
Operational data is stored in a managed, enterprise-grade relational database with encryption at rest using modern symmetric ciphers (AES-256 class). Access to the database is restricted to service identities using rotated credentials; humans do not hold direct production credentials.
Row-level access rules, enforced at the database tier, isolate operator data from other operators and guest data from other guests. A bug in application code cannot override a database-tier policy that says "this row does not belong to this account."
Data · Integrity
Signatures and attestations are cryptographically hashed.
At the moment a guest signs a waiver or acknowledges a safety card, the exact text the guest saw plus the guest's signature, timestamp, IP, and user agent is combined into a canonical document and hashed with SHA-256. The hash is stored alongside the record.
If a record is later exported and its contents are altered even by a single character re-hashing the modified document produces a different digest. Tampering becomes visible. This is the technical backbone of ESIGN and UETA-aligned record integrity.
Data · Audit trail
State changes are logged with actor, time, and method.
Trip creation, waiver signing, captain start, per-card acknowledgment, trip completion, and every export produce structured audit entries. Each entry carries the acting identity (operator, captain, or guest), the timestamp, the method of the action, and the client context.
Audit entries are append-only there is no API or UI that edits or deletes them. After trip completion, the trip's audit log is sealed: further entries reference the sealed state rather than mutating it.
Data · Backups
Backups with integrity verification and tested restores.
Production data is backed up on a continuous basis with point-in-time recovery across a rolling retention window. Backups inherit the same encryption-at-rest posture as primary storage.
We run restore drills on a scheduled cadence a backup that hasn't been tested is an assumption, not a backup.
Restricting access

Who can touch the record
and how that's enforced.

The strongest encryption doesn't help if the wrong identity can walk through the front door. Access control sits at multiple layers, so no single mistake exposes an account.

Access · Operators
Operator sign-in uses short-lived, scoped sessions.
Operator accounts authenticate via email with strong-password requirements and, where elected, passwordless or multi-factor methods. Sessions are short-lived and bound to the originating client; session tokens are rotated on privilege-sensitive actions.
Every route that accesses operator data verifies the session, verifies the account is active, and verifies the target record belongs to the requesting operator. A session for one operator cannot read another operator's data, even by direct object reference.
Access · Guests
Guest trip links are signed, scoped, and time-limited.
When an operator sends a trip link, the URL carries a cryptographically signed token that binds the link to exactly one trip. The guest flow can join that trip and only that trip it cannot pivot to another trip, another operator, or the operator dashboard.
Guest sessions are disposable. Once a guest has completed boarding, their session is no longer usable for administrative actions on the trip or the operator.
Access · Captains
Captain snapshot tokens: versioned, revocable, expiring.
Captains can open a trip snapshot directly from a link without logging in so the workflow holds up on a phone with marginal signal at the dock. The link carries an HMAC-signed token with an explicit expiry and a version counter.
If a captain changes or a snapshot is re-issued, the version counter increments and the prior link stops working. Operators can revoke all active snapshots for a trip from the dashboard.
Access · Internal
Our team reaches production data only when necessary, only when logged.
Our team does not routinely access production operator or guest data. When access is required to investigate a reported issue and only with an identifiable legitimate purpose it is performed via scoped, auditable tooling, and the access itself is logged. Bulk extracts, casual browsing, and "just looking" are not supported workflows.
Production secrets and service credentials are stored in a dedicated secret store, rotated on a defined schedule, and never committed to source code. Principle of least privilege applies to our team as much as it applies to operators.
Access · Public surface
Every public endpoint is rate-limited and validated.
Public-facing API endpoints guest join, waiver submission, contact forms are rate-limited at the edge to slow automated abuse, guarded by a bot challenge where appropriate, and strictly schema-validated on the server side. No endpoint trusts client-supplied data as authoritative.
Suspicious patterns rapid enumeration, malformed payloads, repeated failed signatures produce alerts that route to on-call. We'd rather investigate a false positive than miss a real one.
Vulnerability disclosure program

Find something
we missed? Tell us.

We welcome responsible-disclosure reports from security researchers, operators, and curious engineers. This section describes the scope, the rules, the safe harbor, and how to reach the team directly.

In scope
What we want to hear about
Anything that would let an unauthorized party read, modify, or destroy operator or guest data or impersonate an operator, captain, or guest to do so.
  • Authentication and session handling flaws
  • Authorization bypass across operators or trips
  • Data exposure via direct object reference or enumeration
  • Injection vulnerabilities (SQL, template, header, etc.)
  • Cross-site scripting on operator or guest surfaces
  • Token generation, signing, or rotation weaknesses
  • Abuse of audit-log or record-integrity guarantees
Out of scope
What we usually won't prioritize
Reports on these categories are still welcome, but typically do not receive the same urgency as issues above:
  • Missing security headers without a concrete exploit
  • Self-XSS that cannot be weaponized against another user
  • Rate-limiting abuse against public marketing pages
  • Clickjacking on unauthenticated pages with no sensitive action
  • Reports from automated scanners without a working PoC
  • Denial of service via volumetric traffic
  • Social engineering of our team or operators
Safe harbor & the rules
Good-faith research is welcome within these lines.
We will not pursue legal action against security researchers who act in good faith: who report findings promptly, who do not access or exfiltrate more data than necessary to demonstrate the issue, who do not degrade service for operators or guests, and who do not publicly disclose the finding before we've had a reasonable opportunity to remediate.
Please do not test against real operator accounts or real guest trip links without permission. Use your own account and your own trips. Please do not run automated scans that generate load comparable to a real operator's traffic. Please do not ask for or access payment data, as our payment flow is handled by a PCI-DSS Level 1 processor that is out of scope for independent testing by our program.
We don't currently run a paid bounty program, but we acknowledge valid findings publicly (with your permission) and are happy to write meaningful references for researchers whose work helps us.
Submit a report to
security@boatcheckin.com
PGP key on request →
Our commitment after you report

What happens after you hit send.

These are operational targets we hold ourselves to when a report arrives at security@boatcheckin.com. Severity affects the remediation window but acknowledgment and communication do not.

Stage 01
< 2business days
Human acknowledgment with a tracking reference. Not a bot reply a person confirming we have the report.
Stage 02
< 7days
Initial triage outcome reproduced, scoped, or clarifying questions with a target remediation timeline.
Stage 03
Perseverity
Remediation and verification. Critical findings: mitigated fast, patched as soon as safely possible. Lower severity: grouped into the regular release cycle.
Stage 04
Onresolution
Follow-up to the reporter, credit (with permission), and where affected notice to operators whose data was at risk.
If something goes wrong

Incident communication,
before we need it.

Any platform in production for long enough eventually has an incident. Writing down our communication posture in advance rather than when we're in the middle of one is part of being a serious operator ourselves.

If a security incident occurs that affects operator or guest data, affected operators receive direct email notice without waiting for a public announcement. Where the statute in the operator's jurisdiction requires downstream notification to guests or to regulators, we support operators with the technical details they need to meet those obligations. Our timelines in each category are designed to meet or exceed applicable breach-notification windows including US state laws, and where applicable, GDPR's 72-hour rule.

For service-availability incidents downtime, degraded performance we publish updates to a status page so operators don't need to file a ticket just to learn whether the issue is on our side.

In every case, we prefer direct, specific, and early communication over polished marketing language after the fact.

Questions a security
review needs answered? Ask us.

Operators with a formal vendor-review process can request our current security questionnaire, data-processing addendum, and subprocessor list by email. We'd rather have the conversation than have it avoided.

Email Security →General Contact