DRAFT — sales-enablement content. Source of truth for every claim is the corresponding Phase 3 security policy under /docs/security/. Do not edit this file in isolation: any update here must trace back to a policy section that already passed audit. Aspirational items are explicitly marked "Planned" and MUST NOT be cited as current controls.

DeckTrust Security Overview

Last reviewed: 2026-05-01 Version: 1.0 (Phase 4) Public-facing audience: prospective customers, security reviewers, procurement

At a Glance

DeckTrust is a multi-tenant SaaS platform purpose-built for U.S. Coast Guard 33 CFR Part 101 Subpart F (MTSA Cybersecurity Final Rule, 90 FR 6298) compliance. Customers are MTSA-regulated maritime operators; DeckTrust processes their personnel records, training data, vessel and facility information, and compliance evidence on their behalf.

This page summarizes the security posture of the production Service at decktrust.dev. It is a marketing-tone summary; the authoritative documents are the security policies in /docs/security/ and the Data Processing Addendum in /docs/legal/dpa-template.md. Where the policies and this page disagree, the policies control.

1. Architecture and Hosting

DeckTrust runs on a small set of established U.S.-hosted infrastructure providers covering application hosting, managed Postgres with authentication and file storage, transactional email, and error monitoring. Source code is held in a private repository and contains no Customer Data.

All current subprocessors that process Customer Data are U.S.-hosted. DeckTrust does not transfer Customer Data outside the United States. The current subprocessor list — with each vendor's role, region, certifications, and DPA links — is provided to Customers and prospective Customers under NDA on request to privacy@decktrust.dev. See the Subprocessors page for the request process and change-notification commitment.

DeckTrust is a sole-operator managed service provider (MSP). The founder holds every information-security role today; this is honestly disclosed in the Information Security Policy and shapes which controls are realistic at the current scale.

Source: information-security-policy.md §1, §2; subprocessors-public.md.

2. Data Isolation (Multi-Tenant)

Customer-data isolation is the highest-stakes control on the platform and is enforced at the database layer, not only in application code.

• Row-Level Security (RLS): every Customer-data table has Postgres RLS enabled. RLS policies span 30 migration files in supabase/migrations/.
• JWT-claim-driven tenancy: a Custom Access Token Hook injects org_id, role, and entity_ids into the access token on each sign-in. RLS helper functions read those claims to scope every query.
• Cross-tenant access is reserved for the admin role (DeckTrust internal staff) via explicit super_admin policies. There is no codepath that grants cross-tenant access based on organization name.
• Server-side validation on every request: the application uses supabase.auth.getUser() (not getSession()) so JWT validity is verified against Supabase Auth on every request, not read trustingly from a cookie.
• Automated regression coverage: an RLS test suite (npm run test:rls) exercises cross-tenant isolation and JWT-claim chains. New tables must enable RLS in the same migration that creates them.

Source: information-security-policy.md §5; access-control-policy.md §4; vulnerability-management.md §5.

3. Encryption

• In transit: TLS terminated at Vercel's edge for all public traffic. Application-to-Supabase connections (Postgres, Auth, Storage) are TLS-encrypted by default.
• At rest: Supabase-managed Postgres encrypts data at rest using AES-256 with provider-managed keys. Supabase Storage buckets (assessment-photos, tool-uploads, documents, evidence) are encrypted at rest.
• Backups: Supabase Pro Point-in-Time Recovery snapshots are encrypted at rest by Supabase.
• Secrets: the Supabase service-role key is gated behind import "server-only" and never sent to a browser. All secrets live in Vercel project environment variables; none in source.

Planned: Customer-managed encryption keys (CMK) for Postgres and Storage are on the roadmap; provider-managed keys are the current control.

Source: information-security-policy.md §4; access-control-policy.md §5.1; backup-recovery.md §3.

4. Authentication

• Methods supported: email + password (primary for the personnel role); email one-time-passcode (primary for admin and client_admin); both methods are supported across all roles. Social providers (Google, GitHub, etc.) are disabled.
• Password policy (NIST SP 800-63B aligned, in src/lib/config/auth.ts): minimum 8 characters, maximum 128, no composition rules, no forced rotation, breached-password rejection against a small local starter list (currently 25 entries).
• Lockout: 5 failed attempts within a 15-minute window, tracked in the login_attempts table.
• Session lifecycle: access token TTL 1 hour; refresh token TTL 30 days; refresh-token rotation enabled with a 10-second reuse interval.

