MSA Compliance Checklist: What SaaS Vendors Miss

A Master Services Agreement (MSA) is the foundational contract between a SaaS vendor and its customers. Most early-stage SaaS companies use a template MSA that covers the commercial essentials — payment, IP, warranty, limitation of liability — but omits the compliance provisions that enterprise customers require and that regulations mandate. This checklist covers what a compliance-complete MSA looks like.

Privacy and Data Protection

DPA attached or incorporated by reference: The MSA must reference a GDPR-compliant DPA. Either as a separate document (Exhibit A) or incorporated into the MSA body.
UK GDPR coverage: If UK customers are included, the DPA must address UK GDPR separately (IDTA or UK Addendum to SCCs).
Data processing scope defined: The categories of personal data and data subjects must be specified in the DPA or a processing schedule.
Lawful basis for processing: If the vendor processes customer data for its own purposes (analytics, product improvement, AI training), the lawful basis must be specified.
Customer data ownership confirmed: The contract must confirm the customer owns their data. No ambiguity about whether the vendor has rights to the data beyond agreed service delivery.

Security

Security obligations specified: Not just "we maintain appropriate security" — specific commitments or reference to a Security Policy appendix.
ISO 27001 or SOC 2 commitment: If you hold certification, this should be referenced. If not, consider committing to achieving it within a specified timeframe.
Penetration testing commitment: Annual penetration testing and remediation of critical findings within a specified timeframe.
Multi-factor authentication: MFA required for all access to systems containing customer data.
Employee access controls: Principle of least privilege confirmed; access limited to personnel who need it for service delivery.

Incident Response and Notification

Incident notification timeline: Specific timeline — 1 hour, 4 hours, or 24 hours depending on customer sector. Not "as soon as practicable."
Scope of notifiable incidents: What events trigger notification. Security breaches, data exposure, and significant service outages at minimum.
Notification content: What information will be provided: nature of incident, data affected, steps taken.
DORA alignment for financial services: 4-hour notification timeline for customers subject to DORA; obligation to provide the information needed for regulatory reporting.

Business Continuity and Availability

SLA commitments: Uptime percentage, planned maintenance windows, and the consequences of SLA breach (credits, termination rights).
RTO/RPO commitments: Recovery Time Objective and Recovery Point Objective for the service — relevant for customers with their own BCP obligations.
BCP/DR confirmation: Vendor confirms it maintains a business continuity plan and disaster recovery capability. BCP available for review on request.
DR testing: Annual DR testing confirmed; evidence available on request.

Data Residency and International Transfers

Data location specified: Country and cloud provider where data is stored. Not "EU-based infrastructure" — specific locations.
Transfer mechanism documented: If data is stored or processed outside the EEA: 2021 SCCs, DPF certification, or equivalent. Not outdated 2010 SCCs.
Data residency option: If the service offers EU or UK data residency options, the contract should specify how the customer selects and confirms residency.

Sub-Processors and Third Parties

Sub-processor list published: A current sub-processor list accessible online or as a contract schedule.
Change notification process: How and when customers are notified of sub-processor changes. 30-day advance notice is standard.
Right to object: Customer has a documented process for objecting to new sub-processors.
Chain of obligations: Sub-processors are bound to equivalent data protection obligations.

Termination and Data Handling

Termination rights: Clear grounds for termination — breach, regulatory change, change of control.
Data return on termination: Process for customer to retrieve their data before termination.
Data deletion timeline: When and how customer data is deleted after termination.
Backup retention: What happens to data in backups after the main deletion.
Certification of deletion: Customer can request written confirmation that deletion has occurred.

Intellectual Property and AI

Customer data does not train AI: If the vendor uses AI, the contract should confirm whether customer data is used for model training. If not, confirm explicitly. If yes, identify the legal basis.
Vendor IP in outputs: If the product generates AI-assisted outputs based on customer data, who owns those outputs?
AI classification disclosure: If the product includes high-risk AI under the EU AI Act, disclose the classification and the customer's deployer obligations.

Regulatory and Audit

Audit rights: Customer has the right to audit or commission third-party security assessments. Notice periods and scope specified.
Regulatory cooperation: Vendor will cooperate with the customer's supervisory authority if requested.
Regulatory change notification: Vendor notifies customer of regulatory changes materially affecting the service.

Liability

Liability cap appropriate: Limitation of liability specified and appropriate to deal size.
Data breach carve-out: Consider whether the standard liability cap should apply to data breaches, or whether a separate (higher) cap or uncapped liability applies.
Indemnification: Who indemnifies whom for IP infringement, data breaches, and third-party claims.