如果你在一个受法规监管的公司工作，那么你就有相当大的机会听说过计算机系统验证（CVS）这个术语。问题是“计算机系统”从严格意义上来讲是一个平台系统的硬件和软件。以此为中心，你需要添加应用软件、辅助设备、人员和规程来形成“计算机化系统”。然后，这个计算机化系统就在公司的运营基础设施内运行（或在云端运行，如果在云托管服务环境中运行的话）。
计算机化系统内的这些要素中的每一个都需要经过验证或确认。
验证就是提供基于事实根据的证据表明某一项流程始终持续一致地产生符合其预定规范和质量属性的结果。
确认则是证明某些物理实体适合于一系列要求中所规定的预期用途。
全面自动化解决方案通常由若干不同的验证和确认活动所组成，它们汇集到最终性能确认（PQ）或用户验收测试中。
目前，很少有自动化解决方案在分离于网络上任何其他节点的单机版硬件装置上独立运行。节点是计算机网络上能够发送、接收和/或转发信息的任何物理装置。
由于这个原因，支持计算机化系统的网络基础设施也需要经过确认/验证。先对各个组件进行确认，然后把整个网络作为一个整体进行验证。
在理想世界中，先独立于计算机化系统来完成基础设施的验证并对其进行维护，然后每当需要增配或更新新计算机化系统的时候，只要对之前的基础设施验证进行更新或引用就可以了。
在普通的真实世界场景中（在这种情况下，我们的计算机基础设施受到适当管理，但没有正式经过验证），作为项目一部分来处理或利用的基础设施的各个组件可作为限定的自动化系统项目的一部分来单独进行确认/验证。对于单个项目，这是个好方法，但随着越来越多的计算机化系统需要验证，此方法并不合适。
显然，最好是配备一个已知经过验证的网络基础设施，并且仅仅将此陈述为每个自动化系统项目利用网络上的组件和流程。
责任归属有一个影响任何系统或装置长期验证状态的问题就是该要素的责任归属。没有负责人（或辨别不清谁是负责人）的系统或装置更可能会被错误地验证或脱离验证状态。
每个自动化系统或装置都应当有（流程的）业务负责人和（计算机系统）的系统负责人；并且这些个体们共同为维持系统的验证状态负责。（正如所有可审计的质量流程，质量保证将最有可能为确保实现上述情况而负责——但却不一定负责实际实施。）
IT基础设施确认计划正如一家公司的计算机系统验证主计划，IT基础设施的确认计划规定了实施初始活动和后续工作的框架，以确保基础设施保持在合规状态。
把网络基础设施拆解为各个平台，然后大体上规定每个平台将怎样确认，这是对这项活动进行规划的一个合乎逻辑的方法。
各个平台的示例：
§服务器
§路由器和交换机
§瘦客户机/便携式电脑/台式电脑
§打印机
§电缆
§防火墙
§网络软件
在IT基础设施确认计划中有一些关键部分：
§背景和历史。
§角色和职责。
§系统描述。
§确认方法——策略包括：
§制定用户需求说明。
§制定SOP和政策。
§安装/运行确认。
§确认总结报告。
§对上述每一个平台简要地说明平台在公司怎样使用，以及与平台确认相关的任何具体细节。纳入对相关用户需求文件和平台确认文件的参考引用。
§陈述以下流程在公司怎样管理/控制，或者引用一份提到以下流程的SOP/政策：
§培训
§变更控制
§访问安全
§供应商支持
§病毒防护
§备份和还原
§PC维护
§定期回顾
§偏差/事件
§网络组件退役
§应急规划和灾难恢复
需求在IT基础设施确认计划的框架启动后（不需要所有细节全都定案），每个平台的各份需求文件就可以开始制定了。
确认规范如果需要的话，单独的组件设计文件是可以存在的，或者该信息可以包含在某个组件的特定确认文件中。
应当为每种类型的组件开发模板确认文件，以便为确认工作提供帮助，并且有助于对每个组件采集一致数量的数据和实施一致程度的测试。
可以单独地实施风险评估，或把风险评估添加到确认规范中，以便进一步限制或提升所需测试的程度。
网络组件安装确认（IQ）的意图是为了确保：
§我们所收取到的是我们所订购的物件；
§组件已经按照要求进行配置，以达到规范；并且
§组件已经被正确地固定。
操作说明的程度和在IQ中所留存的配置参数详细程度需要与该组件的关键程度和风险相匹配。网络组件运行确认（OQ）的意图是为了确保组件已在其运行范围内的积极条件和消极条件下充分经过了测试。
另一方面，测试的程度和留存的结果也需要与该组件的关键程度和风险相匹配。正如前面所论述，对于很多网络组件，IQ和OQ可以合并成一份IOQ文件。
对于像电缆之类的要素，良好的做法是保存一份电缆图纸，在其之上各条电缆具有相应标识，并且各端口均有编号和标签。
基础设施放行每个要素独立确认，然后作为本确认的一部分放行。然后，网络基础设施作为一个整体来进行验证。在基础设施放行之前，应当实施各项测试来落实所要求的：
§吞吐量
§安全性
§性能
§服务质量
有趣的是我们注意到，当在网络支持或云计算功能中使用第三方的时候，通常会起草服务级别协议（SLA）来记录各项职责、响应时间和服务水准。但是，当一家公司自己的IT部门实施相同任务的时候，一般不存在任何这类协议。有些公司的确具有内部协议或关键绩效指标（KPI），但无论这些存在与否，都应该实施定期的常规内部审计，以确保普通的支持、备份、常规监测等均得到正确实施，符合文件记录。
云基础设施使用云计算基础设施消除了人员在基础设施确认方面的很多活动，但不代表责任亦随之而去。为了确保各项活动依然受到评估和实施，对数据中心、托管环境和托管软件的风险评估则必不可少。
作为该评估的一部分，建议对云基础设施进行审计，并加上一份SLA（服务级别协议）。应当知道，对基础设施（我们需要在其上面采集并保留数据）的那些管理和支持工作依然由数据责任人来负责。
对验证的网络基础设施的维护在我们有了验证的网络基础设施之后，维持那个状态就很重要了。普遍的失败点在于，当为更新既有网络组件或增加新组件时缺少适当的变更控制规程。
结论与所有的验证活动一样，使一个未经验证的网络基础设施达到验证状态（视环境的成熟度和当前状态而定）需要花费大量的精力、培训和投资。
对整个网络基础设施的验证必须与公司其他CSV（计算机化系统验证）积极行动相一致。换句话说，如果公司对CSV（计算机化系统）文化非常没经验，那么相对于特定的自动化项目，一开始最好只验证网络组件，然后在组织的CSV文化略有完善的时候密切