Multi-factor authentication — honest three-way framing:

Planned: application-level aal2 enforcement for admin and client_admin; HIBP API breached-password check; WebAuthn enabled in production.

Source: information-security-policy.md §6; access-control-policy.md §3.

5. Authorization (RBAC)

The Service has exactly three application roles, defined in code at src/lib/actions/auth.ts:

These role values are the literal strings used in JWT claims, RLS policies, and middleware redirect logic. RLS at the database is the primary enforcement; requireAuth([...]) checks in server actions and route handlers are defense-in-depth.

The Supabase service-role key (which bypasses RLS) is restricted to a single server-only module (src/lib/supabase/admin.ts) and used for a small number of administrative operations (user invitation, platform-wide scope check). It is never imported in any 'use client' file.

Source: access-control-policy.md §2, §4.

6. Backup, Recovery, and Continuity

The 30-day backup-retention number is aligned across this overview, the Information Security Policy, and DPA §11.2(b). RPO and RTO are stated only in the security policies today (they are not in the SLA, which commits to a 99.5% uptime target and support-response targets only). Reflecting RPO/RTO in the SLA, once exercise-verified by the first restore drill, is on the roadmap.

Source: backup-recovery.md §2, §3, §6, §8; information-security-policy.md §13; sla.md §2; dpa-template.md §11.2(b).

7. Logging, Monitoring, and Incident Response

• Application errors: routed to Sentry (@sentry/nextjs v10.x).
• Authentication events: logged by Supabase Auth and visible in the Supabase dashboard.
• Database access: logged at the connection level by Supabase.
• Privileged-action audit trail: a Postgres audit_log table (RLS-protected) records plan-approval state changes, invitation issuance, and role changes on organization_members. Coverage is partial today — not every state change is recorded; expanding coverage is on the roadmap.
• Operational consoles: Sentry, Vercel, and Supabase dashboards are reviewed at least weekly during normal operations.

Incident response:

• The Incident Commander is the founder. There is no formal incident committee.
• Severity is classified Sev1 / Sev2 / Sev3 / Sev4 in incident-response-plan.md §4.
• DeckTrust follows the NIST SP 800-61 lifecycle, adapted for sole-operator scale.
• Outside counsel and a cyber-insurance carrier are engaged for any Sev1, any breach declaration, or any incident affecting Customer Personal Data.

Coverage model — honest framing: monitoring is automated 24×7 (Sentry alerting, provider-side detection by Supabase and Vercel). Human response is currently best-effort during waking hours. The SLA's P1 acknowledgement window is calibrated to that reality (4 Business Hours from receipt during Business Hours; commercially reasonable efforts outside Business Hours). A formal 24×7 P1 acknowledgement window is on the roadmap and is expected to be offered as a paid premium-support tier.

Planned: centralized log aggregation beyond Sentry + provider dashboards; SIEM-style automated correlation; comprehensive audit_log coverage; documented per-scenario runbooks; first formal Sev1 tabletop within 90 days of policy publication; 24×7 on-call rotation, gated on a second engineer or a paid premium-support tier.

Source: information-security-policy.md §8; incident-response-plan.md §3, §4, §5, §10; sla.md §5.

8. Breach Notification

DeckTrust will notify a Customer of a Security Incident affecting that Customer's Personal Data without undue delay, and in any event within 72 hours after DeckTrust's confirmation that a Security Incident has occurred. This timing matches the Data Processing Addendum §9.1 and is operationally implemented in breach-notification.md §2.

