IAM-01 — Identity and Access Management Policy and Procedures

Every framework that asks this

Answer IAM-01 once and it typically satisfies the equivalent control elsewhere. Altitude and confidence vary — a domain-level anchor is a starting point to verify, not an audited equivalence.

Full provenance and NIST 800-53 mappings: the framework crosswalk.

What the reviewer is really checking

The reviewer is establishing that the right people — and only the right people — can reach systems and data, and that this is enforced and periodically re-verified rather than set once and forgotten. They dissect MFA (is it on for all users or just admins, which factors, are there bypasses or exempted service accounts), least-privilege and RBAC (are roles scoped to need, is standing privileged access minimized), the provisioning and de-provisioning lifecycle (how access is granted, changed, and removed), and access reviews (how often entitlements are recertified and by whom). The underlying concern is precise: over-broad or orphaned access is the mechanism by which a single compromised credential becomes a company-wide breach, so a vendor that cannot describe its access model cannot bound the blast radius of an incident involving the buyer's data. Reviewers care especially about privileged and administrative access, and about how you separate your own staff's access from the buyer's data. They cross-check IAM against HRS off-boarding and against your logging answers. The real question is: 'If one of your accounts is compromised, how much can it reach — and would you even notice the access was excessive before we did?'

What a truthful, defensible answer contains

A defensible IAM answer specifies the controls per surface rather than in the abstract. For MFA, it states which user populations it covers (all users, privileged only, customers), the accepted factors, and how exceptions or service accounts are handled — not just 'MFA is enforced.' For authorization, it describes the least-privilege model: RBAC or equivalent, how roles map to need, and how standing privileged access is minimized (for example, just-in-time or approval-gated elevation) if that is what you actually do. It describes the access lifecycle end to end: how access is requested and approved, how changes on role change are handled, and how revocation is triggered and completed. It states the access-review cadence — how often entitlements, especially privileged ones, are recertified, who performs the review, and what happens to flagged access. It should distinguish workforce access from customer/tenant access, and describe how administrative access to buyer data is constrained and logged. A strong answer names the systems these controls apply to and is honest about exceptions, because reviewers trust a scoped, exception-aware answer over a universal claim. Every element should map to configuration or a review record a reviewer could sample.

Make it traceable

Tie each IAM claim to enforceable evidence. An MFA claim points to the identity-provider policy configuration showing enforcement scope and factors, plus a coverage report. A least-privilege claim points to the role definitions and, if used, the JIT/elevation approval records. A provisioning/revocation claim points to sample access-request and de-provisioning tickets with timestamps that reconcile with HRS off-boarding. An access-review claim points to a completed recertification with reviewer, date, and the disposition of flagged entitlements. This is Promise–Proof for access: 'we review access quarterly' resolves to a signed recertification a reviewer can read, and 'MFA is enforced for all users' resolves to a policy screenshot plus an exceptions list. When roles change or a review completes, the answer should update from those live records so enforcement and cadence claims never outrun the evidence.

Answer patterns that hold up

• State MFA by population, factors, and exception handling (all users vs. privileged vs. customers; which methods; how service accounts/bypasses are governed) — not a bare 'MFA is enforced.'
• Describe authorization as a least-privilege/RBAC model tied to need, and how standing privileged access is minimized (e.g., JIT or approval-gated) if you actually do so.
• Describe the access lifecycle: request/approval, change-on-role-change, and triggered revocation — reconciled with off-boarding.
• State access-review cadence with reviewer and disposition (how often entitlements, especially privileged, are recertified and what happens to flagged access).
• Distinguish workforce access from customer/tenant access and describe how admin access to buyer data is constrained and logged.

Evidence that backs the answer

Red flags reviewers catch

• 'We enforce MFA' with no scope, factors, or exceptions stated.
• 'Access follows least privilege' with no roles, review cadence, or handling of standing admin access.
• Access reviews claimed but no cadence, reviewer, or example recertification.
• No distinction between staff access and customer-data access in a multi-tenant product.
• IAM revocation answer that does not match the HRS off-boarding timeframe elsewhere in the questionnaire.

Sources

• CSA Cloud Controls Matrix v4 (IAM domain)
• NIST SP 800-53 Rev. 5 (AC — Access Control; IA — Identification and Authentication)
• NIST Cybersecurity Framework 2.0 (Protect — Identity Management, Authentication and Access Control)
• AICPA SOC 2 Trust Services Criteria (Common Criteria — logical access)

Other Identity & Access Management controls