Building the VERBİS inventory from real discovery, not questionnaires

The VERBİS inventory is an organization’s formal answer to Türkiye’s data protection authority on the question “which personal data do we process, for what purpose and for how long”. In most organizations the accuracy of that answer rests on an Excel questionnaire sent to departments, and it starts to age the day it is sent. A discovery-based inventory answers the same question by looking at the systems themselves, and makes the difference between what was declared and what actually exists visible.

This article is not legal advice; the scope of the VERBİS registration duty for your organization should be confirmed with your legal function.

What VERBİS asks for and what an inventory provides

For readers outside Türkiye: VERBİS is the Data Controllers’ Registry Information System. The Authority’s page “Veri Sorumluları Sicili Nedir” (What is the Data Controllers’ Registry) explains the registry’s purpose and the registration duty of data controllers. The information declared to the registry covers the categories of personal data a controller processes, the processing purposes, the recipient groups data is transferred to, transfers abroad and retention periods. The registry is a category-level declaration, not a list of individuals.

Behind that declaration sits a personal data processing inventory. The inventory maps business processes to data categories, legal bases, retention periods and recipients. What goes to VERBİS is a summary of that inventory, so if the inventory is wrong, the declaration is wrong. The problem begins with how the inventory is built.

In practice there are two methods. The questionnaire-based method sends each department a form and asks it to write down which data it holds, in which system and for what purpose. The discovery-based method connects to systems read-only, detects personal data, classifies it and maps what was found to a business process, a purpose and a retention period. The two are not alternatives, but the order matters.

Why questionnaire-based inventories decay

A questionnaire records what departments know. An HR specialist declares the payroll system and the personnel files, but not the “staff_list_final.xlsx” downloaded to a desktop three years ago to send to a consultant, the recruitment forms shared with “Everyone” in a SharePoint library, or the medical report attachments in a former manager’s PST archive. These are not forgotten; they were never known.

A questionnaire also captures a moment. Systems change: a CRM is migrated, a test environment is built from a copy of production data, a daily backup is written to an S3 bucket, a project team shares a customer list in a Teams channel. Even if the questionnaire is renewed annually, these changes reach the inventory late or not at all. Even an inventory that was accurate on the day it was declared drifts from reality within months.

The third problem is retention. In questionnaires, retention is usually written as a policy value (“ten years”, “for the duration of employment”). Whether that value is actually enforced, meaning whether expired data is really deleted, cannot be seen from the questionnaire. The Authority’s page “Deletion, Destruction or Anonymization of Personal Data” governs what happens to data whose retention period has expired; evidence that it is applied is found in the systems, not in the inventory.

The table below compares the two approaches.

Dimension	Questionnaire-based inventory	Discovery-based inventory
Source	Departmental declarations	Read-only scanning of systems
Coverage	Known systems and processes	Every connected source, unknown copies included
Currency	At questionnaire time	Every scan; continuous with delta scanning
Retention	Policy value	Label-bound calendar; expired data is listed
Evidence	A completed form	Scan record, finding, masked sample, audit log
Weakness	Cannot see the unknown	Does not produce purpose and legal basis on its own

How a discovery-based inventory is built

A discovery-based inventory is built in four steps. The first is scope: which sources will be scanned? File servers (SMB/CIFS, NFS), local disks on Windows, Linux and macOS, Microsoft 365 (SharePoint Online, OneDrive, Teams files), Oracle, SQL Server, PostgreSQL, MySQL and MariaDB databases, S3-compatible object storage and PST/OST/MSG e-mail archives all fall within it. Connections must be read-only; discovery must not change the scanned system.

The second step is detection. For every file, table and object, the personal data types present are identified: national ID numbers (TCKN), tax identification numbers, IBANs, card numbers, e-mail addresses, phone numbers, vehicle plates, health data (ICD codes) and so on. A detection engine built for Turkish is decisive here; generic engines miss Turkish identifiers or generate false positives. Every finding should be presented with a confidence percentage and a masked sample so the inventory owner can verify it.

The third step is classification. Each asset found is labelled on three axes: type, confidentiality level and business category. The business category (HR, finance, customer, health and so on) corresponds to the business process in the inventory; the confidentiality level drives the access policy; the type determines the VERBİS data category. The taxonomy must be manageable according to the organization’s own structure, and automatic classification must be correctable with human approval.

