MFA and access control questions in security questionnaires: how to answer them

After “Do you have SOC 2?”, the block of rows a small SaaS company sees most often is about who can get into what. It usually reads something like: “Is multi-factor authentication (MFA) enforced for all users?”, “Do you support SSO?”, “How often do you review user access?”, “How quickly is access removed when an employee leaves?” and “Describe your password policy.”

These rows look easy, and that is the trap. Most teams can truthfully say “we use MFA”, but the question is usually wider than the answer: all users or only admins, every system or only email, enforced or merely available. This guide covers what reviewers are checking, example answers for each common row, how to word a gap honestly, and a checklist to run before you send.

What the buyer is really asking

The buyer is about to trust you with their data, and passwords get stolen: CISA notes that MFA makes it much harder for attackers to get in when a password is phished or leaked. The buyer wants to know three things: that a stolen password alone won’t get anyone into your systems, that people only have the access their job needs, and that access disappears when someone leaves or changes role.

Every framework behind the questionnaires asks this. In SOC 2 it sits under the Logical and Physical Access Controls criteria (CC6) of the [AICPA Trust Services Criteria](https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022). The Cloud Security Alliance’s [Cloud Controls Matrix](https://cloudsecurityalliance.org/research/cloud-controls-matrix), which the CAIQ is built on, has a whole Identity and Access Management (IAM) domain. The SIG, HECVAT and VSA all have an access control section. If you have filled in one of them, you have seen these rows already; see our CAIQ guide for how that one is laid out.

One more thing to know: there are two different questions hiding in this block. Some rows ask about your staff signing in to your own systems (email, cloud console, code repository, production database). Others ask what your product offers the buyer’s users, such as MFA or SSO inside your app. Read each row carefully and answer the one being asked. Mixing them up is the most common mistake in this section.

Not all MFA is equal

Reviewers increasingly follow up with “What type of MFA?”, so it helps to know how the methods are ranked. CISA’s fact sheet [Implementing Phishing-Resistant MFA](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf) lists them from strongest to weakest:

1. Phishing-resistant MFA: FIDO/WebAuthn (security keys and passkeys) or PKI-based methods such as smart cards. CISA calls this “the gold standard”.
2. Authenticator app codes, hardware tokens, or push notifications with number matching. CISA describes these as the best options for small and medium businesses that can’t yet move to phishing-resistant MFA.
3. Push notifications without number matching, which are open to “push bombing” (sending prompts until someone taps Accept).
4. Codes by SMS or voice call, which CISA says should be used only as a last resort.

You don’t need security keys for everyone to answer well. But if your admins use SMS codes, expect a follow-up, and consider moving your most powerful accounts (cloud console, identity provider, domain registrar) to a passkey or security key first.

Example answers for the common rows

Adapt these only where they are true for you. Brackets are for your own facts.

• Q: Is MFA enforced for all employees? A: “Yes. MFA is enforced through [Google Workspace / Microsoft Entra ID / Okta] for all employees and contractors, and it is required for email, our cloud console, our code repository and production access. Administrators use [security keys / passkeys]; other staff use [an authenticator app].”
• Q: Is MFA available to our users in your product? A: “Yes, users can turn on [authenticator app] MFA, and workspace admins can require it.” Or, if it isn’t: “Not today. Users sign in with [email and password / Google sign-in]. MFA for customer accounts is on our roadmap.”
• Q: Do you support SSO (SAML or OIDC)? A: “Yes, SAML SSO with [identity providers] on [plan].” Or: “Not yet; it is on our roadmap.” Don’t promise a date you can’t keep.
• Q: How is access granted? A: “Access is role-based and follows least privilege. New access is requested from [role], approved by [role], and recorded in [ticket system / access log]. Production access is limited to [number or role] engineers.”
• Q: How often do you review access? A: “We review access to production, our cloud console and [key systems] every [quarter], and remove anything no longer needed. The last review was completed in [month, year].”
• Q: How quickly is access removed when someone leaves? A: “Access is removed on or before the person’s last day, starting with our identity provider, which ends access to connected systems. We follow an offboarding checklist and keep a record of each one.”
• Q: What is your password policy? A: “Passwords are at least [15] characters, checked against lists of known breached passwords, and changed when there is any sign of compromise. Staff use a company password manager, and MFA is required on top.”

The password row deserves a note. Many questionnaires still ask whether you force password changes every 90 days and require special characters. NIST’s current guidance, [SP 800-63B-4](https://csrc.nist.gov/pubs/sp/800/63/b/4/final) (July 2025), says the opposite: no periodic forced changes, no composition rules, a minimum of 15 characters for a password used on its own (8 when it is part of MFA), and a forced change when there is evidence of compromise. If your policy follows NIST, say so in one sentence. Reviewers accept it, and it saves an argument.

If MFA isn’t everywhere yet

Don’t answer “Yes” to “Is MFA enforced for all users?” when it is only switched on for some. That row is easy to test: a reviewer may ask for a screenshot of the enforcement setting, and an auditor certainly will. An honest, specific answer reads better than a “Yes” that falls apart on a call:

“MFA is enforced for all administrator accounts and for access to production and our cloud console. It is enabled for [most] staff email accounts, and we are enforcing it for the rest by [month].”

Better still, close the gap before you send. In most identity providers, enforcing MFA for everyone is one setting plus a week of reminding people to enrol. It is one of the cheapest fixes in the whole questionnaire.

The same goes for access reviews. If you have never done one, do a short one now: list who has access to production, the cloud console, the code repository and your customer database, remove anyone who doesn’t need it, and write down the date and what changed. That note is your evidence, and the date goes into your answer.

What not to say

• “We use Google, so MFA is handled.” Google offers MFA; it doesn’t enforce it until you turn enforcement on.
• “All access is reviewed regularly.” “Regularly” invites the follow-up “How often, and when was the last one?” Give the interval and the date.
• “Only the founders have access to production.” Fine if true, but say how many people and what happens when you hire.
• Shared logins. If a shared admin account exists, say how it is protected (stored in the password manager, MFA on, use logged) and plan to remove it.
• Confusing your staff controls with your product features. “Yes, we have MFA” in a row about your product, when it only applies to your staff, will be caught in a demo.

Our guide to answers that invite follow-up has more on why vague or inflated answers bring more questions, not fewer.

A checklist before you send it

• MFA enforcement is switched on (not just available) in your identity provider, and your answer matches what the setting says.
• You know which method your admins use, and it isn’t SMS.
• Each row is answered for the right scope: your staff, or your product’s users.
• You can give an interval and a date for your last access review.
• Offboarding has a written checklist, and the last leaver’s access is actually gone.
• Your password answer matches your written policy, and the policy matches NIST or says why it doesn’t.
• Roadmap items (SSO, product MFA) are described as roadmap items, with no date you can’t keep.
• Today’s wording is saved in your answer library, so the next questionnaire is a copy, not a rewrite. Our list of common questions with example answers covers the rows around this section.

Answering it with Rendro

Rendro drafts questionnaire answers only from your own documents, such as your access control policy and past questionnaires, and shows the source for each answer. If your documents don’t support a row, for example nothing records when you last reviewed access, it marks the answer Needs review instead of guessing. There is a 14-day free trial on rendro.net with no card required.