How should IT teams classify newly discovered SaaS apps before allowing employees to use them?

How to think about app classification before approval

Classifying a new SaaS app is not just a procurement label, it is a control decision that determines whether the app can enter the organisation’s trusted software estate. The first step is to put every discovery into a single intake path so security, IT, and business owners evaluate the same facts, then assign a status that matches the evidence available at that moment.

The useful distinction is between known and approved, known but not yet approved, and known but excluded. That makes “under review” a real operational state, not a holding bin. It gives teams time to validate the vendor, data handling, integration method, and access model before employees start using the app at scale.

In practice, the class should answer one question: can this app be used safely under current policy, or does it still need assessment? If the answer is not yet clear, the app belongs in the review state. If the app fails policy or introduces unacceptable exposure, it should move to an unapproved or blocked state, with the reason recorded so the decision can be enforced consistently.

What each classification should mean operationally

An unclassified app is one the organisation has discovered but has not yet assessed. That state should be short-lived because it represents uncertainty. The discovery source may be telemetry, browser logs, expense data, CASB alerts, or user reports, but the classification outcome should always be captured in a central inventory rather than left in personal spreadsheets or ticket comments.

An under review app has enough initial information to justify inspection, but not enough to approve use. This is where teams check the app’s owner, business purpose, data sensitivity, identity integration, contractual posture, and whether it will require access to company data or systems. The point is to separate discovery from trust. Discovery alone does not justify use.

An approved app has passed the organisation’s minimum control checks and can be used within defined limits. That approval should be scoped, not open-ended: approval for a department, a data class, or a specific use case is usually more defensible than a blanket organisational endorsement. An unapproved app should be denied or restricted until the gaps are closed. An ignored app is one the organisation has consciously decided not to support or track further, usually because it is irrelevant, low risk, or outside the current control boundary.

Why classification matters for governance and enforcement

Without a standard classification path, app adoption becomes informal and shadow use grows faster than controls. A single repository of status makes it possible to decide whether to allow, restrict, or remove access, and it supports repeatable review instead of ad hoc judgment. For a baseline control view, teams can align the process with ISO/IEC 27002:2022 Information Security Controls, especially where organisational controls, supplier review, and access governance must be tied together.

Classification also helps with blast-radius management. A “review” label should trigger limited use, not broad adoption, while an “approved” label should correspond to defined guardrails such as allowed data types, required authentication, and approved ownership. That pattern matches the intent of NIST SP 800-53 Rev 5 Security and Privacy Controls, where access control, auditability, configuration management, and system integrity all depend on knowing what is allowed.

The same governance logic applies to new app discovery in cloud and SaaS environments: classify first, then enforce. If the organisation cannot tell whether an app is approved, the safer default is to treat it as not approved until review is complete. That keeps enforcement consistent and gives security teams a defensible basis for action when business users ask for exceptions.

Practitioner Guidance

What to verify: Before moving an app from review to approved, verify who owns it, what data it touches, whether it uses corporate sign-in, and whether the vendor’s security posture matches the intended use. If any of those are unknown, keep the app in review rather than guessing.

Decision rule: If an app has been discovered but has not passed policy checks, classify it as under review and restrict use; if it clearly fails policy, mark it unapproved and block it. Do not let “popular with users” become an approval criterion.

What good looks like: The organisation can show a current inventory of discovered apps, each with one unambiguous status, an owner, and a recorded decision path. That makes enforcement possible and reduces inconsistent local exceptions.

Practitioner takeaway: The real control is not the label itself, it is the fact that every newly discovered app is forced through a visible decision process before it becomes part of normal employee access.

Related resources from NHI Mgmt Group

• How should IT teams prioritise newly discovered shadow apps before approving them in SaaS environments?
• How should security teams evaluate the risk of payment apps before allowing employees to use them for transactions?
• How should security teams manage SaaS access when employees use both managed and unmanaged apps?
• How should security teams reduce account takeover risk when employees still use passwords across SaaS apps?