← Legal & compliance

Security

Sign in

Draft administrative policies

  • Subject to attorney review before commercial launch — not legal advice or a binding contract until published by the operator.
  • No certification claims: not SOC 2, HIPAA, PCI DSS, or bank-level certified.
  • Billing: subscription status may be shown; payment card numbers are not stored in the application database.
  • Support access: vendor staff cannot access your tenant silently; tenant OWNER approval is required for time-boxed support sessions.

Check Designer — Security Policy (Draft)

Status: Draft administrative/security policy — subject to attorney review before commercial launch.

1. Purpose

This policy summarizes security measures implemented in Check Designer for SaaS operation. It is not a certification document and does not guarantee prevention of all security incidents.

2. Scope

Applies to the Check Designer web application, API routes, database, and operator-managed hosting environment described in deployment documentation (e.g., Next.js app behind HTTPS reverse proxy, PM2 process manager).

Current production database: SQLite (`prod.db`) per operator configuration. PostgreSQL migration is planned separately and does not change this policy’s principles (encryption format, access model).

3. Authentication and authorization

ControlDescription
AuthenticationEmail/password login; session cookies; `SESSION_SECRET` for signing
Tenant isolationAPIs use tenant scope — records filtered by `tenantId`
Role-based accessOWNER, ADMIN, CHECK_DESIGNER, PRINT_OPERATOR, VIEWER_AUDITOR, SUPPORT, etc.
Route permissionsSensitive routes call `requireRoutePermission` / `requireTenantScope`
Platform separationPlatform routes require platform operator context — separate from tenant sessions
Billing guardsOptional capability limits when `BILLING_ENFORCEMENT_ENABLED=true` (default off)

4. Sensitive check and bank data

4.1 Classification

Routing numbers, account numbers, signature images, and MICR-composed account data are high sensitivity. Printed check records contain payee and amount data appropriate for financial record-keeping.

4.2 Encryption at rest

When `BANK_DATA_ENCRYPTION_KEY` is set:

  • Algorithm: AES-256-GCM
  • Encoding: `enc:v1:` prefix with base64url IV, tag, and ciphertext
  • Key derivation: 64-char hex key or scrypt from passphrase with fixed salt (`check-designer-bank-v1`)
  • Applies to stored account number and signature fields — not a claim of full-database transparent encryption

Production: Missing key prevents correct operation in production mode.

4.3 Masking and reveal (API/UI behavior)

  • List/detail APIs return masked account numbers (e.g., `*****4321`) by default
  • Full account number and signature image require `account.reveal` permission and explicit reveal request
  • MICR printing uses decrypted account data only from linked accounts — masked display values cannot be used for MICR (enforced in application logic)
  • Saving an account preserves existing ciphertext when the user submits empty or masked placeholder input

4.4 What we do not store

  • Payment card numbers (billing foundation has no card storage)
  • `BANK_DATA_ENCRYPTION_KEY` in the database or audit log

5. Audit logging

Significant actions create `AuditLog` rows with action codes (e.g., login, template changes, print, void, support lifecycle, billing updates). Metadata is JSON and should exclude raw secrets — application code redacts known sensitive keys from audit payloads.

Audit logs support accountability; they are not immutable blockchain records.

6. Support access security

See `SUPPORT_ACCESS_POLICY.md` and `SUPPORT_ACCESS_IMPLEMENTATION_REVIEW.md`. Summary:

  • OWNER-only approve/deny/revoke/create (not ADMIN).
  • SUPPORT must explicitly activate an approved session; signed cookie + ACTIVE status required.
  • 24-hour maximum session duration; automatic expiry.
  • Scoped stores and permissions; `account.reveal` cannot be granted to support sessions.
  • `support.impersonate` is not granted to any role.
  • Platform portal: read-only support session metadata; no tenant impersonation.
  • Suspended tenants: support sessions ended/revoked; tenant APIs blocked.

7. Transport and infrastructure

MeasureNotes
HTTPSExpected in production (TLS termination at reverse proxy)
Secrets in `.env``DATABASE_URL`, `SESSION_SECRET`, `BANK_DATA_ENCRYPTION_KEY` — never committed to source control
BackupsContain full DB — protect backup storage as Tier A assets

Operator hardening: firewall, SSH access control, OS updates — per `PRODUCTION_HARDENING_CHECKLIST.md` (operator doc).

8. Vulnerability and change management

  • Dependencies updated through normal development/release process
  • Security patches applied by operator on deployment schedule
  • No bug bounty program described in this draft

9. Customer responsibilities

  • Strong passwords and timely deprovisioning
  • Protect downloaded backups and JSON exports
  • Maintain `BANK_DATA_ENCRYPTION_KEY` confidentiality on self-hosted installs
  • Verify physical check security and printer access

10. Explicit non-claims

This policy does NOT state or imply:

  • SOC 2 Type I/II certification
  • HIPAA compliance or BAA availability
  • PCI DSS certification (card data not stored in-app today)
  • Bank regulator approval or “bank-grade” security
  • Attorney-reviewed legal adequacy

11. Contact (placeholder)

Security reports: *[security@example.com — placeholder]* Privacy: *[privacy@example.com — placeholder]*

*Draft only — no application security behavior changed in Phase 2P-A.*