Identity Security Assessment Questionnaire: What to Ask and Why

Most identity security questionnaires ask the wrong shape of question. “Do you have identity threat detection?” takes a yes, and the yes is true for an organization running a mature ITDR program with automated containment and for an organization that turned on one SIEM rule two years ago and never looked at it again. Both check the same box. Neither answer tells you anything a security leader could act on.

I write and maintain the question set behind the AXIS maturity model, which scores identity security alongside eight other domains. This piece is about questionnaire design specifically: what a question needs beyond its text to actually measure something, why a five-point option ladder beats a checklist, and where most vendor and internal questionnaires fall short of that bar.

Why Yes/No Checklists Fail at Identity Security

A checklist works when a control is binary: either disk encryption is on or it is not. Identity security controls are almost never binary. Coverage is partial by default. Detection exists but is noisy. A recovery plan exists but has never been tested. Reducing any of that to a single checkbox forces the respondent to pick a side, and respondents under-report the gap every time, not out of dishonesty but because “we have this” is the natural answer once a capability exists in any form.

The failure compounds at the questionnaire level. A checklist with forty binary items produces a score that is really a count of things purchased, not a measure of whether identity attacks get detected and contained. Two organizations can tie on a checklist while one recovers from an identity provider outage in hours and the other has never tested its recovery plan at all. The instrument cannot see the difference it was built to find.

Option Ladders: Five Levels, Not Two

An option ladder replaces the single checkbox with five ordered descriptions of how a capability is actually operated, from absent to optimized. Instead of asking whether an organization has identity threat detection, the question describes what detection looks like at each stage: reactive log review with no identity-specific alerting at the low end, detections mapped to real attacker techniques with response playbooks in the middle, and automated containment with tracked detection and response times at the top. The respondent picks the description that matches reality, not the one that matches intent.

This does two things a checklist cannot. It gives partial credit where partial credit is earned, instead of forcing a program that has made real progress into the same bucket as one that has made none. And it makes the gap between adjacent levels concrete enough to plan against: moving from noisy SIEM alerts to playbook-driven detection is a specific, scoped piece of work, in a way that moving from “no” to “yes” never is.

As one illustration of the shape, not the content: a question on privileged credential protection might run from unmanaged, shared credentials sitting in a spreadsheet, up through a credential vault with inconsistent coverage, brokered sessions with an audit trail, just-in-time access with enforced approvals, and finally zero standing privilege with continuous verification. Five real operating states, not two. The full option text for AXIS's 37 questions is proprietary content built for the assessment itself; what matters for questionnaire design generally is the shape, which any team can apply to its own instrument.

Every Option Needs an Evidence Expectation

An option ladder still fails if respondents self-select the flattering description. “We have automated containment” is easy to claim and hard to verify from memory. The fix is attaching a concrete evidence expectation to every option: what an assessor, or an honest respondent checking their own claim, should be able to point to before selecting it.

For a detection-maturity question, the evidence behind a mid-level answer is not “we have a SIEM.” It is whether identity-specific detections exist that map to known attacker techniques, whether a response playbook exists and gets used, and whether session or token revocation has an actual documented procedure. For a resilience question, the evidence behind claiming a tested recovery capability is a real record of a failover drill, not an architecture diagram showing that failover is theoretically possible. Evidence expectations are what turn “probably” into a defensible answer, and they are the part of a questionnaire most templates skip entirely, because writing them takes real domain knowledge and writing a bare question does not.

State the Failure Mode, Not Just the Gap

A well-built question also states what goes wrong at each level, in operational terms rather than abstract risk language. “Insufficient detection maturity” is a category. “Signal gets buried in false positives and a real attack blends into the noise” is something a security leader can picture and act on. The distinction matters because the failure mode is what makes a low score legible to people outside the identity team: a board member does not need to understand identity threat detection and response to understand what happens when a genuine intrusion looks like the fortieth false alarm of the week.

Stating the failure mode plainly also does something for the assessor: it gives them something to argue with. A respondent who disagrees with a score can point to the exact claim, and the conversation becomes concrete instead of a disagreement about vibes. That is a feature, not friction. A questionnaire that cannot be argued with in specific terms cannot be trusted either.

