Why is HR data more sensitive than most business data?

Because it concentrates the exact fields an attacker or a fraudster wants about a real person: salary, national identity numbers, bank account details, home address, and dependants. A leak is not an inconvenience, it is identity theft and financial harm aimed at your own employees. That is why HR data deserves stronger encryption and tighter access than your average CRM record.

Who is responsible for employee data under GDPR or India DPDP, us or the vendor?

In the usual arrangement your company is the data controller (GDPR) or data fiduciary (DPDP) and the software vendor is the processor acting on your instructions. You decide what is collected and why; the vendor holds and protects it. Both have duties, and both can be liable. Confirm the exact split for your situation with counsel, because the roles change how obligations land.

What should we ask an HR vendor about security before signing?

Where the data physically sits, how it is encrypted at rest and who can decrypt it, who on the vendor side can read your records and under what controls, how you export everything and whether the export is blocked by billing state, how deletion actually works, whether any AI evaluates your people, and what compliance status they hold today versus what they are only targeting. Ask them to separate held, commissioned and intended, because those three get blurred deliberately. A vendor that answers these in public rather than under NDA is telling you something good.

Does deleting our account really delete the data?

It depends entirely on the vendor. Soft deletion that hides rows while keeping them in backups is common and weak. A stronger model is cryptographic erase: each tenant has its own encryption keys, and destroying those keys makes the data unreadable even in prior backups, without waiting for every backup to rotate out. Ask specifically what happens to backups, and whether they can prove no row survived.

HR data security and compliance for startups

HR data is the most sensitive data most startups will ever hold, because it combines salaries, national identity numbers, and bank details for real people who trusted you with them. Good practice is not one feature, it is a stack: encryption that the database itself cannot undo, tenant isolation enforced below the application, access control that denies by default, and the ability to export and delete on demand. This guide explains why the risk is unusual, what good looks like in each layer, how data-protection duties apply to employee records at a conceptual level, and the questions that separate a serious vendor from a confident one.

Why HR data is a category of its own

Most business systems hold data that is annoying to lose. HR systems hold data that can ruin someone. A single employee record often contains a national identity number, a bank account, a home address, a date of birth, dependants, and an exact salary. That is the full kit for identity theft and payroll fraud, gathered in one row, about a person who had no choice but to hand it over as a condition of employment.

The consequence is that the ordinary security posture of a business tool is not enough for HR. A breach of your marketing database is embarrassing. A breach of your HR database is a direct financial attack on your own team, and in many jurisdictions a reportable event with regulators and deadlines attached. The bar has to be higher, and you should expect a vendor to meet it before you trust them with a single record.

What good looks like

Encryption that the database cannot undo

Encryption at rest is table stakes, but the detail that matters is who holds the key. If the database can decrypt its own contents, then a stolen database dump is plaintext to whoever stole it. The stronger design is per-tenant envelope encryption, where each customer has its own data key and the master key that unwraps those keys lives only in the application service, never in the database. In Capstan’s model the sensitive classes (compensation, national IDs, bank details) are encrypted with AES-256-GCM this way, so a raw database dump is ciphertext and nothing more. Ask any vendor a blunt version of this: if someone walks off with your database file, what can they read?

Tenant isolation below the application

Multi-tenant software keeps many customers in shared infrastructure, and the risk is one tenant seeing another’s data through a bug. Isolation enforced only in application code fails the moment a query is written wrong. Isolation enforced in the database itself, with row-level rules, survives application mistakes. A good default is deny-by-default for identities that are not members, so that a contractor, an alumnus, or a revoked account sees nothing rather than sees leftovers.

Access control, including the vendor’s own staff

The uncomfortable question most security pages avoid is who at the vendor can read your data. The honest answer for most tools is “support, whenever they need to.” A stronger stance is that support never means database access: staff have no standing read access, and helping you requires a consent you grant, that is time-boxed, scoped to what is needed, revocable, with sensitive fields masked and every read recorded in an audit both sides can see. The detail that makes this real rather than procedural is how the access ends. If expiry is a scheduled cleanup job, access outlives its window whenever the job is late. If expiry is a comparison made on every request, access dies at the instant it expires and there is nothing to sweep.

On your own side, ask about sign-in: passwordless with a one-time email code rather than a stored password, MFA, and, for teams that require them, single sign-on with SAML and IP allow-listing. Ask which of those exist today rather than which are planned. Capstan’s own answer is worth quoting as a shape: sign-in is passwordless with no password stored anywhere, and SSO with SAML and IP allow-listing are not built, which is said here rather than left to be discovered during a procurement review.

Export and deletion as rights, not favours

You own your data only if you can get it out and get it gone.

Export should be available always, in open formats, including when a payment has lapsed and on the day you leave. “Open formats” is worth testing rather than accepting. A good export is a plain archive of documented JSON, a flattened CSV of the same rows, and the original files of every document, with a manifest that lists each entity and its row count so you can check the export against itself. A bad one is a proprietary container, or a set of screens you page through. Ask a second question too: is the export wired behind the billing check? If it is, the promise fails exactly when you need it. In Capstan the export endpoints deliberately sit outside the suspension guard, which is why a suspended workspace can still take a complete copy and leave.

