Authoritative, not just comprehensive
Most organisations have several places that know about employees: a recruitment system, a payroll system, an access directory, a benefits portal, and a spreadsheet somebody maintains. Each is partly right.
The failure that follows is not missing data but disagreement. Headcount differs between reports, a leaver retains system access, a payslip carries an old address, and nobody can say which record is authoritative because none of them is.
The useful design principle is to name one system as the source for each fact and have the others take it from there. That is a governance decision more than a technical one, and organisations that skip it end up reconciling forever.
Comprehensiveness is the lesser goal. A database holding fewer fields that are all correct is more useful than one holding everything with no confidence in any of it.
What belongs in it
| Category | Examples | Why it is held |
|---|---|---|
| Identity | Name, contact details, identifiers required for statutory filings | Payroll, compliance, contact |
| Employment | Start date, role, grade, reporting line, location, cost centre, status | Almost every downstream process |
| Terms | Contract type, notice, working pattern, variations with dates | Answering what applies to this person today |
| Pay | Structure, components, history of changes | Payroll, settlement, pay equity analysis |
| Events | Transfers, promotions, leave, absence, disciplinary outcomes, exit | The history that most questions are actually about |
| Sensitive | Bank details, dependants, health information where held, disability status | Specific purposes only, with tighter access |
The bottom row is the one to be deliberate about. Sensitive data should be held because a named process needs it, not because a form collected it, and it should carry narrower access than the rest.
History is the part that gets lost
Databases are usually designed to answer what is true now, and most of the hard questions are about what was true then.
What was this person's grade when the promotion decision was made. What was the policy on the date they were dismissed. Who was their manager during the period the grievance covers. What was their pay before the restructure.
Systems that overwrite rather than version cannot answer any of these, and the reconstruction is done by hand from correspondence, which is slow and unreliable at exactly the moment accuracy matters.
- Store changes with effective dates rather than replacing values.
- Keep the reason alongside the change, since a pay increase and a market correction look identical in the numbers.
- Retain the reporting line as it was, not only as it is, because manager-level analysis is meaningless without it.
- Make it possible to ask what the record said on a given date, rather than only what it says now.
This is also what makes pay equity and progression analysis possible. Both are questions about change over time, and neither can be answered from a snapshot.
The obligations it carries
An employee database is a large concentration of personal data, and in India the governing instrument is the Digital Personal Data Protection Act, 2023. Its substantive duties are not yet in force: notification G.S.R. 843(E) of 13 November 2025 brings sections 3 to 17, which carry the grounds for processing, notice, consent, the obligations of a data fiduciary and the data principal rights, into force on 13 May 2027. The definitions, the Data Protection Board and the penalty machinery commenced on 13 November 2025. So the practice described here is how to be ready, and good design in its own right, rather than a duty that binds today.
The general shape of what it will require is familiar: collect for a stated purpose, hold no more than the purpose needs, keep it accurate, restrict access to those who need it, retain it only as long as required, and be able to respond when a person asks what is held about them.
The specific provisions are dealt with in the entries covering that Act rather than restated here, because the detail matters and this entry has not verified it.
- Set retention periods, including for leavers, and apply them rather than intending to.
- Restrict sensitive fields separately, since role-based access that treats bank details like job titles is too coarse.
- Log access to sensitive records, which is both a control and the only way to answer questions about misuse.
- Be able to extract everything held about one person, which is difficult if the record is spread across five systems.
The last point connects back to fragmentation. A scattered people record is not only an operational problem; it makes a subject access request genuinely hard to answer.
Access, and who actually needs it
Access is usually granted by seniority, and it should be granted by question.
A manager needs to see their own team's leave and performance record. They do not need salary history across the organisation. A payroll administrator needs bank details for everyone and has no reason to read disciplinary notes. An HR business partner supporting one function does not need the other functions.
Designing access around the question rather than the grade produces narrower and more defensible permissions, and it avoids the common pattern where senior managers accumulate access to everything because refusing them felt awkward.
It also reduces the blast radius of a compromised account, which is the practical security argument for the same design.
Frequently asked questions
What is an employee database?
The structured record of an organisation's people: identity, role, terms, pay, history and status. Its value depends on being authoritative rather than comprehensive, since the real damage from fragmentation is that nobody can say which copy is correct.
Why do duplicate employee records appear?
Because recruitment, payroll and access management are often separate systems, each partly right. The result is disagreement rather than missing data: headcounts differ, leavers keep access, and no record is authoritative.
Why does history matter in an employee database?
Because most difficult questions are about a past date: what grade someone held when a decision was made, who their manager was during the period a grievance covers, what their pay was before a restructure. Systems that overwrite rather than version cannot answer any of them.
What data protection obligations apply?
The Digital Personal Data Protection Act, 2023 governs it. In practice that means collecting for a stated purpose, holding no more than needed, keeping it accurate, restricting access, setting retention periods including for leavers, and being able to say what is held about one person.
Who should have access to employee data?
Access should follow the question rather than seniority. A manager needs their own team's leave and performance, not organisation-wide salary history; a payroll administrator needs bank details and has no reason to read disciplinary notes.
How Engage holds the record
Engage keeps identity, terms, pay, events and exits in one versioned record with effective dates, so what was true on a past date is answerable rather than reconstructed. Because recruitment and payroll draw on the same record, the duplicate people entries that arise from separate systems do not get created in the first place.
See employee records in Engage