You handle workforce data,
not a basic CRM table.
An HR or payroll product sits on identities, salaries, contracts, candidate histories, and supporting documents. An external review shows you fast what an enterprise client, partner, or attacker can already reach from the outside.
Regulatory and business pressure
GDPR — workforce data
In forcePayroll records, contracts, HR files, and supporting documents need proportionate security measures, documented well enough to stand up to scrutiny.
Client security reviews
Every new accountHR buyers and enterprise prospects keep asking for proof of access control, tenant separation, and how you handle data.
Product speed
NowTeams under 50 people ship fast on Supabase, Firebase, or Next.js — usually without ever running a serious external review of roles, APIs, and exposure paths.
Common HR Tech vulnerabilities
- APIs returning employee, candidate, or payroll records with no real access control
- Weak separation between admin, manager, and employee roles, front end and back end
- CSV exports, contracts, or payslips reachable through direct URLs or loose storage buckets
- Missing or incomplete RLS on Supabase or Firebase, opening cross-tenant access
- HR webhooks and automations that fire without any real validation
- Client portals leaking data across organizations
In this space, the worst findings rarely come from a dramatic CVE. They come from an HR API that returns too much, a sloppy role model, or a sensitive export reachable from the outside.
Why HR and payroll vendors are a priority target
An HRIS, a payroll tool, or an ATS holds everything an attacker or a competitor wants about a company: identities, salaries, social security numbers, partial bank details, contracts, sick leave, performance reviews. French vendors typically host dozens of customer companies on the same multi-tenant database. An isolation bug never hits one client. It hits the whole book. That's the most expensive risk in an HRIS: one missed RLS policy, one forgotten API filter, one sloppy multi-tenant endpoint — and the leak covers dozens of SMBs at once. HR vendor teams stay small: a founder, two to five engineers, rarely a dedicated security lead. Risk scales faster than the team.
The typical exposure surface of a payroll product
Beyond the app itself, a payroll tool usually exposes: an employee portal (payslip download), a manager portal (team view, leave, approvals), an HR back office, integration APIs (accounting, banking, third-party HRIS), outbound webhooks to payroll connectors, regulatory filings (DSN and DPAE in France), and document storage (payslips as PDFs, contracts, bank details). Each surface has its own recurring failure modes. Payslips in public buckets with guessable URLs. Unsigned webhooks that happily accept replays. HR exports leaking another tenant's data through a join bug. Integration tokens sitting in JS bundles that anyone can read. None of this shows up in automated scanners. It takes a manual external review.
Getting ready for an enterprise security questionnaire
A large buyer picking an HRIS sends a security questionnaire before signing. These cover: hosting and certifications (ISO 27001, HDS for health data), access management and SSO (SAML, SCIM), encryption at rest and in transit, logging, backups, business continuity, sub-processors, GDPR Articles 32 and 33, incident response drills. Most vendors under 50 people hit these questionnaires too late, mid-sales cycle. Losing an enterprise deal over a half-filled questionnaire can cost tens of thousands of euros in MRR. A prior external audit gives you the evidence: exposure mapping, applicable GDPR articles, review results, remediation plan. Enough to answer with proof instead of promises. That's often what brings HR vendors to us in the first place.
Sensitive integrations: payroll filings, ATS, banking APIs
A payroll tool pushes monthly regulatory filings to social security bodies. An ATS exchanges data with job boards (LinkedIn, Indeed). An HRIS connects to the payroll tool, to enterprise SSO (Azure AD, Okta), and to banking APIs for transfers. Each integration is a surface. Typical failures: HMAC signatures sent but never verified on the receiving side, OAuth tokens that survive a user reset, integration secrets stored in plaintext in the database, webhooks that accept a timestamp from hours ago (replay). An external audit maps these integrations, tests what can be replayed, and surfaces the secrets already sitting out in public — JS bundles, error logs, .map files shipped to production.
GDPR sub-processor (Article 28): vendor obligations
An HR software vendor is almost always a GDPR data processor for its customers (the employer is the controller). Article 28 frames that relationship: written sub-processing agreement, documented technical and organizational measures, timely breach notification, audit rights for the customer. The points that come back to bite vendors under regulatory scrutiny: no documentation of technical measures (encryption, pseudonymization, isolation tests), no second-tier sub-processor registry (host, email provider, AI service), no defined breach notification timeline, missing Art. 28 clauses in the contract. Our audit report maps every exposure to the applicable GDPR articles (32, 33, 28). It's a document enterprise customers accept as due-diligence evidence.
Related reading — HR & payroll
- →Supabase HRIS: the data-separation checklist
- →Multi-tenant HRIS: how to prove one client can't see another's data
- →Employee portal and RLS: what really breaks separation
- →Manager portal: what a manager can see about employees (and shouldn't)
- →Payslip PDFs: where teams get storage wrong
- →Payslip encryption: what to actually check
- →DSN security: weak points to review in payroll software
- →Payroll webhooks to accounting: signature, replay, and data in transit
- →Enterprise SSO and HRIS: SAML and SCIM pitfalls that show up in production
- →GDPR employee data export: what the access request reveals about your product