← Legal & compliance

Privacy Policy

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 — Privacy Policy (Draft)

Status: Draft — subject to attorney review before commercial launch. Not legally binding until published by the service operator with an effective date.

1. Who we are (placeholder)

Service: Check Designer Operator: *[Legal entity name — to be completed]* Privacy contact: *[privacy@example.com — placeholder]* Address: *[To be completed]*

This Policy explains how we process personal and business information when you use the Service as a SaaS customer.

2. Roles

RoleDescription
Customer (tenant)Your organization is typically the controller of employee/user and payee data you enter
Service operatorWe act as a processor (or sub-processor) for tenant-hosted data, per contract and law
Platform operatorsSeparate staff accounts may manage tenant metadata (billing, suspend) without routine access to decrypted bank data

Counsel should confirm controller/processor roles for your deployment model (single-tenant vs multi-tenant hosted).

3. Categories of information we process

3.1 Account and access data

  • User name, email, password hash
  • Tenant membership, role, store permissions
  • Session cookies for authentication
  • Platform operator flag (`isPlatformOperator`) where applicable

3.2 Business and check operations data

  • Store/location names and codes
  • Check templates, fields, versions, printer settings
  • Print queue and printed check records (amounts, dates, payee text, check numbers, status)
  • Sample check data for design/testing
  • Audit log entries (action, actor, timestamp, safe metadata — not full decrypted bank fields in routine logs)

3.3 Sensitive financial data

  • Bank routing/account numbers and signature images — stored encrypted at rest in the database using AES-256-GCM (`enc:v1:`) when `BANK_DATA_ENCRYPTION_KEY` is configured
  • API responses use masked account numbers by default; full values appear only when a user with `account.reveal` permission explicitly requests reveal

3.4 Support access records

  • Support session requests (OWNER-created), approvals, denials, revocations, activation, end, and expiry
  • Reason and ticket reference fields you provide
  • Scoped store IDs and permission names (metadata only — not bank or MICR content)
  • No silent access: vendor SUPPORT cannot view tenant data without an OWNER-approved, time-boxed, explicitly activated session (see `SUPPORT_ACCESS_POLICY.md`)

3.5 Billing metadata (foundation)

  • Plan code, billing status, period dates, usage counts
  • No payment card numbers, CVC, or full payment method details in the application database today
  • Stripe customer/subscription IDs are reserved for future integration and are not populated by live Stripe flows in the current release

3.6 Technical and security data

  • Server logs (should exclude decrypted secrets, MICR plaintext, and encryption keys when properly configured)
  • Backup files containing the database (see retention policy)

4. How we use information

We use information to:

  • Provide and secure the Service (authentication, authorization, tenant isolation)
  • Process print, queue, history, and reporting functions you request
  • Record audit events for accountability
  • Operate approved support sessions
  • Display subscription status and usage (enforcement off by default until operator enables it)
  • Maintain backups and perform recovery per operator runbooks
  • Comply with law and respond to valid legal requests

We do not sell tenant check data. Marketing use of personal data, if any, should be defined at launch with counsel.

5. Sharing and subprocessors

We may share information with:

  • Hosting and infrastructure providers (e.g., cloud VM, TLS certificates) — *[list at launch]*
  • Personnel bound by confidentiality, only as needed to operate the Service
  • Support staff only during an OWNER-approved, time-boxed support session (see `SUPPORT_ACCESS_POLICY.md`)
  • Legal/regulatory authorities when required by valid process

Future payment processing (e.g., Stripe) would receive billing contact data only if enabled — not implemented in current codebase.

A subprocessor list should be published before launch.

6. International transfers

*[To be completed: hosting region, transfer mechanisms, SCCs if applicable]*

7. Security measures (summary)

Administrative and technical measures are described in `SECURITY_POLICY.md`, including encryption at rest for protected bank fields, role-based access, audit logging, and support-access controls. No security program certifies perfect protection.

8. Retention

See `DATA_RETENTION_POLICY.md`. Summary: operational data is retained while your tenant is active and as needed for backups, audit, and legal obligations; deletion requests are handled manually per `ACCOUNT_DELETION_REQUEST_POLICY.md`.

9. Your rights and choices

Depending on jurisdiction, you may have rights to access, correct, delete, or export personal data.

9.1 Operational access (in-app)

  • OWNER and ADMIN users may use Settings backup/export features where permitted (see `DATA_RETENTION_POLICY.md` §7).
  • Database download is instance-wide on shared deployments — not a per-user GDPR export by default.
  • Project JSON export redacts account numbers and signatures in the file.

9.2 Export or deletion/redaction requests (manual)

For formal export review or deletion/redaction beyond in-app buttons:

1. Contact your tenant OWNER or ADMIN for organization-level requests. 2. Email the operator at *privacy@example.com* (placeholder) with tenant name, your role, scope, and request type. 3. The operator performs manual review — no instant automated erasure. Fulfillment may be deactivation, redaction, or selective deletion — not necessarily hard-delete of all records or backups. 4. Printed history, audit logs, billing records, and backups may be retained as described in `DATA_RETENTION_POLICY.md` and `ACCOUNT_DELETION_REQUEST_POLICY.md`.

In-app summary: Settings → Legal & compliance → Data export / deletion requests (draft). Full policy: `/legal/account-deletion` (draft).

Contact: *privacy@example.com* (placeholder) · *support@example.com* (placeholder)

10. Children

The Service is intended for business use, not children under 16 (or age defined at launch).

11. Changes

We may update this Policy. Material changes should be notified before effectiveness where required by law.

12. No certification claims

This Policy does not state or imply HIPAA, PCI DSS, SOC 2, or bank regulatory certification. Compliance depends on how you use the Service and on executed agreements and controls.

*Draft for planning — attorney review required before publication.*