Answering an HR security questionnaire

A security questionnaire is a spreadsheet of questions a customer, investor, or auditor sends before they trust you with data, and it turns into a two-week fire drill only when you are writing the answers for the first time under a deadline. The fix is to answer it once, in public, before anyone asks. Almost every questionnaire covers the same eight categories, and this guide walks through each one with the honest version of a good answer.

The same categories apply when you are the one evaluating an HR vendor, so read this as both a template for answering and a checklist for asking.

Answer it once, in public

The reason a questionnaire hurts is not the questions, it is the timing. A reviewer sends forty questions with a Friday deadline, and someone who has never written the answers has to invent them, check them with engineering, and hope they are accurate. Companies that publish a trust page have already done the writing calmly, so responding becomes a matter of pointing the sender at a URL and copying a few lines into their template. Capstan does this on its security page, which is written for the person who has to sign off on the risk rather than for a marketing audience. Treat that as the goal: a public answer to the questionnaire that makes the private one a formality.

The categories reviewers ask about

Data location

Where does the data physically live, and can the customer choose? The good answer names a region, confirms it is chosen at signup and stays fixed, and notes what does not hold data at all. It helps to be able to say the marketing site holds no database and stores no client records, so signup is a redirect to the chosen region rather than a stop that touches your data on the way through. Where the workforce is Indian, expect the follow-up to be about India data protection rather than geography alone: the notice given to employees, the ground relied on for their records, and how long anything is kept after they leave.

Encryption

Two questions hide inside this one: is data encrypted at rest and in transit, and who holds the keys. Transit encryption is expected. The revealing part is at rest. A strong answer explains that sensitive fields (compensation, national IDs, bank details) use per-tenant envelope encryption with AES-256-GCM, and that the master key lives only in the application service, so the database cannot decrypt its own contents and a stolen dump is ciphertext. If your answer is just “we encrypt at rest,” expect a follow-up.

Access control

Who can see the data, on the customer side and on yours. Cover both. On the customer side, describe roles and what non-members see (ideally nothing, by default). On the vendor side, answer the question most pages dodge: can your staff read customer data? The strong answer is that support never means database access. Staff hold no standing access; helping requires a consent the customer grants that is time-boxed, scoped, and revocable, with sensitive fields masked and every read recorded in an audit both sides can see.

Authentication

How do users prove who they are. Note whether sign-in is passwordless (a one-time email code, with no password stored anywhere to be leaked), whether MFA is available, and whether single sign-on with SAML and IP allow-listing exist. Answer that last pair with a yes or a no rather than a roadmap; a reviewer reads “supported” and “planned” very differently, and finding out later which one you meant is how a deal stalls. Reviewers care about this section because most breaches start at the login, not the database.

Sub-processors

Which third parties touch the data, and for what. This trips people up because the honest list includes your hosting provider, email sender, and any analytics or payment services. Reviewers do not expect zero sub-processors; they expect a current, named list with a purpose against each, and notice when a company cannot produce one.

One distinction is worth building into your register from the start, because it is the thing that makes the list trustworthy rather than boilerplate: a vendor you have approved is not the same as a vendor you are actually sending data to. Publishing an approved-but-unused vendor overstates your data footprint; leaving out one you are using understates it. List both states and label them.

Deletion and retention

What happens to the data when the customer leaves, and how long anything is kept. Weak answers describe soft deletion that hides rows while backups keep them for months. A strong answer describes cryptographic erase, where destroying the per-tenant keys makes the data unreadable even from prior backups, run with a short cooling-off window and followed by a residue scan that proves no row survived outside a narrow allowlist for statutory records.

Pair this with export, and be specific about the shape rather than saying “we support export”. Name the container and the contents: a plain archive, documented JSON as the authoritative form, a flattened CSV of the same rows, the original document files, and a manifest with row counts a customer can check the archive against. Then answer the question reviewers actually care about, which is whether export survives a billing dispute. Say whether it sits behind the billing or suspension check. If it does, that is worth fixing before it is worth answering.

Incident response

What happens when something goes wrong, and how fast the customer hears about it. Reviewers want to know you have a plan, not that you have never had an incident. Cover how you detect, who is notified, the timeline for telling affected customers, and any regulatory reporting duties that apply. A runbook you have actually executed, with the record of a run to show for it, answers this category far better than a paragraph describing one you intend to write.

Compliance status

Which certifications and audits you hold, and which you do not. This is where honesty pays the most, and the useful discipline is to sort every claim into three buckets and never let them blur: held, with a report and a date; commissioned, with a named firm and a date; and intended, which means nothing has started. Most vendors write intentions in the language of commitments, and a reviewer who has read a hundred of these can tell.

Capstan’s own answers are the shape to copy. One certification held and stated in full, ISO/IEC 27001:2022 for the information security management system of the entity behind the product, with its number, its certification body, its accreditation, its issue and expiry dates, its completed surveillance audit and its scope all published, plus the plain statement that certifying a management system is not a test of the product. No SOC 2 report, and no target date published for one. Underneath both, the controls are described concretely: automated security scanning enforced before code can be pushed, an internal adversarial review of the permission model with its findings recorded, and a published register that names, control by control, the document defining it and the artifact that proves it, together with what those proofs do not cover. Where you act as a processor for a customer who is the data controller or fiduciary, say so, because it tells the reviewer how the legal duties split. A claim you cannot back with a report and a date is worse than an honest gap, because the gap costs you one question and the unbacked claim costs you the reviewer’s trust in everything else on the page.

When you are the one asking

Send the same eight categories to any HR vendor you are considering, and read the answers for evasion as much as content. A vendor that publishes its non-goals, states plainly what it does not do (for instance, that no AI evaluates your people through attrition scoring, sentiment analysis, or candidate ranking), and separates held certifications from targeted ones, scope and dates attached, is easier to trust than one with a longer list and vaguer wording. A trust page that answers the questionnaire without a call is a good sign about how the whole company operates.

Where to go next

For the reasoning behind each of these controls and how data-protection duties apply to employee records, read the pillar guide on HR data security and compliance. For the wider question of what a startup needs from an HR system, start with HR software for startups. And to see the answers written out in public rather than promised on a call, read the security page.