Join our Newsletter — 33% off our NHI Course
Home› FAQ› Governance, Ownership & Risk› Should organisations treat SaaS automation as an IGA…
Governance, Ownership & Risk

Should organisations treat SaaS automation as an IGA issue or an IT operations issue?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated October 8, 2026 Domain: Governance, Ownership & Risk

Both, but the access decision itself should sit under IGA governance. IT operations can run the workflow, yet IGA must define the entitlement rules, the approval thresholds, and the evidence required to prove that automated access still matches least privilege.

Why SaaS automation belongs in IGA governance, not just operations

SaaS automation often starts as an operations convenience, but the security question is who is allowed to create, change, or revoke access and on what basis. When automation can grant access, sync roles, trigger approvals, or deprovision users, it is making entitlement decisions. Those decisions need identity governance, not just workflow execution, because the policy and evidence obligations are part of the control, not a byproduct of the tool.

That distinction matters most when the automation touches joiner, mover, leaver flow, delegated administration, or exception handling. A workflow engine can move tickets, call APIs, and notify owners, but it does not by itself define whether a role is appropriate, whether a request is approved at the right threshold, or whether stale access should be removed after a lifecycle event. NHIMG’s IAM and IGA Basics is a useful reference for separating access administration from access governance in those cases.

The practical test is simple: if the automation is deciding entitlement state, changing permissions, or proving that access remains justified, it is in IGA territory even if IT operations owns the runtime. That includes SaaS provisioning, access recertification, role assignment, and automated offboarding. IT operations may operate the connector or integration, but IGA must own the rules that say what the integration is allowed to do. For lifecycle-driven access changes, NHIMG’s Joiner-Mover-Leaver (JML) Guide is the closest match to that operating model.

Where the boundary breaks in real SaaS environments

The boundary breaks when teams treat automation as a technical implementation detail and leave the access decision implicit. That is how organisations end up with overbroad service roles, shared admin accounts, silent exceptions, and access that persists after a user changes job, leaves, or no longer needs a SaaS entitlement. IGA is the layer that keeps those decisions explainable, reviewable, and revocable.

Access review is the clearest example. If an automation can keep synchronising entitlements based on role or attribute changes, then the organisation also needs a way to certify that those mappings are still valid. Otherwise, the process can become self-perpetuating and drift away from least privilege. NHIMG’s Access Reviews and Certification Guide maps directly to the evidence and recertification side of that problem.

Role design is another common failure point. In SaaS, people often create “automation roles” that accumulate permissions because they are convenient to integrate, not because they are justified. That is an authorisation problem, not an operations problem. When role sprawl starts to drive access decisions, governance needs to step in and reset the model so the workflow does not become the policy. NHIMG’s Role Mining and Role Design Guide is relevant here because it addresses how access structures become manageable instead of arbitrary.

How to split ownership without splitting accountability

Operations should own uptime, connector health, queue handling, retries, and application integration. IGA should own entitlement rules, approval criteria, recertification, exception handling, and evidence retention. That split works only if the organisation can show which team owns the decision and which team executes it. If no one can produce that answer, the control is weak even if the workflow is technically working.

For SaaS automation, the best governance model is usually policy first, workflow second. Define which events trigger access, which changes require human approval, which entitlements are time-bounded, and which changes must be logged for audit. Then let IT operations implement the workflow under those constraints. When segregation of duties matters, the automation should also prevent the same party from requesting, approving, and activating sensitive access. NHIMG’s Segregation of Duties (SoD) Guide supports that control design.

If the organisation manages many SaaS apps, an IGA buyer mindset helps because the question is not just “can we automate?” but “can we govern the automation at scale?” That means connectors, entitlement catalogs, approvals, and review workflows should be selected for governance evidence as much as for speed. NHIMG’s IGA Buyer's Guide is useful when the operational tooling needs to support auditability, not just ticket reduction.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5, CIS Controls v8 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

FrameworkControl / ReferenceRelevance
NIST SP 800-53 Rev 5AC-2 — Account ManagementSaaS automation changes account and entitlement state, so account lifecycle rules must be controlled.
AC-6 — Least PrivilegeThe question is about who should govern access decisions and approval thresholds for automation.
AU-6 — Audit Review, Analysis, and ReportingAutomated access decisions need evidence and traceability to prove governance and approvals.
Recommendation — Define automated provisioning and deprovisioning rules under AC-2 and keep account state changes reviewable. Enforce AC-6 so automated SaaS access only grants the minimum entitlement needed for the task. Retain and review audit records for automated entitlement changes under AU-6.
ISO/IEC 27001:2022A.5.15 — Access controlSaaS automation is fundamentally about how access is granted, governed, and reviewed.
A.5.16 — Identity managementAutomated SaaS provisioning and revocation depend on governed identity lifecycle handling.
A.8.2 — Privileged access rightsAutomation often carries elevated permissions that need explicit control and review.
Recommendation — Use A.5.15 to define access policy and approval boundaries for automated SaaS entitlements. Apply A.5.16 to keep automated SaaS identities and entitlement changes under governed lifecycle control. Apply A.8.2 to restrict and review privileged SaaS automation access paths.
CIS Controls v8CIS-6 — Access Control ManagementSaaS automation requires rules for granting, reviewing, and revoking access consistently.
Recommendation — Use CIS-6 to standardise entitlement decisions and reviews for automated SaaS workflows.
CSA Cloud Controls MatrixIAM — Identity & Access ManagementCloud SaaS automation is an identity and access governance problem in the cloud control layer.
Recommendation — Apply IAM controls to govern automated SaaS provisioning, authorization, and review.

Practitioner Guidance

What to prioritise: Classify any SaaS automation that grants, changes, or removes access as an entitlement-control workflow first, and an operations workflow second. If the workflow changes the user’s effective access, it needs governance ownership, approval logic, and review evidence.

What to verify: Ask whether the team can show the rule that authorises the automation, the approver or policy owner, and the record proving the access change was legitimate. If any of those are missing, the automation is running ahead of governance.

Common mistake: Treating a successful API call as proof that access was properly governed. A working integration only proves execution; it does not prove the entitlement was appropriate, time-bounded, or still justified.

Practitioner takeaway: Put the workflow in IT operations, but keep the decision, evidence, and recertification logic in IGA, otherwise automation will steadily convert convenience into standing access.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org