Being audit-ready: the evidence chain behind every compliance claim

There is a decisive difference between telling an auditor “we classified personal data, narrowed access and destroyed what had expired” and showing each of those with a date, a person, a reason and an approval. The first is a statement; the second is evidence. Being audit-ready does not mean having done the compliance work; it means that every piece of that work is traceable as a chain. That chain can only be built while the data stays inside the organization, with every step recorded and every approval given by a separate authority.

The difference between “we did it” and “here is the evidence”

Audits ask two kinds of questions. The first kind is about policy: do you have a retention policy, is your privacy notice current, is your VERBİS registration done? These are answered with documents. The second kind is about practice: did you actually destroy the data whose retention period expired, who did it, when, in which source? Do you know who can reach special-category data, and when was that access narrowed? These can only be answered with records.

Most organizations fall short on the second kind. The work was done, but it was run through e-mails, meeting notes and personal memory. On audit day there is no record to show behind the sentence “we did that last year”. For international readers: VERBİS is the Data Controllers’ Registry kept by KVKK, Türkiye’s data protection authority, and the authority’s page on it explains the data controller’s registration obligation. Showing that the declaration in the registry matches real discovery and has been kept current over time is, however, an evidence task separate from the declaration itself.

The evidence chain has four links: the finding (what we found, where and when), the decision (what was decided, by whom, for what reason), the approval (who approved, when) and the action (what was applied, with what result). If any link is missing, the chain breaks.

The audit log: who, when, why

Technical system logs and the audit log get confused. A system log says “file deleted”; an audit log says “for this finding, on the grounds that the retention period had expired, on this owner’s proposal and with this approver’s sign-off, destroyed on this date; the redacted copy is kept at this location”. The auditor asks for the second.

A good audit log carries at least these fields:

• Finding identity and context. Source, location, data type and confidentiality level, which scan surfaced the finding and when.
• People. The owner assigned to the finding, the person who proposed the action, the person who approved it; each separately.
• Time. The moments of finding, assignment, decision, approval and execution.
• Reason. Why the action was chosen: retention expired, oversharing, false positive, a legal hold still in force.
• Action and result. Masking, quarantine, permission removal, deletion or destruction, label application; whether the action completed successfully.

The Seratus remediation and evidence workflow fills all of these fields automatically; the record is an inseparable part of the action, not something added afterwards. The principle emphasized in KVKK’s Board Principle Decision 2026/2035 of 16 September 2026, that access should be limited to specific staff and access records should be kept, applies to the console as well: in Seratus, console access is role-based, findings are shown as masked samples and full content is opened only inside an approved review workflow, under record.

The approval chain: why a second approver is required

Deletion, permission removal and masking are hard to reverse. Applying them on one person’s decision both raises the risk of operational error and leaves a weak answer to the audit question “who decided this, and did anyone check?”

The approval chain manages that risk through three mechanisms. First, assignment to an owner: every finding has a named owner. Second, separate approval authority: the person proposing an action and the person approving it are different, and authority is split by action type; an owner may approve masking while destruction requires a second approver. Third, role-based access: scanning, review, approval and administration roles are separated; what can be seen and done in the console is limited by role.

This structure shows an auditor concretely that segregation of duties is applied. For every action, the proposer, the approver and the executor appear separately in the record.

Reports: summary, audit, source detail

The evidence chain lives in the record, but it has to become a report to be presented to the auditor and to management. Seratus produces four report types, each exportable as PDF, Excel and CSV:

Report	Audience	Content
KVKK readiness summary	Data controller, compliance team	Readiness score, list of gaps (special-category data broadly shared, overdue data subject request, data past its retention period, data not in the inventory), status of each gap
Audit report	Auditor, internal audit	Findings, decisions, approvals and actions in the period; who, when, why
Source-level detail	Information security, system owners	Detections per source, access status, actions applied
Executive summary	Senior management	Risk trend, closed and open findings, priorities

The KVKK readiness score on its own is not evidence; the list of gaps behind it and the closure record of each gap are. The audit report makes that connection: for every gap, the finding, decision, approval and action links appear in one document. Findings and actions can also be forwarded to SIEM and request management systems, keeping consistency with the organization’s existing audit trail tooling.

Producing evidence without data leaving the organization

A question often overlooked in audit preparation is where the tool producing the evidence takes the data. A system that scans personal data, special-category data and trade secrets and then sends that data out for analysis recreates the very problem it is supposed to solve.

Seratus is installed on-premises and runs in air-gapped networks. Scanning, classification, access analysis, remediation and reporting happen on the organization’s own infrastructure; connections are read-only; installation and updates ship as verifiable signed packages. Optional LLM enrichment (document type, request summaries) runs only on the organization’s own or self-hosted model; no data is sent to external AI services. Details: private LLM and air gap.

KVKK’s Guide on Generative AI and the Protection of Personal Data treats the processing of personal data in generative AI systems as a subject in its own right; choosing a self-hosted model keeps the assessment that subject requires within the organization’s own boundary. Data does not cross that boundary, and the boundary can be shown to the auditor.

Audit day: what gets shown

An audit-ready organization answers these questions from the record on audit day:

1. Which personal data do you hold, and where? A discovery-based inventory; mapping to the VERBİS declaration; the status of the “data not in inventory” gap.
2. Who can reach special-category data? The access and exposure graph; the “special-category data broadly shared” gap and its closure records.
3. What did you do with data past its retention period? The retention schedule; destruction and anonymization records; the redacted copy and destruction of the original; quality measured by a uniqueness check.
4. How did you answer data subject requests? Request records, cross-source search, redacted copies, deadline tracking.
5. Was there a breach, and what did you do? Breach records and the discovery output for the affected data set.
6. Who made these decisions? The owner, the approver and the reason for every action.

For each of these questions the Seratus KVKK compliance suite produces the relevant record and report. The audit stops being a meeting where a statement is defended and becomes a session where the record is shown.

How Seratus closes these gaps

Gap 1: The compliance work was done but there is no record. Every finding, decision, approval and action is written automatically to the audit log with who, when and why; the record is part of the action, not created afterwards. Details: remediation and evidence.

Gap 2: Decisions are made by one person. Owner assignment, separate approval authorities per action type and second-approver sign-off; role-based access separates scanning, review, approval and administration.

Gap 3: The VERBİS declaration does not match the real data. A discovery-based inventory, category/purpose/retention mapping and the “data not in inventory” gap; the KVKK readiness summary makes the difference visible.

Gap 4: There is no consistent report to hand to the auditor. KVKK readiness summary, audit report, source-level detail and executive summary; PDF, Excel, CSV; forwarding to SIEM and request management systems.

Gap 5: Destruction was done but irreversibility cannot be shown. Redacted copy plus destruction of the original plus quality measurement with a uniqueness check; every step recorded. Details: KVKK compliance.

Gap 6: The evidence tool itself carries data outside. On-premises, air-gap-compatible deployment, read-only connections, signed packages, private or self-hosted LLM; no data goes to external AI services.

Takeaway

Being audit-ready does not mean having done the compliance work; it means every step is traceable with who, when and why. The evidence chain of finding, decision, approval and action is secured by separate approval authorities and role-based access, and presented to the auditor through reports. Seratus builds that chain inside the organization’s own network, with no data leaving it, and turns “we did it” into “here is the evidence”.