By Mehdi HassanWhat should an HR software security page cover?
An HR software security page should cover the specific ways you protect employee data, not just a list of general security practices. A security reviewer evaluating an HRIS, payroll or performance tool wants to know what happens to compensation, bank details, identity documents, reviews and leave records, and who can reach them. Generic language about encryption and firewalls doesn't answer that.
This checklist is the employee-data version of a standard SaaS trust page. If you need the basics of trust centers in general, our guide to trust center page design covers structure and tooling. For how security fits into the rest of an HR site, start with our HR tech website design guide.
Employee data type | Why reviewers care | What to state |
|---|---|---|
Compensation and payroll | Leaks cause internal and legal damage | Field-level permissions, audit logs |
Bank and tax details | Direct fraud risk | Encryption, masking, change verification |
Identity documents | Identity theft and right-to-work checks | Storage location, retention period |
Health, leave and benefits | Special category data in many laws | Restricted access, separate handling |
Performance reviews | Sensitive and often disputed | Visibility rules for managers and HR |
Which certifications belong on an HR data privacy page?
An HR data privacy page should list the certifications and attestations you actually hold, with the date of the latest audit and a way to request the report. For most HR software sold in the US, that means a SOC 2 Type II report. Companies selling into Europe often add ISO 27001. State what's done and what's in progress, separately.
Trust center guides recommend putting certifications at the top of the page, because that's what reviewers scan for first. The AICPA also has rules about how its SOC logo may be used, so check them before you design a badge row. If you need the detail on display rules, our guide on b2b website trust pages covers status pages, compliance pages and how to keep them current.
How should a GDPR HR software page explain data processing?
A GDPR HR software page should explain that the employer is the controller and you are the processor, then show how you meet a processor's obligations. EU employers need a data processing agreement, a list of subprocessors, a clear answer on where data is hosted and how international transfers are covered. Put all four on the page or one click away.
- Roles. One sentence: your customer controls employee data, you process it on their instructions.
- DPA. A downloadable data processing agreement or a self-serve signing flow.
- Subprocessors. A dated list with each vendor's purpose and location, plus how customers are told about changes.
- Hosting and transfers. Regions you host in, whether customers can choose, and the transfer mechanism you rely on.
- Retention and deletion. What happens to former employees' records and to all data when a customer leaves.
US employers have their own questions too. California's privacy law now covers employee data, so US buyers increasingly expect the same rights-handling story. The official GDPR overview is a useful plain-language reference for your team, but have counsel review the final wording on your page.
How do you show employee data security inside the product?
Show employee data security inside the product by explaining permissions, not just infrastructure. An HR buyer's biggest internal risk is the wrong person seeing the wrong record: a manager seeing a peer's salary, or a recruiter seeing medical leave. Your page should describe how the product prevents that, with screenshots of the permission settings if you can.
- Role-based access, with default roles for HR admin, payroll, manager, employee and IT.
- Field-level visibility for compensation, bank details, national ID numbers and health information.
- SSO and SCIM so access follows the customer's identity provider and leavers lose access automatically.
- Audit logs showing who viewed or changed sensitive fields, exportable for the customer.
- Change verification for bank details, such as confirmation steps that block payroll diversion fraud.
- Employee self-service rights: how staff view, correct or request deletion of their own data.
These are product features as much as security features, so the marketing page and the product should tell the same story. Our guide to HR dashboard design covers how permission states should look inside the admin console.
What changes if your HR software uses AI?
If your HR software uses AI, the security page has to explain what employee data the models see, whether it's used for training, and where AI influences decisions about people. Employers are cautious here, because AI that screens candidates or scores performance can raise discrimination and transparency concerns, and some jurisdictions now regulate automated hiring tools.
State plainly which features use AI, which model providers process data and under what terms, whether customer data trains any model, and how a human stays in the loop for decisions like hiring or promotion. Our guide to an AI trust center page covers the AI-specific sections in more depth, and enterprise AI website explains what procurement teams check.
Hypothetical example: AI disclosure for a recruiting tool
For example, suppose a recruiting platform summarizes interview notes and suggests candidate rankings. Its security page would add a short "AI features" section: which features use AI, that customer data is not used to train shared models, which model provider processes the notes and where, that rankings are suggestions a recruiter must review, and how customers can switch the feature off.
It would also link to any bias audit or assessment the company has completed. This is an illustrative structure, not a real company's page.
How should you lay out an HR software security page?
Lay out an HR software security page so a reviewer can complete half their questionnaire from it. Put the certification summary first, employee-data handling second, product controls third, and legal documents last, each with a short answer up top and the detail below. Use a trust center tool or your CMS so the security team can update it without a developer.
Summary block
Certifications with audit dates, hosting regions and a "Request our SOC 2 report" button.
Employee data section
The data types you hold and how each is protected, in a table.
Product controls
Roles, field-level permissions, SSO, SCIM and audit logs, with screenshots.
Privacy and GDPR
Controller and processor roles, DPA, subprocessors, retention and employee rights.
AI and incident response
AI data use if relevant, breach notification commitments, and a security contact.
Make the page accessible too. Security and IT reviewers use screen readers and zoom like anyone else, and an HR product that serves every employee should meet the same standard on its own site. Our guide to website accessibility compliance covers the basics.
How do you keep an HR software security page current?
Keep an HR software security page current by giving one person ownership and tying updates to events: a new audit report, a new subprocessor, a new hosting region or a new AI feature. Trust center guides stress that a stale page does more harm than a short one, because reviewers notice expired dates immediately.
- Add a "Last updated" date to the subprocessor list and the page itself.
- Set a calendar reminder for each audit renewal.
- Route new vendor approvals through whoever owns the page.
- Review the page whenever you ship a feature that touches sensitive fields.
