Building a Personal Data Inventory: A Field-Level

Framework

The problem with system-level mapping

Most data inventory exercises begin at the wrong altitude. A team is asked to produce a record of processing,
opens a spreadsheet, and lists systems: CRM, ticketing platform, data warehouse, onboarding service.
Against each system it records "contains customer personal data," a purpose expressed at the level of
"customer relationship management," and a retention period copied from the nearest available policy.

This artefact looks like an inventory and functions as nothing. It cannot answer the questions the inventory
exists to answer. When a deletion request arrives, it does not say which fields to delete. When a purpose
changes, it does not say which consents must be refreshed. When a breach occurs, it does not say what was
exposed. When counsel asks whether a particular data element is personal data at all, it has no view.

A usable inventory is built at field level. The unit of record is not the system but the data element: a single
named attribute, in a single named store, collected for a stated reason. That granularity is expensive to reach
and is the only granularity that pays.

The unit of record

Each row in a field-level inventory should carry, at minimum, the following attributes.

Field identifier. The technical name as it exists in the store, not a business-friendly paraphrase. `cust_dob`
and `date_of_birth` in two different tables are two rows, because deletion, masking, and access requests
operate on the technical name.

Store and location. The database, table, bucket, index, or file share. Include derived and secondary
locations: the warehouse copy, the search index, the analytics extract, the log line. Fields replicate, and
unrecorded replicas are where deletion programmes fail.

Collection source. Directly from the individual, derived internally, or received from a third party. This
determines what notice was possible and what representations were made.

Stated purpose. Expressed narrowly enough to be falsifiable. "Verifying the identity of an applicant to
satisfy statutory customer due diligence requirements" is a purpose. "Business operations" is not.

Personal data status. A determination, not an assumption. See below.

Data principal. Whose data is it? This is harder than it appears and is treated separately below.

Lawful ground. Consent, or the specific named legitimate use relied upon. Where the ground is consent, a
reference to the consent artefact that captures it.

Retention trigger and period. Not a date but a rule: what event starts the clock, and how long does it run.
"Seven years from closure of the account" is a rule. "Seven years" is not.

Processors and recipients. Every third party with access, with the contractual instrument that governs it.

Controls. Encryption state at rest and in transit, access model, masking or tokenisation, logging.

Building a Personal Data Inventory 1

 Determining personal data status
The temptation is to classify each field as personal or not personal by inspection. This produces errors in
both directions.

The relevant test is whether the field, alone or in combination with other information reasonably available to
the organisation, relates to an identifiable individual. Two features of that test are routinely missed.

First, it is contextual. A five-digit postal code in isolation identifies a region containing tens of thousands of
people. The same postal code sitting in a row alongside a date of birth and a gender marker identifies, with
high probability, one person. Fields cannot be classified independently of the table they live in.

Second, the reference set is information reasonably available to the organisation, not information available
to the world. A pseudonymous customer identifier is personal data in the hands of a team that holds the
mapping table, and may not be in the hands of a downstream vendor that does not. The same field therefore
receives different classifications in different rows of the inventory, which is correct and frequently resisted.

A practical three-way classification is more useful than a binary:

• Direct identifier. Identifies an individual without assistance. Name, government identity number,
personal mobile number, personal email, biometric template, photograph.
• Indirect identifier. Identifies in combination. Date of birth, postal code, device identifier, IP address,
employer, transaction timestamps.
• Attribute. Neither identifying nor identifiable alone, but personal once attached to an identified
individual. Account balance, product held, risk score, support ticket text.

The classification drives control selection. Direct identifiers are candidates for tokenisation. Indirect
identifiers are candidates for generalisation in analytical copies. Attributes are candidates for access
restriction rather than transformation.

The data principal question

The statute confers rights on the individual to whom the data relates. In a consumer product, identifying that
individual is trivial. In a business-to-business product, it is the hardest question in the exercise, and getting it
wrong invalidates every downstream determination.

Consider a platform that onboards businesses. It collects the business name, its tax registration, its bank
account details, the name and identity document of an authorised signatory, and the address of the registered
office. Which of these are personal data, and whose?

The signatory's name and identity document are unambiguously the signatory's personal data. The business
name and tax registration of an incorporated company are, equally unambiguously, entity data and outside
the statute. The bank account belongs to the entity. The registered office is an entity attribute.

Now change one fact: the business is a sole proprietorship.

A sole proprietorship has no legal personality separate from the proprietor. The "business" bank account is
the proprietor's account. The tax registration is issued against the proprietor's own identity. The registered
office is very often the proprietor's home. The trading name may be a variant of the proprietor's own name.

Building a Personal Data Inventory 2

 Every field that was entity data in the first case is personal data in the second, and the same field in the same
column of the same table therefore has two different classifications depending on the value of a
constitution-type column elsewhere in the record.

This is not an edge case. In most Indian markets, sole proprietorships and other unincorporated forms make
up a large share of the merchant or customer base. Any inventory that classifies by column rather than by
column-conditional-on-entity-type will systematically misclassify a large fraction of its holdings.

The resolution is to make entity type a first-class dimension of the inventory. A field's classification is
recorded as a function, not a constant:

Field Incorporated entity Partnership / LLP Sole proprietorship /

individual

Business legal name Entity data Entity data Personal data (proprietor)

Tax registration number Entity data Entity data Personal data (proprietor)

