SOC 2 — Common Criteria + TSC
Mapping of all CC1.x–CC9.x criteria plus the optional Availability, Processing Integrity, Confidentiality, and Privacy categories.
Security, privacy, and compliance
Built for governed data from day one
kiLM ships the controls auditors ask for — SOC 2 Common Criteria, HIPAA Security Rule mapping, GDPR-aligned PII handling, sensitivity-class enforcement, and a full audit trail — and documents each one in the customer install so your security team can sample evidence directly from the running system.
Framework coverage
Each badge below maps to documentation that ships inside every install + cites the source file + runtime evidence an auditor can sample.
HIPAA Security Rule
Administrative, Physical, and Technical safeguards mapped to controls — with BAA-readiness checklist and cloud-provider boundary.
GDPR + privacy-by-design
Data-subject erasure path, retention policy enforcement, lawful-basis audit, and PII-class redaction in chat output.
Air-gap ready
Run with zero outbound network. Optional intake-only and managed-mode profiles for less-strict deployments.
Data handling posture
Three deployment profiles let you pick exactly how much trust the install needs to extend outside its own perimeter.
Airgap
Zero outbound connectivity. License + telemetry rotate via signed offline bundles. Suitable for defence, intelligence, and the strictest regulated industries.
Intake-only
Inbound MCP, SharePoint, email, and cloud-storage ingestion permitted; outbound is allow-listed per-connection with auto-classification (intranet vs internet) and per-caller burst detection.
Polycracy-managed
We run the EC2; you keep the data + the configuration overrides. Patch flow is auditable via vendor portal heartbeats with HMAC-signed payloads.
PII + sensitivity-class enforcement
Every chunk of every document carries a sensitivity classification (public / internal / confidential / restricted / secret). The classification follows the data across vector / lexical / graph / visual retrieval legs, and the chat agent will refuse to surface a chunk a user's role can't see.
Field-level encryption for sensitive tiers
Confidential, restricted, and secret tiers are encrypted at the column level with keys managed via KES. Fail-closed on decryption error — no plaintext leakage on misconfiguration.
Cascade erasure on subject request
A GDPR subject-erasure request soft-deletes the source document and supersedes every downstream chunk, vector, graph edge, and visual artifact. Lineage is preserved for audit; content is not.
PII redaction at chat-output time
A second-pass redactor runs over the LLM's drafted answer before it reaches the user, scrubbing any PII the model surfaced that the caller's role isn't cleared for.
Sensitivity-class drift detection
Daily reconciliation cross-checks the source-of-truth classification against the mirrored classification on every retrieval store. Any drift fires a high-severity finding the admin can resolve in one click.
GDPR alignment
Six concrete points map to the GDPR articles your DPO will ask about — each backed by a shipped feature, not just a paragraph in a policy doc.
Article 5 — Lawful, fair, transparent
Every admin write is audited with a mandatory change reason. Every retrieval that touches sensitivity-classed content is recorded with caller, timestamp, and classification — sampleable from the live install.
Article 15 — Right of access
Per-user activity bundles via the Users Dashboard plus on-demand report renderings (DOCX + PDF) the customer admin can hand back to the data subject.
Article 17 — Right to erasure
Cascade-erasure worker soft-deletes the source plus every downstream artifact across all six stores. Lineage rows stay for audit; content does not.
Article 25 — Data protection by design
Module gates default OFF for destructive features; the centralised require_admin / require_executive dependency enforces role separation at every endpoint; air-gap mode is one env-flag away.
Article 30 — Records of processing
Per-domain schemas plus the data-domain registry document what each corpus holds. Domain-classifier flags mis-routed documents (e.g. PII landing in 'enterprise') before they're indexed.
Article 32 — Security of processing
Field-level encryption for sensitive tiers, mTLS via the edge gateway, integrity-verifier scheduled workflow, backup-drill daily probes, and cross-store reconciliation. The full SOC 2 matrix maps each control to a source file.
Audit trail commitment
Every admin write is recorded in append-only tables. Auditors don't take our word for it — they sample directly from the live install.
- Module configuration changes — before-and-after value, who, when, and the mandatory reason.
- Compliance authoring edits — sensitivity vocabulary and role-grant changes, each with a mandatory reason.
- Policy decisions — every authorization check captured with input, decision, and reasoning trace.
- External tool calls — caller, tool name, and the sensitivity clamp applied to the result.
- Retrievals on classed content — role, classification tier, and deployment domain.
- Vendor telemetry — HMAC-signed payloads with counts-only data (no PII).
- Release lineage and integrity — what was installed, when, by whom, and the verification result.
Disaster recovery + HA
Per-tier RTO and RPO targets are documented for every backing store. Daily backup-drill probes verify the targets are real, not aspirational.
Hard recovery targets
Postgres (4h RTO / 15min RPO with WAL) and MinIO (4h RTO / 1h RPO with versioned buckets) are the only stores that must be restored from snapshot. Everything else is re-derivable from these two.
Re-derivable stores
Qdrant, OpenSearch, Neo4j, and Feast all re-converge from Postgres on restore. The reconciliation worker fires automatically once Postgres is back.
HA topologies tested
CloudNativePG operator on Kubernetes for Postgres, Qdrant clustered mode with replication_factor=2, MinIO distributed mode with erasure coding, Neo4j causal cluster for graph.
What we don't do
Honest scope matters more than marketing claims. Here's what we explicitly don't ship — so a security review team knows where the customer-side responsibility starts.
- We don't substitute for your cloud-provider BAA. AWS / Azure / GCP BAAs cover physical safeguards; ours covers the application layer.
- We don't run your password policy. Keycloak does, and you configure it via the AuthPolicies admin page.
- We don't manage your workstation security. Endpoint policy is your IT team's responsibility.
- We don't claim SOC 2 Type II certification on this page. Our controls matrix maps every criterion to shipped code — the certification itself is a customer-side audit engagement that uses our matrix as the starting point.
- We don't ship a multi-tenant SaaS by default. kiLM is single-tenant per install; that's a deliberate trust + air-gap choice.
Read the full docs inside any install
Every install bundles four customer-facing compliance documents that load into the system documentation corpus on first run. Your chat agent answers questions like "are we SOC 2 ready?" and "what is our recovery-point objective for the primary store?" from these primary sources — sampleable by your security team directly from the running install.
- SOC 2 controls matrix — every Common Criterion mapped to a shipped control.
- HIPAA Security Rule mapping — Administrative, Physical, and Technical safeguards plus BAA-readiness checklist.
- Disaster-recovery + HA runbook — per-store RTO/RPO targets and the verification cadence.
- Vulnerability disclosure + encryption posture — reporting channel, response SLA, and the encryption inventory.
Have a security question?
Email security@polycracy.example for vulnerability reports, or use the contact form below for procurement-stage security reviews.