How we protect vessel and voyage data

1. Data residency

All customer data — accounts, vessel profiles, port calls, generated reports — is stored in Supabase's Sydney region (ap-southeast-2). Your data does not leave Australian data centres for storage.

The exception is AI processing: when you generate a PAR field mapping or compliance check, the relevant prompt is sent to Anthropic's Claude API in the United States. Anthropic does not train on customer data sent via the API. We do not send personal information that isn't directly required for the field mapping (e.g. crew passport numbers are never included in AI prompts).

2. Encryption

• ·In transit: TLS 1.3 enforced on all endpoints. HSTS with a one-year max-age. No HTTP fallback.
• ·At rest: AES-256 on the database and file storage layer (managed by Supabase).
• ·Secrets: API keys and database credentials stored in Vercel environment variables, never in source code.
• ·Passwords: Hashed with bcrypt by Supabase Auth. Plaintext passwords are never stored or logged.

3. Access controls

• ·Row-level security: Every database table enforces row-level security policies. Users can only read and write rows belonging to their account or team.
• ·Team plans: Agent and Fleet plans support seat-based access. Team members see only the vessels and port calls explicitly shared with them.
• ·Staff access: A small number of company staff have administrative access for support and incident response. All admin actions are logged.
• ·Two-factor auth: On the roadmap. Available via Supabase Auth's TOTP support — we're wiring it into the dashboard now.

4. Application security

• ·HTTP security headers enforced site-wide: Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options: DENY, Referrer-Policy, Permissions-Policy.
• ·Open-redirect protection on the auth callback — only relative paths are accepted as next targets.
• ·Server-side input validation on every API route. AI-generated content is escaped before rendering.
• ·Dependencies monitored via GitHub Dependabot and audited before each release.

5. Sub-processors

We use the following sub-processors to deliver the service. Each has been selected for its security posture and (where applicable) Australian-region availability.

Customers will be notified at least 30 days before any new sub-processor is added.

6. Backups and availability

• ·Daily automated database backups, retained for 7 days. Point-in-time recovery on the production database.
• ·Target uptime: 99.5%. We're working towards a public status page.
• ·Hosting on Vercel's global edge with automatic failover between regions.

7. Incident response

If we detect or are notified of a security incident affecting customer data, we will:

• ·Contain the incident and preserve forensic evidence.
• ·Notify affected customers within 72 hours of confirmation, with the facts known at that time.
• ·Notify the Office of the Australian Information Commissioner (OAIC) where required under the Notifiable Data Breaches scheme.
• ·Publish a post-incident report once the investigation is complete.

8. Compliance roadmap

We're an early-stage company and don't yet hold third-party security certifications. Here's the order we plan to pursue them in:

9. Reporting a vulnerability

If you believe you've found a security vulnerability in PortClear AI, please email us at security@portclear.ai. We aim to acknowledge reports within one business day and remediate confirmed issues as quickly as possible.

We don't currently run a paid bug bounty, but we will publicly credit responsible disclosures (with your permission) once the issue is fixed.

10. Questions

For procurement reviews, security questionnaires, or any other questions about how we handle your data, contact us at hello@portclear.ai.