HR data security in an automated environment comes down to API security — how candidate and employee data moves between systems, who can access it in transit, and what happens when something goes wrong. These 12 questions represent what HR leaders actually ask when they’re evaluating automation tools and deciding whether to connect their systems.

Automation connects your HR systems in ways that create new security surface area. The Automate Engagement: Stop Candidate Ghosting with Strategic AI — Complete 2026 Guide addresses the candidate experience layer; this FAQ addresses the security infrastructure that makes automation responsible to deploy.

Q1: What is an API and why does HR data security care about it?

An API (Application Programming Interface) is the mechanism by which two software systems exchange data. When your ATS sends candidate data to your email platform, or your HRIS sends employee records to payroll, those exchanges happen through APIs. HR data security cares about APIs because they’re the primary pathway through which data breaches and unauthorized access occur in connected systems.

Q2: What is an API key and how should we manage them?

An API key is a credential — like a password — that authenticates your automation platform’s right to access another system’s data. API keys should be: stored in a secrets management system (not in spreadsheets or email), rotated on a defined schedule (at minimum annually, and immediately after any personnel change that had access), scoped to the minimum permissions required, and revoked immediately when a vendor relationship ends.

Q3: What is OAuth and when should we use it instead of API keys?

OAuth is an authentication protocol that grants time-limited, scope-limited access without sharing the underlying credentials. When a vendor supports OAuth, prefer it over API keys — it limits exposure if a token is compromised, and provides audit trails of what was accessed when. Make.com supports OAuth connections for most major HR platforms.

Q4: How do we know if our API connections are encrypted in transit?

All API connections should use HTTPS (TLS encryption). Before enabling any integration, confirm: the API endpoint begins with https:// (not http://), the vendor’s TLS certificate is valid and current, and your automation platform enforces TLS validation (does not allow connections to endpoints with invalid certificates).

Q5: What is a webhook and what are the security risks specific to webhooks?

A webhook is a mechanism by which one system sends data to another when a specific event occurs — ATS stage changes, new applications, offer acceptances. Webhook security risks include: no authentication (any system that knows the URL can send data), replay attacks (valid webhook payloads reused to trigger automation multiple times), and payload injection (malicious data embedded in webhook payloads to manipulate downstream logic). Mitigate with: webhook signature verification (most platforms support this), HTTPS-only endpoints, and payload validation before processing.

Q6: How do we conduct a security review of a new HR automation vendor?

Request: SOC 2 Type II report (the current year’s, not a 3-year-old certification), penetration testing results summary, data processing agreement with clear subprocessor disclosure, breach notification timeline (must be 72 hours or less for GDPR-covered data), and data retention and deletion policies. Any vendor that can’t produce these on request introduces unacceptable security risk.

Q7: What is the principle of least privilege and how does it apply to HR API connections?

Least privilege means each connection should have access only to the specific data and actions it needs — nothing more. In practice: your status notification automation needs read access to ATS stage data and write access to your email platform — not read-write access to your entire ATS. Scope every API key and OAuth permission to the minimum required. Audit permissions quarterly and remove any access that’s no longer needed.

Q8: How do we handle API security when an HR team member leaves?

Immediately: revoke all API keys or OAuth tokens associated with that person’s accounts, audit any automation scenarios they built for hardcoded credentials (credentials embedded directly in scenario configuration rather than stored in a secrets manager), and change any shared credentials they had access to. This offboarding checklist should be as standard as revoking email access.

Q9: What is data residency and why does it matter for HR automation?

Data residency refers to the physical location where data is stored and processed. It matters for HR automation because some jurisdictions (EU under GDPR, certain US states) restrict the transfer of personal data to locations that don’t provide equivalent privacy protections. Confirm your automation platform’s data residency for any HR data that includes EU resident information.

Q10: How do we monitor for unauthorized API access?

Enable API access logging in every system that supports it. Set up alerts for: access from unexpected IP addresses or geographic locations, access outside normal business hours, volume anomalies (10x the normal API calls in an hour), and failed authentication attempts. Review API access logs monthly as part of your security review cadence.

Q11: What should our breach response plan include for an HR API breach?

A breach involving HR API data requires: immediate revocation of all compromised credentials, assessment of what data was accessed (scope determination), notification to affected individuals within the timeframe required by applicable law (72 hours for GDPR), notification to HR leadership and legal, and a root cause analysis to prevent recurrence. Pre-define this response before you need it — not after.

Q12: How do we explain API security requirements to HR technology vendors who don’t prioritize it?

Frame security requirements as contractual prerequisites, not preferences. Your Data Processing Agreement should specify security standards as obligations with audit rights. If a vendor can’t meet your minimum security standards, they aren’t a viable partner — regardless of their feature set. Sarah’s team replaced two vendors during their framework build for this reason. The short-term disruption was significantly less costly than the security exposure.

FAQ Schema