2. 信任服务准则 (TSC)

好，咱们直接进入正题。SOC2 审计的核心，说白了就是围绕五个信任服务准则（TSC）来展开的。很多刚接触的朋友会觉得这五个词看着都懂，但一到实际落地就懵了。我当年第一次做 SOC2 项目时，也花了很长时间才理清它们之间的边界和联系。

这五个准则分别是：安全性、可用性、处理完整性、保密性、隐私性。它们不是孤立的，而是相互支撑的。你想想看，一个系统如果连安全都做不到，谈何保密？如果系统老宕机，可用性为零，处理完整性再高也没用。

下面我一个一个拆开来讲，结合我踩过的坑，帮你真正吃透它们。

2.1 安全性（Security）—— 系统的“门锁”

安全性是所有准则的基础。它关注的是：系统是否受到保护，防止未经授权的访问、使用或破坏。

我个人习惯把安全性理解为“门锁”。你家的门锁够不够结实？钥匙有没有乱丢？窗户有没有关好？对应到 IT 系统，就是防火墙、访问控制、入侵检测这些。

2.2 可用性（Availability）—— 别让业务“断粮”

可用性关注的是：系统是否按照约定的服务水平正常运行？说白了，就是你的系统能不能稳定提供服务。

我记得有一次审计，客户说他们的系统可用性达到 99.9%，但审计师一问：“那你有监控吗？有告警吗？有灾备吗？”客户当场愣住了。原来他们只是凭感觉说“好像没怎么宕机”。

可用性不是靠感觉的，得有数据支撑。

关键要素	说明
监控与告警	系统宕机了，你多久能知道？
容量规划	流量高峰期，系统扛得住吗？
备份与恢复	数据丢了，能恢复回来吗？多久能恢复？
灾备演练	真出事了，你的灾备方案能跑通吗？

2.3 处理完整性（Processing Integrity）—— 数据“不走样”

处理完整性听起来有点抽象，其实很简单：系统处理数据时，是不是准确、完整、及时？有没有丢数据？有没有算错账？

举个例子，你网购下单，系统扣了钱但没生成订单，这就是处理完整性出了问题。或者银行转账，转出去 100 块，对方只收到 99 块，这也是问题。

为什么会这样？很多时候是因为系统设计有缺陷，或者数据处理流程中缺少校验。

2.4 保密性（Confidentiality）—— 敏感数据“不外泄”

保密性关注的是：敏感数据（比如客户名单、商业机密、源代码）有没有被妥善保护？

注意，保密性和安全性有重叠，但侧重点不同。安全性是“谁都不能进”，保密性是“不该看的人不能看”。比如，公司内部员工可以登录系统，但只有特定角色才能查看客户合同，这就是保密性控制。

我个人习惯把保密性控制分为两类：

• 数据分类：你得先知道哪些数据是敏感的，才能谈保护。
• 加密与访问控制：传输加密（HTTPS）、存储加密（AES-256）、最小权限原则。

2.5 隐私性（Privacy）—— 个人信息“合规用”

隐私性是五个准则里最“麻烦”的一个，因为它涉及法律法规（比如 GDPR、CCPA、中国的《个人信息保护法》）。它关注的是：个人信息的收集、使用、存储、共享、删除，是否合规？

你想想看，用户注册时你收集了他的手机号，你有没有告诉他用来干嘛？你有没有给他删除数据的权利？你有没有把数据卖给第三方？这些都是隐私性要管的事。

隐私性其实可以看作是保密性的“升级版”。保密性只管“别泄露”，隐私性还要管“怎么用、用多久、用完怎么删”。

隐私性原则	说明
告知与同意	收集数据前，要明确告知用途并获得同意。
目的限制	收集的数据只能用于告知过的目的。
数据最小化	只收集业务必需的数据，别什么都想要。
访问与更正	用户有权查看、修改自己的数据。
删除权	用户要求删除时，你得能彻底删掉。

2.6 五大准则的关系与优先级

最后，我简单总结一下这五个准则的关系。你不需要把它们割裂开来看，它们是一个整体：

• 安全性是地基，没有它，其他都是空谈。
• 可用性是保障，系统都跑不起来，其他准则没意义。
• 处理完整性是核心，数据不准，系统再安全也没用。
• 保密性是底线，敏感数据泄露，后果很严重。
• 隐私性是合规要求，法律风险不可忽视。

在实际审计中，并不是所有公司都需要覆盖全部五个准则。比如，你只做内部系统，不涉及个人信息，那隐私性可能就不在审计范围内。但安全性、可用性、处理完整性，几乎是所有 SOC2 审计的标配。