SaaS Management

SaaS management encompasses the operational procedures for maintaining visibility and control over cloud-delivered applications. These procedures establish how to discover applications in use, maintain an accurate inventory, configure security baselines, manage user access throughout employment, extract data for backup and portability, and optimise costs. Organisations with 50 or more staff members routinely operate 40-80 distinct SaaS applications, and without active management, this number grows by 15-25% annually through departmental purchases and free-tier adoptions.

Prerequisites

Complete the following before beginning SaaS management procedures.

Procedure

Discovering SaaS applications

Discovery identifies applications in active use regardless of how they were procured. The procedure combines four data sources to build a comprehensive view.

1. Extract OAuth and SAML application grants from your identity provider. In Keycloak, navigate to the realm’s Sessions tab and export the client sessions list. In Microsoft Entra ID, access Enterprise Applications and export the full application list including those with zero assigned users. In Okta, generate an Application Usage report covering the past 90 days. Record each application name, vendor, authentication method, and last access date.

   Expected output: A list of 30-100 applications with IdP integration, depending on organisation size.

2. Query financial systems for SaaS-related payments. Search accounts payable for the past 12 months using vendor names containing: “software”, “cloud”, “subscription”, “.io”, “.ai”, “.com”. Search expense reports for the same period using category codes for software, subscriptions, or technology. Export results showing vendor name, payment amount, payment frequency, and cost centre.

   Expected output: 50-150 distinct vendor payments, of which 40-70% represent SaaS applications.

3. Analyse DNS query logs or web proxy logs for cloud application domains. If your organisation operates a DNS resolver with logging (Pi-hole, Cloudflare Gateway, or similar), export queries to domains matching common SaaS patterns. Focus on domains with more than 100 queries per month from more than 5 distinct users. Cross-reference against known application domains.

   # Example DNS log analysis for common SaaS domains
   # Adjust grep patterns for your log format

   grep -E '\.(slack|notion|airtable|monday|asana|trello|miro|figma)\.com' \
     /var/log/dns/queries.log | \
     awk '{print $5}' | sort | uniq -c | sort -rn | head -50

Expected output: 20-40 additional applications not visible through IdP or financial data.

4. Survey department heads using a structured questionnaire. Request confirmation of applications their teams use daily, weekly, and monthly. Include questions about applications used for external collaboration with partners or beneficiaries. Allow 10 working days for responses with one reminder at day 7.

   Sample questions:

   • Which applications does your team use to complete core work activities?
   • Which applications store programme data or beneficiary information?
   • Which applications involve external users (partners, consultants, beneficiaries)?
   • Which applications were adopted in the past 12 months?

   Expected output: 10-25 applications not discovered through technical means, particularly field-specific tools.

5. Consolidate discoveries into a single deduplicated list. Match applications across sources using vendor name and primary domain. Flag applications appearing in only one source for verification. Assign a confidence rating: High (3+ sources), Medium (2 sources), Low (1 source).

Building the SaaS inventory

The inventory captures attributes required for governance, security assessment, and cost management. Maintain this inventory in a structured format accessible to IT, finance, and compliance functions.

1. Create inventory records for each discovered application using the following attribute schema:

   application:
     name: "Application Name"
     vendor: "Vendor Legal Name"
     primary_domain: "app.example.com"
     category: "collaboration|productivity|programme|finance|hr|security|other"

   ownership:
     business_owner: "Name, Role"
     technical_owner: "Name, Role"
     cost_centre: "CC-1234"

   authentication:
     method: "saml|oidc|local|none"
     idp_integrated: true|false
     mfa_enforced: true|false

   data:
     classification: "public|internal|confidential|restricted"
     contains_pii: true|false
     contains_beneficiary_data: true|false
     data_residency: "EU|US|UK|other"

   commercial:
     contract_type: "enterprise|team|free|trial"
     renewal_date: "YYYY-MM-DD"
     annual_cost: 0000.00
     billing_frequency: "annual|monthly|usage"
     licensed_users: 000
     active_users: 000

   security:
     last_assessment_date: "YYYY-MM-DD"
     security_rating: "approved|conditional|prohibited|unassessed"
     sso_capable: true|false
     scim_capable: true|false

   lifecycle:
     status: "active|deprecated|retiring|retired"
     introduced_date: "YYYY-MM-DD"
     planned_retirement: "YYYY-MM-DD"|null

