Data discovery: follow the record through its lifecycle

An application inventory tells you which tools exist. A data inventory should also explain what those tools hold, why, who can access it, and where copies travel. For an engineering team, that means looking beyond database schemas to the operational paths that create, transform, disclose, retain, and delete information.

Start by following one representative record. A customer contact might enter through a form, appear in a CRM, become a support ticket, feed an analytics pipeline, and end up in an exported spreadsheet. Its lifecycle can also include logs, documents, backups, and a supplier’s systems. Each branch changes what you need to protect and what you can credibly say about the processing.

The useful output is not a scanner report. It is a maintained map of data, processing activities, technical dependencies, and accountable owners, supported by evidence of how the workflow actually operates.

What discovery supports under GDPR

The GDPR does not prescribe a particular discovery product or scanning method. Discovery supports the information and evidence needed to meet obligations in the GDPR:

These duties have conditions and exceptions. Erasure is not unconditional, and not every personal data breach requires supervisory notification. Controllers must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of awareness, unless the breach is unlikely to result in a risk to individuals’ rights and freedoms. Processors notify the controller without undue delay.

Where Article 30 applies, connect discovery to the required record of processing activities. An asset inventory is not that record: one activity may span several applications, while one application may support several purposes. Controller and processor records also have different required contents.

Set a boundary without hiding the edges

Choose a first business workflow rather than attempting every system simultaneously. Customer onboarding, recruitment, or support can provide a manageable starting point. Define the trigger, end state, teams, systems, and suppliers involved.

Then reconcile the approved application list with operational evidence. Useful inputs include identity-provider records, cloud inventories, procurement and expense records, integration configurations, and interviews with the people doing the work. Each source has limitations: single sign-on will not reveal every personal account, and a purchasing register will not reveal a spreadsheet sent to a consultant.

Look deliberately for locations that fall outside the main application architecture:

• Free-text fields, uploaded attachments, email archives, and chat conversations.
• Shared folders, endpoint downloads, scheduled exports, and temporary migration files.
• Data warehouses, product analytics, logs, and monitoring platforms.
• Production copies in development, testing, and troubleshooting environments.
• Transcription services and AI tools receiving prompts, documents, or recordings.
• Backups, replicas, archived accounts, and decommissioned services.

Unapproved tools are one discovery outcome, not the whole subject. Approved systems can contain unexpected data too. Record exclusions explicitly, including inaccessible supplier environments and repositories awaiting authorization. “Not inspected” must not silently become “contains no personal data.”

Trace the record and document each handoff

Use a realistic record type, preferably a synthetic example, to walk through the process with its operators. Ask them to demonstrate routine steps, exceptions, and workarounds. A workflow diagram describes intended behavior; a demonstration often exposes additional copies.

For each stage, establish what enters, what changes, what leaves, and what remains. Capture enough detail to answer these questions:

Record transfer mechanisms as well as destinations: an API, webhook, manual CSV, shared link, or email attachment creates different control and evidence needs. Note whether the receiving system transforms identifiers, aggregates records, or creates new derived information.

Use stable activity and system identifiers so teams can update relationships without rebuilding the map. Keep the inventory descriptive: it should identify categories and rules, not become another unnecessary repository of personal records.

Validate technical findings before relying on them

Scanning and classification tools can identify likely personal or sensitive data across supported repositories. Treat those findings as leads. A field named customer_email provides a useful clue; it does not establish every purpose, recipient, or retention rule.

Validation should combine technical inspection with owner confirmation. Check representative fields, configuration, access policies, and integration behavior. Where appropriate, use metadata or redacted samples rather than exporting entire datasets.

Distinguish direct identifiers from information that remains personal through context or linkage. A customer ID, pseudonymized event stream, or device identifier may still relate to an identifiable person. Removing names alone does not establish anonymization. Conversely, a pattern match for a number is not proof that the field contains a personal identifier.

