How to Create a Data Inventory: A Practical Guide for KVKK Compliance

A data inventory is a working map that makes visible where an organization processes personal data, in which processes, for what purposes, and with whom. For KVKK compliance, the goal is not merely to create a spreadsheet, but to understand the data flows between business processes and the systems used.

A well-prepared inventory helps ensure that privacy notices and internal procedures reflect actual practices. It also shows which activities should be reviewed first, because the organization gains a concrete view of the data it holds and the points through which that data moves.

What Questions Does a Data Inventory Answer?

The primary purpose of an inventory is to describe personal data processing activities by process. For each record, it should answer at least the following questions: What personal data is being processed, who is the data subject, what is the purpose of processing, where does the data come from, where is it stored, who has access, and with which third parties is it shared?

Data categories and processing purposes should not be confused. For example, a sales process may involve a name, contact details, and billing information; however, these data may be processed for different purposes, such as preparing a proposal, executing a contract, and carrying out accounting activities.

Consider a common example: A customer fills out a form, the information appears on the sales team’s screen, a proposal is prepared, and the data is then transferred to the accounting system for invoicing. The inventory should not treat this as a single customer data record. Instead, it should document it as a processing activity that makes the source, purpose, systems, and transfers visible.

Start with Processes, Not Departments

When creating a data inventory, simply listing departments such as human resources, marketing, or information technology may produce incomplete results. The same personal data may be processed for different purposes within a single process involving multiple departments. For this reason, the starting point should be the work the organization carries out, not the name of a department.

As a first step, you can list core processes such as customer acquisition, sales, support, recruitment, procurement, visitor management, and finance. Then identify the forms, applications, email inboxes, file folders, and service providers used in each process. Interviews with process owners are important for uncovering practices that may not appear in existing documentation.

For example, if the human resources process is assumed to involve only the collection of résumés, the inventory will be incomplete. Interview notes, reference checks, onboarding documents, and access-card issuance may also be separate data processing points within the same process.

Document Every Processing Activity Using the Same Record Structure

For an inventory to be useful, a consistent record structure should be used across all processes. A practical record template may include the following fields:

• Name of the processing activity and the process to which it belongs
• Data subject group
• Personal data categories and, where applicable, special categories of personal data
• Purpose of processing
• The organization’s assessment of the legal basis for processing
• Source from which the data is obtained
• Application, device, or physical environment used
• Internal units and service providers with access
• Parties to which the data is transferred and the purpose of the transfer
• The organization’s rules regarding retention and destruction
• Process owner and date of last update

These fields do not need to be applied at the same level of detail in every organization. What matters is that anyone reading a record can understand the data lifecycle. If the processing purpose is unclear, or if only a department is named without specifying the system, the record will become difficult to review or audit later.

For example, support requests may contain a customer’s name, contact details, device information, and correspondence. The record should clearly state that this data is used to resolve the support request, stored on the support platform, and shared with a technical service provider when necessary.

Verify Data Flows with Systems and Service Providers

Process interviews alone may not be sufficient, because employees may not always know in the same level of detail which systems data passes through or which services operate in the background. For this reason, the application inventory, user permissions, contracts, forms, email groups, and file storage locations should also be reviewed.

The system list obtained from the technical team can be compared with the process information provided by business units. If customer data is found to be stored in a system that does not appear in the relevant unit’s inventory, there is a gap between the two records that needs to be explained. Similarly, if data is being transferred to a service provider but that transfer does not appear in the contract or process documentation, the matter should be assessed separately.

For example, while using a campaign form, the marketing team may assume that the data goes only to an email list. A technical review may show that the form data is first transferred to a customer relationship management system and then to another communications tool. If the map does not show this chain, the resulting notices and access controls will not reflect the actual flow.

Keep the Inventory Up to Date and Consistent with VERBİS

A data inventory should not be treated as a one-time project. The introduction of new software, a change to a form, the use of an external service, or the launch of a new business process should trigger a review of the inventory. Unless responsibility for updates is assigned, the file will quickly become an archive that no longer reflects the current state of affairs.

The inventory can also serve as a foundation for preparing, where required, for the Data Controllers Registry Information System (VERBİS). However, VERBİS obligations and exemptions must be assessed separately according to the current criteria; any registration or notification based on the inventory must be consistent with the information it contains.

One common mistake is to review only forms on the website while excluding physical documents, telephone conversations, and supplier-related data flows. Another is to group all activities under one broad purpose. A more effective approach is to establish a working system that is approved by process owners, compared against technical records, and updated whenever changes occur.

As a first low-risk step, select a single process and document its flow together, from the point where the data is collected to the point where it is deleted or archived.

Frequently Asked Questions

Is a data inventory prepared only by the information technology team?

No. The information technology team verifies systems and access rights, while business units explain how and for what purposes the data is used within each process. The inventory becomes reliable when these sets of information are assessed together.

Must each type of personal data be listed on a separate line in the inventory?

Not always. Data categories processed within the same process, for the same purpose, and through similar flows may be grouped together. However, separating them is clearer when the purpose, system, or transfer is different.

Are a data inventory and a VERBİS registration the same thing?

No. A data inventory is an internal working map that documents processing activities in detail. VERBİS is a registry registration made according to the applicable procedure when the relevant obligation arises; the inventory is one of the key sources used in its preparation.