Yes, when a tool solves a real problem and can be brought under governance. The decision should depend on whether the app can be inventoried, access can be controlled, and offboarding can be enforced. Approval should follow evidence, not only employee preference.
When employee choice is acceptable, and when it is not
Employee-chosen apps can be acceptable when the organisation is choosing between unmanaged convenience and governed use. The real question is whether the app can be treated like any other business service: known, approved, monitored, and removable. A good decision tests operational fit, control fit, and the ability to withdraw access cleanly if the app stops being safe or useful.
The biggest distinction is between a personal preference and a controlled exception. A tool that improves productivity may still be a poor fit if it cannot be inventoried, if its permissions are opaque, or if the business cannot prove what data it touches. Approval is therefore less about who suggested the app and more about whether it can be brought into a supportable control model.
That control model should be explicit about ownership, sanctioned use, and evidence. If a team wants to use a user-selected app in production, the organisation should know who owns the approval, who reviews the risk, and what conditions trigger review or removal. Without that structure, “approved” quickly becomes “tolerated without oversight.”
Which controls matter before you approve it?
The first control question is inventory. If the organisation cannot discover the app, track where it is used, and understand what systems it connects to, approval creates blind spots rather than governance. The second is access control. If the app requests broad permissions, shared credentials, or uncontrolled tokens, its convenience may mask a real access problem.
Offboarding is the third control that separates a safe exception from a lasting exposure. When an employee leaves, changes role, or the app is discontinued, the organisation should be able to remove access, revoke credentials, and confirm that lingering integrations do not remain active. That is why approval should cover the full lifecycle, not just the initial download or sign-up.
For app access and trust boundaries, the principle is similar to NIST SP 800-207 Zero Trust Architecture: treat every app as untrusted until it proves it can operate within policy, least privilege, and monitoring expectations. If the app cannot satisfy those conditions, it should stay outside the approved set.
There is also a supply-chain angle. A user-selected app may look harmless while depending on a third-party service, plugin, or integration that the organisation has not evaluated. In practice, approval should include the app’s permission model, vendor dependence, and data handling path, not just its feature list.
What approval should look like in practice
Approval should be evidence-based, lightweight where possible, and reversible. A useful decision pattern is to approve the smallest viable use case first, then expand only if the app demonstrates stable behaviour, clear ownership, and no material policy conflict. That is better than blanket approval or blanket rejection.
Practitioners should require a simple but defensible review record: what business problem the app solves, what data it needs, what access it receives, and what happens when the user leaves or the app changes. If the answer to any of those points is “we are not sure,” the app is not ready for approval in a governed environment.
Where the app exposes sensitive data or integrates with core systems, the bar should rise quickly. A user-friendly tool that sits near business data may still be acceptable, but only if the organisation can keep it inside a controlled boundary with logging, review, and timely revocation. For general application risk context, the OWASP Top 10 is a useful reminder that exposed application features, weak authorization, and insecure design often matter more than the app’s popularity.
Risk and Threat Considerations
Employee-chosen apps create risk when convenience outruns governance. The main exposure is unmanaged trust: the organisation may not know what data the app can reach, what external services it depends on, or whether access can be revoked cleanly when circumstances change.
Failure mechanism: Apps are approved informally, permissions expand over time, and the business loses the ability to inventory, constrain, or offboard the tool. That can leave stale access paths, hidden integrations, and shadow data flows in place long after the original need has passed.
Impact: The organisation can end up with data leakage, excessive access, unsupported dependencies, and compliance gaps, especially when the app touches customer data, regulated records, or core workflows. In the worst case, a convenience tool becomes an unmanaged pathway into business systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST Zero Trust (SP 800-207), OWASP ASVS and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | PR.AA-05 — Least Privilege | Approval depends on constraining app access to what the use case needs. |
| Recommendation — Enforce least-privilege access before approving any user-selected app. | ||
| OWASP ASVS | V8 — Authorization | User-chosen apps often fail when permissions and access boundaries are unclear. |
| Recommendation — Verify authorization boundaries before allowing app access to business data. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Integrated apps can overreach if function access is not controlled. |
| Recommendation — Test app-integrated functions for authorization gaps before approval. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems are inventoried | Approval requires the app to be discoverable and tracked in inventory. |
| PR.AA-01 — Identities and credentials are issued, managed, verified, revoked, and audited | Offboarding and revocation are central to governing approved employee apps. | |
| Recommendation — Inventory every approved app and its integrations before granting use. Require revocation and auditability for every approved app lifecycle. | ||
Practitioner Guidance
What to verify: Before approving a user-chosen app, verify that the app has a named business owner, a defined data scope, a revocation path, and a supportable offboarding process. If any of those are missing, treat the request as an exception candidate rather than a standard approval.
Decision rule: If the app cannot be inventoried, cannot be constrained to least privilege, or cannot be cleanly removed when the employee departs, do not approve it for routine use. If it can meet those conditions, approve it only for the smallest necessary use case and keep the decision reviewable.
Practitioner takeaway: The right question is not whether employees picked the app, but whether the organisation can still govern it like any other business service.