Maintain a coverage record alongside the findings:

• Repositories and environments included, inspection dates, and permissions used.
• Discovery methods, classifier rules, and sampling approach.
• Encrypted content, unsupported formats, inaccessible stores, and other limitations.
• Confirmed findings, unresolved results, and the reviewer responsible for validation.

Restrict access to sensitive findings and avoid collecting unnecessary personal data just to prove its presence. Discovery credentials should have only the permissions needed. If elevated access is necessary, authorize it, limit its duration, and retain appropriate access evidence.

Convert locations into processing decisions

Technical discovery identifies where information sits. It cannot determine whether a purpose is justified, which Article 6 legal basis applies, or whether a data protection impact assessment is required under Article 35.

Group the findings into business activities with the relevant process owners and privacy reviewers. An email address used for account administration and the same address used for marketing may require different reasoning, retention rules, and notice content. Record the decisions rather than assigning one legal basis to the entire application.

Assess supplier relationships separately from geography. An Article 28 processor contract and a Chapter V international-transfer assessment answer different questions. An EU hosting region alone does not settle remote access, subprocessors, or onward transfers. Capture the recipient and access arrangements before deciding which contractual and transfer measures are relevant.

Where purposes, ownership, or legal justification remain unclear, create a review task. Do not disguise uncertainty as an approved inventory entry.

Worked example: a customer contact through support

The following is illustrative. Assume a SaaS provider collects a business contact through a signup form, uses a CRM and support platform, runs product analytics, and maintains recoverable backups. A support team also prepares weekly exports for workload analysis.

The discovery team follows a synthetic contact through signup and a support request. They compare integration settings with actual operating steps and find these branches:

The shared-folder finding changes the remediation plan. Deleting a contact from the CRM would not address that export. The support owner must identify existing files, confirm who received them, and implement an appropriate cleanup and export change.

The backup finding requires a different treatment. The team documents the retention schedule and restricted use of backup data, then tests the restoration workflow so an old restore does not silently reintroduce records that should remain deleted. Any retention exception needs justification; technical inconvenience alone is not a blanket exemption.

The deliverables are a validated lifecycle map, updated activity records where applicable, identified evidence gaps, and assigned remediation tasks. A second synthetic test checks whether the changed workflow behaves as intended.

Make the map useful during real work

Use discovery results to prioritize excessive access, inconsistent retention, missing supplier reviews, and inaccurate notices. Give each finding an owner, severity or priority, due date, and acceptance evidence. “Reduce access” is incomplete; “remove the broad support group from the export folder and verify effective permissions” is actionable.

For a subject access request, the map identifies likely systems, identifiers, recipients, and search owners. It does not replace the search itself or review for third-party rights. Responses are normally due within one month, subject to the GDPR’s extension conditions. Continue with subject access request handling for the operational workflow.

For a breach, the map helps responders locate affected stores and downstream copies. Confirm exposure using incident evidence; an inventory does not prove what an attacker accessed. Record uncertainties and the reasoning behind notification or non-notification decisions.

Keep discovery inside change management

A practical recommendation is to combine periodic reconciliation with event-driven updates. Trigger review when teams introduce a feature, supplier, integration, export, new data category, or retention change. Decommissioning should trigger checks for residual accounts, archives, and copies.

Assign a process owner and technical contacts, and keep validation dates visible. Review frequency should reflect change rate and risk rather than assuming every repository needs identical scanning intervals. Compare declared architecture with operational evidence to catch undocumented changes.

Secani can preserve the review context: model relevant systems and providers as target objects, connect evidence to requirements and decisions, and turn gaps into owned tasks. Keep approvals and source references attached to the work, reviewing any AI-generated suggestions before relying on them. Discovery tools establish the technical findings; the compliance workspace preserves their meaning and the decisions that follow.

Start with one representative record this week. Walk it through the actual workflow, document every handoff and copy, and assign the first unresolved branch to someone who can validate it.