3. 合同主体与资质审查

SaaS服务合同的风险，往往不是从条款措辞开始的，而是从“和谁签、对方有没有资格签、签了能不能履行”开始的。一份条款再完善的合同，如果签约主体本身不具备相应经营资质、数据安全能力或履约信用，后续的履行风险仍会集中爆发。因此，主体识别与资质审查是合同设计的前置动作，也是法律风险管理的第一道闸门。

一、先识别主体：一份SaaS合同里可能不止两方

传统软件采购常被理解为“买方—卖方”两方关系，但SaaS场景下的主体结构明显更复杂。至少需要区分以下角色：

• 客户（采购方）：可能是最终使用SaaS的企业用户，也可能是集团总部代下属公司统一采购，实际使用主体与签约主体不一致。
• SaaS提供商（服务方）：直接提供SaaS服务并承担服务义务的一方，可能是软件著作权人，也可能只是获得授权的运营方或代理商。
• 第三方集成商：负责将SaaS与企业现有系统（如ERP、CRM、单点登录、数据中台）对接的实施方，可能由客户另行委托，也可能由SaaS提供商推荐。
• 基础设施与云服务商：提供IaaS/PaaS底座、CDN、短信、支付、身份认证等能力，通常不直接与客户签约，但其服务中断会直接影响SaaS可用性。
• 数据接收方或再处理方：如SaaS提供商将部分数据处理外包给第三方，或调用外部AI接口处理客户数据。

识别主体的核心目的，是明确“谁承担什么义务、谁对什么结果负责”。如果客户是集团总部，而实际使用人是子公司，就需要在合同中明确授权使用范围、数据归属和费用承担；如果SaaS提供商只是代理运营方，就必须审查其是否获得著作权人的合法授权，以及授权范围是否覆盖本合同的服务内容。

二、经营资质审查：不只看营业执照

经营资质审查的第一步是核对营业执照，但仅看“有没有执照”远远不够。需要重点核对三项内容：一是经营范围是否覆盖SaaS服务、数据处理、信息技术服务等对应类别；二是存续状态是否为“在营”，是否被列入经营异常名录或严重违法失信名单；三是注册资本与实缴情况是否与合同金额、服务规模相匹配。

对于SaaS提供商，还需进一步审查其是否拥有软件著作权，或是否获得著作权人的合法授权。如果对方只是代理运营方，应要求其提供授权书，并确认授权范围包括本合同的客户、服务模块和期限。若SaaS涉及特定行业（如医疗、金融、教育），还需核查是否具备行业主管部门要求的备案、许可或认证。例如，面向医疗机构的SaaS若处理患者健康数据，通常需要关注其是否通过等保测评、是否具备医疗数据处理的合规安排。

三、数据安全能力审查：从“有没有证”到“能不能做”

数据安全能力审查不能停留在收集证书层面，而应结合SaaS的实际数据处理场景进行判断。建议从以下维度展开：

• 数据分类分级：SaaS提供商是否对客户数据进行了分类分级，是否明确哪些数据属于敏感个人信息、重要数据。
• 访问控制：是否支持多因素认证、最小权限原则、操作日志留存与审计。
• 加密与隔离：传输层是否启用TLS，存储层是否加密，多租户之间是否实现逻辑或物理隔离。
• 备份与恢复：备份频率、保留周期、恢复时间目标（RTO）和恢复点目标（RPO）是否有明确承诺。
• 安全事件响应：是否具备安全事件应急预案，发生数据泄露时的通知时限和处置流程是否清晰。
• 子处理者管理：若SaaS提供商使用第三方云服务或外包数据处理，是否对子处理者进行安全评估并承担连带责任。

审查时，可以要求对方提供近一年的等保测评报告、渗透测试报告或安全审计报告，并重点关注报告中是否存在高危未整改项。如果对方无法提供，或报告已过期，应在合同中设置相应的整改期限和安全承诺条款。

四、履约信用审查：用公开信息交叉验证

履约信用审查的目标是判断对方“有没有能力持续履行合同”。可以通过公开渠道进行交叉验证：

对于合同金额较大或服务周期较长的SaaS项目，还可以要求对方提供近期财务报表、银行资信证明或履约保证金。若SaaS提供商为初创企业，应重点关注其资金链和核心团队稳定性，必要时在合同中约定源代码托管或数据导出机制，以降低服务中断风险。

五、把审查结果写进合同

主体与资质审查的结论，最终要转化为合同条款。常见的转化方式包括：将SaaS提供商的资质承诺写入陈述与保证条款；将数据安全能力要求写入数据处理附件；将履约信用风险通过保证金、分期付款或退出机制进行对冲；将第三方集成商的责任边界写入三方协议或背靠背条款。只有把审查发现落实到合同文本中，主体与资质审查才真正完成闭环。