Settlement bank account Entity data Entity data Personal data (proprietor)

Registered address Entity data Entity data Personal data (proprietor)

Signatory identity document Personal data (signatory) Personal data (partner) Personal data (proprietor)

Beneficial owner details Personal data (owner) Personal data (partner) Personal data (proprietor)

The operational consequence is that rights fulfilment, retention, and access control must all read the entity
type. A deletion workflow that treats the settlement account as entity data will refuse a valid erasure request
from a proprietor. An access request handler that treats it as personal data for all entity types will disclose a
company's banking details to an individual signatory who has no right to them. Both failures are common
and both are avoidable only if the inventory encodes the conditionality.

Risk tiering
Not every field warrants the same investment. A tiering scheme lets the programme allocate control effort
defensibly. A workable four-tier model:

Tier 1 — Critical. Compromise enables direct financial or identity harm. Full government identity numbers,
complete bank account and routing details, payment card data, biometric templates, authentication
credentials, one-time passcodes. Controls: tokenise or encrypt at field level, restrict access to named roles
with just-in-time elevation, log every read, never write to logs or analytics copies.

Tier 2 — High. Compromise enables targeted fraud or significant privacy intrusion. Identity document
images, precise geolocation, full date of birth in combination with name, income and credit data, health
information, communication content. Controls: encrypt at rest, role-based access, mask in non-production,
exclude from general analytics copies.

Tier 3 — Moderate. Compromise enables nuisance, profiling, or aggregation harm. Contact details, coarse
location, device identifiers, transaction metadata, support interaction records, behavioural event streams.
Controls: standard access control, retention discipline, generalisation in analytical copies.

Tier 4 — Low. Personal data with minimal standalone harm potential. Display preferences, locale,
non-identifying product configuration. Controls: baseline.

Building a Personal Data Inventory 3

 Tiering should be assigned against the field-in-context, not the field name. A partial identity number
retaining only the last four digits is not Tier 1. The same number in full is.

Special treatment for identity documents

Identity document data deserves separate handling because it presents a distinctive combination of high
sensitivity, statutory collection mandate, and format complexity.

Several categories of identity document carry legal restrictions on storage and use that sit outside general
data protection law — restrictions on retention of full numbers, requirements to store only redacted forms,
prohibitions on use for purposes other than the one authorised. These restrictions are sector- and
instrument-specific and cannot be inferred from data protection principles alone.

A document image, moreover, contains far more than the field it was collected to verify. An identity card
image submitted to verify an address also contains a photograph, a date of birth, a parent's name, and a
document number. If the inventory records only "address proof," it under-states the holding by four fields,
and a breach notification built from that inventory will be materially inaccurate.

The correct treatment is to inventory the contents of document images as separate derived fields, each with
its own classification, and to record the image itself as a Tier 1 or Tier 2 asset in its own right.

Sequencing the exercise

A field-level inventory of a mature organisation runs to thousands of rows. Attempting it in a single pass
fails. A workable sequence:
1 Bound the scope by processing activity, not by system. Pick one activity with a clear beginning and
end — onboarding, for instance, or payroll. Follow the data through every store it touches.
2 Enumerate fields from the schema, not from interviews. Interviews establish purpose; schemas
establish existence. Teams reliably forget fields they no longer use, and unused fields are pure liability.
3 Classify with the entity-type dimension present from the start. Retrofitting conditionality into a
completed inventory means re-reviewing every row.
4 Assign purpose and lawful ground with the business owner, in writing. Where no named legitimate
use applies and no consent exists, the row is a finding, not a blank.
5 Derive retention from the trigger, and test the trigger exists. A retention rule keyed to an event the
system does not record is not a retention rule.
6 Reconcile against reality. Sample the store and confirm the fields the inventory claims are the fields
present. Discrepancy rates on first reconciliation are typically material.

Common failure modes

Derived and inferred fields omitted. Risk scores, segments, propensity models, and fraud signals are
personal data about the individual and are frequently absent from inventories built from collection forms.

Logs and telemetry excluded. Application logs routinely capture identifiers, request bodies, and
occasionally credentials. A store excluded from the inventory is a store excluded from deletion.

Building a Personal Data Inventory 4

 Backups treated as out of scope. Backups are within scope. The realistic position is not that backups are
exempt but that deletion from backups occurs on the backup expiry cycle, and that this is documented,
bounded, and disclosed.

Purpose inflation. Purposes written broadly to avoid future re-consent. A purpose broad enough to cover
anything is not specific, and consent obtained against it is defective.

Retention periods asserted without authority. Every retention period should cite either a statutory
requirement, a limitation period, or a documented business justification. "Standard practice" is not an
authority.

Hidden and archived rows. Inventory spreadsheets accumulate hidden rows, filtered views, and archived
tabs. Fields parked there are fields excluded from every downstream process that reads the file. Before
sign-off, unhide everything and reconcile the row count.

The output
The inventory is not the deliverable. It is the substrate from which four deliverables are generated: the notice
presented to individuals, the retention schedule enforced in systems, the rights fulfilment runbook, and the
breach impact assessment template. If the inventory cannot generate all four without additional research, it is
not yet finished.

Prepared as a general methodological guide. It does not constitute legal advice, and it does not describe the practices of any
particular organisation. Sector-specific obligations, including those applicable to financial services, frequently impose requirements
more demanding than those discussed here.

Building a Personal Data Inventory 5