2. Populate commercial attributes by cross-referencing financial records. For each application, locate the most recent invoice or contract. Record the exact annual cost, renewal date, and licensed user count. Where contracts span multiple years, record the current-year value and note the total contract value in a separate field.

   For applications without contracts (free tiers, trials, or departmental credit card purchases), estimate annual cost based on visible pricing and current usage. Flag these for procurement review.

3. Populate authentication attributes by examining IdP configuration. For each application listed in your identity provider, record whether SAML or OIDC is configured, whether the application enforces MFA through the IdP, and whether SCIM provisioning is active. For applications not in the IdP, record authentication method as “local” and flag for SSO integration assessment.

4. Classify data sensitivity for each application based on its function and the information it processes. Applications handling beneficiary data, protection cases, or financial transactions require “confidential” or “restricted” classification. Apply your organisation’s data classification scheme consistently.

5. Assign ownership for each application. The business owner holds accountability for the application’s purpose and user base. The technical owner holds responsibility for configuration, security, and integration. For applications without clear ownership, assign to the department with the highest usage and schedule an ownership confirmation meeting within 30 days.

Configuring security baselines

Security baselines establish minimum acceptable configuration for each SaaS application based on its data classification and authentication capabilities. Apply these configurations systematically across the inventory.

1. Integrate SSO-capable applications with your identity provider. For applications supporting SAML 2.0 or OpenID Connect, configure federation following the vendor’s documentation. Disable local authentication after confirming SSO functions correctly for all user roles.

   Configuration sequence:

   • Create application registration in IdP
   • Configure SAML/OIDC endpoints in SaaS application
   • Map user attributes (email, name, groups)
   • Test with single administrator account
   • Enable for all users
   • Disable local password authentication
   • Verify emergency access procedures

2. Enable SCIM provisioning for applications supporting automated user lifecycle management. SCIM eliminates manual user creation and ensures deprovisioning occurs within minutes of identity provider changes. Configure attribute mapping to include group memberships for role-based access.

   +------------------+          +------------------+
   |                  |   SCIM   |                  |
   | Identity         +--------->| SaaS             |
   | Provider         |   Push   | Application      |
   |                  |          |                  |
   | - Create user    |          | - Account        |
   | - Update attrs   |          |   created        |
   | - Deactivate     |          | - Role assigned  |
   | - Group change   |          | - Access removed |
   +------------------+          +------------------+

3. Configure MFA requirements at the identity provider level for all integrated applications. For applications not integrated with SSO, enable application-native MFA and document the configuration. Applications handling confidential or restricted data require MFA without exception.

4. Review and restrict administrative privileges within each application. Document all users with administrative access. Reduce administrator count to the minimum required for operations. For applications with more than 3 administrators, verify each assignment with the business owner.

5. Configure session timeouts appropriate to data sensitivity:

   Data classification	Maximum session duration	Idle timeout
   Public	30 days	24 hours
   Internal	7 days	8 hours
   Confidential	24 hours	2 hours
   Restricted	8 hours	30 minutes

6. Enable audit logging in every application where available. Configure log retention for minimum 90 days within the application. For applications handling confidential or restricted data, configure log export to your centralised logging system if the application supports SIEM integration.

7. Review data sharing and integration permissions. Disable OAuth grants and API integrations not explicitly approved. Document approved integrations in the inventory record with justification and review date.

Managing user provisioning and deprovisioning

User provisioning creates accounts and assigns appropriate access when staff join or change roles. Deprovisioning removes access promptly when staff leave or no longer require the application. For SCIM-integrated applications, these processes occur automatically through the identity provider.

1. For SCIM-integrated applications, verify provisioning by creating a test user in the identity provider. Confirm account creation in the SaaS application within 5 minutes. Verify attribute mapping accuracy (name, email, department, role). Deactivate the test user and confirm access removal within 5 minutes.

2. For SSO-integrated applications without SCIM, implement just-in-time (JIT) provisioning where supported. JIT creates user accounts upon first successful authentication. Document which applications support JIT and configure default role assignments.

3. For applications requiring manual provisioning, document the account creation procedure:

   Application: [Name]
   Provisioning URL: [Admin console URL]
   Required information: [Email, name, department, role]
   Role assignment: [How roles map to job functions]
   Approval required: [Yes/No, approver role]
   SLA: [Maximum days from request to provisioning]

