Trust

SMC operates the platform we sell. The controls SMC leads on client engagements — least privilege, separation of duties, audit trail, defense in depth, data minimization, encryption at rest, MFA — are the same controls the platform enforces on itself. This page lists them, as of 2026-09-29.

The authoritative source is docs/SECURITY-MODEL.md in the platform's repository. If this page and that doc disagree, the doc wins — please flag it to jvenuto@securitymedic.com.

Identity & access

▸ Passwordless authentication via Auth.js v5 email magic-link. No password storage. No password-reset attack surface.
▸ Fail-closed admission. Operators must be on the operator allowlist (an empty allowlist admits no operator). Invited client users require an active recipient approval bound to their account and client.
▸ Multi-factor authentication: passkeys (WebAuthn) or an authenticator app (TOTP, RFC 6238; compatible with Google Authenticator, 1Password, Authy, Bitwarden, Microsoft Authenticator). Client portal users must enroll one; setup recommends passkeys. Operators who enroll a factor must clear MFA for their session. TOTP secrets are stored application-encrypted; backup codes are hashed with per-user salt.
▸ Role-based access control: operator | client-admin | client-viewer. Client-portal users are tenant-scoped to their own client's data; operators never cross into a client's portal view.
▸ Step-up authentication on dangerous actions (delete client, delete claim, mark board report delivered). 5-minute re-auth window.

Data protection

▸ TLS in flight (Vercel + Neon). At-rest encryption from Neon plus application-level AES-256-GCM encryption on sensitive columns: client notes, finding descriptions, evidence inline text, claim text, verification notes, coach signal bodies, regulatory summaries, KB source content, KB wiki bodies. Each ciphertext carries a 12-byte random IV and 16-byte GCM auth tag — tampered content fails decryption cleanly rather than returning corrupt plaintext.
▸ Encryption key rotation quarterly. A previous key can be held during rotation windows so old rows decrypt while new writes go to the fresh key.
▸ Tenant boundary: every domain row carries a clientId. Cross-tenant queries either filter explicitly by client OR are wrapped in crossTenant(rationale, …) with a documented reason. An audit script scans the codebase; a lint rule blocks unscoped queries in client-portal code.

Audit & integrity

▸ Immutable audit trail — every mutating server action writes anaudit_event row (actor, action, entity, before/after snapshot, source metadata). CI blocks any mutating action lacking an audit call.
▸ 7-year retention (HIPAA-aligned) with a legal-hold flag that prevents purge on regulator or contract request.
▸ Sealed snapshots — delivered board reports and claim verifications each carry a SHA-256 hash over their contents. Tampering surfaces as a broken-signature banner on the report / detail view.
▸ Separation of duties — the user who asserts a control claim cannot verify it, unless an explicit override rationale is recorded in the audit event.

Backup, recovery, & incident response

▸ Neon point-in-time recovery for hosted storage. Weekly logical export as NDJSON + SHA-256 manifest to independent storage. Monthly restore drill against a scratch instance — "you don't have a backup until you've restored it."
▸ Written incident-response playbook (docs/IR-RUNBOOK.md) — severity levels, first-30-minute containment, evidence preservation, breach notification per client contract SLA, post-incident review.
▸ Quarterly key rotation for AUTH_SECRET, RESEND_API_KEY, ANTHROPIC_API_KEY, SMC_ENCRYPTION_KEY. Annual rotation for the Neon connection string. Semi-annual tabletop exercises.

Supply chain

▸ npm audit --omit=dev --audit-level=high blocks every PR via CI (.github/workflows/security-checks.yml). A high or critical production-dependency finding fails the build.
▸ Dependabot enabled for weekly npm updates and monthly GitHub-Actions updates. Major upgrades on the auth stack held for manual review.
▸ Software Bill of Materials (SBOM) generated on demand via npm run sbom — Cyclone-DX-style JSON listing every production package + version + resolved integrity hash.

Governance

▸ Quarterly access review — a generated Markdown artifact enumerates the allowlist, every user + role + last-auth, and recommended actions (dormant users, users off the allowlist). Committed to the repo under docs/access-reviews/.
▸ Data retention policy per data class (audit log 7y, board reports 7y, KB indefinite, active client data through contract end + 2y).
▸ LLM provenance — every LLM call writes an audit event with model id, record counts, and a data-minimization marker. Client identifiers are stripped from cross-client-pattern prompts; regulatory-ingest prompts send only industry + adopted-standard slugs, never notes or findings.

What we do NOT claim

▸ Third-party attestations (SOC 2, ISO 27001) are on the roadmap; SMC has not completed a formal audit at time of writing. Informal SOC 2 Type I readiness artifacts are being produced.
▸ External penetration testing is planned — has not yet occurred.
▸ Passkeys (WebAuthn) and authenticator-app codes (TOTP) are both live; client portal users must enroll one of them (setup recommends passkeys).

Questions? Comments? jvenuto@securitymedic.com. For security-relevant reports, please include [security] in the subject.

← Home