首先，一些关于 CC 的一般信息将有助于理解如何应用其概念。CC 的官方名称是“信息技术安全评估通用准则”，但通常简称为通用准则（Common Criteria）。CC 文件包含三个部分：导言（总体描述 CC）、安全功能需求（列出产品可能希望包含的各种安全功能）和安全保障需求（列出确保产品安全的各种方法）。还有一个相关文件，即“通用评估方法”（CEM），它指导评估人员如何在进行正式评估时应用 CC（特别是，它放大了 CC 在某些情况下的含义）。
尽管 CC 是国际标准 ISO/IEC 15408:1999，但从 ISO 订购 CC 非常昂贵。希望有一天 ISO 会效仿其他标准组织（如 IETF 和 W3C）的做法，免费重新发布标准。毫不奇怪，IETF 和 W3C 标准比许多 ISO 标准更常被遵循，部分原因是 ISO 对标准收取的费用使大多数开发人员都无法获得它们。（我不介意作者因其工作获得报酬，但 ISO 并没有资助大多数标准开发工作——事实上，许多 ISO 文件的开发者都是志愿者——因此 ISO 站不住脚的费用只会中饱私囊，实际上并没有帮助作者或用户。）值得庆幸的是，CC 的开发者预见到了这个问题，并确保 CC 的技术内容可以免费提供给所有人；您可以从 http://csrc.nist.gov/cc/ccv20/ccv2list.htm 下载 CC 的技术内容。即使是那些进行正式评估过程的人通常也使用这些版本的 CC，而不是 ISO 版本；根本没有充分的理由为 ISO 版本付费。
尽管 CC 可以以其他方式使用，但它通常用于创建两种文档，“保护轮廓”（PP）或“安全目标”（ST）。“保护轮廓”（PP）是由用户组（例如，消费者团体或大型组织）创建的文档，它标识了产品的期望安全属性。基本上，PP 是用户安全需求列表，以 CC 定义的非常具体的方式描述。如果您正在构建与其他现有产品类似的产品，则很可能有一个或多个 PP 定义了一些用户认为对该类产品（例如，操作系统或防火墙）是必要的需求。“安全目标”（ST）是一个文档，它标识了产品实际执行的操作，或其安全相关的子集。ST 不需要满足任何特定 PP 的要求，但 ST 可以满足一个或多个 PP 的要求。
PP 和 ST 都可以通过正式评估。PP 的评估仅确保 PP 符合各种文档规则和健全性检查。ST 评估不仅涉及检查 ST 文档，更重要的是，它涉及评估实际系统（称为“评估目标”或 TOE）。ST 评估的目的是确保，在 ST 指定的保障需求级别上，实际产品（TOE）满足 ST 的安全功能需求。然后，客户可以将评估后的 ST 与描述他们需求的 PP 进行比较。通过这种比较，消费者可以确定产品是否满足他们的需求——如果不是，则可以确定限制在哪里。
要创建 PP 或 ST，您需要经历一个识别安全环境的过程，即您的假设、威胁和相关的组织安全策略（如果有）。从安全环境中，您可以得出产品或产品类型的安全目标。最后，选择安全需求，使其满足目标。安全需求有两种：功能需求（产品必须能够做什么）和保障需求（激发人们对目标已实现的信心的措施）。实际上，创建 PP 或 ST 通常不像这里概述的那样简单直接，但最终结果需要显示清晰的关系，以便不会轻易忽略任何关键点。即使您不打算编写 ST 或 PP，CC 中的想法仍然很有帮助；识别安全环境、目标和需求的过程对于识别真正重要的内容仍然很有帮助。
CC 的绝大部分文本用于定义标准化的功能需求和保障需求。本质上，CC 的大部分是一个“中式菜单”，列出了某人可能需要的可能的安全需求。PP 作者从各种选项中挑选以描述他们想要什么，而 ST 作者从选项中挑选以描述他们提供什么。
由于许多人可能难以确定合理的保障需求集，因此预先创建了称为“评估保障级别”（EAL）的保障需求集，范围从 1 到 7。EAL 2 只是为 EAL 2 定义的保障需求集的标准速记。产品可以添加额外的保障措施，例如，他们可以选择 EAL 2 加上一些额外的保障措施（如果组合不足以达到更高的 EAL 级别，则这种组合将被称为“EAL 2 加”）。许多世界国家之间签署了相互承认协议，只要采取的所有保障措施都在 EAL 4 级别或以下，就将接受其他国家认可实验室进行的评估。
如果您想实际编写 ST 或 PP，有一个可以帮助您的开源软件程序，称为“CC 工具箱”。它可以确保满足需求之间的依赖关系，建议通用需求，并帮助您快速开发文档，但它显然无法为您思考。PP 或 ST 中必须包含哪些信息的规范分别在 CC 第 1 部分附件 B 和 C 中。
如果您确实决定让认可的实验室评估您的产品（或 PP），请做好花钱、花时间并在整个过程中工作的准备。特别是，评估需要支付认可实验室进行评估的费用，并且更高的保障级别会迅速变得更加昂贵。仅仅相信您的产品是安全的还不够；评估人员将需要证据来证明所做的任何声明。因此，评估需要文档，并且通常必须改进或开发现有文档以满足 CC 要求（尤其是在更高的保障级别）。每一项声明都必须在一定程度上得到证实，因此声明越多，声明越有力，设计越复杂，评估就越昂贵。显然，当发现缺陷时，通常需要修复它们。请注意，实验室的报酬是评估产品并确定真相。如果产品不符合其声明，那么您基本上有两种选择：修复产品，或更改（减少）声明。
在开始正式的 ST 评估之前，与客户讨论期望内容非常重要；包含客户真正不需要的功能或保障需求的 ST 将不必要地昂贵，而遗漏必要需求的 ST 可能无法被客户接受（因为必要的组成部分将没有经过评估）。PP 识别了这些需求，但请确保 PP 准确反映了客户的实际需求（也许客户只想要 PP 中的一部分功能或保障，或者有不同的环境考虑，或者在您的产品将要使用的情况下想要其他东西）。请注意，ST 不需要包含产品中的每个安全功能；ST 仅声明将要（或已经）评估的内容。具有较高 EAL 等级的产品不一定比具有较低等级或没有等级的类似产品更安全；环境可能不同，评估可能通过不以更高的级别评估其他产品来节省了金钱和时间，或者评估可能遗漏了重要的内容。评估不是证明；它们只是施加了定义的最低标准，以增强对需求或产品的信心。