Trust & Security

MYACHT runs on real yachts and holds real vessel data — from certificate registers to accounting records. This page describes the technical and organisational measures we use to protect that data, the choices we’ve made about hosting and sub-processors, and what we’re working toward next.

Last updated: 8 July 2026

What this page is (and isn’t)

This is a plain-English description of MYACHT’s security posture as it exists today. It is not a certification. Where we rely on a third-party sub-processor for security functionality (for example, EU hosting via Fly.io) we say so and link to their own security documentation. Where we do not yet hold a formal certification (SOC 2, ISO 27001), we say so.

Data at rest

Customer data stored in the MYACHT backend is encrypted at rest using AES-256 provided by the underlying block-storage volumes in Fly.io’s EU regions. Application-level database files are stored on encrypted volumes with per-region isolation. Backup snapshots are encrypted using the same key hierarchy and retained in-region.

On the mobile applications, the local database is stored inside the platform’s application sandbox (iOS Data Protection / Android app-private storage). Authentication tokens and secrets are stored in the platform keychain (iOS Keychain / Android Keystore) and are never written to the plain application file system.

Data in transit

All communication between the mobile applications, the shoreside dashboard, and the backend uses TLS 1.2 or higher. Certificates are issued and rotated automatically via the hosting platform. HTTP is redirected to HTTPS at the edge. Certificate transparency logging is enabled by default via our issuer.

Authentication and access control

User passwords are stored using a strong password hash (bcrypt-family, salted per user). Plaintext passwords are never logged or persisted. Session tokens are opaque, short-lived, and revocable. We do not use static long-lived API keys for end-user access.

Within a vessel account, access is governed by a role-based permission system managed by the vessel’s administrator. MYACHT operational personnel do not access Customer data in the ordinary course of operating the Service; access is limited to what is necessary for support, on documented request, and is logged.

Hosting and data location

The MYACHT backend runs on Fly.io in EU regions (primary: Amsterdam, secondary: Frankfurt). Databases, background workers, and object storage are co-located in-region. Backups remain in the EU.

Cross-border transfers occur only where a sub-processor’s corporate parent may require support access from outside the EEA. See the sub-processors page for the current list of sub-processors, their locations, and the transfer mechanisms in place.

Sub-processor due diligence

MYACHT keeps its sub-processor footprint deliberately small. Each sub-processor is chosen for a specific operational purpose, reviewed for security posture and regulatory alignment, and documented on the sub-processors page. We give customers with a signed Data Processing Addendum thirty (30) days notice before adding or replacing a sub-processor.

Software supply chain

Dependencies are pinned via lockfiles. Dependency updates are reviewed and merged manually. Automated security advisories are monitored via the GitHub Security graph and CVE feeds relevant to our stack.

Container images are built from official base images, pinned by digest where feasible, and rebuilt on the current image on each release. Build artefacts are versioned and traceable to a specific commit.

Incident response

MYACHT maintains a defined incident-response process. In the event of a Personal Data breach affecting Customer Personal Data, we notify affected customers without undue delay and, where feasible, within seventy-two (72) hours of becoming aware of the breach, in line with our Data Processing Addendum. Notifications include the nature of the breach, categories and approximate number of data subjects and records affected, likely consequences, and measures taken.

Documented on-call rotation for production incidents
Post-incident review for every Sev-1 and Sev-2 event, no exceptions
Rollback capability tied to every release
Structured logging with retention aligned to legal and diagnostic needs

Availability and backups

The primary database is backed up daily. Backup restore is exercised on a defined cadence. Because MYACHT is offline-first at the application layer, most user-facing functionality remains available on the mobile applications even during a backend outage — data buffers locally on the device and synchronises when connectivity is restored.

Vulnerability disclosure

We appreciate reports from security researchers. If you believe you have identified a vulnerability in MYACHT, please email security@myachtsystems.com with a description, reproduction steps, and any relevant proof-of-concept. We aim to acknowledge reports within two business days and to provide a timeline for remediation within ten business days. We do not currently operate a paid bug-bounty programme but we credit responsible disclosures with your permission.

Compliance and roadmap

MYACHT complies with the EU General Data Protection Regulation (GDPR) and Portuguese Lei n.º 58/2019. Our Data Processing Addendum is available for enterprise customers.

Formal certifications currently on our roadmap:

ISO/IEC 27001 — targeted for evaluation in 2027
SOC 2 Type I — evaluated after ISO 27001 gap analysis
Cyber Essentials Plus (UK) — under evaluation for management-company customer requirements

Enterprise-buyer packet

Procurement or IT teams evaluating MYACHT can request the enterprise packet — including our current sub-processor list, DPA template, security questionnaire responses, and hosting-region diagram — by emailing security@myachtsystems.com. We aim to respond within two business days.