Compliance automation

Why it matters

Compliance cannot be a document someone reads once.

Most organizations discover compliance gaps late: during audits, procurement reviews, incidents, or customer escalations. The hard part is not writing a policy. The hard part is proving what the system actually does and making the code match the policy.

Existing systems are unknown territory

Real codebases have old modules, hidden data flows, background jobs, logs, telemetry, and admin tools. Faktorial reviews the actual system instead of assuming the architecture diagram is still true.

Evidence beats assertion

Each audit slice records files reviewed, personal-data touchpoints, persistence locations, retention behavior, export/delete support, controls already present, and gaps that remain.

The audit creates work

Findings do not die in a report. Gaps become normal engineering issues with acceptance criteria, implementation notes, tests, and traceability back to the compliance requirement.

Operating model

From policy to enforced delivery loop.

A compliance spec becomes active work. It changes how future issues are investigated, built, and reviewed, while retroactive audits bring the existing codebase into view.

01

Install the spec

Faktorial creates an inert parent issue from a compliance template, such as GDPR baseline, SOC 2 control evidence, audit logging, or domain-specific rules.

02

Enforce new work

The requirement is injected into investigate, build, and review. New changes must explain relevant data categories, controls, retention, evidence, and remediation.

03

Split the audit

Faktorial chooses bounded slices by module, vertical workflow, service boundary, data store, queue, API surface, or operational control.

04

Publish evidence

Each slice documents what is solid, what is partial, what is missing, and why. Clean slices can close with evidence. Gaps become remediation issues.

05

Implement the plan

Remediation issues go through the normal delivery pipeline: investigation, build, tests, review, PR, and learnings carried forward.

Audit output

The audit becomes a gap-filling backlog.

The useful picture is not a certificate on a wall. It is a live board where evidence creates issues, and issues move into tested remediation work.

Compliance workbench Spec -> Evidence -> Gaps -> Fixes

Installed spec #3726

GDPR baseline Every new change must identify personal-data touchpoints, storage location, retention behavior, export/delete support, and minimization evidence.

Audit fan-out #3727-29

Code/data mapTables, DTOs, queues, logs, telemetry, APIs, and frontend surfaces.

Runtime operationsAuth sessions, workers, AI chat, audit logs, message jobs, metrics, and erasure.

Frontend/API surfaceCustomer ownership, public booking intake, telemetry, errors, and request logging.

Where data livesConcrete tables and repositories, not a generic privacy checklist.

What is missingEach gap is specific enough to become an engineering task.

Generated backlog - Interactive Demo gap filling

Evidence 2

Gaps opened 3

Fixes shipped 3

This is the core product point: Faktorial does not stop at finding risk. It turns evidence into a backlog and then works that backlog through the normal engineering loop.

Live proof

BokaBra.com GDPR baseline: audit, gaps, fixes.

In BokaBra.com, Faktorial installed a GDPR baseline and immediately started both forward enforcement and retroactive review of the existing codebase. The broader system is described in the BokaBra.com case study.

Compliance parent #3726

Personal data behavior became an explicit engineering requirement.

The installed GDPR baseline requires any work that stores, moves, displays, logs, exports, deletes, or documents personal data to identify data category, persistence location, retention behavior, and user-facing rights support before acceptance.

Future workInvestigate/build/review now call out data touchpoints, export, deletion, retention, audit logging, and minimization.
Audit slicesFaktorial created code/data map, runtime/operations, and frontend/API surface audits.
Gap policyConfirmed gaps become normal actionable issues without being confused with the inert compliance parent.

#3728Runtime and operations audit reviewed auth sessions, magic links, AI chat history, message jobs/logs, audit logs, metrics, OTEL, customer export, and erasure.

#3729Frontend/API audit reviewed route permissions, customer ownership, public booking intake, customer self-service, telemetry, errors, and audit logging.

#3732Closed: purge expired customer auth sessions and magic links.

#3733Closed: add AI chat transcript retention controls.

#3744Implemented: suppress raw 500 error details in API responses.

#3745Implemented: minimize personal data captured in audit-log request bodies.

SolidTenant-scoped customer export, GDPR export, erasure/anonymization, and public projection filtering were documented as existing controls.

PartialOperational stores had useful audit evidence, but several retention policies were not explicit enough.