Create provisioning procedures for each manually-provisioned application and store in your IT service management knowledge base.

4. Integrate deprovisioning with your offboarding workflow. For staff departures, deprovisioning must complete within:

   • Immediate (within 1 hour): Voluntary resignation, role change
   • Same day: End of fixed-term contract
   • Before notification: Involuntary termination, security incidents

   Generate a deprovisioning checklist from your inventory showing all applications where the departing staff member holds accounts.

5. Conduct quarterly access reviews for applications containing confidential or restricted data. Export user lists from each application and compare against current staff roster and role requirements. Remove access for users who no longer require the application. Document review completion with date, reviewer, and actions taken.

Extracting data for backup and portability

SaaS applications store organisational data on vendor infrastructure. Data extraction procedures ensure you maintain independent copies and can migrate to alternative platforms if required.

1. Identify data extraction capabilities for each application in your inventory. Review vendor documentation for:

   • Built-in export functions (format, completeness, frequency limits)
   • API access for programmatic extraction
   • GDPR data portability compliance
   • Third-party backup tool compatibility

   Record extraction capability in the inventory: Full (complete data export available), Partial (limited export, some data inaccessible), None (no extraction mechanism).

2. For applications with Full extraction capability, establish a backup schedule aligned with data classification:

   Classification	Backup frequency	Retention period	Storage location
   Restricted	Daily	7 years	Encrypted, organisation-controlled
   Confidential	Weekly	5 years	Encrypted, organisation-controlled
   Internal	Monthly	3 years	Organisation-controlled
   Public	Quarterly	1 year	Any secure location

3. Execute and verify backup procedures. For each scheduled backup:

   # Example: Exporting data from a SaaS API
   # Replace with application-specific endpoints and authentication

   export BACKUP_DATE=$(date +%Y-%m-%d)
   export APP_NAME="application-name"

   # Authenticate and export
   curl -H "Authorization: Bearer ${API_TOKEN}" \
        -o "${APP_NAME}-backup-${BACKUP_DATE}.json" \
        "https://api.example.com/v1/export/all"

   # Verify export integrity
   jq '.record_count' "${APP_NAME}-backup-${BACKUP_DATE}.json"

   # Encrypt for storage
   gpg --encrypt --recipient backup@example.org \
       "${APP_NAME}-backup-${BACKUP_DATE}.json"

   # Transfer to secure storage
   rclone copy "${APP_NAME}-backup-${BACKUP_DATE}.json.gpg" \
       remote:backups/saas/${APP_NAME}/

4. For applications with Partial extraction capability, document which data elements are not exportable. Assess whether the non-exportable data represents acceptable risk or requires alternative preservation methods (screenshots, manual documentation, or vendor-provided archive services).

5. For applications with None extraction capability, escalate to vendor relationship management. Request data portability features through official channels. If the application contains confidential or restricted data, assess whether continued use is appropriate given portability limitations.

6. Test restoration procedures annually for critical applications. Export data, then import into a test instance or alternative platform to verify data integrity and usability.

Identifying and addressing shadow IT

Shadow IT describes technology adopted without IT department involvement or approval. Shadow SaaS applications create security blind spots, compliance gaps, and redundant costs.

1. Analyse discovery results to identify unapproved applications. Compare discovered applications against your approved application list. Applications present in discovery but absent from approvals constitute shadow IT. Prioritise investigation based on:

   • User count (applications with 10+ users first)
   • Data sensitivity indicators (file sharing, database, or form applications)
   • Cost (any application with associated payments)

2. Investigate each shadow IT application to understand its purpose and usage pattern:

   • Interview primary users to understand the business need
   • Assess whether approved alternatives exist
   • Evaluate security posture (authentication, data handling, vendor reputation)
   • Determine data classification for information stored in the application

3. Determine disposition for each shadow IT application:

   +-------------------+
   | Shadow IT         |
   | Application       |
   | Discovered        |
   +---------+---------+
             |
             v
   +---------+---------+
   | Business need     |
   | legitimate?       |
   +---------+---------+
             |
       +-----+-----+
       |           |
       v           v
      Yes          No
       |           |
       v           v
   +---+----+   +---+---+
   |Approved|   |Remove |
   |alter-  |   |and    |
   |native? |   |block  |
   +---+----+   +-------+
       |
   +---+---+
   |       |
   v       v
  Yes      No
   |       |
   v       v
   +-------+   +----------+
   |Migrate|   |Assess for|
   |users  |   |approval  |
   +-------+   +----+-----+
                    |
              +-----+-----+
              |           |
              v           v
           Approved    Rejected
              |           |
              v           v
         +----+----+ +----+----+
         |Onboard  | |Remove   |
         |formally | |and block|
         +---------+ +---------+

