Information Security Policy¶
| Field | Value |
|---|---|
| Status | draft |
| Owner | DIR (director/operator) |
| Applies to | All Partile systems, data, code, and the operator and any future contributors; all idea worktrees (infra, mobile, ops, cloudflare) and the Atelier workflow. |
| Review cadence | Annual, or on material change to systems/risk. |
| Mapped controls | GOV-01, GOV-03, OPS-04, and the SEC-* family (top-level). |
| Evidence | This data room; READINESS.md decision log; readiness/threat-model-and-auth-review.md; Git history. |
| Exception handling | See Exceptions below — DIR records any deviation in READINESS.md decision log with a rationale and review date. |
Purpose¶
State, in one place, how Partile protects the confidentiality, integrity, and availability of its information — appropriate to a small remote company building a stranger-matching travel product where matching moves people from online to physical co-location, which makes security and safety the same problem.
Principles¶
- Honest evidence over claimed maturity. Controls are recorded at their true
status (
not started→operational). Overstating is evidence against us. - Build security in, don't bolt it on. Privacy/security/safety controls
accrue per-PR (see
change-management-policy.md), not in a pre-audit sprint. - Minimize by construction. We do not collect or retain what we do not need (e.g. no raw boarding-pass artifacts; session tokens stored only as hashes).
- Defence in depth. Authorization is enforced in SQL, not only at routes; block separation is enforced at every read/derive path.
- Two-tier data room. Governance evidence is in Git; sensitive operational
records are restricted (
data-classification-and-handling-policy.md). - No secrets in the repo, ever. Secrets live in environment/Secret Manager, never in code, logs, or this data room.
Scope of the ISMS (current)¶
- In scope: the backend (auth, presence, matching, messaging, safety), mobile client, GCP production stack, Cloudflare API/data-room edges, the LinkedIn identity integration, the Git/Atelier development workflow, and the data room itself. The AWS staging path is retained only as superseded evidence.
- Out of scope today (with reason): physical/office controls — no office, no
paper, no owned data centre. Recorded in
not-applicable-controls.mdand../registers/not-applicable-register.md.
Roles & responsibilities¶
Roles, not people (the operator currently holds most). DIR owns the ISMS,
risk, governance, incident command, and counsel hand-off. INFRA owns backend
security and secure development. OPS owns infra/cloud, Secret Manager,
backups, and production preflight. MOBILE owns client-side data handling.
COUNSEL ratifies legal/privacy positions (queued in ../counsel-queue.md).
Policy statements¶
- All work lands through reviewed, version-controlled PRs (
change-management- policy.md);mainis the integration point and the audit trail. - Access to data and systems is least-privilege and reviewed
(
access-control-policy.md,../procedures/access-review-procedure.md). - Data is classified and handled per
data-classification-and-handling-policy.md; cryptography and secrets percryptography-and-secrets-policy.md. - Risks are tracked and treated per
risk-management-policy.md; the live risk evidence isreadiness/threat-model-and-auth-review.md. - Security incidents and personal-data breaches follow
incident-response- policy.mdand the 72-hour ICO clock. - ML/data governance — including the Art 9 / safety-data / Art 22 hard
constraints — follows
ai-ml-data-governance-policy.md.
Exceptions¶
No control is silently skipped. A deviation from any policy is recorded by DIR in
the READINESS.md decision log (or ../counsel-queue.md if it is a legal call)
with: what is deviated, why, compensating measure, and a review/expiry date. The
control register row is annotated. Risk-acceptance is a dated decision, never a
default.