Roadmap: Compliance and Security Posture for Enterprise Buyers

Gap statement: strong security engineering, zero procurement collateral

Wikantik's security engineering is genuinely good — but none of it is packaged in the form enterprise procurement consumes: certifications, whitepapers, DPAs, and compliance documentation. In the RAG market, these are described as table stakes, not differentiators. The self-hosted model softens the requirement (customer data never leaves their infrastructure) but does not eliminate it: buyers still checklist the vendor's practices before running its code on their data.

Owner gate: compliance and legal claims are [OWNER] territory throughout this brief. An agent may draft, map, and inventory; nothing compliance-related is published externally without owner review, and GDPR/regulatory interpretations are never presented as legal advice.

Market grounding

Certifications as table stakes: SOC 2 Type II and GDPR compliance are baseline for enterprise RAG procurement; Onyx claims SOC 2 Type II + GDPR with ISO 27001 in progress; Azure stacks SOC 1/2/3, ISO 27001, HIPAA, PCI DSS, FedRAMP High; Bedrock KB is available in GovCloud at FedRAMP High (Onyx enterprise RAG platforms, Azure AI Search guide, Sphere, best enterprise RAG platforms 2026).
The 2026 regulated-buyer checklist: compliance documentation, self-hosted/VPC deployment flexibility, auditable retrieval logs, and permission-inheritance enforcement (Sphere, same source). Wikantik already has two of the four — the missing two are documentation and external ACL inheritance (RoadmapExternalAclInheritance).
GDPR mechanics: continuous delete propagation from source systems (right to be forgotten) is a compliance requirement for synced corpora, which lands on the connector framework's tombstone handling (Truto, multi-tenant RAG isolation).
Vendor security posture as a sales asset: Unstructured advertises SOC 2 Type 2, HIPAA, per-org credential encryption, zero persistent retention (Unstructured).

Current Wikantik state (the controls already exist)

Tamper-evident audit log (/admin/audit*); checkPermission as the audited enforcement chokepoint.
SCIM 2.0 provisioning (IdP-driven offboarding — an SOC 2 access-control story), SSO with fail-closed identity binding, session rotation, CSRF/CSP/security headers, NIST 800-63B password policy with blocklist, bcrypt, deserialization filtering, unified user-lifecycle decommission.
Retrieval surfaces enforce view ACLs; the ontology's public/restricted split keeps restricted content out of public RDF entirely.
Nothing published: no security whitepaper, no threat model document, no DPA template, no pen-test report, no compliance mapping.

Proposed direction (cheapest credibility first)

Security whitepaper (weeks, not months): architecture, auth model, ACL enforcement points, audit log design, data flows including the Ollama inference boundary, deployment hardening guide. This is mostly writing down what exists.
SOC 2 mapping, then readiness: map existing controls to the Trust Services Criteria; the gap list becomes the program. Note SOC 2 audits an organization, not code — for a single-maintainer project, this is only worth starting when a commercial entity exists (RoadmapPackagingAndPricing).
GDPR data-subject tooling: user data export and erasure endpoints; delete propagation through connectors, embeddings, KG nodes, and citations — an inventory of everywhere a person's data lands.
Auditable retrieval logs: extend the audit log to cover retrieval events (who retrieved which sections, when) with per-tenant scoping and retention policy — the Azure reference architecture explicitly requires grounding-data access logs.

Phase 1 scope and acceptance criteria

First session scope: the security whitepaper skeleton with the architecture, auth-model, and ACL-enforcement sections drafted — every claim traceable to code or config.

Phase 1 (whitepaper) is done when:

All six sections exist: architecture overview, authentication model, ACL enforcement points (with the actual chokepoints named), audit log design, data flows including the Ollama inference boundary, and a deployment hardening guide.
Every claim carries a code/config reference — no aspirational statements; a reviewer can grep each claim to its implementation. Anything not yet true goes in an explicit "roadmap" appendix, clearly separated.
The erasure-inventory draft exists: a table tracing one user's data through pages, versions, embeddings, chunks, KG mentions, citations, query logs, and briefing logs.
[OWNER] has reviewed and approved before any external publication — this gate is part of the DoD, not optional.

Verify before designing on these

Competitor certification claims (Onyx SOC 2, Azure FedRAMP) are market context; do not restate them in the whitepaper without checking their current status.
The "regulated-buyer checklist" comes from a vendor listicle — useful as a structure, not as a compliance authority.
Any GDPR mechanism described here (erasure scope, delete propagation) is an engineering interpretation — counsel review is an [OWNER] action before it appears in customer-facing material.

Non-goals

No certification pursuit (SOC 2, ISO 27001) until a commercial entity exists — mapping and readiness only.
No agent-published compliance claims — everything externally visible passes the owner gate.
No retrieval-audit implementation in this brief beyond design — the audit-event table rides the observability work (RoadmapRetrievalEvaluationObservability).

Investigation starting points

[AGENT] Control mapping: existing controls vs SOC 2 CC-series criteria — which are code (done), which are process (missing: change-management evidence, vendor management, incident-response runbooks)? Produce the gap list; [OWNER] accepts it.
[MEASURE] Retrieval audit volume: what does logging every bundle/section access at the 480 RPS envelope cost in storage — sample, aggregate, or full-fidelity per tenant?
[AGENT] Erasure completeness trace (acceptance item 3 above) — what does "forgotten" actually require in each store?
[OWNER] Third-party pen test scoping, vendor, and timing (post-whitepaper, pre-first-enterprise-customer) — spend decision.