Control catalogueTenancy, identity, encryption, audit and retention
The controls a security team asks about first, described as they are implemented rather than as they are aspired to. The full pack, including the framework mapping, is available under NDA.
Tenancy and isolation
- Tenancy model
- Single-tenant by construction. Every deployment is a dedicated install of the platform on infrastructure you control; there is no multi-tenant service and therefore no tenant-separation logic to fail.
- Network isolation
- Services run in a dedicated namespace or Docker network with explicit ingress rules. Outbound egress can be set to default-deny with no loss of function, including model loading and licence validation.
- Workload hardening
- Containers run as a non-root user with read-only root filesystems where the component permits, no privileged containers, and resource limits per workload. Kubernetes manifests ship with baseline network policies and pod security settings.
- Environment separation
- Production, disaster recovery and non-production are separate installs with separate credentials and separate storage. No shared control plane spans environments.
Identity and access
- Authentication
- OIDC and SAML 2.0 single sign-on against your own identity provider, with your MFA and conditional-access policies applied. Local accounts exist for break-glass use and can be disabled entirely.
- Authorisation
- Role-based access control mapped to your directory groups, with separate roles for administration, schema configuration, review-queue work and read-only audit access.
- Least privilege
- Service accounts are scoped per component with the narrowest storage and database grants that function. Administrative actions are separated from document access, so a platform administrator need not be able to read claim contents.
- Permissions-aware retrieval
- Question answering and search respect the document permissions of the asking user. A user cannot retrieve, cite or summarise a document they are not entitled to open — the access check happens at retrieval, not in a prompt instruction.
Encryption and key custody
- In transit
- TLS 1.2 or 1.3 on every interface, including service-to-service traffic inside the cluster, using certificates issued by your own PKI or your service mesh.
- At rest
- AES-256 for documents, extraction output, database contents and backups, applied through your storage and database encryption or the bundled configuration where you prefer it.
- Key custody
- Your KMS or HSM holds the keys. DocxIntel does not generate, escrow, export or transmit key material, and BizfyLabs holds no copy of any customer key. Rotation follows your policy and schedule.
- Secrets management
- Credentials are read from your secret store or from Kubernetes secrets backed by it. Nothing is baked into an image, and no default credential ships enabled.
Logging and audit trail
- What is logged
- Authentication, authorisation decisions, document access, extraction runs, schema and configuration changes, review-queue decisions, redaction actions and administrative operations — each with actor, timestamp, source and object.
- Immutability
- Audit records are append-only and can be streamed to your SIEM or to write-once storage, so the tamper-evidence guarantee comes from infrastructure you already have accredited.
- Field-level provenance
- Every extracted value retains its page number, bounding-box coordinates and confidence score, so an auditor can trace a posted figure back to the source region months later without re-running anything.
- Export
- Structured JSON logs to stdout, syslog or your collector, plus Prometheus metrics. Monitoring stays inside your estate — there is no vendor observability endpoint.
Data lifecycle and retention
- Where data lives
- In your object storage, your filesystem and your database. DocxIntel is stateless with respect to your documents beyond the processing window and holds no separate copy of its own.
- Retention policy
- Set entirely by you. Retention, archival and deletion follow your storage lifecycle rules, so the evidence you already produce for your regulator covers DocxIntel data without a separate vendor attestation.
- Caching
- No external cache of parsed documents. Intermediate artefacts live in storage you control and are cleared according to your configuration.
- Residency
- Determined by where you install. In-country, on-premise or fully air-gapped residency is a property of the deployment rather than a contractual promise about a region you do not control.
Control implementation for a specific release is evidenced in the security pack and verified against the deployed system during a Proof of Value, not asserted on a marketing page.