Map Every Option to the Frameworks That Actually Apply

Identity security controls are the load-bearing wall under a long list of regulatory and audit requirements: NIST CSF's detection and response functions, ISO 27001's monitoring and access control annex, SOC 2's common criteria, DORA's ICT risk provisions, and sector rules such as NYDFS 500 or NERC CIP, depending on industry. A question that maps its answer options to the specific clauses they satisfy turns a maturity questionnaire into something an auditor can use directly, rather than a separate artifact someone has to reconcile against the audit evidence later. This is one of the reasons a single questionnaire can serve both the security team building a roadmap and the compliance team preparing for a review, provided the mapping is built into the question rather than bolted on afterward. AXIS carries this mapping through to the framework library, so a completed assessment shows which of 20-plus frameworks each answer touches.

Structuring the Question Set: Capabilities, Not a Grab Bag

A good identity security questionnaire is organized by capability, not by vendor category or product name, because products change faster than the underlying problem. AXIS groups identity security into named capabilities covering threat detection and response, resilience of the identity infrastructure itself, behavioral analytics after authentication succeeds, data-to-identity exposure mapping, and posture and attack-surface management, sitting alongside the other eight domains that cover privileged access, governance, and authentication. A questionnaire organized this way survives a platform migration. One organized around “which identity threat detection product do you run” does not, and has to be rewritten every time the market moves.

Coverage matters as much as depth. A questionnaire that asks five detailed questions about detection and none about whether the identity provider itself can fail over measures a narrow slice of identity security and calls it the whole picture. The temptation to go deep on the capability a team already knows well, at the expense of breadth across the ones it does not, is exactly how blind spots survive an assessment that felt thorough to the people running it.

A Foundational Question Deserves to Be Marked as One

Not every identity security question carries equal weight, and a questionnaire that treats them as interchangeable line items misleads whoever reads the summary score. Some capabilities are prerequisites: an organization with no systematic visibility into identity misconfigurations, dormant accounts, or MFA coverage gaps has a ceiling on how much its detection and response investment can actually accomplish, because defenders cannot protect what they cannot see. A questionnaire that flags certain questions as foundational, and lets a weak answer there constrain the interpretation of everything else, is telling the truth about how identity risk actually compounds. One that averages a foundational gap in with everything else is not. AXIS applies this gating explicitly through foundational, domino-tagged questions; the qualitative rationale, without the scoring mechanics, is on the methodology page.

Building One vs. Borrowing One

Writing a questionnaire that clears this bar for a single domain, five levels, evidence expectations, stated failure modes, and framework mappings across five to six capability areas, is a real research undertaking, not an afternoon of brainstorming with a security team. That is a reasonable thing to build internally if identity security review is a recurring, well-resourced function. It is also the exact work a structured, published instrument already exists to save. The trade a team is actually making, when it chooses between the two, is between control over the exact wording and the time to build and validate a comparable instrument from scratch.

The AXIS assessment applies this design across all nine domains in 37 questions, with an evidence expectation and a regulatory mapping attached to every option, and it is free to run. For the operational steps of getting good answers out of a questionnaire like this, including who to involve and how to check a claim against evidence, see how to run an IAM maturity assessment.

Common Questions

What is the difference between an identity security questionnaire and a general IAM maturity assessment? Identity security specifically covers threat detection and response, resilience, behavioral analytics, data-to-identity exposure, and posture management. A general IAM maturity assessment covers identity security as one domain alongside privileged access, governance, authentication, and, for customer-facing organizations, CIAM. Most identity security questions worth asking already assume the broader program context around them.

How many questions does a credible identity security questionnaire need? Enough to cover the distinct capabilities in the domain without collapsing them into one broad question. Five is a reasonable floor for identity security specifically: threat detection, resilience, behavioral analytics, data exposure mapping, and posture management are different problems with different failure modes, and a single combined question cannot carry evidence expectations for all five at once.

Can a self-assessed questionnaire be trusted at all? Yes, if it forces evidence rather than intent. The instrument matters more than who administers it. A well-built option ladder with stated evidence expectations produces a defensible answer whether a consultant or an internal team fills it out, because the standard for each level is written down rather than left to judgment.