Why data discovery comes first: surveys are not enough

A data protection program is only as good as its inventory, and the inventory is only as good as the method that built it. A survey-based inventory records what the department head knows, not what is on the disk. This entry sets out why discovery has to be the first step, why later steps such as DLP, policy and disposal fall flat without it, and what a sound discovery exercise must produce.

How inventory surveys decay

Most organizations build their personal data inventory the same way. Legal or compliance prepares a form, sends it to department heads, merges the answers into a spreadsheet and turns that into the VERBİS record. The method is incomplete on day one and becomes more so with time.

The first limit of the survey is the respondent’s knowledge. A department head knows what their own system holds; they do not know about the reports exported from it, the spreadsheets attached to emails, or the copies saved into personal folders. The customer export left on the desktop of someone who resigned four years ago enters no questionnaire.

The second limit is time. A survey is a photograph of the day it was completed. When a new project opens, a system changes or a SharePoint site is created, the inventory is not updated, because updating depends on someone remembering rather than on a trigger.

The third limit is technical detail. A database column may be called “ref_no” and contain national ID numbers. The person completing the survey reports it as “customer reference”, because that is how it appears on screen. Every inventory built without looking at content trusts the accuracy of column and folder names; that trust is rarely earned.

The Authority’s explanation of the Data Controllers Registry expects the registry to reflect the data the organization processes, by category, purpose, recipient group and retention period. That expectation rests on the assumption that the inventory reflects reality. A survey cannot meet the assumption; discovery can.

Why the later steps fail without discovery

Every step of a data protection program relies on the output of the previous one. When discovery is skipped or replaced with a survey, the later steps run on bad input.

DLP and access policy. A data loss prevention control has to know what it protects. If nobody knows which files are sensitive, the policy drifts to one of two extremes: it blocks everything and the business stops, or it blocks nothing and the control exists only on paper. A well-calibrated policy rests on labels such as “top secret, HR”; the label is the output of discovery.

Retention and disposal. A retention schedule requires knowing which data expires on which date. The obligation the Authority explains on its deletion, destruction and anonymization page cannot be met if the location of the data is unknown. The record in the core system is destroyed but the copy in the shared folder remains; disposal has not taken place.

Data subject requests. When a person asks what data is held about them, the answer has to cover every source. Data in an archive file that is not in the inventory is not in the answer either; the request has been answered incompletely.

Breach management. When unauthorized access to a server is detected, the first question is what was on that server. Without prior discovery, that question is answered at the moment of the incident, under pressure and incompletely.

Access review. “Who can reach what” is meaningless without the “what”. An ACL list on its own is a system administrator’s report; combined with content, it becomes a risk map.

The elements of discovery

Discovery is not the production of a file list. A sound discovery exercise produces four elements together.

• Scope. Which sources are scanned: file servers, local disks, Microsoft 365, databases, object storage, email archives. Sources outside the scope are recorded explicitly; “not scanned” and “not found” are not the same thing.
• Content. For each file and column, which data types were found, with what confidence and which sample. Turkish identifiers (TCKN, tax ID, Turkish IBAN, phone, plate) and special-category data (health, ICD codes) are detected with separate rules.
• Classification. The finding is labelled with type, confidentiality level and business category. The label can be corrected with human approval and is tied to policy.
• Access context. Next to every finding, who can reach it: ACL, sharing link, database role. Without this, a finding is a content report, not a risk decision.

The table below compares the combination of these four elements with a survey-based inventory.

Question	Survey-based inventory	Discovery-based inventory
Where is the data?	The systems the respondent knows	Every scanned source, down to file and column
What kind of data?	Declared category	Type detected from content, with a confidence percentage
Who can reach it?	Usually not asked	ACL, sharing link and role information
When is it updated?	When someone remembers	Continuously, through incremental scanning
Copies and archives?	Invisible	Scanned and linked to the original record
Evidence?	A form and a signature	Scan record, findings, access and action log

Discovery is a continuous process

Discovery does not end with a project. Data is copied, moved and archived every day; a shared folder that is clean today is contaminated by an export file a month later. A one-off discovery starts going stale the day it finishes.

Continuous discovery brings two technical requirements. First, scanning must not burden the source systems; agentless, read-only connections solve that. Second, not everything should be rescanned every time; for sources such as Microsoft 365, processing only changes (delta) after the first full pass, and on file servers resuming an interrupted scan where it stopped, make this possible.

The product of continuous discovery is a living inventory: the VERBİS record is built from the latest scan rather than from a survey, and “data missing from the inventory” is listed as a gap. An example scenario: at a manufacturing company the VERBİS record covers only the HR and accounting systems, while discovery finds occupational physician reports on an old quality-management server and photocopied ID cards attached to dealer contracts on a sales share. Neither finding is in the inventory; both are, after discovery.

The outputs of discovery and what to do with them

Discovery should be designed as the input to the next step. The outputs it must produce are these:

1. A per-source data map. What is in which share, which site, which schema. This map fills the category and recipient-group fields of the VERBİS inventory.
2. Classified findings. Type, confidentiality level, business category, confidence percentage and masked sample. False positives are weeded out at the review step.
3. Access context and risk ranking. Which finding is in wide sharing, which is open to a departed user, which is reachable by an anonymous link.
4. A difference list. Data in the inventory but not found, and data found but not in the inventory.
5. Work items. Actions that enter the remediation flow, are assigned to an owner and approved: masking, quarantine, permission removal, disposal, label application.
6. Evidence. Scan date, scope, findings and actions taken, so that at audit time the answer is “here is the proof” rather than “we did it”.

These outputs are linked. The difference list corrects the inventory; the risk ranking prioritizes the work items; the evidence carries all of it into the audit.

How Seratus closes these gaps

Each gap described in this entry corresponds to a concrete capability in Seratus.

• The survey not reflecting what is on disk. Seratus scans file servers, Windows/Linux/macOS local disks, Microsoft 365, Oracle, SQL Server, PostgreSQL/MySQL/MariaDB databases, S3-compatible object storage and PST/OST/MSG archives agentlessly and read-only, and builds the VERBİS inventory from that scan (agentless DSPM, KVKK compliance).
• Trusting column and folder names. The Turkish-specific detection engine looks at content; TCKN, tax ID, Turkish IBAN, phone, plate and ICD-coded health data are found with separate rules, a confidence percentage and a masked sample. In databases, “not found in the sample” is explicitly marked as a technical finding (Turkish detection accuracy).
• Findings without access context. The access and exposure graph places ACLs, sharing links and database roles next to every finding; overshared and orphaned access is surfaced (access and exposure graph).
• Discovery remaining a one-off. Delta scanning in Microsoft 365 and resumable scanning elsewhere keep the inventory alive; “data missing from the inventory” is listed as a gap in the KVKK readiness score (Microsoft 365).
• Discovery output not tied to action. Findings are assigned to an owner, and masking, quarantine, permission removal or disposal is executed with a second approver; every step is written to the audit trail with who, when and why (remediation and evidence).
• Scattered evidence. The KVKK readiness summary, audit report and per-source detail are produced as PDF, Excel or CSV; findings can be forwarded to a SIEM or ticketing system (integrations).

Takeaway

Data discovery is the first step of a data protection program because every other step runs on its output. A survey is a starting point, not a verification method; only a scan that looks at content shows what is on the disk, in the database and in the archive. Discovery that does not produce continuity, access context and evidence is merely a file list. The next entry looks at how this discovery is carried out without touching the source systems, that is, what agentless scanning means.