4. For applications approved through the shadow IT review, complete full onboarding:

   • Add to inventory with all required attributes
   • Configure security baseline
   • Integrate with identity provider if SSO-capable
   • Assign business and technical owners
   • Establish contract or procurement record

5. For applications requiring removal, communicate with users before taking blocking action. Provide 14 days notice except where immediate security risk exists. Offer migration assistance to approved alternatives. After the notice period, block access at the network level or identity provider.

6. Implement preventive controls to reduce future shadow IT:

   • Publish an approved application catalogue accessible to all staff
   • Create a streamlined application request process (target: decision within 5 working days)
   • Configure identity provider to alert on new OAuth grants
   • Block known high-risk application categories at the web proxy if available

Optimising SaaS costs

Cost optimisation reduces expenditure on SaaS applications without degrading capability. Focus on licence utilisation, pricing tier alignment, and consolidation opportunities.

1. Calculate utilisation rate for each licensed application:

   Utilisation rate = (Active users in past 90 days / Licensed users) × 100

Active users means users who authenticated at least once in the measurement period. Export authentication logs from your identity provider or the application’s admin console.

Example calculation:

   Application: Project Management Tool
   Licensed users: 150
   Users authenticated (90 days): 87
   Utilisation rate: 87/150 × 100 = 58%

   Annual licence cost: £12,000
   Cost per licensed user: £80
   Cost per active user: £138
   Potential savings (reduce to 100 licences): £4,000/year

2. Review applications with utilisation below 70%. For each underutilised application:

   • Verify licence count matches contract (some vendors oversell)
   • Identify inactive users and confirm they no longer need access
   • Reduce licence count at next renewal to 110% of current active users
   • For applications below 30% utilisation, evaluate whether the application remains necessary

3. Assess pricing tier alignment. Many SaaS applications offer multiple tiers with different feature sets. Review whether your organisation uses features exclusive to higher tiers:

   • Export feature usage reports where available
   • Interview power users about feature requirements
   • Calculate savings from tier reduction
   • Test critical workflows on lower tier before committing

4. Identify consolidation opportunities by mapping applications to business capabilities:

   Capability	Current applications	Consolidation opportunity
   Project management	Asana, Trello, Monday	Standardise on one platform
   File storage	Dropbox, Google Drive, OneDrive	Consolidate to platform included in productivity suite
   Form building	Typeform, JotForm, Google Forms	Consolidate to one tool or use data collection platform
   Diagramming	Lucidchart, Miro, draw.io	Standardise based on integration requirements

5. Negotiate nonprofit pricing at renewal. Many vendors offer 50-90% discounts for registered charities and NGOs. Prepare for negotiations by:

   • Documenting charitable status and registration numbers
   • Researching published nonprofit programmes
   • Obtaining competitive quotes from alternative vendors
   • Calculating total contract value including all users and add-ons

6. Track cost optimisation outcomes. Maintain a register of optimisation actions with projected and realised savings:

   optimisation_action:
     date: "2024-11-15"
     application: "Design Tool"
     action_type: "licence_reduction"
     previous_state: "50 licences at £15/user/month"
     new_state: "30 licences at £15/user/month"
     projected_annual_savings: 3600.00
     realised_savings: 0.00  # Update after 12 months
     notes: "Reduced following utilisation review"

Maintaining the SaaS lifecycle

SaaS lifecycle management ensures applications progress through defined stages from introduction to retirement, with appropriate governance at each stage.

1. Assign lifecycle status to each inventory application:

   • Active: Approved for use, supported, receiving investment
   • Deprecated: Approved for existing users only, no new adoption
   • Retiring: Scheduled for removal, migration in progress
   • Retired: Removed from use, data archived or migrated

2. Conduct quarterly lifecycle reviews. For each application:

   • Verify business need remains valid
   • Review security assessment currency (assessments older than 12 months require refresh)
   • Check contract renewal dates (flag renewals within 90 days)
   • Assess vendor viability (funding announcements, acquisition news, service quality)
   • Review user feedback and support ticket trends

