
使用此模板
清晰的 IT 采购政策可控制支出、管理风险,并确保每一笔 IT 采购都符合安全与合规要求。使用 Trupeer,您可以从一份免费的 IT 采购政策模板开始,节省数小时的政策编写时间;再用您的 品牌规范 进行定制;最后将政策转换为视频演练,员工和供应商可快速理解。
什么是 IT 采购政策,以及它不是什么
IT 采购政策是用于决定谁可以代表公司承诺某个技术供应商、在作出该承诺之前必须检查什么、以及承诺之后关系将如何处理的书面规则。它不是采购流程、供应商清单或合同——这些都在它之后。
它也不是在前面加上“IT”字样的通用采购政策。通用采购假设所采购的东西交付一次、放在某处并随时间折旧。技术会把这个假设打破四次:它会自我续费,因此三年承诺只签一次,却会在无人重新审批任何内容的情况下支付三十六次;它会持有您的数据,因此采购会以与您交付的价值毫无关联的价格,把客户或员工记录交给第三方;它可能是免费的,而免费的工具会通过任何曾经写下的支出门槛;而且它不会“死”:硬件会被核销,而软件会在选择它的人离开公司之后继续计费。
为什么大多数 IT 采购政策“漏掉了钱”
几乎每一份采购政策模板的结构都一样:目的、范围、角色、门槛、审批矩阵、例外。审批矩阵总是以一个数字为键——也就是这项支出要花多少钱。这个设计假设“昂贵的时刻”和“有风险的时刻”是同一个时刻。但在 IT 里,它们几乎从不相同。
“昂贵的时刻”是续费,因为续费会自动发生,价格由供应商设定、座位数由供应商统计,且没有任何人类决定任何事情。在为期五年的合作关系中,最初的采购通常是整个序列里最小的决策,也是唯一一次被任何人认真审阅的决策。
“有风险的时刻”是数据。一个每位用户十二美元的笔记记录工具会摄取会议录音,因此它带来的暴露风险,往往高于一个从不离开机房的六万美金存储阵列。支出门槛会把阵列路由给 CFO,而笔记记录工具则路由给无人。
因此,这份模板用两种不同方式来处理。它在两个维度上路由请求——支出与数据暴露——而不是只用一个维度。并且它把续费视为一次全新的采购决策,而不是一次会计事件。其他部分都很标准,而标准是好的。真正关键的是路由表、条款 9 和登记表。
如何在 Trupeer 中自定义此模板
步骤 1:打开模板(Templates)部分
从主导航进入“Templates(模板)”部分。

步骤 2:选择并打开模板
点击任意您想要处理的模板以打开它。

步骤 3:展开模板视图
如有需要,展开模板视图以清晰查看完整布局与细节。

步骤 4:编辑模板
点击“Edit(编辑)”开始修改所选模板。

在编辑器中,您可以:
添加新的章节
定义或更新格式规则
添加徽标并调整其位置及相关设置
步骤 5:保存您的自定义模板
完成所有必要更改后,点击“Save(保存)”,将更新后的模板存为您的版本。

步骤 6:预览并微调模板
当您想查看自定义模板的效果时,打开“Preview(预览)”。

