Trust & Security

Last updated: September 5, 2026

This page exists so a security or procurement reviewer can answer their questions without waiting on us. It describes what we actually run today, including the parts that are not finished. Where a control is absent, it says so rather than leaving the gap for you to find during an audit.

1. Where your data lives

All primary processing happens on Microsoft Azure in the Central India region. The application, the PostgreSQL database, Redis, and the storage that holds generated reports are all in that region. A second Azure virtual machine in the same tenancy runs our self-hosted error tracking and outbound mail relay.

Static assets and DNS are fronted by Cloudflare, whose edge terminates TLS and therefore sees request metadata and in-transit content at the point of presence nearest your user.

2. Sub-processors

These are every third party that can reach customer data, what they do, and where they sit. We give 30 days notice before adding or replacing one, and you may object; if we cannot resolve your objection you may terminate the affected service without penalty.

Not sub-processors. Error tracking (Sentry) and operational alerting (ntfy) are self-hosted on our own Azure infrastructure rather than bought as a service, so no third party receives that telemetry. We say so explicitly because both are commonly assumed to be vendor SaaS, and a reviewer comparing our list against a typical stack would otherwise flag the omission as an oversight.

No AI sub-processor touches customer data. The screening and scoring engines are deterministic. No customer request, vessel list, or screening result is sent to a large language model, and nothing you submit is used to train any model, ours or anyone else's.

3. Security controls

Authentication and credentials

• Passwords hashed with scrypt (N=16384) using per-user random salts. Never stored or logged in plaintext.
• API keys stored as SHA-256 hashes. The plaintext key is shown once at creation and cannot be recovered from us afterwards.
• Keys are scoped — a key that may screen a hull need not be able to manage webhooks — and split into arc_test_ and arc_live_ environments with independent quota, idempotency and webhook namespaces.
• Session tokens generated from a cryptographically secure random source, expiring 7 days from creation.
• Host access is SSH public-key only; password authentication is disabled.

Data in transit and at rest

• TLS on all external traffic, with HSTS.
• Webhook payloads signed with HMAC-SHA256 over a timestamped payload, so you can verify origin and reject replays.
• Off-site backups encrypted with AES-256 (GnuPG symmetric, SHA-512 key derivation) under a passphrase we control rather than the storage provider. Every backup is decrypted and integrity-checked by the job that creates it, and the upload is refused if that round-trip fails — an untested backup is not counted as one.
• Database at-rest encryption is provided by Azure managed-disk encryption.

Tenant isolation and abuse limits

• Every query is scoped by customer identifier. There is no cross-tenant read path in the API.
• Per-key rate limiting, global and per-customer concurrency ceilings on expensive scoring work, and metered quota with reserve-and-refund semantics so a failed call does not silently consume your allowance.
• Idempotency keys on every mutating endpoint, so a retried request cannot double-charge or double-write.

Access logging

• Every authenticated API request is recorded durably and is readable by you at GET /api/v1/access-log: method, path, status, error code, duration, source address, user agent, which key was used, and the request id you were given at the time. Retained 365 days.
• Refusals are recorded, not only successes. The refusals are usually the half of an access log worth reading.
• The source address is taken from the edge and never from a caller-supplied X-Forwarded-For header, so the log cannot be made to record an origin an attacker chose.
• Separately, an account audit trail records governance rather than traffic: who minted or revoked an API key, who invited, promoted or removed a colleague, and from what address. Retained 730 days and readable by any member at POST /core/list-account-audit. A removed member stays named in it — the record has to outlive the person it describes.

Individual accounts and roles

• Colleagues are invited to their own logins rather than sharing one credential, under a single-use invitation that expires in 14 days.
• Roles are admin, manager and analyst. Managing the team and creating or revoking API keys require admin; an administrator cannot change their own role or remove themselves.
• Removing someone ends their access immediately — their sessions are destroyed and their cached credentials cleared in the same operation, not left to lapse when a token expires.
• API keys can carry an expiry, and can be rotated with a grace window so a leaked or ageing key is replaced without taking your integration down. Set the window to zero to cut a key off at once.
• Any key can be restricted to your own IP addresses — exact addresses or CIDR ranges — so a stolen key is unusable from anywhere else. Changes take effect on the next request, not at the end of a cache window.

What we do not have