GapsExpired sessions, AI chat transcripts, operational logs, raw 500 details, and audit request bodies were turned into issues.

ActionSome remediations have already moved from audit finding to implemented code and tests.

Actual evidence

This is what proof looks like in BokaBra.com.

The compliance documents do not just say "GDPR reviewed." They map personal data to concrete storage locations, retention behavior, export/delete support, minimization notes, and the gaps that need follow-up.

Customer registry Names, phone numbers, email addresses, tags, comments, private notes, marketing consent, lifecycle opt-outs, and custom-field values are mapped to customer-owned tables and the customer ownership workflows.

Customer auth Customer session cookies and magic links are mapped to auth_sessions and customer_magic_links, including tenant id, customer id, email, session id, raw token, and expiry.

Messaging Recipient addresses, message bodies, provider ids, delivery logs, and queue state are mapped to message_jobs and message_logs, with a distinction between delivery evidence and over-retained message content.

AI chat Admin chat messages and compacted summaries are mapped to public.ai_chat_histories, with explicit wording that pasted customer data cannot reliably be tied to a structured customer GDPR package.

Audit logs Actor, action, entity, request id, response status, and request-body evidence are mapped to audit_logs; the audit identified that full request bodies could retain non-secret personal data.

Customer rights The audit found existing tenant-scoped customer CSV export, GDPR package export, erasure/anonymization, customer history, and an explicit retention policy for core customer records.

So yes: there is already documentation showing where personal information is stored in BokaBra.com. The code/data map is broad, and the runtime/operations audit has a dedicated personal-data touchpoint table. The remaining work is to keep extending that map as remediation closes more gaps.

What it found

Examples of gaps and how they were solved.

These are plain-English examples from the BokaBra.com GDPR run. The important point is that every fix is tied back to the evidence that found the gap.

Expired auth artifacts Faktorial found that expired customer sessions and one-time magic links were ignored after expiry, but not automatically purged. The fix added an expiry-bounded backend cleanup path and an opt-in scheduled worker so stale customer ids, emails, session ids, and raw tokens are deleted after they can no longer authenticate anyone.

AI chat transcript retention Faktorial found that admin AI chat transcripts could contain pasted personal data and only had manual clear behavior. The fix added a 90-day rolling retention policy, a backend purge path, an opt-in retention worker, and explicit wording that free-form transcript data is handled separately from structured customer GDPR exports.

Raw 500 error details Faktorial found that server errors could return raw internal exception text to API clients. The fix kept useful validation messages for client errors, but changed 500 responses to a generic safe detail while preserving internal diagnostics in server-side logs.

Audit-log request bodies Faktorial found that mutating API request bodies could be retained too broadly in audit logs. The fix changed the audit trail toward deterministic summaries and field-level minimization: keep actor, action, entity, request id, and status evidence, but stop storing raw customer contact data, custom-field values, review text, and similar payload details.

What this gives you

A compliance system that keeps working after the first audit.

The important shift is structural: compliance becomes part of the engineering system, not a parallel spreadsheet that slowly drifts away from the code.

Current-state map

You get a code-backed view of where sensitive data lives, where it flows, how long it remains, and which controls are real.

Prioritized gap backlog

Findings become normal issues with evidence, scope, acceptance criteria, and a plan. The team can review and schedule them like any other engineering work.

Remediation delivery

Faktorial can implement the plan, add tests, update documentation, open PRs, and preserve the audit trail from requirement to code change.

Forward enforcement

New work is checked against the installed requirement, so the codebase does not immediately drift back into unknown compliance posture.

Evidence for stakeholders

Security, legal, enterprise buyers, auditors, and engineering leadership can see what was checked, what passed, what failed, and what changed.

Trust boundary

Faktorial is not a legal certification by itself. It produces code-backed evidence, scoped findings, remediation work, and reviewable changes that your team can validate.

Repeatable standards

The same model applies to GDPR, SOC 2 evidence, ISO controls, audit logging, AI governance, security hardening, and domain-specific standards.

Start with one repo

Find the gaps before your customers, auditors, or incidents do.

Pick a standard and a representative codebase. Faktorial will install the spec, run bounded audits, produce evidence, create remediation issues, and start closing the gaps.

Plan a Compliance Pilot