Keep Track of Where Your KYC Data Went

You have given your ID to a bank, two brokers, a notary, three SaaS platforms, a landlord, and a crypto exchange you barely use anymore. Quick: name all of them, what each one still holds, and which copies are sitting in someone's email inbox. You can't, and that is the entire problem. A personal KYC register is the boring, decisive fix — a single inventory of where your identity data went so that revocation, deletion requests, and breach response become lookups instead of archaeology.

The reason this matters is asymmetry. Each individual share feels trivial. The aggregate is a sprawling, undocumented attack surface that you cannot defend because you cannot see it. When a provider gets breached, the first question is "did they have my data?" — and without a register you are guessing. This guide builds the register and the cadence that keeps it alive.

The six columns that matter

Resist the urge to over-engineer. A register with twenty fields gets abandoned by week two. Six columns carry all the weight:

Column	Why it earns its place
Recipient	Who holds the data — the entity you would contact to revoke or delete
What you sent	Full document, or just specific fields — determines breach severity
Date sent	Starts the retention clock
Channel	Email, secure link, portal upload — tells you whether a copy still exists
Stated retention	When they said they would delete it — your trigger for an Art. 17 request
Next review	The date you will check this row again

The channel column is the one people skip, and it is the most operationally useful. A document sent over a controlled link with download disabled behaves completely differently from the same document pasted into an email — one you can revoke, the other is gone the moment it lands. Knowing the channel tells you what is recoverable.

Capturing entries without it becoming a chore

A register only works if entries get logged at the moment of sharing, not reconstructed later. Build the habit into the share itself:

1. Log before you send. The thirty seconds it takes to add a row is the cheapest insurance you will ever buy.
2. Record what, not just who. "Sent passport + proof of address to Bank X" is actionable; "did KYC with Bank X" is not.
3. Note the stated retention immediately. It is in their privacy notice at the moment of onboarding; it is buried and forgotten a year later.

This logging discipline is one piece of a broader KYC hygiene routine — the register is the memory layer that makes the rest of the routine possible. Without it, every other good habit operates blind.

What a complete register looks like in practice

To make this concrete, here is a register a moderately active sharer might hold after a year. The detail is the point: each row is independently actionable.

Recipient	What you sent	Date	Channel	Stated retention	Next review
Bank X	Passport + address proof	2025-02-10	Portal upload	5 yrs after closure	2026-02
Broker Y	Passport, name + DOB only	2025-04-22	Secure link	5 yrs	2026-04
Notary Z	Full passport scan	2025-06-01	Email	Statutory (notarial)	2026-06
SaaS platform	Name, DOB, address	2025-08-15	Secure link	Until account closed	2026-08
Landlord	ID + proof of income	2025-09-30	Email	Unspecified	2026-03

Read down the rows and the worklist writes itself. The landlord row has an unspecified retention and an email channel — that is your highest-priority erasure request, because you have neither a deletion date nor any way to revoke. The two secure-link rows are low-anxiety: you can revoke them and see their access logs. The register does not just record exposure; it ranks it.

When the register earns its keep

The register feels like overhead right up until the moment it doesn't. Two scenarios make the value obvious.

A provider you used announces a breach. Without a register, you spend an evening trying to remember whether they ever had your full document or just a couple of fields, and whether the copy is still live. With one, you read a single row, see exactly what they held and how, and act in minutes. This is the difference between a managed ID data breach response and a panicked guess.

The second scenario is quieter and more common: nothing dramatic happens, but a deal falls through, a subscription lapses, a relationship ends. The register's review pass catches these and prompts the revocation or erasure that would otherwise never happen, because nobody remembers to clean up data when there is no crisis forcing them to.

The revocation and deletion cadence

A register that nobody reads is just a list. The value comes from the recurring pass over it. Set a quarterly review and, for each row, ask three questions:

• Is the stated retention period over? If yes, that is your cue to send an Art. 17 DSGVO erasure request. The provider had a defined purpose and a defined window; once both lapse, continued storage is hard to justify.
• Is this share still needed? A link you sent to a deal that fell through should not still be live. If the channel was a controlled link, revoke it now.
• Has anything changed? New address, expired document, a provider you have offboarded — the register should reflect reality.

The deletion side connects directly to your GDPR rights in KYC — the register turns the abstract right to erasure into a concrete worklist. Instead of vaguely intending to "clean up your data someday," you have a dated list of erasure requests to send this quarter.

Why the channel determines your options

It is worth dwelling on the difference the channel makes, because it changes what the register can do for you.

If you emailed a flat scan, the register can record that the data is out there — but you have no lever. You cannot expire an email, cannot revoke it, cannot see whether it was forwarded. The register documents an exposure you cannot close.

If you shared through a controlled link, the register points at something you can act on. You can revoke access, see the audit log, confirm whether the file was ever downloaded. The same row in the register is either a dead exposure or a live control, depending entirely on how you sent it. This is the strongest argument for moving away from email attachments, covered in email encryption vs secure links.

Letting the tooling keep the register for you

The honest weakness of a manual register is that it depends on you remembering to log every share and run every review. The moment you forget a row, the inventory is wrong in exactly the way that bites during an incident.

A verify-once model closes that gap by making the register a byproduct of sharing rather than a separate chore. With ShareKYC, every share you create is already logged: who you sent it to, which fields, when it expires, whether download was allowed, and a full audit trail of every access. The register is generated automatically from the shares themselves. Revocation is a button, not a phone call, and the retention clock is enforced by the expiry you set rather than by the recipient's good intentions. You still keep notes on email-based shares you made before — but the new ones maintain their own inventory.

That also makes the quarterly review faster: instead of reconstructing what you sent, you scan a live dashboard of active shares and revoke the ones that have outlived their purpose.

Conclusion

You cannot defend what you cannot see. A personal KYC register — six columns, logged at the moment of sharing, reviewed quarterly — turns a scattered, forgotten exposure into a manageable worklist for revocation and deletion. The channel you used decides whether each entry is a live control or a dead exposure, which is the strongest reason to share through links you can revoke. If you would rather the inventory maintain itself, ShareKYC logs every share automatically and turns revocation into a single click.