The notification will include the categories then known under DPA §9.2(a)–(e), including (where relevant) the information needed for the Customer to satisfy its own obligations under 33 CFR Part 101.620 (the MTSA Cybersecurity Final Rule's cyber-incident reporting rule). DeckTrust does not file the Customer's regulatory reports for them — DeckTrust supplies the timely facts the Customer needs to file its own.

A notification is not an acknowledgement of fault or liability (DPA §9.4).

Source: breach-notification.md §1, §2, §3.4; dpa-template.md §9.1, §9.2, §9.4.

9. Vulnerability Management and Disclosure

• Severity and patch SLA (CVSS v3.1):
  • Critical (9.0–10.0): 7 calendar days
  • High (7.0–8.9): 30 calendar days
  • Medium (4.0–6.9): 90 calendar days
  • Low (0.1–3.9): 180 calendar days
• Dependency monitoring: GitHub Dependabot default repository-level alerts are active. There is no committed .github/dependabot.yml in the repository today; default alerts run.
• Static analysis: internal review (founder self-review + AI-assisted review) and the RLS test suite. SAST in CI (CodeQL or Snyk) is planned, not in place.
• Penetration testing: DeckTrust has not commissioned an independent penetration test as of 2026-05-01. The commitment is an annual third-party penetration test commencing once either DeckTrust has 5 paying customers under contract or by 2027-05-01, whichever is earlier.
• Coordinated disclosure channel: security@decktrust.dev. Acknowledgement target: 5 Business Days. Triage: 10 Business Days. Remediation: per the Patch SLA above. PGP key publication and a .well-known/security.txt file are on the roadmap.

Source: vulnerability-management.md §3, §4, §6, §7, §9.

10. Compliance Posture

DeckTrust does not currently hold a SOC 2, ISO 27001, or other certification. This is honestly disclosed.

DeckTrust's subprocessors carry their own third-party certifications (typically SOC 2 Type II, with ISO 27001 and PCI-DSS Level 1 where relevant to the service provided). DeckTrust relies on each subprocessor's published security posture rather than on independent audit by DeckTrust. Vendor-by-vendor certification details are included in the subprocessor list provided to Customers and prospective Customers under NDA — see Section 1 above for the request process.

Source: information-security-policy.md §10, §14; subprocessors-public.md.

11. Customer Audit and Diligence Rights

Customers under a Master Services Agreement (MSA) have the audit rights set out in DPA §10:

• Annual questionnaire-style materials on request (no more than once per twelve-month period, except after a confirmed Security Incident affecting the Customer's Personal Data). Materials may include current Subprocessor SOC 2 reports under NDA, a written response to a reasonable security questionnaire (see security-questionnaire.md), and policy summaries.
• On-site or Customer-conducted audits are available where questionnaire materials do not satisfy a documented audit obligation under Applicable Data Protection Laws, on 30 days' written notice and under reasonable confidentiality terms.
• Regulator-compelled audits override the frequency limits.

Source: dpa-template.md §10.

12. Contact

For a full security questionnaire response (CAIQ-Lite + SIG-Lite hybrid), see security-questionnaire.md. For a customer onboarding runbook, see onboarding-checklist.md.

Roadmap Summary (Planned, NOT Current Controls)

The following items are explicitly not in place today and must not be cited as current controls:

• Application-level aal2 enforcement for admin and client_admin.
• WebAuthn enabled in DeckTrust's project.
• HIBP API breached-password check.
• GitHub branch protection on main and CI-side enforcement of quality gates.
• Committed .github/dependabot.yml and CI-side npm audit gate.
• SAST in CI (CodeQL or Snyk); DAST in non-production.
• Customer-managed encryption keys (CMK) for Postgres and Storage.
• First quarterly restore drill (target: within 90 days of policy publication).
• Reflecting RPO/RTO contractually in the SLA, once exercise-verified.
• Cross-region disaster recovery; scheduled pg_dump to cold storage.
• Centralized log aggregation; comprehensive privileged-action audit logging; documented per-scenario runbooks.
• Annual third-party penetration test (trigger: 5 paying customers under contract OR 2027-05-01, whichever earlier).
• SOC 2 Type I — evaluated against customer demand.
• 24×7 on-call rotation (gated on a second engineer or paid premium-support tier).
• Published .well-known/security.txt and PGP key for security disclosures.
• Bug-bounty program.
• First formal Sev1 tabletop exercise (target: within 90 days of policy publication).

Roadmap is consolidated from: information-security-policy.md §14; access-control-policy.md §11; backup-recovery.md §8; incident-response-plan.md §10; vulnerability-management.md §9; breach-notification.md §8.