An HR analyst at a 900-person company built a dashboard to help managers plan annual raises. It was genuinely useful: current salary, pay band, last performance rating, and a suggested increase, all in one view. To feed it, she asked a friendly data engineer to set up a cloud storage location for the nightly salary export. He configured it so the dashboard could read the file via a shared link. Then the link got pasted into a managers' chat channel. For three weeks, anyone who had it could download salaries, ratings, and home addresses for the entire company. A routine security scan finally caught it.
Nobody acted in bad faith. Everyone was trying to get raises out on time.
HR Builds Because It Has To
HR teams rarely get engineering time. IT prioritizes customer-facing systems, and the core HR platform is often rigid and slow to change. So HR analysts, recruiters, and operations staff build their own tools: onboarding trackers, compensation planners, interview scorecards, headcount dashboards.
That's mostly healthy. The trouble is that HR works with some of the most sensitive data in any company, and the people building tools are usually not trained in security. They shouldn't have to be, as long as the platforms and rules around them do part of that work.
Choosing the Right Platform
When evaluating tools for citizen development, HR teams should look past drag-and-drop ease and check how the platform handles permissions.
Can access be restricted at the field level, so a manager sees their own team's salaries but not the department's? Does it connect directly to the HR system and inherit its permissions, or does it need manual setup that's easy to get wrong? Does it support single sign-on, so access ends automatically when someone leaves the company? Are there audit logs showing who viewed or exported what?
My strong preference is for platforms that read from the HR system directly over those that depend on regular file exports. Every export is a copy, and every copy is something else to protect.
Where Employee Data Actually Leaks
The leaks rarely come from sophisticated attacks. They come from spreadsheets attached to emails, exports saved in personal drives, test environments loaded with real Social Security numbers, apps shared with "everyone in the company" because that was the default, and former employees who still have access to tools nobody remembered to remove them from.
When HR Data Reaches the Cloud Directly
Increasingly, HR builders end up working with the company's cloud infrastructure, usually through a data engineer who helps them, as in the opening story. The best practices for AWS apply here as they would to any cloud provider, and a handful would have prevented that incident entirely.
Block public access at the account level, not bucket by bucket, so nobody can accidentally make storage readable from the internet. That single setting would have stopped the salary leak. Keep HR data in a separate account with its own access controls rather than mixing it into a general analytics account. Grant the narrowest permissions possible: the dashboard should read one file, not the whole storage location.
Encrypt sensitive data with keys whose use is logged, and set alerts for unusual activity, such as a full employee file downloaded at 2 a.m. Prefer links that expire within hours over permanent ones. Tag anything containing employee data as sensitive, and set old exports to delete automatically after 30 days.
None of this requires the HR analyst to become a cloud engineer. It requires the engineers who support her to start from safe defaults.
Rules That Keep Builders Building
Sort data by sensitivity. Salary, medical information, performance ratings, and government ID numbers sit at the top. Apps touching that tier get a short security review with a fixed turnaround, say three business days, so HR isn't stuck waiting through raise season. Offer templates with permissions preset by role. And require realistic synthetic data for testing, never copies of real employee records.
The analyst rebuilt her dashboard the following month, connected directly to the HR system with permissions limited by reporting line, and the export file disappeared entirely. Raises went out on schedule. The fix took less time than the original build, which says something about where the effort belongs: in the defaults that were missing on day one, not in the person who built the tool.