• No SOC 2 report, no ISO 27001 certificate, no third-party penetration test.
• No customer-managed encryption keys, and no private networking or VPC peering.
• No SSO, SAML or SCIM. Accounts are email and password only.
• No formally exercised disaster-recovery drill beyond the automated restore verification described above.

If any of these is a hard requirement for your organisation, tell us which one. We would rather scope it into a contract than have you discover its absence in week three.

4. Data retention

Retention is enforced by an automated daily process, not by manual hygiene.

On termination we delete or return customer personal data within 30 days, except where retention is required by law. Screening evidence is the deliberate exception described above: we will hand you an export of it rather than destroy a record you may be legally obliged to hold.

5. Availability

We target 99.5% monthly availability of the API, excluding maintenance announced at least 48 hours in advance. On a paid agreement this becomes a contractual commitment carrying service credits; see the Service Level Agreement.

Availability is independently observable at status.arcnautical.com. It deliberately does not run on the infrastructure it monitors — a status page hosted on the machine it watches reports that everything is fine right up until it stops answering at all — so it sits on Cloudflare’s edge with no dependency on our API, our database or our host. It probes every minute, publishes ninety days of history, prints the number of checks behind every percentage, and rounds percentages down. It is the measurement of record for the SLA.

It cannot see everything, and says so on the page: it runs on Cloudflare and measures through Cloudflare, so a Cloudflare-wide outage would take the page down alongside the service.

The page publishes an incident log written by the prober itself — opened, updated and closed automatically from the same checks that produce the percentages, with no authoring page and no way to edit or remove an entry afterwards. And rather than checking it, you can be told: subscribe any HTTPS endpoint on the page and you will get one message when an incident opens, one if its cause changes, and one when it closes. A Slack or Microsoft Teams incoming webhook works unchanged; messages are signed, and your endpoint has to accept a test delivery before we store it. RSS and Atom feeds are at /feed.xml and /feed.atom, and /healthz answers 503 during an outage if you would rather alert on it. Those notifications are sent from the same Cloudflare Worker, so they do not depend on the systems they are reporting on. Incidents affecting your integration are still emailed to your technical contact.

API contract stability is a separate promise, and one we have kept in writing since launch: breaking changes ship as a new major path with 90 days notice, never in place. The full policy and changelog are at API stability.

6. Incident response

• Application errors, failed scheduled jobs, and upstream data-source degradation raise alerts to an on-call channel. A nightly health digest is sent whether or not anything is wrong, so the absence of the digest is itself a signal.
• On a personal-data breach we notify affected controllers without undue delay and within 72 hours of becoming aware, with the categories and approximate volume of data involved, the likely consequences, and the measures taken. This is contractual under the DPA, not discretionary.
• Security issues can be reported at any time under our vulnerability disclosure policy. We do not pursue researchers who act in good faith.

7. Business continuity and key-person risk

ArcNautical is run by one person. Pretending otherwise would be the least defensible thing on this page, so here is the position and what offsets it.

• Backups. The database is dumped daily, encrypted, and pushed off-site to separate infrastructure in a different country from the primary region. Fourteen restore points are retained. Recovery point objective is 24 hours.
• Restore is verified, not assumed. Each backup is decrypted and integrity-checked as part of the job that creates it, and that job fails loudly rather than silently producing nothing — a failure mode we have been bitten by before and now explicitly guard against.
• Reproducibility. Every screening is stored exactly as returned and replayed byte-for-byte on retrieval, so your audit trail does not depend on our engine still behaving the same way years later.
• Source code escrow is available on request for an annual agreement. If continuity is a board-level concern, this is the mechanism that addresses it, and we would rather sign it than argue about it.

8. Your rights and ours

We process customer personal data solely as a processor on your documented instructions. We do not sell it, we do not use it for advertising, and we do not use it to train models. Assistance with data-subject requests, and with your own data protection impact assessment where our processing is in scope, is committed in the DPA.

Audit rights: we will complete a reasonable security questionnaire once per year at no charge and provide evidence for the controls described here. We cannot host an on-site audit.

You do not have to ask us for your own access trail: GET /api/v1/access-log returns every authenticated call made with your keys, so the answer to "who used our credentials, against what, and when" is yours to pull rather than ours to promise.

9. Contact

• Security reports and vulnerability disclosure: [email protected] — see /security and security.txt
• Data protection and privacy: [email protected]
• Contracts and DPA execution: [email protected]

Related documents: Data Processing Addendum · Service Level Agreement · Privacy Policy · Terms of Service · Vulnerability Disclosure