Security

Data Protection

What We Collect

What We Do NOT Collect

• Continuous crew location or tracking data
• Biometric data
• Financial information
• Non-safety-related personal communications

Encryption

• In transit: TLS 1.2+ enforced on all endpoints. HSTS enabled with a 1-year max-age.
• At rest: PostgreSQL hosted on Render (Frankfurt, EU), encrypted at rest using AES-256 by the hosting provider.
• Backups: Automated daily backups with point-in-time recovery, stored encrypted in the same region.

Data Residency

All production data is stored in Frankfurt, Germany (EU), supporting GDPR compliance requirements for European maritime operators.

Authentication & Access Control

Authentication

MarinerMind uses Clerk as its identity provider — a SOC 2 Type II certified authentication platform. We do not store passwords.

• Email + password (managed by Clerk, bcrypt-hashed)
• Single Sign-On (SSO) via Google OAuth (optional)
• Multi-factor authentication (TOTP or SMS) — available and recommended for all admin accounts

Role-Based Access Control

Role assignments are stored in Clerk's verified user metadata and enforced on every API request server-side. Roles cannot be self-assigned or escalated by end users.

Session Management

• Session tokens managed exclusively by Clerk (short-lived JWTs, 1-hour expiry with refresh)
• Sessions revoked immediately upon password change or admin-initiated logout
• All protected routes validated server-side on every request — client-side role checks are decorative only

Admin Access

• Admin accounts require multi-factor authentication
• Admin users invited via time-limited cryptographic tokens (256-bit random)
• All admin actions logged with timestamp and user ID

Incident Reporting Privacy

Protecting the identity of seafarers who report safety incidents is the most critical privacy feature of the MarinerMind platform.

How It Works

• The crew mobile app requires no account and no login. A submitted report carries no name, email, or account identifier of any kind — anonymity is at the data layer, not a display-only filter. (A separate, unrelated push-notification token may be stored per device for delivering reminders — see “What We Collect” above — but it is never linked to the content of any report.)
• Before submitting, crew confirm they've selected the correct vessel by entering a short confirmation code specific to that ship (printed on a poster on board) — this prevents wrong-vessel submissions without weakening anonymity.
• Shore-side roles (Safety Officer, Fleet Manager, Administrator) see ship name, report type, and incident details, scoped to their assigned vessel(s)/fleet(s) — never the identity of who reported it, because that identity was never collected in the first place.

Identity Architecture

• There is no device fingerprint or other identifier linking a submitted report back to the individual who submitted it. Anonymity is enforced at the point of collection, not by access-control policy on top of identifiable data.
• Shore-side accounts (Safety Officer, Fleet Manager, Administrator) are a separate, identified population — real name and email, managed in Clerk — used to operate the platform, not to submit reports.

Anonymisation Roadmap

We are evaluating:

• Data minimisation: automatic redaction of free-text details that could inadvertently identify a location or individual, after a defined retention window
• Configurable retention windows per customer, beyond the default described above

Vulnerability Disclosure Policy

We welcome responsible disclosure of security vulnerabilities. If you discover a security issue in MarinerMind:

How to Report

Email: team@marinermind.com (subject: “Security Disclosure”)
Response SLA: We will acknowledge your report within 48 hours and provide an initial assessment within 7 days.

Scope

In scope:

• marinermind.com and all subdomains
• MarinerMind mobile app (iOS / Android)
• API endpoints

Out of scope:

• Denial-of-service attacks
• Social engineering of staff
• Physical security
• Third-party services (Clerk, Render, Resend)

Our Commitments

• We will not take legal action against researchers acting in good faith
• We will acknowledge your contribution (with permission)
• We do not currently offer a paid bug bounty programme, but we will recognise impactful findings

Safe Harbour

Security research conducted in good faith following this policy will not result in legal action from MarinerMind. We consider this policy a legal authorisation for the purposes of applicable computer fraud laws.

Compliance & Standards

GDPR (EU 2016/679)

• Legal basis: Legitimate interest (occupational safety reporting) and performance of contract
• Data subject rights: Access, rectification, erasure, and portability requests handled within 30 days
• Data Processing Agreement (DPA) available for enterprise customers on request
• EU data residency (Frankfurt, Germany)
• No transfers to third countries except through Clerk (US, SCCs in place) and Resend (US, SCCs in place)

ISM Code (International Safety Management Code)

MarinerMind is purpose-built to support ISM Code Chapter 9 compliance (reports of non-conformities, accidents, hazardous occurrences).

• Structured report collection matching ISM Near-Miss and Incident categories
• Report records maintained for the ISM-mandated retention period
• Management review supported via aggregated trend analytics
• Audit export functionality for port state control or classification society inspection

TMSA (Tanker Management and Self-Assessment)

MarinerMind supports TMSA 3 Element 7 (Incident Investigation and Analysis) via:

• Systematic near-miss capture
• Cross-vessel trend analysis
• Closed/open status tracking per report

SOC 2

We do not yet hold SOC 2 certification ourselves. Our key infrastructure providers do:

• Clerk (identity): SOC 2 Type II
• Render (hosting/database): SOC 2 Type II
• Resend (email): SOC 2

We're happy to discuss our roadmap toward independent certification directly with enterprise customers as part of onboarding.

Third-Party Services

We do not use third-party analytics tools that track individual user behaviour. No data is sold to or shared with advertising networks.

Security Controls Summary

Ongoing Security Reviews

We run internal security reviews as an ongoing practice, not a one-time event — most recently in August 2026, covering authentication, authorisation, API security, database schema, dependency CVEs, secrets management, and frontend security across the full codebase (web application, API layer, database, mobile app). Findings are remediated as they're identified rather than batched.

We do not yet hold a third-party-certified audit report. We're glad to walk enterprise customers through our internal review findings and current posture directly as part of due diligence.