Make role-based permissions the primary control and grant each role the least it needs. Review entitlements whenever someone joins, moves or leaves. Log reads and edits on sensitive fields, encrypt in transit and at rest, run real vendor due diligence, and govern exports, because the downloaded spreadsheet is the copy nobody is watching.
Technical protections defend against outsiders. The realistic risk to an HR record is an insider who was given more than the job required and never had it taken away. So the first design task is a permission model built from roles rather than from individuals: define what an HR generalist, a recruiter, a finance analyst, a site administrator and a line manager each need to do, then grant exactly the fields and actions those tasks require. Granting by person produces a system where nobody can describe who can see what within a year. Two refinements matter. Permissions should be scoped by population as well as by field, so a site administrator sees their own site rather than the whole organisation. And read, edit, approve and export should be separable rights, because the ability to view a record is a very different thing from the ability to extract a thousand of them.
Three events change what a person should be entitled to, and only one of them is usually handled well. Joining is easy because someone is actively setting the person up. Leaving is mostly handled, though the gap between last working day and account closure is worth measuring rather than assuming. Moving is where entitlement quietly accumulates: an internal transfer adds the new team's permissions and almost never removes the previous ones, and after two or three moves an individual holds a set nobody designed. Fix it by making the entitlement change part of the transfer process rather than a separate request, and by running a periodic review where each owner confirms their list. The review only works if it is short and specific; asking a manager to approve a page of technical role names produces a rubber stamp rather than a decision.
Logging every action produces a volume nobody examines, which is indistinguishable from logging nothing. Choose the fields where a read is itself significant - identity documents, bank details, medical or disability information, disciplinary records, compensation - and log views as well as changes on those. Record who, what, when and from where, and keep the log outside the reach of the people it observes, including administrators. Then decide what actually gets reviewed: an alert on an unusual pattern such as a single account opening many unrelated records in a short window is far more useful than a monthly report nobody opens. Logging has a second purpose beyond detection. When an employee asks who accessed their file, a specific answer settles the question, and a vague one turns a query into a grievance.
Encryption in transit and at rest is table stakes and every serious vendor provides it; the useful follow-up is who holds the keys and how they are rotated. Single sign-on matters more than it appears to, because it centralises the removal of access when someone leaves rather than requiring a separate revocation in every system. Enforce multi-factor authentication on administrative accounts at minimum. Confirm that backups exist, are themselves encrypted, and have actually been restored in a test rather than only in a policy document. If you run [cloud HR software](/cloud-hr-software), also establish where the data physically sits and whether that location can be specified, since data residency drives obligations that differ by jurisdiction and change over time - confirm your position with a qualified advisor rather than relying on a marketing page.
Your controls stop at the boundary of the product, so the vendor's controls become yours. Ask for a current independent audit report or certification summary and check the period it covers, since these lapse. Get the subprocessor list in writing: the hosting provider, email delivery, document storage, analytics and any model provider are separate companies handling your employees' information. Read the data processing agreement rather than filing it, because it defines who is accountable when something goes wrong and what happens to your data at contract end. Ask specifically how a breach is notified to you and within what period, because your own obligations depend on their timeliness. Where you have no internal security function, have a technically literate colleague sit through the vendor's overview and record unanswered questions as open items rather than closing them optimistically.
A well-permissioned system can be undone by one download. A payroll register pulled into a spreadsheet for a reconciliation, a headcount extract mailed to a consultant, an ID document saved locally to attach to a form: each of these creates a copy outside every control you built, and copies do not expire. Treat export as a distinct right granted to few people, log it separately from ordinary reads, and prefer in-product reporting and read-only shared views over sending files. Where an extract is genuinely needed, restrict the fields rather than exporting everything and letting the recipient delete what they do not need. Watch attachments too, since a scanned identity or bank document forwarded by email is the same problem in a different container. Include this in the induction for anyone joining a team that touches [employee records](/employee-database-software).
Data you no longer hold cannot leak, which makes disciplined deletion a security control rather than only a compliance chore. Build a retention schedule field by field instead of record by record, because payroll and statutory records, disciplinary papers, recruitment leftovers and medical information are governed differently and expire at different points. Decide what happens at expiry: hard deletion, or anonymisation where you need the aggregate but not the person. Then check the parts people forget - backups, archived exports, the old system left running after a migration, and the shared drive nobody has opened since it was created. Retention periods are set by employment, tax and statutory record-keeping rules that differ by jurisdiction and change, so confirm the current position with a qualified advisor and revisit it rather than treating the schedule as permanent.
Pitch N Hire is an applicant tracking system built for recruiters and hiring teams. If this answer described something you want to run properly, the ATS is where it lives.
Free for 1 user · No credit card · Talk to a real hiring expert
Get a personalized walkthrough of Pitch N Hire on your own roles and workflow. No slides, no obligation.
Prefer to talk? Book a demo · Talk to sales · View pricing
Free 1-user plan · No credit card · Talk to a real hiring expert
See your true cost-per-hire and how much Pitch N Hire could save you — our free Recruitment ROI Calculator gives you the numbers in under a minute. No signup required.
Open the free ROI calculatorPrefer a tailored walkthrough on your real roles? Drop your work email:
★ Free 1-user plan · No spam · Talk to a real hiring expert
