Skip to content
Ordermatic Docs

Information Security Policy
Owner [Security Owner — to be named: founder/CTO]
Approved by [signatory]
Effective date [set on approval]
Review cadence Annual, and on material change
Version 0.1 — DRAFT
TSC mapping CC1, CC2, CC5

1. Purpose

Section titled “1. Purpose”

This is the master policy for Ordermatic, Inc. (“the Company”). It establishes that protecting customer data — purchase orders, ERP records, and the PII they contain — is a first-class engineering and business requirement, and it names the supporting policies that implement that commitment.

2. Scope

Section titled “2. Scope”

Applies to all personnel (employees and contractors), all Company-managed systems and code, and all customer and Company data processed by the Ordermatic platform. The platform is cloud-hosted (Google Cloud Run, Neon, Cloudflare R2); there is no Company-operated data-center.

3. Security ownership and governance

Section titled “3. Security ownership and governance”
  • The Security Owner (named above) is accountable for the information security program: policy maintenance, the control set, and remediation.
  • Management holds a quarterly security review (control status, open incidents, access-review results, vendor changes) with written minutes. This is the standing oversight cadence (CC1.2 / CC4.2).
  • Control ownership is tied to named people in the compliance platform (Drata), not left per-project (CC1.5).

4. Policy framework

Section titled “4. Policy framework”

The Company maintains the following policies; each is reviewed at least annually:

5. Principles (security by default)

Section titled “5. Principles (security by default)”

The Company’s controls are built into the codebase, not bolted on:

  • Least privilege & default-deny — every data path filters by tenant (clerkOrganizationId); access is denied unless explicitly granted (packages/auth/src/middleware.ts).
  • Secrets are never committed or logged — credentials are read at runtime from Infisical and 1Password; secret values are never written to files or logs (see AGENTS.md, CLAUDE.md).
  • Change is reviewed and gated — all code reaches production through reviewed pull requests and CI gates; ERP writes are feature-flag-gated.
  • Encryption everywhere — TLS in transit; AES-256-GCM at rest for sensitive credentials.

6. Compliance and enforcement

Section titled “6. Compliance and enforcement”

All personnel must read and acknowledge this policy and the Acceptable Use Policy on hire and annually. Violations are handled per the Acceptable Use Policy and may result in revoked access or termination. Security concerns are reported per the Incident Response Policy.

7. Review

Section titled “7. Review”

Reviewed at least annually by the Security Owner and re-acknowledged by the team. The annual review and re-acknowledgement are themselves operating controls.