TL;DR: Access reviews are the operational backbone of SaaS governance, but 1Password argues that spreadsheets, custom apps, and fragmented visibility still make them slow, inconsistent, and audit-prone. The real issue is that many organisations are reviewing access across tools their governance model cannot fully see or standardise.
At a glance
What this is: This is an analysis of why SaaS access reviews break down when organisations rely on spreadsheets, fragmented app visibility, and non-standard workflows.
Why it matters: It matters because IAM, IGA, and compliance teams need repeatable review evidence across SaaS, custom apps, and offboarding flows, not ad hoc governance by spreadsheet.
By the numbers:
- 1Password says its SaaS Manager includes over 350 native API integrations for popular applications.
Context
SaaS access reviews are the control that confirms whether people still need the permissions they already have. In practice, those reviews often sit on top of inconsistent application coverage, manual spreadsheets, and review evidence that is hard to standardise across tools.
The governance gap is not the idea of access review itself. It is the fact that many organisations are trying to run review and certification processes across non-SCIM apps, custom apps, and multiple owners without a single operational model for evidence, approvals, and remediation.
Key questions
Q: What breaks when SaaS access reviews rely on spreadsheets?
A: Spreadsheets freeze access data in time, so reviewers work from stale exports while roles, teams, and app usage keep changing. That creates entitlement drift and weak evidence for auditors. A better model is recurring review automation with current usage, department, and risk context, plus direct remediation from the review step.
Q: Why do non-SCIM and custom apps make access reviews harder to govern?
A: They often cannot expose entitlement context in a standard way, so reviewers have to stitch together role, access level, and ownership information from multiple systems. That creates blind spots, slows approvals, and weakens audit evidence. Governance breaks down when the application cannot provide the data needed to make a defensible decision.
Q: How should teams connect access reviews to deprovisioning workflows?
A: Every review outcome should map to a clear enforcement path, such as removing access, adjusting permissions, or recording an approved exception. If the decision does not lead to a system change or an auditable justification, the review is only a report. The strongest controls treat remediation as part of the review itself.
Q: What does good audit evidence look like for SaaS access reviews?
A: Good evidence shows who reviewed the access, when the review happened, what context they used, and what action followed. Reviewer names, timestamps, notes, and access-level detail matter because they prove accountability and support external audits. Without that structure, organisations may complete reviews operationally but still fail compliance testing.
Technical breakdown
Why spreadsheet-based access reviews break at SaaS scale
Spreadsheet-led access reviews work poorly because they turn a repeatable control into a one-off project. Each application may have different role models, different owner expectations, and different evidence requirements, so reviewers end up reconciling access manually instead of validating entitlement decisions consistently. When visibility is split across multiple systems, reviewers cannot reliably judge whether access is still appropriate or whether the app has been offboarded correctly. That creates incomplete coverage, slow approvals, and audit friction. The real technical problem is not the spreadsheet file itself. It is the absence of a normalised review workflow that can absorb different SaaS application types without changing the control every cycle.
Practical implication: standardise the review workflow before expanding coverage across more applications.
Why non-SCIM and custom apps create access-review blind spots
Non-SCIM and custom applications often sit outside the clean automation path that IAM teams expect. If the app cannot expose user roles, access levels, or current entitlement state in a consistent way, reviewers have to pivot across systems to reconstruct the picture. That increases cycle time and raises the chance that access issues are missed or accepted without full context. In SaaS governance, incomplete telemetry is a control issue, not just an integration inconvenience. Access reviews depend on evidence quality, and evidence quality depends on whether the application can surface the fields needed to support reviewer judgment and auditability.
Practical implication: inventory which SaaS apps cannot provide review-grade entitlement data and treat them as governance exceptions.
How audit evidence and deprovisioning need to work together
Access review is only useful when it links to a remediation path. A reviewer approval or rejection should be accompanied by a reliable way to revoke access, update permissions, or document why a change was not made. If evidence, approval, and enforcement live in different systems, the control becomes a reporting exercise rather than a governance control. That is why compliance teams care about reviewer names, timestamps, and notes. They are not just audit artifacts. They are proof that ownership, accountability, and remediation were connected in the same process, not assembled after the fact from separate tools.
Practical implication: connect review outcomes to deprovisioning and permission change workflows, not just to reporting.
NHI Mgmt Group analysis
Spreadsheet governance is the symptom, not the control model. Once access reviews rely on manual files, the review process stops being a governed lifecycle and becomes a recurring reconciliation task. That distinction matters because spreadsheets cannot enforce completeness, consistency, or ownership across a SaaS estate with non-SCIM and custom applications. The practitioner conclusion is that access review quality is determined by workflow normalisation, not by review frequency alone.
Access reviews fail when entitlement context is fragmented. Reviewers cannot make reliable decisions if user role, access level, and application state are scattered across tools. This is a governance problem first and an integration problem second. The implication for IAM and IGA teams is that evidence quality must be designed into the control, not assembled manually at audit time.
Auditability is now part of the control, not a by-product of the control. The article links access reviews to SOC 2, SOX, PCI DSS, and ISO 27001 because compliance demands a defensible trail of who reviewed what and when. If reviewer identity, timestamps, and notes are not captured in a standard way, the organisation may have completed a review operationally but still fail to prove it. Practitioners should treat audit evidence as a control requirement, not an after-action report.
Continuous review is the right direction, but only if it includes remediation authority. Scheduled reviews alone do not solve the underlying issue if the workflow cannot de-provision leavers or adjust permissions when roles change. The field should move away from counting completed reviews and toward measuring how quickly access decisions become enforcement actions. That is the line between governance theatre and actual control.
From our research library:
- 1 in 3 organisations encountered suspicious AI agent activity in 2025, and 99.4% experienced a SaaS or AI ecosystem incident.
What this signals
Standardised entitlement evidence is becoming the real control surface for SaaS governance. Teams can no longer treat access review as a periodic spreadsheet exercise if they want defensible certification across fragmented SaaS estates. The programme question is whether the review workflow can absorb custom apps, non-SCIM apps, and remediation without forcing every application into a manual exception path.
Access review maturity now depends on workflow consistency more than review volume. The organisations that struggle most are usually not the ones doing no reviews at all, but the ones doing reviews that cannot scale across app types or produce reliable audit trails. For IAM and IGA leads, the next maturity step is to make review context, evidence, and enforcement part of one control chain.
For practitioners
- Standardise the access review workflow Replace ad hoc spreadsheet cycles with one approved process for reviewer assignment, evidence capture, and decision logging across SaaS applications.
- Map review coverage by application type Identify which apps are SCIM-enabled, which depend on APIs, and which require CSV-based handling so review coverage gaps are visible before the next certification cycle.
- Link approval outcomes to remediation Make sure each approval, rejection, or exception can trigger deprovisioning, permission adjustment, or documented acceptance in the same control flow.
- Capture audit evidence in a consistent format Require reviewer names, timestamps, notes, and access level context so compliance teams can trace each decision without reconstructing it from multiple tools.
Key takeaways
- Spreadsheet-led access reviews create inconsistency because each SaaS application ends up being governed differently.
- The main failure is not review intent but review standardisation across applications that do not share the same workflow or visibility.
- The control improves only when review decisions, evidence, and remediation are tied together in one auditable process.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 and SOC 2 (AICPA) define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on reviewing and validating SaaS entitlements across applications. |
| Recommendation — Use PR.AA-05 to standardise entitlement review and approval across SaaS applications. | ||
| CIS Controls v8 | CIS-5 — Account Management | Access reviews and deprovisioning are core account management controls in SaaS governance. |
| Recommendation — Apply CIS-5 to keep account review, removal, and ownership changes under one governance process. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | The article is about recurring review, approval, and removal of user access in managed applications. |
| Recommendation — Use AC-2 to tie account review, revocation, and audit evidence into one lifecycle control. | ||
| ISO/IEC 27001:2022 | A.8.2 — Privileged Access Rights | The control problem is whether access remains justified and appropriately scoped in SaaS apps. |
| Recommendation — Apply A.8.2 to review and limit privileged SaaS access on a recurring basis. | ||
| SOC 2 (AICPA) | CC6.1 — Logical Access Security Software, Infrastructure, and Content | The article explicitly ties access reviews to audit trail requirements such as SOC 2. |
| Recommendation — Use CC6.1 to demonstrate that SaaS access is reviewed and authorised under a repeatable control. | ||
Key terms
- SaaS Lifecycle Governance: SaaS lifecycle governance is the set of controls that manage applications from onboarding through access assignment, renewal, and decommissioning. It matters because the security value of SaaS management depends on whether the organisation can prove ownership, revoke access, and retire unused tools on demand.
- Access Review: A formal process for confirming whether access is still needed and justified. In IAM programs, the review becomes an evidence-bearing control when decisions are recorded, scoped correctly, and traceable to the right reviewer, application owner, or auditor.
- Non-SCIM application: A non-SCIM application is any app that cannot use SCIM for standard lifecycle automation. These applications usually require custom integration, direct API handling, or manual administration, which makes them harder to govern consistently and more likely to retain access gaps.
- Audit Trail: An audit trail is a record of who accessed a system, what they did, and when they did it. For PHI environments, it provides the evidence needed to investigate incidents, support breach determinations, and demonstrate that access was attributable to a specific identity or workflow.
Deepen your knowledge
NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org