セキュリティ保証要件.
CC は、評価結果の信頼性を担保するための数多くのセキュリティ保証要件を規定している。
必要なセキュリティ保証要件を個別に指定するのは煩雑であるばかりでなく、その正当性を検証するのも大変である。
そこで、標準的なセキュリティ保証要件の組がいくつか定義されており、保証パッケージと呼ばれる。
保証継続.
評価・認証済み製品をバージョンアップする際、軽微な変更なら必ずしも再評価（差分評価）せずに、同等の保証が維持されていることを判定できれば効率がよい。
共通評価基準であるコモンクライテリアに加え、スポンサー組織および委員会によって、評価結果が理解可能かつ比較可能にするための評価方法が開発された。
これは、評価機関が CC 評価を行うための最低限のアクションを記述している。
歴史.
起源.
CC は三つないし四つの標準を起源とする。
TCSEC の概念を基にしながら、より柔軟な枠組みをもち、民生品から政府専用製品まで幅広く評価・認証が行われた。
国家間での相互承認、機能主張と保証要件の分離、そして評価基準 ITSEC に加え評価方法マニュアル ITSEM の標準化など、いくつかの点で CC の枠組みの基礎となっている。
FC は、元々軍需用の TCSEC を、民需にも使いやすいよう ITSEC の内容も取り入れた改訂版として構想された。
統一.
CC は、これら既存の標準規格を統一することによって誕生した。
これにより、防衛機関や情報機関向けにコンピュータ製品を販売する会社は、製品セキュリティ標準の適合性評価を、一つの標準についてだけ評価を受ければ済むようになった。
この活動は CC プロジェクトと名付けられ、各々の評価基準を統一し、成果を ISO に提供することを目的とした。
国際規格化.
試行評価、公開審査、および ISO からのフィードバックを基に CC の大規模な改訂が行われた。
用語や概念の定義に齟齬や循環がある、評価作業に無駄な重複がある、抽象度の大きく異なる機能要件が混在している、保証要件として内容を評価すべきセキュリティ側面が機能要件として形式しか評価されない、などである。
ところが、特に機能要件は既存の PP の移植が困難な程の抜本改訂であったので、問題となった。
CCRA: コモンクライテリア承認アレンジメント.