Skip to content

Partile Data Room

An evolving, audit-ready evidence repository for privacy, security, ML governance, and trust & safety. Its purpose is to demonstrate compliance continuously — so that audits, certifications (SOC 2 / ISO 27001), regulator inquiries, enterprise security reviews, and investor/M&A due diligence are answered from here rather than scrambled for.

This operationalizes the GDPR accountability principle (Art 5(2)): it is not enough to be compliant; we must be able to show it on demand, with dated, attributable evidence. Git history is that audit trail — every change here is timestamped and attributable.

This is not legal advice. Items needing qualified legal/privacy counsel are marked [counsel required]. Provisional framework mappings must be confirmed by counsel before they are relied upon externally.

Where This Lives (worktree vs director-root)

The data room is maintained as a first-class Atelier workstream in the dataroom idea worktree. It is the canonical, version-controlled evidence pack. It does not replace the director-root readiness artifacts; it is the audit-facing crystallization of them.

Artifact Home Role
dataroom/ (this tree) dataroom worktree Canonical evidence pack: control register, product spec/decision log, registers, policies, procedures, evidence index. Git-safe (Tier 1).
READINESS.md director-root (/home/dgx/partile) The cross-cutting backlog + decision log for taking Partile to 1M users. The plan.
readiness/*.md director-root The narrative design docs (data inventory, threat model, ML taxonomy, safety baseline). The why.

Relationship rule: READINESS.md is the director-owned plan and decision log; this data room is the audit-ready evidence layer that proves the parts of that plan which are actually true. The data room's control statuses are derived from real evidence (code paths, merged PRs, registers), not from the backlog's intentions. When READINESS.md says a thing is planned and the data room says it is not started, both are correct: the plan exists, the control does not yet operate. The director-root files are not edited from this PR — sanitized content is synthesized into this worktree instead.

Narrative docs are referenced by name (e.g. readiness/threat-model-and-auth- review.md) as evidence pointers; they live director-root and are not duplicated here.

Structure

dataroom/
  README.md                ← you are here: what this is, how to use it
  control-register.md      ← THE INDEX: one row per control, crosswalked to
                             SOC 2 / ISO 27001:2022 / UK GDPR, with evidence links
  counsel-queue.md         ← the consolidated lawyer hand-off pack
  cfo-charter.md           ← CFO (Ernst) charter: read-only financial visibility
  agent-enablement-register.md ← Vera's agent-operability audit (dated snapshot)
  product/
    user-journeys.md        canonical professional-networking journeys
    product-spec.md          live product-owner spec + working assumptions
    product-decisions.md     product decision / assumption log
  registers/               ← the formal registers auditors ask for
    ropa.md                  Record of Processing Activities (Art 30)
    retention-schedule.md
    subprocessors.md
    dsar-log.md              (pointer-only; sensitive instances live restricted)
    incident-log.md          (pointer-only; sensitive instances live restricted)
    not-applicable-register.md  controls scoped out today, with rationale
    action-register.md       open items and accepted risks
    vendor-spend.md           CFO vendor & spend register (Prepared by Ernst)
    renewal-calendar.md       renewal / billing lapse-risk calendar (Ernst)
    spend-report-template.md  monthly spend report format (Ernst)
  policies/                ← the policy layer (ISO 27001 / SOC 2 shaped)
    policy-index.md          the index of policies + ownership + cadence
    *.md                     individual policies (information security, access
                             control, secure development, incident response, …)
    not-applicable-controls.md  physical/office controls scoped out, with rationale
  procedures/              ← focused operating procedures the policies point to
    access-review-procedure.md
    onboarding-offboarding-procedure.md
    incident-response-playbook.md
    vulnerability-triage-procedure.md
    release-review-procedure.md
  evidence/
    evidence-register.md     evidence types, retention, Git-vs-restricted placement
  technical/
    README.md                live CTO / technology diligence pack index
    architecture-overview.md, data-architecture.md, security-architecture.md,
    infrastructure-and-deployment.md, sdlc-and-quality.md  (baseline pack)
  intranet/
    index.html               static local navigation layer (open from disk)
    build.py                 stdlib generator that bakes index.html from the tree
    README.md                how to open/use/regenerate the intranet

Intranet (navigation layer)

For a quicker review path, intranet/index.html is a static, repo-contained page that surfaces current state, blockers, control/evidence coverage, and entry points into the product/technical/policy/register/counsel material. It links back to these canonical Markdown files and is not a second source of truth. Open it directly from disk (file://.../dataroom/intranet/index.html) - no server needed - and regenerate it with python3 dataroom/intranet/build.py after docs change. See intranet/README.md.

The control register is the spine. Each control links out to its evidence — a readiness narrative doc, a code path/PR in an idea worktree, a register, a policy/procedure in this tree, or a restricted artifact. The narrative docs explain why; the policies state the rule; the procedures state how; the register proves that, who owns it, when it was last verified, and to which framework clauses it maps.

Two-Tier Rule (important)

Some evidence is itself sensitive. We separate:

  • Tier 1 — governance/evidence (in git, here): policies, procedures, registers, control statements, decisions, threat models, design docs. Safe to version within the company. No secrets, PII, raw credentials, full ARNs, real incident details, raw exploit write-ups, vendor account IDs, or counsel-private advice.
  • Tier 2 — sensitive operational records (restricted store, NOT in repo): actual DSAR/erasure request contents, real incident records with PII, raw pentest exploit detail, signed DPAs, entity/contact details. The git room points to these; it does not contain them.

dsar-log.md and incident-log.md are deliberately pointer-only for this reason. The split is defined formally in evidence/evidence-register.md and policies/data-classification-and-handling-policy.md.

No-Secrets / No-PII Rule

Nothing in this tree may contain: secrets or credentials; access keys or private keys; .env values; token-bearing or signed URLs; OAuth handoff/authorization codes; real personal data of any user; account contact details; full ARNs or raw cloud-provider JSON; vendor account IDs beyond already-public project context; or counsel-private legal advice. Safe labels (e.g. DATABASE_URL, RETENTION_SESSIONS_DAYS) are fine; values are not. Every PR touching this tree runs an rg secret/PII scan (see notes of each PR and the release-review procedure). When in doubt, it is Tier 2.

Status Model (shared with READINESS)

Status Meaning
not started Recognized; no design or owner yet.
designed Approach written down; not built.
implemented Built and merged; not yet proven under realistic conditions.
verified Demonstrated against acceptance criteria.
operational Running with owner, monitoring, and runbook.

Honesty rule: only claim what is true. A control we have not built is not started/designed, never dressed up. A data room that overstates is evidence against us — overclaiming a control is worse than admitting a gap. A drafted policy supports designed; it does not by itself make a control implemented, verified, or operational. Those require evidence the process actually operates.

Upkeep (how it stays current)

Every PR that touches privacy, security, data, ML, safety, availability, or compliance must update the relevant control row (status, evidence link, last-verified date) or state why it is unaffected. Compliance accrues as a byproduct of the work — never as a pre-audit sprint. This mirrors the rule in READINESS.md.

Every passed PR that changes or clarifies user-facing behavior, product policy, release scope, safety behavior, consent behavior, messaging behavior, platform support, or event semantics must update product/product-spec.md and, when a product assumption/decision is created or changed, product/product-decisions.md. Product decisions use working assumptions by default and do not block execution unless the operator explicitly asks or the choice would cause major rework if wrong.

Ownership & Review Cadence

Owners are roles, not people (a pre-team company): DIR (director/operator), INFRA (backend executor), OPS (infra/ops executor), MOBILE (mobile executor), COUNSEL (legal/privacy). Today most roles are held by the operator; the role split is what scales when people are hired.

Document class Owner Review cadence
Control register DIR Per-PR (live); full pass quarterly
Product spec / decision log PRODUCT OWNER / DIR Per-pass when product behavior/scope changes; full pass quarterly
Registers (RoPA, retention, subprocessors, DSAR, incident, action) DIR / COUNSEL / OPS Per-PR when touched; quarterly + on any new processing/vendor/risk
Policies DIR Annually, or on material change to systems/risk
Procedures DIR Annually, or after any execution that exposes a gap
Counsel queue DIR → COUNSEL Accumulate continuously; counsel one-pass before private beta (M2)

Cadence is aspirational until a control is operational: a draft policy's "annual review" clock starts when it is adopted, not when it is drafted.

Framework Legend

  • SOC 2 — AICPA Trust Services Criteria (CC = Common Criteria; P = Privacy; C = Confidentiality; A = Availability). Security (CC) is the only mandatory category; we also track A/C/P and ML governance because they are central to product risk.
  • ISO 27001 — ISO/IEC 27001:2022 Annex A control references (A.5–A.8). The standard is an ISMS/risk-management system; this room prepares the evidence shape, it does not claim certification.
  • UK GDPR — UK GDPR / DPA 2018 article references. [counsel required] before external reliance.