Understanding Modern IT Contracts: SaaS, On-Premise Licenses, and Managed Services
The way companies buy and use software has completely changed over the past decade. Remember when you used to purchase software in a box from a store? Those days are largely gone. Today's businesses face a much more complex world of software options, each with different legal implications and business considerations.
If you are handling IT procurement or contract negotiations, it is important to understand three main types of IT agreements that dominate today's market: Software-as-a-Service (SaaS), On-Premise Licence Agreements (OPLA), and Managed Services Agreements (MSA). Each one shifts risk and responsibility in different ways, and getting this wrong can expose your organisation to significant legal and operational problems.
Software-as-a-Service (SaaS) Agreements: The New Standard
Most companies today use SaaS solutions, whether they realise it or not. Think about platforms like Salesforce for customer management, Slack for communication, or Workday for HR functions. These are all SaaS products, and they work fundamentally differently from traditional software purchases.
What Makes SaaS Different
With SaaS, you're not buying software – you're renting access to it. The software lives on the provider's computers (servers), and your employees access it through a web browser or mobile app. You pay a monthly or annual subscription fee, much like you would for Netflix or Spotify, but for business software.
This arrangement creates several important legal considerations. First, you never actually own the software, which means you can't modify it extensively or control where your data is stored. Second, you're dependent on the provider's infrastructure staying operational. If their servers go down, your business operations may grind to a halt.
Key Legal Points in SaaS Contracts
Service Level Agreements (SLAs) become crucial in SaaS contracts. These specify how much uptime the provider guarantees (usually 99.9% or higher), how quickly they'll respond to support requests, and what happens if they fail to meet these commitments. However, many SaaS providers offer standardised contracts with limited negotiation room, especially for smaller customers.
Data responsibility is another critical area. While the SaaS provider typically handles technical security measures and compliance with regulations like GDPR, your company remains responsible for how the software is used and what data is put into it. For example, if your employees upload sensitive customer information inappropriately, you could still face regulatory penalties even if the provider's security was adequate.
SaaS providers also commonly include liability limitation clauses that cap their financial responsibility if something goes wrong. This means that even if their service failure causes your business significant damage, you might only be able to recover a fraction of your losses.
Real-World Example
Consider a multinational company implementing a cloud-based HR system. The SaaS provider promises to handle data security. However, the company must still ensure that employee consent is properly obtained (or some other lawful basis is relied on), that internal access controls are appropriate, and that data is being used according to company policies. If there's a data breach due to poor employee practices rather than technical failure on the part of the provider, the company – not the SaaS provider – will likely face the regulatory consequences.
On-Premise License Agreements (OPLA): The Traditional Approach
On-premise licensing is the more traditional model that many people think of when they imagine "buying software". With OPLA, you purchase a licence to install and run the software on your own computers and servers.
How OPLA Works
Think of OPLA like buying a car versus leasing one. You get more control and ownership rights, but you also take on more responsibility. The software runs entirely within your organisation's IT environment, giving you complete control over data storage, security configurations, and system integrations.
This control comes with significant responsibilities. Your IT team must handle software updates, security patches, server maintenance, and backup procedures. If the software stops working, it's typically your problem to fix, not the vendor's (unless you've purchased separate support services).
Legal Considerations for OPLA
The main legal focus in OPLA contracts revolves around licensing terms and intellectual property rights. These agreements specify exactly how you can use the software, how many users can access it, and what modifications are permitted. Violating these terms can result in expensive licensing disputes.
Customisation rights become particularly important in OPLA arrangements. Many organisations want to modify software to fit their specific business processes, but the licence agreement must explicitly permit this. Some agreements allow modifications but require that any improvements be shared back with the vendor.
Liability distribution also shifts significantly with OPLA. Since you're running the software on your own infrastructure, you bear most of the operational risk. If the software fails and causes business disruption, your remedies are typically limited to software replacement or refund rather than compensation for business losses.
Real-World Example
A financial institution might choose to install risk analysis software on its own servers to maintain complete control over sensitive financial data. The bank's IT team becomes responsible for ensuring the software stays updated with the latest security patches, integrates properly with existing systems, and complies with financial regulations. If the bank develops custom risk models using the software, the licensing agreement must clearly specify who owns the intellectual property rights to those customisations.
Managed Services Agreements (MSA): Full-Service Solutions
Managed services agreements represent the most comprehensive approach, where a provider doesn't just supply software but takes on complete responsibility for delivering a business service. This goes well beyond traditional software licensing into operational partnership territory.
What Managed Services Include
In a managed services arrangement, the provider typically handles everything: software, hardware, maintenance, monitoring, support, and often even some business processes. For example, instead of just licensing payroll software, a company might outsource their entire payroll function to a provider who handles calculations, tax compliance, employee enquiries, and regulatory reporting.
This comprehensive service delivery model creates complex contractual relationships. The provider becomes deeply integrated into your business operations, making the relationship more strategic but also more difficult to exit if problems arise.
Legal Complexity in MSA Contracts
Managed services contracts are typically the most legally complex of the three models because they must address operational performance, not just software functionality. Service level agreements become much more detailed, covering response times, quality metrics, staffing requirements, and business continuity procedures.
Exit planning becomes crucial in MSA contracts because of the operational dependency they create. Unlike SaaS or OPLA, where you can relatively easily switch to alternative solutions, managed services often involve the provider taking over entire business functions. The contract must specify how services will be transitioned back to the client or to a new provider, including data migration, knowledge transfer, and operational continuity.
Liability and accountability provisions require careful attention because the provider is taking on significant operational responsibility. However, this doesn't mean they accept unlimited liability. These contracts often include complex liability allocation schemes that distinguish between different types of failures and their causes.
Real-World Example
A retail company might outsource its entire e-commerce platform under a managed services agreement. The provider handles website hosting, payment processing, inventory management integration, customer service systems, and performance monitoring. The contract must specify uptime requirements, response times for system issues, data security standards, and disaster recovery procedures. If the website crashes during a major sales event, the agreement must clearly define the provider's obligations to restore service and any compensation for lost revenue.
Comparing Your Options: A Practical Framework
Understanding when to use each model requires considering several key factors:
Operational Control vs. Responsibility: SaaS offers the least control but also the least operational burden. You can't customise extensively, but you don't need to manage infrastructure. OPLA provides maximum control and customisation options but requires significant internal IT capabilities. MSA falls in between, offering customised solutions without the need for internal technical expertise.
Risk Distribution: In SaaS arrangements, the provider bears most operational risks but limits their liability exposure through contract terms. With OPLA, you assume most risks but also have more control over outcomes. MSA providers typically accept more operational accountability but negotiate carefully defined liability boundaries.
Cost Structure: SaaS involves predictable subscription costs but limited ownership value. OPLA requires larger upfront investments but can provide long-term cost advantages for stable, high-usage scenarios. MSA costs are usually higher than either alternative but include comprehensive service delivery.
Customisation Needs: If your business requires extensive software customisation or integration with legacy systems, OPLA typically provides the most flexibility. SaaS offers limited customisation options, while MSA can provide custom solutions, but within the provider's service framework.
Internal Capabilities: Your organisation's IT maturity significantly influences the appropriate choice. Companies with strong internal IT teams can effectively manage OPLA solutions, while organisations preferring to focus on their core business might benefit more from SaaS or MSA approaches.
Practical Guidance
When evaluating and negotiating these different types of agreements, several key principles apply regardless of the specific model:
Understand the Real Risk Allocation: Don't just read what the contract says about liability – understand what it means in practice. A SaaS provider might accept responsibility for data security but define it so narrowly that most real-world problems fall outside their obligations.
Match Contract Terms to Business Reality: Ensure that the agreement's terms align with how the software will actually be used. For example, if employees will access a SaaS application from personal devices, make sure the contract addresses this scenario rather than assuming it only applies to corporate computers.
Plan for the End of the Relationship: Every IT relationship eventually ends, whether due to business changes, better alternatives, or performance problems. Make sure the contract addresses data retrieval, service transition, and knowledge transfer requirements before you need them.
Consider Regulatory Requirements: Different industries have varying compliance obligations that may favour one model over another. Healthcare organisations, for example, might prefer on-premise solutions for sensitive patient data, while startups might prioritise the compliance capabilities built into SaaS platforms.
Negotiate Meaningful Remedies: Standard liability limitations often leave customers with inadequate recourse when things go wrong. Focus on negotiating service credits, performance guarantees, and termination rights that provide real protection for your business.
The choice between SaaS, OPLA, and MSA isn't just a technical decision – it's a strategic business choice that affects risk management, operational flexibility, and long-term costs. By understanding the legal implications of each model, you can help your organisation choose the approach that best aligns with its capabilities, requirements, and risk tolerance.
Article by Marina Danielyan.