Approving New Applications & SaaS Tools
Note: This is general information and not legal advice.
On this page
Executive Summary
- Shadow IT creates unknown data exposure and unknown admin access.
- Offboarding fails when nobody knows what apps exist or who owns them.
- Audits, insurance, and customer questionnaires increasingly expect evidence of controls.
- Data classification and business impact drive review depth.
- Single Sign-On (SSO), Multi-Factor Authentication (MFA), least privilege, and logging are standard for higher-risk tools.
- Ownership is explicit: admin, billing, renewals, integrations, and exit plan.
The core principle: controls follow risk
The most important step is not the questionnaire. It’s understanding what data is involved and what happens if the tool is unavailable, compromised, or misused.
If a tool only stores public marketing content, a lightweight review can be acceptable. If a tool stores regulated or high-impact data, stronger controls and evidence are mandatory.
Step 1: Identify data and business impact
Before evaluating features, answer these questions:
- What data will be stored, processed, or transmitted? Public, internal-only, PII, PHI, financial data, CUI, intellectual property.
- Who will access it? Employees, contractors, vendors, customers, integrations, service accounts.
- What is the business impact? If it’s down for a day, what breaks? If data leaks, what happens?
If you can’t answer the data question, you can’t justify controls. That’s how teams either over-secure low-risk tools or under-secure high-risk tools.
Step 2: Choose review depth using tiers
Use simple tiers so reviews are consistent and fast:
No sensitive data, low business impact. Lightweight review + assign an owner.
Internal data or moderate impact. Prefer SSO/MFA, role-based access, and basic logs.
Regulated or high-impact data, privileged access, or operational criticality. Strong controls, contracts, and evidence required.
Vendors with admin access to your environment (identity, DNS, backups, endpoints). Treat as part of your attack surface.
Related: vendor risk management and IT vendor management.
Step 3: Verify security capabilities
For the tier you selected, confirm the controls that matter most:
- Identity: SSO support, MFA (MFA guide), conditional access patterns, admin role discipline.
- Access model: Role-Based Access Control (RBAC) (RBAC guide), least privilege, separate admin roles, access review ability.
- Logging: audit logs for admin actions and sensitive events; export capability; retention controls where required.
- Data protections: encryption in transit and at rest, sharing controls, and Data Loss Prevention (DLP) (DLP guide) where applicable.
- Integrations: API tokens, service accounts, and what happens when you rotate keys or disable a user.
A common failure mode is picking a tool that technically supports security features, but only in an enterprise tier that nobody bought.
Step 4: Design the lifecycle up front
This is where most teams get burned: the tool works, but governance is missing.
User lifecycle
- How are users provisioned? Who approves access?
- Do role changes remove access before adding new privileges?
- What happens when someone leaves? Is access removed everywhere?
Related: onboarding & offboarding.
Data lifecycle
- How long is data retained? Can you delete it when needed?
- Can you export data and audit logs in a usable format?
- Does the vendor retain backups after termination? What is the data destruction story?
Exit plan
- What happens if you need to switch vendors quickly?
- Who owns the offboarding responsibilities for billing, admin consoles, and integrations?
Step 5: Monitoring and incident readiness
Higher-risk tools need a response path: what you will do if the vendor has an incident, if an admin account is compromised, or if suspicious activity appears in logs.
- Logs: what exists, where it goes, and who reviews it.
- Notification: how the vendor communicates incidents and timelines.
- Access containment: can you revoke tokens, disable integrations, and lock down roles quickly?
Related: tabletop exercises and vendor questionnaires.
A lightweight intake worksheet
Use this as a starting point for a ticket, form, or approval doc:
App / Vendor:
Business owner:
Technical owner:
What problem does it solve?
Who will use it?
Data types involved (public / internal / PII / PHI / financial / CUI / IP):
Business impact (low / medium / high):
Access model:
- SSO supported? (yes/no)
- MFA enforced? (yes/no)
- Admin roles minimized? (yes/no)
Logging:
- Audit logs available? (yes/no)
- Export possible? (yes/no)
Lifecycle:
- Offboarding steps defined? (yes/no)
- Data retention/deletion understood? (yes/no)
- Exit plan documented? (yes/no)
Decision (approve / approve with controls / accept risk / reject):
Notes:How this maps to NIST Cybersecurity Framework (CSF) 2.0
This workflow is intentionally outcome-focused and maps cleanly to CSF 2.0 functions:
- Govern: define ownership, approval paths, and a review cadence.
- Identify: classify data, understand impact, and inventory apps and integrations.
- Protect: enforce identity controls (SSO/MFA), least privilege, and data handling rules.
- Detect: require audit logs and monitoring where risk demands it.
- Respond: define the vendor incident path and how you contain access quickly.
- Recover: plan for exit: data export, ownership transfer, and continuity if a vendor fails.
What this looks like in practice
Low-risk example
Marketing wants a social media scheduling tool. Public content only. Low business impact. A lightweight review, an owner, and basic access hygiene are usually sufficient.
High-risk example
HR wants a new payroll system. PII and bank data. High impact. MFA, encryption, logging, stronger vendor terms, and explicit offboarding/retention requirements are non-negotiable.
Common Questions
Do we need to run the same security review for every new tool?
No. Start by classifying the data and business impact, then scale the review depth. Low-risk tools can get a lightweight review; tools that touch regulated or high-impact data require stronger controls and evidence.
What is the fastest way to reduce risk when teams onboard SaaS tools?
Make identity your control plane: prefer SSO, require MFA, minimize admin roles, and ensure offboarding revokes access everywhere. Then add logging and retention for investigations and evidence.
Is SOC 2 required before we can approve a vendor?
Not always. SOC 2 can be helpful evidence, but the real question is what access the vendor has and what data they touch. For higher-risk vendors, you should require stronger documentation and contract terms and reduce access exposure.
What do we do if the tool does not support SSO or audit logs?
Treat that as a risk decision. You can sometimes compensate with stronger MFA, reduced data scope, and tighter processes. If the tool touches regulated or high-impact data and cannot be monitored, it may need to be rejected.
Who should approve new applications?
At minimum: a business owner and an accountable technical owner. For higher-risk tools, include security and legal/procurement review. The goal is clear ownership for access, data handling, renewals, and offboarding.
What should we keep as evidence after approval?
Keep a lightweight record: data classification, owner, access model (SSO/MFA), admin list, logging/retention notes, key contract terms, and the last review date. This makes audits, insurance renewals, and vendor questionnaires predictable.
Related resources
Sources & References
Want a lightweight intake workflow your team will actually follow?
We can help you build a risk-based approval process, standardize identity controls, and keep evidence current across your SaaS and vendor ecosystem.
Contact N2CON