The fourth step is mapping. Every classified asset is bound to a VERBİS category, a processing purpose and a retention period. This step needs input from business units and the legal function: discovery says “there is health data in this folder”; the organization supplies “this data is processed for occupational health purposes, for this period”. Discovery does not eliminate the questionnaire; it puts the questionnaire on real ground.

Mapping category, purpose and retention

The hardest part of mapping is that the same data type can be processed for different purposes with different retention periods. A national ID number in a customer contract, in a personnel file and in a visitor logbook is subject to a different purpose and period in each case. Discovery says where the ID number is; the business category label says which purpose it belongs to. The link between the label and the retention calendar makes it possible to compute which copy expires when.

An example scenario: at a manufacturing company, discovery detects health data in a “Quality” share on a file server. Classification assigns those files to the “HR / occupational health” category. The inventory shows the retention period and recipient group declared for that category, but the share is open to the quality team, and the quality team is not among the declared recipients. This is an inventory inconsistency that cannot be seen without discovery: the data is in the right category but in the wrong place, and the wrong people can reach it.

Once the mapping is done, assets found in later scans are labelled automatically under the same rules and the inventory stays current. For Microsoft 365, delta scanning processes only changed items; for file servers and databases, an interrupted scan resumes where it stopped.

The “data not in the inventory” gap

The most valuable output of a discovery-based inventory is the difference between what was declared and what was found. There are three kinds of difference. First, an undeclared category: the inventory has no health data, but discovery found ICD-coded reports in a folder. Second, an undeclared system: the inventory lists the CRM, but customer data also has a copy in a test database and in an S3 bucket. Third, a copy past its period: the inventory says five years, but twelve-year-old payroll files are still on the share.

Each difference calls for a risk assessment and a decision. An undeclared category requires updating the inventory and, where needed, the declaration; an undeclared system requires either adding it to the inventory or disposing of the copy; a copy past its period requires disposal or anonymization. Who decides, who approves and how it is proven are the questions at which the inventory stops being a document and becomes an operation.

How Seratus closes these gaps

Gap 1: The inventory rests on departmental declarations. Seratus’s KVKK suite builds the VERBİS inventory from real discovery results. Agentless discovery scans file servers, local disks, Microsoft 365, Oracle, SQL Server, PostgreSQL/MySQL databases, S3-compatible storage and PST/OST/MSG archives over a read-only connection.

Gap 2: Turkish identifiers are missed or produce false positives. The Turkish-specific detection engine finds national ID numbers, tax IDs, IBANs, phone numbers, vehicle plates and ICD-coded health data in context; every rule has its own accuracy and false-positive reduction program. Findings carry a confidence percentage and a masked sample, and in databases “not found in the sample” is never presented as a risk decision.

Gap 3: Found data is not mapped to a VERBİS category and purpose. Classification assigns every asset a type, a confidentiality level and a business category; the taxonomy is managed to fit the organization’s structure and corrections pass through human approval. Labels are bound to the retention calendar and to disposal processes.

Gap 4: The difference between declared and found is invisible. The KVKK readiness score lists “data not in the inventory”, “data past its retention period” and “special-category data widely shared” as separate gaps. The source-level detail report shows in which system and on which path each gap sits.

Gap 5: Data is in the right category but the wrong people can reach it. The access and exposure graph joins ACLs, sharing links and database roles with findings; access outside the recipient group declared in the inventory is surfaced as oversharing. Permission removal is a remediation action assigned to an owner and carried out under separate approval.

Gap 6: There is no evidence of inventory maintenance. Every scan, classification correction, mapping and remediation is written to the audit log with who, when and why. The KVKK readiness summary and the audit report export to PDF, Excel or CSV, and findings can be forwarded to SIEM and ticketing systems.

Takeaway

A VERBİS declaration is a statement, and a statement is worth only as much as the inventory it rests on. A questionnaire writes down what the organization knows; discovery shows what the organization holds. The difference between the two is the gap that surfaces during an audit or a breach. An organization that builds its inventory from real discovery, maps findings to category, purpose and retention, and measures the difference continuously can stand behind the answer it gives to VERBİS. Seratus runs that loop on the organization’s own infrastructure, without agents and with evidence.