SAS70，那个曾经定义了服务审计的传奇标准，如今还好吗？

大家好，我是你们的老朋友，一个在注会行业摸爬滚打多年的“笔杆子”，今天咱们不聊枯燥的会计准则分录，也不谈那些让人头秃的复杂合并报表，咱们来聊一个在审计圈内既让人怀念，又让新人感到陌生的“老古董”——SAS 70。

虽然从严格的合规角度来看，SAS 70已经成为历史，被 SSAE 16 和现在的 SOC 1 所取代，但在很多人的口头上，甚至在不少合同条款里，它依然是一个绕不开的名字，它就像审计界的“诺基亚”，虽然现在的年轻人都在用智能手机（新的审计标准），但那个曾经坚如磐石的“板砖机”,依然在许多老审计师的心中占据着特殊的位置。

我就想用最接地气的方式，带大家扒一扒 SAS 70 的前世今生，聊聊它为什么那么重要，以及在这个风云变幻的数字时代,我们该如何看待它的遗产。

什么是 SAS 70？别被缩写吓到了

咱们先抛开教科书上那些晦涩的定义，SAS 70 全称是“审计准则第70号声明：服务组织的控制报告”。

在互联网经济大爆发之前，很多公司虽然业务做得很大，但后台处理往往是自己搞的，后来，分工越来越细，为了省钱省事，大家开始把非核心业务外包出去，把工资单发给第三方代发公司，把数据托管给数据中心,把电商平台的物流交给第三方。

这时候,问题就来了。

假设你是“老张”，你是甲方公司的审计师，你要审计甲方公司的财务报表，甲方的员工工资都是“大力神薪金公司”代发的，按照审计准则，老张必须确认工资这个数字是对的，老张没权也没法直接去查“大力神公司”的账，难道老张要对每一笔工资都发函证吗？那得查到猴年马月去,而且成本高得离谱。

这时候，SAS 70 就像一位救世主登场了。

“大力神公司”可以聘请自己的审计师，按照 SAS 70 的标准，出具一份报告，这份报告就像是“大力神公司”内部控制的一张“体检表”，老张只要拿到这张体检表，确认上面没有重大隐患，就可以放心地依赖“大力神公司”的数据,而不用自己去重复劳动了。

我的个人观点是： SAS 70 的诞生，本质上是信任机制的一种商品化，它把看不见摸不着的“内部控制”，变成了一份可以流通、可以交易的标准化文件，这在当时,绝对是审计行业的一大创举。

一个关于“披萨店”的生活实例

为了让大家更透彻地理解 SAS 70 的核心逻辑,我给大家讲个生活中的例子。

想象一下，你是一家大型连锁餐饮集团“美味汉堡”的老板，你生意太好了，忙不过来，于是你把“送外卖”这个业务，外包给了一家专业的物流公司——“飞毛腿配送”。

作为老板，你最担心的是什么？你担心“飞毛腿”把你的汉堡送错了，或者送慢了，甚至被司机偷吃了，这会影响你的声誉和收入，你不可能每时每刻盯着“飞毛腿”的司机看。

这时候，SAS 70 的逻辑就来了：

“飞毛腿配送”请来了一位独立的检查官（审计师），这位检查官不检查汉堡好不好吃（那是你产品的事），他专门检查“飞毛腿”的流程：

接单的流程有没有漏洞？
司机有没有背景审查？
车辆有没有定期保养？
如果汉堡洒了,有没有赔偿机制？

检查官看完后，给“飞毛腿”出具了一份 SAS 70 报告。

这份报告分两类：

第一类（Type I）： 就像拍了一张照片，告诉你，“在某一天，飞毛腿的送餐流程设计得很完美，看起来没问题。”
第二类（Type II）： 就像拍了一段录像，告诉你，“在过去半年里，我不仅看了流程，还实际盯着他们送了半年餐，他们的流程不仅设计得好，而且确实执行到位了，这半年没出大乱子。”

作为“美味汉堡”的老板，你肯定只认 Type II 报告，对吧？因为光说流程好没用,我得看实际效果。

这就是 SAS 70 最核心的价值：它让外包服务的接受者（用户企业）能够“搭便车”，利用服务机构的审计成果来降低自己的审计风险。

那些年，我们与 SAS 70 爱恨交织的日子

回想我还在事务所做审计经理的那些年，SAS 70 可是我们又爱又恨的“老朋友”。

爱它，是因为它省事。 记得有一年，我审计一家大型互联网公司，他们的服务器托管在一个顶级的数据中心，如果没有 SAS 70 报告，我得亲自跑到数据中心，去数服务器，去检查门禁记录，去问他们UPS电池能用多久，那简直是噩梦，但幸好，数据中心每年都会出一份 Type II 的 SAS 70 报告，我拿到那本厚厚的报告，翻到“审计师意见”那一页，看到“无保留意见”，心里的大石头就落地了，我只需要在底稿里写一句：“已获取服务机构出具的 SAS 70 报告，未发现重大控制缺陷。”这就搞定了几百万资产的审计底稿。

恨它，是因为它有时候是个“黑箱”。 早期的 SAS 70 报告有个很大的问题，它是为“服务组织”写的，而不是为“用户审计师”写的，我拿到一份几百页的报告，里面全是数据中心的技术术语，什么“冷通道封闭”、“冗余电源切换”，看得我云里雾里，最要命的是，有些服务组织会在 SAS 70 报告里“注水”，他们把一些无关痛痒的控制写得天花乱坠,而对于用户真正关心的关键风险点却一笔带过。