3. Trigger deprecation when any of the following conditions apply:

   • Superior alternative approved and available
   • Vendor announces end-of-life
   • Security assessment reveals unacceptable risk
   • Utilisation falls below 20% for two consecutive quarters
   • Contract renewal terms become unfavourable

   Upon deprecation, notify all users of the status change and provide timeline for migration to alternatives.

4. Execute retirement following procedures in Application Retirement. Key milestones:

   • User migration complete (0 active users)
   • Data extraction and archival complete
   • All integrations disconnected
   • SSO configuration removed
   • Vendor contract terminated
   • Inventory record updated to Retired status

5. Report lifecycle metrics to application portfolio governance:

   • Total applications by lifecycle stage
   • Applications approaching contract renewal (90-day horizon)
   • Applications with overdue security assessments
   • Shadow IT applications discovered (quarterly trend)
   • Cost optimisation savings (cumulative and period)

Verification

After completing SaaS management procedures, verify effectiveness through these checks.

Inventory completeness: Compare total applications in inventory against discovery results. Inventory should account for 95% or more of discovered applications by user count. Undocumented applications with more than 5 active users represent gaps requiring investigation.

Security baseline compliance: For each application in inventory, verify:

# Verification checklist per application
# Score: Compliant/Non-compliant/Not-applicable

[ ] SSO integrated (if SSO-capable)
[ ] MFA enforced
[ ] Administrative accounts minimised (≤3 per application)
[ ] Session timeouts configured per classification
[ ] Audit logging enabled
[ ] Unauthorised integrations removed

Calculate compliance rate: (Compliant checks / Applicable checks) × 100. Target: 90% or higher for applications containing confidential or restricted data.

Provisioning timeliness: Measure time from access request to provisioning completion. For SCIM-integrated applications, target: under 5 minutes. For manual provisioning, target: under 2 working days.

Deprovisioning completeness: For staff departures in the past quarter, verify access removal across all applications. Sample 10% of departures and confirm zero remaining access. Any exceptions indicate process gaps.

Cost optimisation: Compare current annual SaaS expenditure against baseline established at procedure initiation. Track utilisation rates quarterly; downward trends indicate successful optimisation or potentially indicate adoption problems requiring investigation.

Troubleshooting

Automation

Automate recurring SaaS management tasks to reduce operational burden and improve consistency.

Automated discovery: Deploy a SaaS management platform (Productiv, Zylo, Torii, or open-source alternatives like Nudge Security) that continuously monitors OAuth grants, browser extension activity, and expense transactions. Configure weekly discovery reports delivered to IT administration.

Provisioning automation: For organisations using Microsoft Entra ID or Okta, configure Lifecycle Workflows to automatically provision accounts in SCIM-enabled applications based on group membership. Example trigger: user added to “Marketing Team” group automatically receives accounts in approved marketing applications.

Deprovisioning automation: Configure identity provider to automatically disable or remove accounts in all SCIM-connected applications when the user account is disabled. Set suspension delay to 0 for immediate deprovisioning on involuntary terminations.

Cost monitoring: Schedule monthly export of licence utilisation data. Configure alerts for:

• Applications with utilisation below 50%
• Applications approaching renewal (60 days)
• Applications exceeding budget threshold
• New applications appearing in expense data

Compliance monitoring: Automate security baseline verification using vendor APIs where available. Example script structure:

# Pseudocode for automated security baseline check
# Implement with vendor-specific API libraries

for application in inventory.get_active_applications():
    config = application.get_security_configuration()

    checks = {
        'sso_enabled': config.sso_provider is not None,
        'mfa_enforced': config.mfa_policy == 'required',
        'admin_count': config.admin_users.count() <= 3,
        'audit_logging': config.audit_log_enabled,
        'session_timeout': config.session_timeout <= classification_timeout[application.data_classification]
    }

    compliance_score = sum(checks.values()) / len(checks)

    if compliance_score < 0.9:
        alert.send(
            recipient='it-security@example.org',
            subject=f'Security baseline compliance alert: {application.name}',
            body=f'Compliance score: {compliance_score}. Failed checks: {[k for k,v in checks.items() if not v]}'
        )

See also

• Application Portfolio Management
• Vendor and Licensing Management
• Application Security
• Application Retirement
• User Onboarding
• User Offboarding
• Third-Party Security Risk
• Single Sign-On and Federation