这是Chiaro关于SOC 2准备和审计的完整方法论：我们测试的控制库、每个控制映射的标准、我们接受的证据，以及收集所遵循的规则。准备和审查基于相同的框架，因此公司所准备的标准就是审查所适用的标准。之所以发布，是因为展示您的工作是避免让人们仅凭信仰信任，而依靠信仰运作的合规行业正是让大家读取此内容的原因。这里的内容：framework/controls.json ：86条控制。 framework/test_attributes.json ：355条测试属性。每一条都说明了测试的内容、通常满足的证据、在特定时点和一段时间内的通过标准，以及何时不适用。 framework/criteria.json ：每个控制映射到的61个信任服务标准。 framework/evidence_map.json ：映射到满足控制的22个证据来源。 framework/calibration-examples.json ：所有的校准示例集中在一个文件中。基于属性的嵌套也存在于test_attributes.json中；此文件的存在是为了让您能够实际找到它们。 method/scoping-playbook.json ：系统如何分类为范围内、范围外或作为子服务组织。 method/collection-rules.md ：收集所遵循的操作规则，复制自服务器实际发送的指令。 method/type2-testing.md ：如何进行Type II测试。默认情况下，完整数量，偏差规则及其应用示例，以及具有选择算法的抽样后备。 method/tools.md ：连接AI可以调用的每一个工具，来自实时服务器生成。 校准示例 属性中包含498个经过计算的示例，每一个记录了AI做出的判决、正确的判决，以及原因。它们存在的目的是校准判断，且是本存储库中我们最不希望竞争对手获得的部分。它们记录了我们的经验，而非我们客户的信息。每个发布的示例都带有来源："synthetic_taste_v1"。每一个都采取了我们实际必须做出的判断，并为此写作了场景。这是故意的，并且是两个选项中更严格的：客户工作是机密的，而编辑会去除一个名字而不去除一个身份，因此从实地工作中提取的案例会对任何了解公司的人的显而易见。这里发布的是教训：所绘制的区别及其背后的推理。场景中的公司、系统、数字和人员并不真实，也无任何客户。它们推向哪个方向？303个修正了一个过于严格的AI，而195个则修正了一个过于宽松的AI。我们发布这个比率是因为任何拥有文件的人都可以计算出来，因为诚实的解读默认并不美好：一个例子大多教导"其实这样就好"的审计师，正是行业在2025年之后应该怀疑的对象。我们的答案是，这两种错误并不同样常见。一个读取证据与书面标准对比的引擎更容易标记过多，而不是标记过少，因为它没有看到缺失的材料在其他地方受到三种方式的覆盖。纠正这一点是大部分工作。而推向另一边的示例是对获取意见非常重要的，所以我们故意增加了它们的数量，而不是让比率维持在它落下的地方，也没有强求其为1:1，这样会形成另一个虚构。如果您认为特定示例软化了某些不应软化的内容，那是您可以指向的具体事项。针对控制和属性ID打开问题。这就是该文件公开的全部原因。 Type II：完整的数量，而不是样本 默认情况下，我们不进行抽样。现代公司的数据是由机器生成的，因此可以以机器速度进行验证，所有数据都是如此。客户的AI为每个控制（观察窗口内的每个变更，每个终止，每次访问审核）检索完整的数量。完整性得到了证实：始终记录检索，并在存在独立第二来源时进行对账。然后每个项目都经过测试，在数据结构化的地方以确定的方式进行，在散文中以校准的读取方式进行，所有候选偏差在成为例外之前都得到了CPA的确认。抽样仅在无法完整检索一个数量的情况下才存在，报告中会披露每个控制所采用的方式。当抽样发生时，没有人选择：选择是通过银行数据本身的哈希生成的，因此双方都无法操控或重新摇骰。完整的方法见method/type2-testing.md ：数量规则、偏差规则及其示例、后备表和选择算法。79个逐项属性大多写着“对于一个样本”，控制手册和通过标准中也有零散的“样本”用语。与方法相对比，这种表达是错误的。