Personal Data Discovery and Data Subject Request Workflow for Small Companies

The problem small companies have with personal data

A 20-person startup collects names, phone numbers, national ID numbers, addresses and payment references across a production database, an analytics warehouse, a support tool export and a folder of spreadsheets. Then a customer asks, under a data protection law, "what data do you hold about me, and please delete it". Nobody knows where everything is. The answer takes a week of engineers grepping tables, and some copies are still missed.

Data protection laws modelled on the GDPR are spreading, and enterprise customers now ask startups for a data map in security questionnaires. Pakistan has had a draft Personal Data Protection Bill under discussion for years; whatever its final form, the engineering problem is the same everywhere: know where personal data lives, and be able to act on it.

What already exists and the gap

• OneTrust: the market leader in privacy management, broad and expensive, sold to large enterprises.
• Transcend and Ketch: modern privacy platforms with automated discovery and request fulfilment, aimed at engineering-led mid-size companies.
• BigID: data discovery and classification at enterprise scale.
• Microsoft Presidio: an open source library for detecting and anonymising PII in text and structured data. A building block, not a workflow.

The gap is a small, self-hostable tool that a startup's one backend engineer can connect in an afternoon, which does discovery well enough for their few systems and runs the request workflow with deadlines and evidence.

What you build

Roles: privacy owner (often a founder or engineer), reviewer, data subject (the member of the public making a request).

1. Connect data sources with read-only credentials.
2. Discover: sample each column or file, classify it (email, phone, name, national ID, address, free text containing PII), and propose a data map.
3. Review: the privacy owner confirms or corrects classifications and marks which column identifies a person in each table.
4. Request: a data subject submits a request through a hosted form and verifies their email. The owner sees the deadline counting down.
5. Fulfil: the tool looks up the person across mapped systems, generates an export for access requests, and for deletion requests produces the list of records and either runs approved deletions or generates the statements for an engineer to run, logging everything.

The technically interesting part

Column-level classification from samples is the core. Detecting that a single string is a phone number is easy; deciding that a column called "ref2" is a national ID column from 200 samples, with low false positives on order numbers that look similar, is not. Combine value recognisers, checksum validation where formats have one, column name hints and the ratio of matching samples. Build a synthetic schema with tricky decoys and measure precision and recall per category.

The second hard part is finding one person across systems with only a verified email: follow the data map's identifier columns and join through foreign keys. Document the limits honestly.

How to evaluate it

• Classification: precision and recall per PII category on a 100-column synthetic schema, with and without column name hints.
• Request fulfilment: time to complete an access request across three connected systems, compared with doing it by hand.
• Coverage: on a seeded dataset, percentage of a test person's records found.
• Safety: confirm connectors never write, and that sampled values are not stored beyond the classification result.

Suggested plan

1. Weeks 1 to 4: study GDPR data subject rights at a practical level, design the synthetic schema, try Presidio.
2. Weeks 5 to 10: connectors and sampling, classifier and custom recognisers.
3. Weeks 11 to 15: data map UI and review flow.
4. Weeks 16 to 21: request portal, fulfilment, audit log.
5. Weeks 22 to 26: evaluation, pilot with a friendly startup on a staging copy, write-up.

Path to a product

The first customer is a startup whose enterprise client has sent a security and privacy questionnaire. Sell a self-hosted licence or a hosted plan priced per connected data source. Privacy consultants and law firms who advise startups are a strong channel, since they need the data map but cannot build it.

Scope warning

Do not build cookie banners or consent management. Do not give legal advice in the product; link to the law and let a professional interpret it. Do not copy full production data into your tool; sample, classify and discard.

Learn what you need on Sefism

• Backend roadmap : database connectors, job queues and API design.
• Backend cheat sheet : quick reference for the service layer.
• PostgreSQL Documentation : information schema queries and safe sampling.
• OWASP ASVS : data protection and logging requirements for your own tool.
• Machine learning cheat sheet : precision, recall and threshold tuning for the classifier.

Get help with this idea

Scoping a security project is mostly about deciding what you will not defend against and how you will prove the rest works. If you want a second opinion on scope, stack or your evaluation plan, a mentor can review it with you; you still build it yourselves. New to Sefism? Create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session