我有一次遇到过一个极端的案例，一家做第三方支付的公司，给客户出具了 SAS 70 报告，客户拿来给我们看，觉得挺完美，但我作为审计师，敏锐地发现这份报告虽然覆盖了资金划转的流程，但在“反洗钱”和“资金归集”的具体控制点上，描述得非常模糊，当我们试图去函证细节时，对方竟然以“商业机密”为由拒绝提供更详细的底稿。

这就引出了我的一个观点： SAS 70 在后期，某种程度上变成了一种“合规秀”，很多公司拿它不是为了证明自己安全，而是为了作为一张“入场券”，只要我有这个报告，你就能把单子签给我，至于报告里到底有什么水分，那就看各家的本事了，这种形式主义的倾向,也是它最终被取代的原因之一。

为什么 SAS 70 会“死”？进化的必然

如果你现在去考 CPA，或者去问现在的四大合伙人，他们会告诉你：“SAS 70 已经作古了，现在是 SOC 1 的天下。”

2010年，美国注册会计师协会（AICPA）发布了 SSAE 16，正式取代了 SAS 70，随后又推出了 SOC 1（System and Organization Controls）报告体系，为什么要变？难道是因为 SAS 70 不够好吗？

这是全球化的必然结果。

SAS 70 是美国的标准，但是在这个时代，业务是无国界的，美国的公司可能把后台中心设在印度，或者外包给中国的团队，这时候，国际上需要一套通用的标准，国际审计准则（ISA）有一个对应的标准叫 ISAE 3402。

为了和国际接轨，AICPA 只能忍痛割爱，把 SAS 70 升级为 SSAE 16，并在内容和形式上向 ISAE 3402 靠拢。

除了国际化，还有一个核心的变化：管理层的责任。

在 SAS 70 时代，审计师承担了太多的责任，审计师要去评价服务组织的控制设计是否合理，这在逻辑上有点怪——那是你公司的系统，凭什么让我来评价设计得好不好？应该是你自己说设计得好,我来检查你说得对不对。

SSAE 16 和 SOC 1 纠正了这一点，它要求服务组织的管理层必须出具一份“管理层声明书”，明确说是由管理层负责系统的设计和运行,审计师只是对管理层的声明进行审计。

我对这个变化的看法是： 这是一种回归理性，审计师不是万能的，我们不能既当裁判又当教练，把责任还给管理层，让审计师专注于鉴证,这才是职业界成熟的标志。

SAS 70 的遗产：我们究竟在审计什么？

虽然标准变了，但 SAS 70 留给我们的思考并没有过时，特别是在云计算和SaaS（软件即服务）普及的今天，我们面临的环境比 SAS 70 时代要复杂得多。

以前我们担心的只是工资单算错，现在我们担心的是云端数据泄露、API 接口被恶意调用、甚至是算法歧视。

现在的 SOC 1 报告（也就是 SAS 70 的转世灵童），依然面临着当年的挑战：如何在一个高度互联、高度自动化的世界里，建立真正的信任？

我经常看到一些创业公司的CEO，拿着云服务商的 SOC 2 Type II 报告（这是针对安全性的，比 SOC 1 范围更广）来向我炫耀：“你看，我们用的是大厂，绝对安全。”

这时候，我通常会泼一盆冷水：“亲，你看过报告里的‘用户实体考虑事项’（User Entity Considerations）吗？”

这就好比你去买保险，保险公司告诉你：“这份保单管赔。”但保单里有一行小字写着：“前提是你出门必须戴头盔。”如果你没戴头盔,保险公司是不赔的。

SAS 70 及其继任者，都有一个非常重要的部分叫“用户实体考虑事项”，意思是，服务提供商（比如亚马逊云）已经做了他们该做的控制，但作为用户（你），你也必须做一些配套的控制,否则整个链条是断的。

举个具体的例子：一家电商公司把数据存放在符合 SOC 1 标准的云服务器上，云服务商承诺：服务器是有防火墙的，数据是加密存储的，电商公司的管理员为了图省事，把服务器的密码设成了“123456”,而且把权限开放给了所有员工。

一旦数据泄露，云服务商可以说：“我的 SAS 70/SOC 1 报告里写了，我有防火墙，但我控制不了你设弱密码啊。”

我的观点非常明确： 不要迷信一份报告，SAS 70 或者 SOC 1 报告，只是信任链条的起点，而不是终点，它不能替代你作为企业管理者应有的审慎，如果你把审计报告当成“免死金牌”,那离灾难就不远了。

给年轻审计师的几点掏心窝的建议

作为一个在行业里写了这么多年文章的老兵，看到很多刚入行的小朋友对着标准死记硬背,我总是忍不住想多说几句。

不要只做“报告搬运工”。 当你拿到服务机构的 SOC 1 报告（以前叫 SAS 70）时，不要只看意见那一段，去读读描述部分，去理解他们的控制逻辑，如果你不理解客户是怎么运作的,你就永远无法真正评估风险。
学会“说人话”。 当你的客户（比如非财务背景的运营总监）问你什么是 SAS 70 时，别扔给他一个定义，用我上面提到的“披萨店”或者“体检表”的例子去解释，在这个行业，能把复杂的事情讲简单,才是真本事。
关注实质，而非形式。 哪怕对方拿出的报告名字叫“SAS 99”（瞎编的），只要里面的控制逻辑是严密的，是能解决你的风险担忧的，它就有参考价值，反之，如果名字叫“SOC 1 Type II”但内容空洞无物,那就是一张昂贵的废纸。