What access control model do you use (RBAC, ABAC)?

How to answer this security questionnaire question, with an expert response your security or GRC team can adapt.

Expert answer

Describe your model, whether RBAC, ABAC, or a hybrid, and how it enforces least privilege and segregation of duties. Explain how policies are defined, evaluated on each request, and reviewed.

What the security reviewer is checking

The parenthetical is an invitation to be precise, and reviewers notice when vendors just echo "we use RBAC" without describing the roles, what they grant, or how assignments are governed. They evaluate the model on three axes: design (what roles or attributes exist and whether granularity supports least privilege), lifecycle (how access is requested, approved, changed on role transfer, and revoked at offboarding), and verification (periodic access reviews with documented outcomes). If the question concerns your product, they also want to know what role granularity their own administrators get. Hybrid answers are fine — most real systems are RBAC with attribute-based conditions layered on — as long as you can describe both parts concretely.

Example response you can adapt

This is an illustrative template, not a real vendor's security posture. Replace every claim with what is actually true for your organization before submitting it.

Internally we use role-based access control with attribute-based conditions layered on top. Baseline roles are defined per job function and grant least-privilege access to the systems that function requires; assignments are managed centrally in our identity provider via group membership, so joiners, movers, and leavers are handled by directory automation — access changes when the role changes and terminates at offboarding within one business day. Sensitive grants, including any production access, sit outside baseline roles and require a ticketed request, manager and system-owner approval, and in most cases time-boxed just-in-time elevation rather than standing access. Attribute conditions — device compliance and network context — gate access to higher-sensitivity systems at authentication time. Quarterly access reviews require system owners to recertify every non-baseline grant, with removals tracked to completion. In the product, customer administrators get the same discipline: configurable roles with granular permissions, so they can implement least privilege for their own users.

Evidence reviewers expect you to attach

Access control policy describing the model, role definitions, and approval workflow
Role-to-entitlement matrix for key systems (sanitized)
Most recent quarterly access review completion evidence
Offboarding checklist or deprovisioning SLA documentation
Product documentation for customer-facing roles and permissions

Follow-up questions reviewers ask next

How quickly is access revoked when an employee leaves or changes roles?
Is production access standing or granted just-in-time?
How often are access reviews performed, and who signs off?
Can custom roles be defined in the product, or only preset ones?
How are service accounts and API keys scoped and reviewed?

Answer every security questionnaire in minutes

Wolfia drafts accurate, cited answers to security questionnaires and RFPs from your existing documentation. See it work on your own questions.Book a demo