Deletion should be real. The weak version hides rows while keeping them in backups for months. A stronger version is cryptographic erase: destroying the per-tenant keys makes the data unreadable even from prior backups, run with a short cooling-off window in case of mistakes, and followed by a residue scan that proves no row survived outside a narrow allowlist for records the law requires you to keep.

Data residency

Where data physically sits is both a compliance question and a trust question. Choosing the region at signup, and keeping it fixed, lets you meet residency expectations without a migration project later. Worth confirming: the marketing site should hold no database and store no client data at all, so signing up is a redirect to your chosen region rather than a detour through someone else’s.

No quiet profiling of your people

Security is not only about breaches. It is also about what the software does with the data while it holds it. A line worth drawing is that no AI evaluates people: no attrition scoring, no sentiment analysis, no candidate ranking. Employee data collected to run HR should run HR, not feed a model that judges the humans it describes.

How data-protection law applies, in plain terms

This is a conceptual map, not legal advice, and you should confirm your obligations with counsel who knows your jurisdictions.

Two regimes matter for many startups: the EU GDPR and India’s Digital Personal Data Protection Act (DPDP). They differ in wording but share a shape. Your company decides what employee data to collect and why, which makes you the data controller under GDPR and the data fiduciary under DPDP. The software vendor holds and processes that data on your instructions, which makes them the processor. Both roles carry duties, and being the controller does not outsource your responsibility to the vendor. If your workforce is in India, the DPDP Act and employee data works through the employment-specific version of this: the notice you owe, the ground you rely on for employee records, retention after someone leaves, and what to ask a vendor about it.

At a conceptual level the shared principles are: collect only what you need for a stated purpose, keep it accurate, hold it no longer than justified, protect it with appropriate security, and honour the individual’s rights over their own data (access, correction, and in many cases deletion and portability). A vendor helps you meet these when export and deletion are built in, when the individual can reach their own records, and when the security controls above are real.

The last-day problem is worth naming on its own, because most systems fail it. The right of access does not end when someone’s work email is switched off, and the usual answer is that a former employee emails you and somebody digs a payslip out of a folder. A better answer is a surface built for it. Capstan has one, Alumni Access, where a former employee reaches their own payslips, letters and settlement documents on their personal email after they leave. Being accurate about it: how it is packaged is recorded as an open commercial question, so check what your own plan includes rather than taking a marketing page’s word for it.

That whole class of request is about a moment that has already gone. Reading the record at a date, rather than only as it stands today, is what an access request, a dispute or a regulator usually needs, and a record that overwrites in place cannot answer it however well it is encrypted.

None of this replaces advice from a lawyer. Use it to ask better questions, then get the specifics confirmed for your company, your regions, and your headcount.

Reading a vendor’s compliance claims honestly

Certifications are useful signals, and they are also easy to imply without holding. The honest way to read a security page is to separate three states that vendors habitually blur: what is held today, what is genuinely commissioned with a firm and a date, and what is only an intention.

A SOC 2 report takes an audit window and an auditor; a startup at launch has usually not completed one. Any audit or external assessment needs a firm, a scope and a date behind it before the word “scheduled” means anything at all. If a page names a certification or an audit without naming who is performing it and when, read it as an intention rather than a plan.

Capstan’s own position, since it would be strange to write this and not say it, and written to the standard this section just asked for. The entity behind Capstan holds an ISO/IEC 27001:2022 certificate for its information security management system, issued in August 2025 by a certification body accredited by the Standards Council of Canada, with the certificate number, both dates and the scope published on the security page rather than reduced to a badge. Its scope is information security applied to software development, business consulting and digital transformation services, which is the management system the company works under and not a test of the product, and that limit is published beside it. No SOC 2 report is held and no target date is published for one, because a date nobody has committed to is an intention wearing the clothes of a plan. What runs underneath the certificate is automated security scanning, static analysis, secret scanning, dependency and container scanning, enforced before code can be pushed rather than only after, plus an internal adversarial review of the permission model whose findings are recorded. Beyond that, each control is published with the document that defines it and the artifact that proves it, in the control register, alongside a plain list of what those proofs deliberately do not cover. That is less flattering than a badge and considerably more useful to a reviewer.

Apply the same reading to any vendor. Ask for the report behind each claim, the date on it, and the name of whoever produced it. A page that reads like an award shelf is usually a page with nothing behind the awards.

Where to go next

If a customer or investor has sent you a security questionnaire and you are staring at a two-week fire drill, the guide to answering it walks through each category reviewers ask about. For the wider decision about what a startup needs from an HR system in the first place, start with the pillar guide on HR software for startups. And to see how these controls read when a vendor writes them out in public, the security page answers the hard questions without a call.