Access Control Policy
| Owner | [Security Owner — to be named: founder/CTO] |
| Approved by | [signatory] |
| Effective date | [set on approval] |
| Review cadence | Annual; access reviews quarterly |
| Version | 0.1 — DRAFT |
| TSC mapping | CC6.1–CC6.3, CC6.6 |
1. Purpose
Section titled “1. Purpose”Ensure that access to Ordermatic systems and data is granted on a least-privilege basis, authenticated strongly, isolated per tenant, and reviewed regularly.
2. Authentication
Section titled “2. Authentication”- Application authentication is delegated to Clerk (RS256/JWKS verification,
packages/auth/src/server.ts); the Company stores no first-party passwords. - Multi-factor authentication is required for all personnel on every system that supports it: the identity provider (Google Workspace), version control (GitHub), cloud infrastructure (Google Cloud), the secrets manager, and the password manager.
- Each person has a unique individual account on every infrastructure and version-control system. Shared/role accounts are prohibited.
3. Authorization & tenant isolation
Section titled “3. Authorization & tenant isolation”- Default-deny: requests are rejected unless explicitly authorized
(
packages/auth/src/middleware.ts). - Tenant isolation: every data path filters by
clerkOrganizationId; no cross-organization data access is possible through the application. - Least privilege: roles grant only the access a function requires. Production-impacting actions (e.g. ERP writes) are additionally feature-flag-gated.
- Privileged/support access is audited: any support-admin access to tenant
data is logged via
SupportAccessAudit.logAccess().
4. Provisioning & deprovisioning
Section titled “4. Provisioning & deprovisioning”- Onboarding: access is granted by role on hire via a documented checklist; the new hire acknowledges the Acceptable Use Policy and enables MFA before receiving access.
- Offboarding: on termination, access is revoked promptly (target: same business day) across Clerk, Google Workspace, GitHub, Google Cloud, Neon, Infisical, 1Password, and Cloudflare. Offboarding is tracked as evidence.
5. Secrets & key management
Section titled “5. Secrets & key management”Credentials and keys are stored in Infisical (/runtime/<service>) and
1Password, read at runtime, and never committed to source or written to
logs. Rotation follows the secret-rotation runbook.
6. Periodic access review
Section titled “6. Periodic access review”A quarterly access review is performed across all systems above. The Security Owner confirms that each account still maps to a current person and an appropriate level of access; findings are remediated and the review is recorded (this is the program’s highest-frequency recurring evidence — CC6.3).
7. Review
Section titled “7. Review”Reviewed at least annually by the Security Owner.