ITSM and the SaaS Dilemma: Getting Governance Right

The shift towards Software-as-a-Service (SaaS) solutions is no longer a distant possibility — it's the new normal. Organisations across every sector are embracing cloud-based applications for everything from human resources to financial management, collaboration tools to specialised industry platforms. Yet whilst the benefits are clear — agility, scalability, reduced capital expenditure — many IT Service Management (ITSM) teams are finding themselves struggling to reconcile SaaS adoption with traditional ITIL® frameworks. The challenge isn't technical. It's philosophical. How do you govern, control, and deliver value when you no longer own the infrastructure?

1. The Fundamental Shift in Control

Traditional ITSM practices were designed around in-house infrastructure and applications. Your organisation owned the servers. You deployed the patches. You backed up the data. You controlled the change window.

SaaS flips this model on its head.

• You no longer own the platform. The vendor does. They manage updates, security, availability, and infrastructure.
• You no longer control the deployment schedule. Vendors push updates on their terms, and you must adapt.
• You inherit shared responsibility. The vendor is accountable for the service layer; you're accountable for configuration, access control, data governance, and integration.

In my opinion, this is where many ITSM teams stumble. They try to apply Configuration Management Database (CMDB) discipline as if a SaaS application is a CI (Configuration Item) they can manage the same way they manage a database server. It isn't. The vendor owns the baseline; you own the context.

2. Service Design for SaaS Must Be Different

Service Design under ITIL® 4 remains crucial — but its focus must shift.

Instead of designing the technical architecture, you're designing the governance model. This includes:

• Vendor Management: Understand the vendor's support model, SLA commitments, roadmap, and change process. Is there a technical account manager? What's the escalation path? How are critical issues resolved?
• Integration Points: Map how the SaaS solution connects to your existing systems. Which APIs will you use? What data flows between systems? Where are the failure points?
• Access and Identity: How will users be provisioned? Which directory will you use for authentication — Active Directory, LDAP, or the vendor's built-in system? What about role-based access control (RBAC)?
• Data Governance: Where does sensitive data live? What are the backup and recovery options? How do you ensure compliance with regulatory requirements like GDPR or HIPAA?
• Exit Strategy: What happens if you need to switch vendors? Can you export your data? In what format? How long will it take?

A well-designed Service Design Document (SDD) for a SaaS solution looks less like a technical specification and more like a partnership agreement.

3. Incident and Problem Management Requires New Thinking

When something goes wrong with a SaaS application, your traditional incident response workflow breaks down.

Consider this scenario: users report that their expense reports aren't syncing to the finance system. Your first instinct is to open an incident, assign it to the applications team, and expect a fix within four hours. But the problem might be:

