如上所述，CC 有一套可供选择的可能的保障要求，以及几个预定义的保障要求集（EAL 级别 1 到 7）。同样，如果您真的要进行 CC 评估，您应该查阅 CC 文件；我将跳过描述涉及审查官方 CC 文件（评估 PP 和 ST）的措施。以下是一些可以增加其他人对您软件信心的保障措施。
配置管理 (ACM)。 至少，为每个 TOE 版本设置唯一的版本标识符，以便用户知道他们拥有什么。 如果您有良好的自动化工具来控制您的软件，并为每个部分设置单独的版本标识符（典型的 CM 工具如 CVS 可以做到这一点，尽管 CVS 不将更改记录为原子更改，这是它的一个弱点），您将获得更多保障。 纳入配置管理的越多越好； 不仅要控制您的代码，还要控制文档，跟踪所有问题报告（尤其是与安全相关的问题），以及所有开发工具。
交付和操作 (ADO)。 理想情况下，您的交付机制应让用户检测到未经授权的修改，以防止他人冒充开发人员，甚至最好从一开始就防止修改。 您应该提供关于如何安全地安装、生成和启动 TOE 的文档，并可能生成一个日志来描述 TOE 是如何生成的。
开发 (ADV)。 这些 CC 要求涉及描述 TOE 实现的文档，以及它们之间需要保持一致（例如，ST、功能规范、高级设计、低级设计和代码中的信息，以及安全策略的任何模型）。
指导文档 (AGD)。 您的产品的用户和管理员可能需要某种指导，以帮助他们正确使用它。 它不需要是纸质的； 在线帮助和“向导”也可以提供帮助。 指导应包括关于在安全环境中可能存在问题的操作的警告，并描述如何安全地使用系统。
生命周期支持 (ALC)。 这包括开发安全（保护用于开发的系统，包括物理安全）、缺陷修复流程（跟踪和纠正所有安全缺陷）以及明智地选择开发工具。
测试 (ATE)。 简单的测试可能会有所帮助，但请记住，您需要测试安全功能，而不仅仅是通用功能。 您应该检查如果某项设置为允许，它是否被允许；如果它被禁止，它是否不再被允许。 当然，可能有一些巧妙的方法可以破坏这一点，这正是漏洞评估的全部内容（接下来会描述）。
漏洞评估 (AVA)。 进行漏洞分析非常有用，其中有人假装是攻击者，并尝试使用可用信息（包括文档，例如查找“不要做 X”的语句，并查看攻击者是否可以利用它们）和公开已知的此产品或类似产品的过去漏洞来查找产品中的漏洞。 本书介绍了应对先前产品的已知漏洞的各种方法，以解决诸如重放攻击（其中存储和重新传输已知良好信息）、缓冲区溢出攻击、竞争条件以及本书其余部分描述的其他问题。 应该检查用户和管理员指导文档，以确保删除误导性、不合理或冲突的指导，并已解决所有操作模式的安全程序。 专用系统可能需要担心隐蔽通道； 如果您想了解更多关于隐蔽通道的信息，请阅读 CC。
保障维护 (AMA)。 如果您不进行 CC 评估，则不需要正式的 AMA 流程，但所有软件都会经历变更。 您的流程是什么，以便让所有用户对您软件未来的更改不会产生新的漏洞充满信心？ 例如，您可以建立一个流程，让多人审查任何提议的更改。