How should security teams design app request workflows so employees get access quickly without creating shadow IT risk?

Security teams should centralise requests in a controlled workflow, publish approved app options, and require justification for new software. Approval paths should reflect app risk, department need, and procurement involvement. The goal is to reduce delays while keeping visibility over who requested what, why it was needed, and whether the app aligns with policy.

Why This Matters for Security Teams

App request workflows are where speed and control collide. If employees have to email, ping chat channels, or wait on informal manager approvals, they will often bypass the process and install unsanctioned tools. That creates shadow IT risk, hides data flows from security, and weakens policy enforcement. The goal is not to slow work down, but to make the approved path faster than the unofficial one.

This is especially important when SaaS apps handle sensitive data, integrate through OAuth, or connect to core business systems. NHI Management Group’s research shows that organisations still struggle with visibility into third-party connections and over-privileged access, which means request workflows need to be designed as a control point, not a ticket queue. Guidance from the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both reinforce the need for visibility, least privilege, and clear governance over access paths.

In practice, many security teams encounter shadow IT only after a risky app has already been connected to business data, rather than through intentional review of the request flow.

How It Works in Practice

A workable request workflow starts with a single intake path and a curated catalogue of approved apps. Employees should be able to see what is already sanctioned, what it is for, and what data it can access before they submit a request. That reduces duplicate demand and makes the approved option the easiest option. For unlisted tools, the request form should capture business justification, data classification, required integrations, department owner, and whether procurement or legal review is needed.

Approval logic should be risk-based. Low-risk apps can move through a lightweight path, while apps that touch regulated data, require admin scopes, or create external connections should trigger deeper review. This is where controls from NIST SP 800-53 Rev. 5 are useful in practice: access approval, configuration control, audit logging, and least privilege should be built into the workflow itself, not added later. For app-centric governance, NHI Management Group’s Ultimate Guide to NHIs highlights why third-party app visibility and credential discipline must be part of the approval chain.

• Use a central catalogue for approved software and preferred alternatives.
• Require business justification and data-use details for every exception.
• Route approvals by app risk, data sensitivity, and integration scope.
• Attach procurement, security, and legal review only when the risk warrants it.
• Record the requester, approver, rationale, and expiry or review date for each decision.

The best workflows also feed downstream controls, such as SSO enforcement, scoped OAuth consent, and periodic access recertification, so an approved app does not become a permanent exception. These controls tend to break down in decentralised SaaS-heavy environments because business units can approve tools faster than security teams can maintain an accurate inventory.

Common Variations and Edge Cases

Tighter approval gates often increase cycle time, so organisations have to balance speed against assurance. That tradeoff is real: if every request needs multiple reviews, employees will route around the process; if approvals are too loose, the business inherits hidden risk. Current guidance suggests keeping the default path fast and reserving manual review for higher-risk apps, but there is no universal standard for what qualifies as “high risk” across every organisation.

One common edge case is a tool that begins as low risk and later expands into sensitive workflows. In those cases, approvals should include expiry dates or periodic reassessment, not one-time permission. Another is department-led procurement, where teams believe they already own the budget and therefore do not need security review. The workflow should make procurement and security checkpoints visible early, before contract signature or OAuth consent.

For employee adoption, clear language matters as much as control design. The request form should explain why certain tools are blocked, what alternatives exist, and how long review usually takes. That reduces friction without relaxing governance. The practical lesson from the breach patterns documented in 52 NHI Breaches Analysis and the visibility gaps described in The State of Non-Human Identity Security is simple: if the sanctioned route is slow, users will create an unsanctioned one.

Related resources from NHI Mgmt Group

• How should security teams use automation in SOC workflows without creating new access risk?
• What do security teams get wrong about role design and access governance in ERP cloud projects?
• How should security teams govern ABAP customisation in large SAP environments without creating upgrade risk?
• How should security teams implement SCIM without creating more access risk?