• A vendor API change (vendor's responsibility)
• Your integration configuration (your responsibility)
• A third-party service dependency (neither party's responsibility, directly)
• Network latency (infrastructure responsibility, but it's the vendor's infrastructure)

What you need instead:

• Vendor engagement protocols: Establish clear escalation paths. Know exactly how and when to contact the vendor's support team. Use their ticketing system if available.
• Diagnostic playbooks: Before you open a vendor ticket, you need a way to diagnose whether the issue is on your side or theirs. This might involve checking API logs, reviewing recent configuration changes, or testing connectivity.
• SLA alignment: The vendor's SLA rarely aligns perfectly with your users' expectations. A vendor SLA of 99.5% availability sounds good until you realise it permits 3.6 hours of downtime per month. If your users need better, you need a contractual escalation path or a backup solution.

Problem Management becomes about identifying patterns across incidents and working with vendors — not fixing the underlying code, which you can't do.

4. Change Management Must Embrace Vendor Control

Here's where ITSM purists often bristle: Change Management can't work the way it used to.

In a traditional environment, you control every change. You assess risk, plan a rollback, schedule a maintenance window, and execute with precision. With SaaS, the vendor controls major changes. You can't delay a security patch because it falls outside your change window.

What you can control:

• Notification and testing: Establish a communication channel with your vendor so you're informed of upcoming changes well in advance (ideally 30+ days for major features).
• Pre-production validation: Many SaaS vendors offer sandbox or testing environments. Use them to validate that changes won't break your configurations or integrations before they're deployed to production.
• Internal communication: Ensure your Service Desk and end users are informed about upcoming changes. Set expectations about potential temporary unavailability or feature shifts.
• Post-deployment verification: Have a defined process to verify that the change didn't break anything critical in your environment.

I am always conscious that this requires a mindset shift from "we control the change" to "we collaborate with the vendor on change impact."

5. Asset and Configuration Management Needs Pragmatism

The CMDB is beloved in ITSM circles, but it struggles with SaaS because:

• The vendor owns the baseline. You can't record the server specifications because there are no servers — at least, none you can see.
• Configuration is frequently updated. The vendor pushes updates; tracking every change becomes impractical.
• Visibility is limited. You might not know what's running on the vendor's infrastructure, only what you've configured within the tenant.

Rather than attempting to track the SaaS platform itself, focus your CMDB efforts on:

• Your tenant configuration: Document your org-level settings, security policies, and customisations.
• Integrations and dependencies: Record which systems integrate with the SaaS application, API versions, and data flows.
• Contracts and licences: Link the application to its vendor contract, support level, and licence agreement.
• User and access configurations: Maintain a record of which users have access and what roles they hold — this might be synced from your directory service or managed manually.

The CMDB becomes a relationship and context repository rather than a complete technical inventory.

6. Reporting and Continuous Service Improvement

One underestimated advantage of SaaS: vendors often provide exceptional reporting and analytics.

Most mature SaaS platforms include dashboards for usage, performance, feature adoption, and user engagement. This is a goldmine for Continuous Service Improvement (CSI).

• Usage analytics: Understand which features users actually use and which they ignore. This informs training needs and configuration tweaks.
• Performance metrics: Monitor response times, error rates, and availability against the vendor's published SLAs.
• Cost optimisation: Many SaaS vendors charge per user, per feature tier, or per transaction. Regular analysis of consumption can reveal opportunities to right-size your licence agreement.
• User feedback: Vendor communities, feature request boards, and user surveys tell you whether the solution is genuinely delivering value or whether it's become a shadow system (where users prefer workarounds).

CSI for SaaS is less about "how do we fix the application" and more about "how do we maximise the value we're getting for our investment?"

7. Security and Compliance: Shared Responsibility in Practice

SaaS vendors will tell you about "shared responsibility." It's real. It's also complicated.

• Vendor responsibility: Infrastructure security, data centre access controls, encryption at rest and in transit, vulnerability patching, disaster recovery.
• Your responsibility: User access control, password policies, data classification, audit logging, compliance reporting, integration security.

In my experience, the line between these responsibilities often blurs. For example:

• If the vendor offers single sign-on (SSO) but you misconfigure your identity provider, whose fault is the security breach? Both.
• If the vendor encrypts data at rest but you fail to use the encryption keys properly, who's accountable? Both.

The ITSM teams I've seen handle this best establish clear responsibility agreements with vendors. This might include:

• Regular security assessment questionnaires (like CAIQ)
• Audit rights and scheduled reviews
• Compliance certifications (SOC 2, ISO 27001, etc.) that the vendor maintains
• Clear escalation procedures for security concerns

Conclusion

ITSM hasn't become irrelevant in the age of SaaS — it's evolved. The principles remain sound: governance, risk management, process discipline, and continuous improvement. But the practice looks different.

Rather than owning and controlling infrastructure, ITSM teams now orchestrate partnerships with vendors and manage the interfaces between in-house systems and cloud platforms. This requires less focus on the technical control of an application and more on the contractual, operational, and strategic governance of vendor relationships.

The organisations I've seen thrive with SaaS adoption aren't those that tried to force SaaS into a traditional ITSM box. They're the ones that recognised the model had changed and adapted accordingly — keeping the discipline of ITIL® whilst embracing the realities of cloud delivery.

Yes, it's different from what we trained for. But different doesn't mean less rigorous. If anything, managing SaaS requires more negotiation, clearer communication, and more transparent governance than managing infrastructure ever did.

---

Hopefully this has been useful to you and I wish you well on your ITSM journey…