When ransomware affects a business, identifying the compromised servers is only the beginning. The next questions concern people: whose information was there, what happened to it, and what protection or communication is needed?
The Mefa Endüstri ransomware notice provides a useful starting point for examining these questions. A practical data inventory connects information to the systems, business activities and access permissions behind it. That connection helps an incident team turn technical findings into a defensible assessment of personal-data impact.
For IT managers, privacy teams and business owners, the priority is straightforward: make sure the inventory can answer questions during an outage, when ordinary systems and the people who usually explain them may be unavailable.
The controller’s notification reports:
The listed categories span identity, contact, location, personnel, legal proceedings, customer transactions, physical premises security, transaction security, risk management, finance, professional experience, marketing, audiovisual records, health, and criminal convictions/security measures.
The notice identifies ransomware but does not specify initial access, exact systems, encryption extent, exfiltration, consultancy privileges, backup impact, reasons for the data mix, completed individual notifications, or remediation. It gives kvkkiletisim@mefaendustri.com for enquiries and says examination continues. No subsequent official final findings were identified for this review.
Detection by a consultancy does not establish that it caused the incident or held administrative access. Nor does the category list establish that everything occupied one system, every person had every category affected, or Mefa’s inventory was deficient.
Consider a hypothetical manufacturer with payroll exports, customer order records and employee health documents across its applications and file shares. This example illustrates an operational risk; it is not a reconstruction of Mefa’s environment.
An investigator might identify a compromised account quickly. Understanding what that account could reach requires a different set of information: folder permissions, application roles, inherited access, export locations and historical copies.
The same person might appear in several places. A former employee could have records in payroll, a legal case folder and an archive. A customer contact might also have a portal account. Counting files, rows or accounts will therefore not necessarily produce an accurate count of affected individuals.
Scoping should distinguish three things:
An inventory helps locate relevant information. It cannot, by itself, prove that a particular file was accessed or stolen.
A KVKK personal-data processing inventory describes business activities and connects them to purposes, legal grounds, data categories, people, recipients, retention, international transfers and security measures. Controllers obliged to register in VERBİS must prepare one. The detailed internal inventory and the public, category-based registry entry serve different functions.
Whether registration is required needs its own assessment. Operational visibility remains useful even where a registration exemption applies. For the broader framework, see our KVKK compliance guide for businesses.
To make that inventory useful during an incident, we recommend linking it to a technical register containing:
These are operational extensions. A hostname or backup-test field should not be presented as a separately prescribed statutory inventory requirement.
Take payroll processing. Ask the payroll owner to explain the workflow, then ask IT to demonstrate where the records actually reside. Reconcile the answers with the application configuration and file locations.
If payroll generates a monthly spreadsheet, record where it goes, who receives it and what happens to old versions. If an external provider receives a copy, identify that relationship and the relevant access or transfer arrangements. If the spreadsheet is later attached to a legal matter, record that distinct purpose and retention assessment.
This exercise produces something more useful than a row labelled “HR system.” It identifies the places investigators would need to examine and the people who can explain their contents.
Avoid turning the inventory itself into a second collection of sensitive records. Record descriptions and controlled references rather than copying medical documents or identity records into it.
Health information and data concerning criminal convictions and security measures are special-category personal data under KVKK. Their processing needs an applicable Article 6 condition and the additional safeguards specified by the Board.
A broad label such as “personnel data” can obscure those requirements. Identify the actual document or field, why it is needed and the people authorised to use it. Do not assume that every HR record is special-category data, or that an ordinary customer record is harmless merely because it falls outside Article 6.
The Board’s safeguards address defined permissions, periodic access checks, removal of obsolete access, cryptographic protection, separate secure key storage, protected transaction logs and at least two-stage authentication for remote access to electronic special-category environments, among other measures.
As a practical design choice, examine separation between general HR administration, restricted health records and customer operations. Test whether a customer-support account can reach an HR export, or whether a routine support session grants access to sensitive attachments. The answer should come from a permission check, not the folder name.
Business functions may share infrastructure legitimately. Where they do, review the application, identity, network and administrative boundaries that are meant to limit access.
For any organisation relying on external IT support, the incident plan should explain what happens after the provider detects an alert.
Agree who receives urgent notifications, including outside business hours; who can approve containment; which logs the provider must preserve; and who maintains the affected-system list. Keep an alternative communication route available if corporate email fails.
Record provider accounts in the technical inventory, including purpose, privileges, authentication and expiry or review dates. Named accounts and recorded support sessions make activity easier to attribute. An external support contract should also address prompt incident escalation and evidence cooperation.
Where a supplier acts as a processor and personal data in its custody are unlawfully obtained, the Board’s breach procedure requires it to inform the controller without delay. The controller’s own response arrangements still need a clear owner.
Backups support recovery. They do not answer whether information was copied before systems became unavailable.
For each critical processing activity, identify which backup contains the necessary records, how recent it is and what is needed to restore it. Test restoration with the business owner: opening a database successfully does not establish that payroll or customer service can operate correctly.
Keep protected backup copies separated from the production environment, test recovery regularly and check backups for malware before restoring them to clean systems. A synchronised folder should not be assumed to provide independent recovery protection.
Also test whether a compromised administrator could delete backup versions, change retention settings, disable recovery accounts or destroy encryption keys. Preserve a recovery route that does not depend entirely on the identity system being restored. Cloud backup design should protect against destructive changes and alert the right people when privileged actions occur.
Containment and evidence preservation should be coordinated. Rebuilding a machine or removing an account can change the information investigators need.
Preserve relevant endpoint alerts, authentication records, server and application logs, network-transfer evidence and available cloud audit records. Qualified responders should determine where system images or memory capture are appropriate. Record collection times, time zones, sources and who handled each item.
We recommend connecting the resulting evidence to an incident-specific copy of the inventory. For every potentially affected repository, record its processing activity, person groups, relevant period, observed impact and confidence level. Explain what evidence supports inclusion or exclusion.
Keep missing telemetry visible. “No transfer found in the available logs” has a narrower meaning than “no data left the environment.” Likewise, a ransomware label alone cannot settle whether an incident involved encryption, theft, or both.
Under the Turkish breach framework, where personal data have been unlawfully obtained by others, the controller must notify the Board without delay and within 72 hours of awareness. If information cannot be supplied together, it can be provided in stages without delay. Late notification requires an explanation.
Affected individuals must be informed within the shortest reasonable period after identification, directly where contact details are available or through an appropriate alternative. Individual notices should explain timing, affected data including special-category distinctions, possible consequences, protective measures and a contact route in clear language.
Do not wait for a complete forensic report to begin assessing these duties. Where the facts leave the notification trigger uncertain, involve privacy counsel promptly and document the assessment.
Post-incident improvement should address the difference between documented processing and what investigation actually found.
First, preserve necessary evidence and identify applicable retention duties or legal holds. Then review unexpected repositories, redundant exports, obsolete accounts and unexplained access. Assign each finding an owner and a completion date.
Where the reasons for processing no longer exist, KVKK requires deletion, destruction or anonymisation. Apply that assessment through a controlled process. An incident does not justify indiscriminate deletion, and an evidence hold should have a defined purpose and review point rather than becoming permanent retention by default.
Update the inventory, permissions, retention rules and relevant documentation together. Check how restored historical backups will be handled so that obsolete copies or permissions are not silently returned to active use.
Finally, run a short exercise: select one unavailable system and ask the team to identify its activities, people, data, copies, evidence sources and recovery owner. Record the unanswered questions as work to complete.
Use this matrix as an implementation starting point. The accountable roles are illustrative; adapt them to your organisation. It combines operational recommendations with the legal requirements discussed above and is not an exhaustive compliance checklist.
A useful inventory lets a responder move from a compromised account or server to the business activities and people potentially affected. It also gives business owners a way to spot unnecessary copies, excessive access and recovery gaps before an outage forces the issue.
Start with one important activity and verify the complete route from collection to deletion, including exports and backups. Expand from what the team can demonstrate.
Need help connecting your KVKK documentation to your systems? Kooch’s KVKK & GDPR Gap Analysis can help identify mismatches between documented processing and operational practice, then turn them into a prioritised action plan. Contact Kooch to discuss your inventory and readiness needs.
Checked on 12 September 2026. Incident facts are drawn from the controller notification published by the Authority. The control recommendations are the article’s practical synthesis; they are not findings about Mefa’s implementation.