在预览界面中,如有需要,您还可以继续直接进行调整,确保模板呈现得与您期望完全一致。
使用带有 IT 采购政策模板,您可以:
节省编写时间:跳过空白页面,使用为 IT 采购打造的结构直接开始。
控制支出:内置审批门槛可防止未经授权的采购。
保持品牌一致:使用 Trupeer 的品牌套件应用您的徽标、字体和颜色。
管理供应商风险:内置安全与合规评估标准。
随时可审计:与 SOC 2、ISO 27001 及类似框架保持一致。
覆盖全球团队:一键将采购政策翻译为 65+ 种语言。
当最便宜的工具带来最多风险时,如何路由审批
下方的路由表替代了单一列的审批门槛矩阵。横向读取支出、纵向读取数据暴露,然后选择您落入的单元格。让它真正可用的规则是:数据暴露可以提高审批级别,但绝不会降低。触达客户个人数据的免费工具将进入安全审查,而“它不花钱”这一事实并不重要。
年度承诺支出 | 无公司数据 | 仅内部数据 | 个人数据(客户或员工) | 受监管数据(健康、支付、金融、政府) |
|---|---|---|---|---|
零,包括免费档 | 直属经理 | IT 负责人 | 安全审查与 IT 负责人 | 完整审查 |
低于 2,000 | 直属经理 | IT 负责人 | 安全审查与 IT 负责人 | 完整审查 |
2,000 至 15,000 | IT 负责人 | IT 负责人和财务 | 安全审查、IT 负责人和财务 | 完整审查 |
15,000 至 75,000 | IT 负责人和财务 | 安全审查、IT 负责人和财务 | 完整审查 | 完整审查 |
超过 75,000 | 完整审查 | 完整审查 | 完整审查 | 完整审查 |
完整审查意味着在任何签署或录入卡信息之前,安全、法务、财务以及技术高管将共同完成审查。
货币与分档由您决定,而且它们远不如这些列重要。如果您不在其他地方做任何更改,那么请把门槛从一个维度改为两个维度。另请注意,“年度承诺支出”指的是十二个月的总额,而不是单笔交易规模。每月四百四十五美元的费用对应的是五千三百四十美元的承诺;而那些按交易而非承诺来读取的政策,正是导致下方“实际案例”发生的原因。
IT 采购政策模板,第一部分:目的、范围、角色
从这里复制。替换方括号中的任何内容。
1. 目的
本政策说明 [Company] 如何评估、审批、采购、续费并停用信息技术产品与服务。本政策旨在确保技术支出是有意图的;在将数据交给第三方之前会先评估数据;并且每一段在运行的供应商合作关系在公司内部都有明确的负责人。
2. 范围
本政策适用于 [Company] 的所有员工、承包商与临时人员,以及所有技术采购行为(不论价值或付款方式)。它涵盖软件订阅与许可证、云与托管服务、硬件与设备、专业服务与实施服务、数据与内容源,以及开发者工具与 API。
本政策也适用于提供零成本的产品(这些产品将处理 [Company] 数据),以及通过公司卡、个人费用报销、免费试用或供应商自助结账方式获取的产品。
本政策不涵盖人员招聘、设施、营销媒体采购或法律服务;这些由 [相关政策] 管理。
3. 定义
年度承诺支出:在任何十二个月期间内应付给供应商的总额,包括许可证费用、按座位收费、使用费用、支持费用与实施成本。
数据暴露:产品将存储、处理或传输的 [Company] 数据中最敏感的类别;评估基于产品具备接收的能力,而不是基于提出请求的人打算把什么放进去。
负责人:对供应商合作关系、其成本、续费决策以及最终停用负责的指定个人。
影子 IT:任何未在技术登记表中记录的正在使用的技术。
4. 角色与职责
提出请求者说明业务需求、已考虑的替代方案,以及产品将触达的数据。
负责人(可能是提出请求者)在合作关系的整个生命周期内持有该关系,确认续费决策,并发起停用/退役。
IT 评估技术适配性、集成成本、与已持有工具的重叠程度,以及支持负担。
安全部门评估供应商的控制措施、认证、分包处理方(subprocessors)与泄露历史,并确定是否需要签署数据处理协议。
财务确认预算、记录承诺,并控制付款方式。
法务审查责任、赔偿、终止权、自动续费条款、以及司法管辖区。
政策负责人 [role] 维护本政策与登记表,并在每个 [quarter] 向 [committee] 同时汇报。
IT 采购政策模板,第二部分:请求、审查与采购
5. 提出请求
所有请求必须通过 [request form or ticket queue] 提交,且在创建任何试用账户、签署任何合同以及完成任何付款之前进行。作出承诺之后提交的请求将按第 12 条作为例外处理。
每一项请求都应说明:所寻求的业务结果、产品将触达的数据类别、未来十二个月预计的用户数量、年度承诺支出、合同期限,以及是否有任何 [Company] 已持有的工具能够满足该需求。
6. 审查与审批
请求将使用 [Appendix A] 中的审批路由表进行路由。审批结果会在 [system] 中记录,包括审批人、日期以及已批准的年度承诺支出。审批授予基于所述期限与所述支出。审批不延续至续费、期限延长,或超过 [15] percent 的支出增加。
7. 安全与数据审查
任何将处理个人数据或受监管数据的产品,必须在审批前由安全部门进行审查。审查内容包括:供应商的安全认证及其适用范围、分包处理方与数据存储所在国家、身份验证与访问控制、事件通知承诺、数据导出与删除机制,以及任何泄露历史。
如处理个人数据,应在产品接收实时数据之前执行数据处理协议。如处理受监管数据, [Company] 将另外 [insert the assessment your regulator or framework requires]。
8. 合同签署与付款
只有 [named roles] 可代表 [Company] 签署合同或接受服务条款。点击确认协议等同于签署合同。
法务将审查所有年度承诺支出高于 [15,000] 的协议,以及任何价值不等的协议,只要其中包含自动续费、个人数据处理、排他性或最低量承诺,或期限超过十二个月。
付款由 [purchase order or corporate card held by Finance] 完成。个人卡与费用报销并非任何价值下技术采购的已批准路由方式。发给个人的卡不得用于经常性技术费用。
在释放首笔付款之前,所有已批准产品都必须记录到技术登记表中。
IT 采购政策模板,第三部分:续费、退出与例外
9. 续费
续费是一项采购决策,而不是会计事件。
如需在续费日期前超过 [60] 天发出不续费通知,则不得签署任何协议,除非已按第 12 条获得批准。
每个续费日期前 [Ninety] 天,负责人完成续费审查:将活跃座位与过去九十天内的已许可座位进行对照;将实际支出与已批准支出进行对照;确认最初的业务结果是否已达成;确认 [Company] 目前是否有任何其他工具能够覆盖相同需求;并评估产品处理的数据是否发生任何变化。
续费审查由与批准最初采购相同的级别进行审批,使用当前支出与当前数据暴露。如果任一项已将产品提升到更高级别,则由更高级别进行审批。
未在续费日期前 [30] 天由 [30] 天前完成审查的续费将升级至 [role]。如负责人已离开 [Company] 且未指定继任者,则续费默认不予批准,且该产品将被视为停用/退役的候选项。
10. 所有权与技术登记表
[Company] 维护技术登记表,记录每一款处于活跃状态的产品:供应商、产品、负责人、审批权限与日期、年度承诺支出、续费日期、通知期、已处理的数据类别、是否已到位数据处理协议、已许可座位,以及行政账户持有人。
登记表将 [quarterly] 进行审查。任何无法与登记表条目匹配的公司卡或银行对账单上的费用,都将在 [30] 天内接受调查。
当员工离职时,[role] 会检查其负责的产品并在其最后一天之前重新分配所有权。任何供应商账户的管理访问权限将转移给基于角色的账户,而非指定给某个个人。
11. 停用/退役
当产品被退役时,负责人以可用格式导出 [Company] 数据,向供应商发出带有文档记录的删除请求并记录其回复;移除所有用户账户;取消付款工具或采购订单;更新登记表;并确认没有依赖系统仍在调用该产品。
在记录删除确认之前,停用/退役尚未完成。
12. 例外与紧急采购
如遇服务中断、安全事件或法律义务导致延迟不可接受,紧急采购可在未完成全部审批的情况下继续进行。[Role] 可对此进行授权。完整审批流程将在 [10] 个工作日内完成,且采购会在例外日志中记录。
其他所有例外都需要来自 [role] 的书面批准,并需附上原因与到期日期。例外不会自动续期。
13. 不合规
未经批准的技术采购不得报销;一旦发现未经批准的产品正在处理 [Company] 数据,将被禁用。重复不合规将按 [disciplinary policy] 处理。
14. 审查
本政策由 [role] 在 [annually] 进行审查;如发生重大事件、监管义务变更或公司结构变更,也应更早进行审查。
从这里复制。
一个实际案例,以及它花了多少钱
Meridian Freight、三百一十名员工,制定了一份采购政策,审批门槛为五千美元。这是一份合理的政策。下面是它如何失败的。
2024 年 3 月,一位支持团队负责人购买了一款工单分析工具:四个座位,每座每月八十九美元;公司卡每月支付四百四十五美元。政策按交易而非承诺来读取,因此四百四十五从未接近五千,也就没有触发任何审批。年度承诺为五千三百四十美元,超过了门槛。
该工具摄取了完整的工单内容,而 Meridian 的工单包含客户姓名、送货地址、电话号码以及托运详情。没有进行任何安全审查,也没有签署数据处理协议,供应商的分包处理方列表也从未被阅读。
负责人于 2024 年 11 月离职,她的卡在例行的财务交接中被重新发给了继任者,因此这笔费用也随之延续。
该工具在 2025 年 3 月续费。按座位定价从八十九美元变为一百一十九美元,且计费基于使用量,因此随着人员加入共享队列,座位数增长到十一。每月成本约为一千三百美元。没人批准,因为根本没有需要批准的内容——这是一笔一直存在的卡费用。
2026 年 2 月进行的卡审计发现了这一点。在这十一个座位中,有三个在过去九十天内登录过。跨越二十四个月的总支付约为一万八千二百美元,其中五千三百四十美元来自某个人做出的决策。剩余的一万二千八百五十二美元则是“无人”花掉的。
真正重要的成本并不是钱。二十个月的客户个人数据一直由一个未经评估的供应商持有;而由于行政账户属于一位已离职的员工,Meridian 无法在不打开支持工单并证明所有权的情况下导出或删除自己的数据。这花了十一天。
这里每一条看起来像“额外工作”的条款之所以存在,是因为某种版本的上述问题。第 8 条阻止个人卡。第 9 条让 2025 年 3 月成为一个决策点。第 10 条捕捉未匹配的费用,并在退出时重新分配所有权。第 11 条意味着删除请求并不是第一次有人想到它。
在两周内编写并推广上线
第一周:在写规则之前先建立事实。拉取过去十二个月的卡与银行数据,列出所有经常性技术费用;然后询问每位团队负责人他们使用但不在该清单上的工具——这就是“免费工具”会浮现出来的原因。为每一行指定负责人。任何无人认领的内容,都是您第一批停用/退役的候选项。该清单将成为您登记表的第一个版本。
第二周:用您刚刚找到的分布来设定门槛,而不是用一个整数字。调整上面的条款,让法务与安全审查第 7、8 和 11 条,并与将要实际执行的人一起确认路由表。把它与登记表一起发布,而不是在发布之前。没有登记表的政策是一份文件;有登记表的政策是一种控制。
把推广上线当作行为改变,而不是一次公告。人们不会因为粗心而在流程之外购买工具;他们这么做是因为流程比截止日期更慢。如果您的审批路径无法在两天内处理一个低风险请求,那么您的政策就会被绕开。为审批设置服务水平,并发布您在该水平上的表现;我们的 变更管理指南 会更详细地介绍。
应该省略什么
供应商选择标准与评分矩阵应放在采购来源指南中。规定如何给供应商演示加权的政策在一年内就会过时,而且在那之前也太长、难以阅读。
供应商清单应放在登记表里,因为在政策中点名已批准供应商意味着每次更换工具都要进行变更控制。
针对采购系统的逐步操作说明应放在 IT SOP 中。政策说明需要采购订单;SOP 说明哪个按钮会触发它;把两者分开意味着您可以更改系统,而无需重新打开并修改政策。
值得与本政策并行构建的相关文档包括:用于您最终会购买的系统的 IT 文档模板;用于承载第 10 条所述技术登记表的 应用与凭据登记表(这也是它最自然的归宿);用于第 10 条所有权交接的 知识交接 SOP;以及用于任何足够大、需要实施的事项的 IT 项目计划模板。
关于法律与监管审查的说明
本模板是起点,而不是法律意见。采购义务会因司法辖区与行业而有显著差异。公共部门机构、受监管的金融机构、医疗服务提供者以及受公共招标规则约束的组织,都承担本模板未尝试复现的法定义务。数据处理条款与 GDPR、UK GDPR、CCPA 以及行业特定规则的交互方式会因您的数据主体与供应商所在位置而不同。
在您发布之前,请让您的法务顾问以及数据保护或合规负责人审查第 7、8 和 11 条,并让他们确认这些门槛与董事会已批准的任何授权委派一致。
把政策变成真正会被执行的东西
存放在共享盘里的政策只会被阅读一次。人们会遵循的版本,是与他们需要它的那个时刻绑定的——也就是他们正准备购买某样东西的那个时刻。
Trupeer AI 会把屏幕录制转换为可记录的流程,因此第 5 条中的请求路径会变成对您实际请求表单的演练,而不是一段描述性的文字。只录制一次,您就能在 知识库 中获得逐步指南、视频与文档——全部来自同一段录制,并使用您自己的品牌风格。
录制它。打造它。翻译它。用 Trupeer 来实现它。
对于维护政策库的团队,documentation 与 SOP creator 会让政策、登记表与流程保持在一起;而翻译意味着全球财务团队可以用自己的语言阅读审批路由表。设置说明在 文档模板设置指南 中。
常见问题
这个 IT 采购政策模板有 Word 版本吗?
完整的政策文本就在本页的两个“copy(复制)”标记之间,并且编写方式确保可复制粘贴后仍能正常使用。选择第 1 条到第 14 条,粘贴到 Word 或 Google Docs 中,编号与加粗标题会自动保留。没有需要申请的受限 Word 下载,因此也就没有在您和文本之间的邮件表单。
有 PDF 版本吗,或者我可以转发的 IT 采购政策 PDF?
把文本粘贴到您的文档编辑器中,然后从那里导出为 PDF。与固定的 PDF 相比,这对本文件更好,因为采购政策在任何意义出现之前,都需要把您的门槛、角色名称与货币替换到方括号中。仍在第 2 条写着 [Company] 的 PDF 不是政策;转发这样的 PDF 只会让人觉得政策是装饰性的。
我可以免费下载这个模板吗?
文本是免费的且不受限制。使用它、编辑它,并以您自己的名义在内部发布。您不需要在政策文档中署名 Trupeer AI。
COBIT APO10 是什么?这个模板能满足它吗?
APO10 是 COBIT 目标之一,涵盖受管理的供应商,涉及整个供应商生命周期中的供应商选择、关系管理、合同管理以及绩效监控。采购政策是 APO10 的输入,但它并不等同于 APO10。
本模板对采购与合同签署部分覆盖得很好,而第 9、10 条也涵盖了一些持续的关系管理内容。但它不覆盖供应商绩效记分卡、服务水平监控或覆盖整个投资组合的供应商风险分级——这些都是 APO10 所期望的。如果您正在进行 COBIT 评估,请把它视为您可能需要的多份文件之一,而不是能够直接关闭该目标的控制措施。
什么是简单的采购政策?什么时候它就足够了?
简单的采购政策通常只有两到三页:目的、范围、支出门槛表,以及谁来签署。对于一家大约只有五十人、只采购主流工具且不涉及受监管数据的公司来说,这确实已经足够;而一份包含十四条的政策也不会被真正执行。
如果您想要简短版本,请保留第 1、2、4、6、8 和 9 条,并删除其余条款。不要删除第 9 条。续费纪律是任何规模公司都能“自我回本”的唯一控制措施,也是短政策中最常缺失的条款。
这是否涵盖 SaaS 和云服务,还是只涵盖硬件?
两者都涵盖,而且第 2 条中的范围写得很明确,因为模糊性正是大多数政策泄漏的来源。云与 SaaS 是更难的情况,因此路由表里有“零支出”的行,以及“数据暴露”的列。在大多数公司里,硬件采购通常只需按支出单独路由即可。
谁应该负责这份政策?
谁对技术支出负责——在大多数公司里通常是 CIO、IT Director 或 Head of IT;在较小的公司里往往是 COO 或财务总监。比职称更重要的是:负责人必须能看到第 10 条所描述的卡与银行数据。看不到费用的政策负责人无法执行它。
我们应该多久审查一次?
在第 14 条中,“每年一次”是合理的默认选项。如果您发生过与某个供应商相关的安全事件、监管机构变更了适用于您的义务、您经历了收购或被收购,或者您每季度对登记表的审查连续两次发现未匹配的费用,那么应更早审查。最后这一点是一个信号:路由表或审批服务水平没有发挥作用,而不是人们需要被提醒政策。
