Common Criteria — ISO/IEC 15408 administered internationally under the Common Criteria Recognition Arrangement (CCRA) and operationalised in the U.S. by the National Information Assurance Partnership (NIAP), in Germany by the Bundesamt für Sicherheit in der Informationstechnik (BSI) under the German CC scheme, in France by the Agence nationale de la sécurité des systèmes d'information (ANSSI), and by the corresponding national schemes in Canada, the Netherlands, Japan, Korea, Australia-and-New-Zealand, and Singapore — is the product-security-evaluation standard that closes the gap between a self-asserted "secure-by-design" marketing claim and an independently-evaluated product-security-posture that procurement can rely on for the U.S. federal procurement regime under the Committee on National Security Systems Policy 11, the EU member-state procurement regimes that recognise CCRA-mutual-recognition certificates, the smart-card-and-secure-element supply chain, and any regulated buyer that anchors its product-security requirements against an externally-evaluated certified-products-list. The program is consulted by product-security-engineers and procurement leads at every federal-and-defense-and-regulated-industrial-buyer, and the question the program is consulted to answer is whether the supplier's product — the target-of-evaluation (TOE) inside the named security target — has been evaluated against the Common Criteria evaluation assurance level (EAL 1 through EAL 7) or against a NIAP-published collaborative-or-PP-conformant Protection Profile, and posted to the public certified-products-list with a current certification and a defined TOE-and-operational-environment boundary.
A customer who has just completed a Common Criteria certification cycle — selected the licensed-evaluation-facility, scoped the target-of-evaluation, written the security target document, completed the evaluation activities against the Protection Profile or the EAL package, received the certification report, and posted the result to the public certified-products-list — is a customer who is sitting on a twelve-to-twenty-four-month operational story that, if extracted correctly, becomes the testimonial that closes the product-security-evaluation question on the buyer's vendor risk assessment. This playbook is the interview-and-redaction protocol for that extraction.
Why the standard Common Criteria testimonial is procurement-illegible
The default Common Criteria testimonial reads "This product is Common Criteria certified" and procurement reads it as a marketing artifact. The procurement reader is looking for five specific pieces of information — the target-of-evaluation boundary the certification covered, the Protection Profile the evaluation conformed to (or the EAL package the evaluation targeted), the security functional requirements (SFRs) the security target document instrumented against, the licensed-evaluation-facility and the national-scheme certificate-issuing body, and the certified-products-list posting URL with the active-or-archived status — and the default testimonial supplies none of them. The buyer's product-security-engineer reads the default and forwards it to procurement with a note: no usable information, ask for the security target document and the certification report.
The Common Criteria certification testimonial that closes the product-security-evaluation question on the vendor risk assessment is a different artifact. It is short, specific, and instrumented against the program's EAL packages and Protection Profiles. It names the TOE-boundary, the Protection Profile or EAL package, the security functional requirements, the licensed-evaluation-facility and national-scheme, and the active certified-products-list URL, and it does so in the register the buyer's product-security-engineer and procurement lead use internally. The playbook below is the protocol that produces that artifact.
The post-certification interview battery
The five questions below are the post-certification interview battery. Run them with the customer's product-security-engineer, security-engineering-and-product-security lead, or platform-security-architect — not with the marketing counterpart, because the marketing counterpart will smooth the answers into marketing register and the marketing register is the register the buyer's product-security-engineer discounts.
Q1 — The target-of-evaluation boundary and Protection Profile question
When you scoped the Common Criteria certification, what target-of-evaluation boundary did the evaluation cover — which product components, which deployment configurations, and which exclusions — and did you target a Protection Profile conformance or a bare EAL package, and which EAL level (EAL 1 through EAL 7 or PP-conformant) did the certification reflect?
The TOE-boundary-and-Protection-Profile answer is the first artifact the buyer's product-security-engineer reads. The evaluation covered our product configured for the production deployment posture, with the target-of-evaluation boundary drawn around the customer-data-encryption-and-tls-termination subsystem, the customer-authentication-and-session-management subsystem, the customer-data-and-tenant-isolation subsystem, and the audit-logging-and-tamper-evident-storage subsystem; the marketing-website-and-self-service-portal and the internal-administrative-tooling were carved out of the target-of-evaluation and explicitly noted as out-of-scope in the security target document; we targeted Protection Profile conformance against the NIAP-published collaborative-Protection-Profile for the relevant product category at EAL 2 augmented, with the certificate reflecting the Protection Profile conformance claim and the augmentation-claim is the answer that lets procurement match the certification against the deployment the buyer is purchasing. Without the TOE-boundary and Protection Profile, procurement cannot rely on the certification, because procurement does not know whether the product surface the buyer is purchasing is inside the evaluated boundary and against which Protection Profile or EAL package the assurance is anchored.
Q2 — The security functional requirements and security target question
How did the security target document instrument the security functional requirements (SFRs) against the Protection Profile, which SFR families ended up in the security target, and which assumptions, organisational security policies, and threats did the security target enumerate?
The SFR-and-security-target answer is the second artifact procurement reads. The security target document instrumented the security functional requirements against the Protection Profile's required-and-optional SFR families — the FAU audit-and-accountability family, the FCS cryptographic-support family, the FDP user-data-protection family, the FIA identification-and-authentication family, the FMT security-management family, the FPT TOE-self-protection family, the FTA TOE-access family, and the FTP trusted-path-and-channel family — and added the augmentation-claim SFR refinements the Protection Profile required against our product's architecture; the security target enumerated the assumptions about the operational environment (the TOE runs in a physically-secured datacenter, the operator-administrator is non-hostile, the cryptographic-key-management-subsystem operates inside the FIPS 140-3 validated boundary), the organisational security policies (the audit log is reviewed at a defined cadence, the cryptographic-keys are rotated at a defined cadence), and the threats the TOE counters (the network-attacker, the privileged-insider-attacker, the unauthorised-tenant-attacker); the assumptions, OSPs, and threats together constrain the certification's applicability and the buyer's product-security-engineer reads them as the boundary conditions under which the certification holds is the answer that gives procurement the SFR-coverage picture and lets the buyer's product-security-engineer evaluate whether the security target matches the buyer's product-security-policy.
Q3 — The evaluation activities and assurance evidence question
What evaluation activities did the licensed-evaluation-facility execute against the security target, what evidence packages did you supply against the security assurance requirements (SARs), and which evidence packages ended up the longest to prepare?
The evaluation-activities-and-evidence answer is the third artifact procurement reads, and it is the answer the buyer's product-security-engineer relies on most heavily to triage whether the certification was a real-evaluation or a paper-exercise. The licensed-evaluation-facility executed the evaluation activities against the Protection Profile's evaluation-activities-and-supporting-document specifications — including the ATE_FUN functional-testing activities, the ATE_IND independent-testing activities, the AVA_VAN vulnerability-analysis activities at the augmentation-claim attack-potential, and the ADV_FSP-and-ADV_TDS architectural-design activities at the augmentation-claim depth — and we supplied the evidence packages against the security assurance requirements (the ASE security-target evaluation package, the ALC life-cycle-support package covering the configuration-management-and-flaw-remediation procedures, the ADV development package with the functional-specification-and-TOE-design documentation, the ATE testing package with the test-coverage-and-test-procedures documentation, and the AVA vulnerability-analysis package with the public-and-private-vulnerability-analysis); the AVA_VAN vulnerability-analysis package and the ALC_FLR flaw-remediation package were the longest to prepare because the augmentation-claim raised the attack-potential against which the vulnerability analysis had to demonstrate resistance and the flaw-remediation procedures had to demonstrate the post-certification vulnerability-disclosure-and-response cadence is the answer that tells procurement the certification was a real-evaluation against substantive evidence, not a paper-exercise on top of marketing claims.
Q4 — The CCRA mutual-recognition and national-scheme question
Under which national-scheme did the certificate issue, does the certificate fall under CCRA mutual-recognition or only the issuing-scheme's recognition, and how does the buyer reconcile the certificate against the buyer's national-procurement-requirements?
The CCRA-and-national-scheme answer is the fourth artifact procurement reads, and it is the answer the buyer's product-security-engineer uses to determine whether the certificate transfers to the buyer's procurement context. The certificate issued under the NIAP-and-NSA U.S. national-scheme with the licensed-evaluation-facility operating under NIAP-licensure, the certificate falls under CCRA mutual-recognition up to the EAL 2 augmentation-claim ceiling that the CCRA recognises across all member-nations, and the certificate is consequently honoured by the U.S. federal procurement regime under CNSSP-11 and by the EU member-state procurement regimes that recognise CCRA-mutual-recognition certificates; the buyer's product-security-engineer reconciles the certificate against the buyer's national-procurement-requirements by matching the CCRA-mutual-recognition ceiling against the buyer's required-assurance-level, and where the buyer's required-assurance-level exceeds the CCRA-mutual-recognition ceiling the buyer's product-security-engineer documents the supplementary national-scheme certificate the buyer requires is the answer that tells procurement how the certificate transfers across national-procurement-regimes.
Q5 — The certified-products-list posting and assurance-continuity question
Where on the public certified-products-list does the certificate appear, what is the certificate's active-or-archived status, what is the certification date and the assurance-continuity expiration date, and what assurance-continuity maintenance has the product undergone since certification?
The certified-products-list-and-assurance-continuity answer is the fifth artifact procurement reads. The certificate is posted to the public NIAP product-compliant-list at the niap-ccevs.org product-compliant-list landing-page and cross-referenced on the international Common Criteria portal certified-products-list, the certificate's status is the active-certified status (not the archived status) with the certification date in a specific quarter and the assurance-continuity expiration date two years from the certification date in line with the NIAP assurance-maintenance-program; the assurance-continuity record shows the product-version updates the licensed-evaluation-facility has reviewed and assurance-continuity-certified since the original certification, with the most recent assurance-continuity certificate reflecting the current shipping-product-version; the testimonial cites the certificate identifier, the active-status, the certification date, the assurance-continuity expiration date, and the public NIAP product-compliant-list landing-page URL, and the trust-center landing-page hosts the certificate badge alongside the SOC 2 and ISO 27001 badges is the answer that closes the certificate-posting question and lets the buyer's product-security-engineer reconcile the testimonial against the public certified-products-list.
The 3-pass redaction workflow
The raw transcript from the five-question battery is not the testimonial. It is the raw material. The redaction workflow below turns the raw material into the testimonial that lands on the procurement page.
Pass 1 — strip the evaluation-internal observations. The raw transcript will include observations the licensed-evaluation-facility flagged during the evaluation activities that the customer remediated under the evaluation-facility's corrective-action-window and that the public certification report does not surface. Strip the observation text from the public testimonial, because the public testimonial cannot disclose evaluation-internal-corrective-action detail, and replace it with the public certification report's clean-certification summary. Keep the corrective-action workflow in the NDA-version of the testimonial that lives in the procurement-NDA-package, because the corrective-action workflow is the artifact the buyer's product-security-engineer asks about under NDA.
Pass 2 — surface the security target document and Protection Profile cross-reference. The raw transcript will narrate the security target document and the Protection Profile conformance claim in conversational form. Surface them in the testimonial as a structured artifact — the security target document URL, the Protection Profile reference, the security functional requirements table, the assurance-continuity record, and the active certified-products-list landing-page URL — because the structured artifact is what the buyer's product-security-engineer reads, not the conversational form. The structured artifact is also what makes the testimonial procurement-legible against the buyer's vendor risk worksheet.
Pass 3 — close the placement. The redacted testimonial does not belong on the marketing landing page. It belongs on the trust-center landing page next to the publicly-accessible certified-products-list landing-page URL, in the procurement-NDA-package next to the security target document and the assurance-continuity record, and in the sales-enablement battle-card next to the Protection Profile cross-reference and the SOC 2 and ISO 27001 cross-mapping artifact. The placement is the decision that determines whether the testimonial closes the question on the vendor risk worksheet or whether procurement asks for the security target document and ignores the testimonial.
How this fits the procurement-supplier-attestation testimonial series
This playbook is the Common Criteria ISO/IEC 15408 certification extension to the procurement-supplier-attestation testimonial series. The series covers the regulated-attestation conversations a procurement-supplier customer has with their buyer's product-security-engineer, vendor risk team, and information-security-and-cloud-governance lead. The series so far includes the SOC 2 Type II attestation conversation playbook, the ISO 27001 ISMS certification conversation playbook, the FedRAMP authorization attestation conversation playbook, the CSA STAR cloud security alliance certification attestation conversation playbook, the CMMC cybersecurity maturity model certification attestation conversation playbook, and the FIPS 140-3 cryptographic module validation attestation conversation playbook. The Common Criteria playbook closes the product-security-evaluation question that the SOC 2, ISO 27001, FedRAMP, CSA STAR, CMMC, and FIPS 140-3 playbooks reference but do not evaluate at the target-of-evaluation-and-Protection-Profile level. Use the playbooks together — the cross-mapping spreadsheet that emerges from running all the interviews is the single document that closes the product-security-evaluation question on the buyer's vendor risk worksheet for procurement-supplier customers that need to satisfy the federal-and-defense-and-regulated-industrial product-security requirements in a single conversation.
The testimonial that closes the procurement-supplier and product-security-evaluation question is the testimonial that names the TOE-boundary and Protection Profile, surfaces the security functional requirements and the evaluation activities, and reconciles against the active certified-products-list posting. The playbook above is the protocol that produces it.