TrustCB apply a set of Shared Scheme Procedures for those aspects of Certification Body procedures that are common across the certification schemes operated by TrustCB. For each scheme, a scheme-specific procedure is provided to refine and specify how the Shared Scheme Procedures are to be applied to the given scheme, and to defined any scheme-specific rules. The Shared Scheme Procedures can be downloaded from this webpage.  The procedures relating to a given scheme can are located on the webpage relating to that scheme.

The Terms and Definitions used within the TrustCB procedures and templates are consistent with those used within the applicable Scheme. The schemes operated by TrustCB are based on ISO/IEC 15408 (Common Criteria), so that terminology is used.

For ease of reference the commonly-used terms and the phases of certification are defined here:

Terms and Definitions
Developer The organisation that has primary responsibility for the development and maintenance of the TOE.
Typically, the Developer is also the Sponsor.
Sponsor The entity paying for the certification process and that gets usage rights for the certificate.
In ISO/IEC 17065, the Sponsor is commonly referred to as “customer”.
Quality Supervisor The individual within TrustCB who has day-to-day responsibility for monitoring the application of, and adherence to, the Quality Management System (QMS).
Evaluator An evaluation facility licensed by TrustCB. The evaluation facility must be an ISO/IEC 17025 accredited (or equivalent) laboratory specialised in the field of IT Security Evaluation.
For Common Criteria evaluations, such a laboratory is referred to as an Information Technology Security Evaluation Facility (ITSEF).
Certifier TrustCB, or (depending on context) an individual within TrustCB who is assigned to a specific certification task.
Target of Evaluation (TOE) The IT entity to be certified, used in a specific manner. This includes:

  • a specified version of a product that is to be used in a specified deployment
  • a site used for specified activities during the product lifecycle (such as development, manufacturing, and despatch)
  • a Protection Profile to be used in product evaluation activities.
User The User of the certificate; for example, the User of an e-Passport would be the government issuing the e-Passport.
Application Form The document submitted by the Sponsor (in cooperation with an Evaluator) to request Certification activities.
Application (verb) The act of submitting the Application Form (document).
Certification Agreement The contractual agreement between the Sponsor and TrustCB for the performing of certification activities in relation to the specified TOE.

The phases of certification are as follows:

Phases of certification
Submission Phase The initial phase, which commences with the initiation of TrustCB involvement and ends when the Evaluation Review Phase commences.
This phase includes all activities associated with the generation and delivery of the Application Form by the Sponsor and the processing of the Application Form by TrustCB, resulting in either acceptance of the application by TrustCB and an agreed contract for certification activities, or rejection of the application.
Evaluation Review Phase The phase where the TrustCB certifiers oversee the Evaluator:
The transition from Submission Phase to Evaluation Review Phase is receipt by TrustCB of (a commitment to) payment from the Sponsor.
This phase is made up of the Certifier review of each verdict reached by the Evaluator, to endorse or query the evaluation verdict.
Certification Phase The phase where the evaluation tasks have finished successfully and the certificate is being issued:
The transition from Evaluation Review Phase to Certification Phase is Certifier endorsement of all Evaluator verdicts relating to the specified certification activity.
During this phase, the certification artefacts are generated by the Certifier. This includes the generation of the Certification Report, which records the certification decision and, where applicable, the generation of the certificate.

TrustCB defines — and protects materials according to — three levels of confidentiality, as described here:

Levels of confidentiality
Public Public information is already in the public domain. Confidentiality of this information does not need to be protected by TrustCB. We do, however, pay attention to the active publication of such information. In particular, information that previously was secret should not be published if it has become public without permission from its owner. Typically treated as Public: Scheme procedures, published certificates, and associated documents (such as Security Targets).
Sensitive/Confidential Sensitive/Confidential information should not be made public. Protection against that occurring is achieved by means such as online services, which have a reasonable expectation of protection against accidental disclosure or intentional breach by an attacker with low attack potential. Examples of such services are Dropbox, and Apple iCloud services, (unencrypted) e-mail such as the content of TrustCB.com e-mail accounts, and Google Cloud services such as Calendar and Drive.
Typically treated as Sensitive/Confidential: Certification Identifier and product (code)names prior to publication of the certificate, procedural and progress updates, calendar entries, non-secret questions and discussions, applications/offers/purchase orders/invoices, information disclosed about customer and related products not already in the public domain, and internal TrustCB procedures.
Secret Information shall be labelled Secret if disclosure could result in serious harm to reputation, access to high-value assets, or a destabilising financial impact to an organisation. Secret information must be available only in plain text form on permanently-offline systems. All Secret information must be decrypted/encrypted on these permanently-offline systems with sufficiently-strong encryption. The decryption key shall be available only on these permanently-offline systems, and protected with a strong passphrase. PGP/GPG with at least 4096-bit RSA keys shall be used at the TrustCB side. The PGP/GPG keys of other, non-TrustCB, side should be at least 2048 bits. All permanently-offline systems shall use full disk encryption and encrypted containers to protect data at rest and isolate client data. Microsoft BitLocker, MacOS FileVault, PGPDisk or TrueCrypt/VeraCrypt shall be used with a strong passphrase.
As secret information can only be available in plain text form on a permanently-offline system, all secret information shared via email must be shared as an encrypted attachment (not encrypted email body) to enable the data to be encrypted in a package offline and then transferred to an online machine for transmission, and vice versa.

In the event that a TrustCB customer has a complaint against any aspect of TrustCB’s work or wants to appeal against a decision made by TrustCB or raise an issue concerning the operation of TrustCB, the customer is encouraged to raise the concern with the customer’s point of contact in TrustCB. This will enable the concern to be investigated and resolved. The TrustCB point of contact will acknowledge receipt of a complaint/appeal and will keep the customer apprised of progress.

The following details should be provided to the customer point of contact for any complaint or appeal raised:

  1. Certification ID of related task
  2. Reason for compliant/appeal
  3. Supporting evidence for complaint/appeal

A third party within TrustCB shall be assigned to collect information about the concern, review it, and then form an objective, independent and fair judgement on any claim or appeal filed. TrustCB shall provide formal notice of the outcome and end of the process to the complainant/appellant.

If, however, the customer is unsatisfied with the response and wants to escalate the concern, the customer is at liberty to raise the issue to a higher level in the Scheme’s chain of command and, if necessary, up to the CEO of TrustCB.

Ultimately, any customer who still feels that the issue has not been addressed sufficiently can escalate the concern to the Advisory Board of TrustCB.

To escalate a concern to the Advisory Board, please complete the following information clearly and concisely and then send it to [email protected]:

Certification ID of related task
Name of customer point of contact
Customer point of contact Details (including telephone number and e-mail address)
Name of TrustCB point of contact
Details of original complaint/appeal
Submission date of complaint/appeal
Date of complaint/appeal response from TrustCB
Reason for escalation of issue
Supporting evidence for escalation

In the event that a TrustCB point of contact has not been assigned or the complaint is on a different aspect of TrustCB operation, please complete the following information clearly and concisely and then send it to [email protected] :

  • Name and company
  • Contact details (email or phone, as preferred)

TrustCB defines — and protects materials according to — three levels of confidentiality, as described here:

Levels of confidentiality
Public Public information is already in the public domain.

Confidentiality of this information does not need to be protected by TrustCB. We do, however, pay refrain from active publication of such information unless it is explicitly intended for publication by us. In particular, information that previously was secret should not be published if it has become public without permission from its owner.

Typically treated as Public: Scheme procedures, published certificates, and associated documents (such as Security Targets).

Sensitive/Confidential Sensitive/Confidential information should not be made public, but the impact is limited if it were to happen (including evidence for Knowledge of the TOE below or at Restricted level, typically translating to enabling an attack potential of ≦AVA_VAN.3/EAL4/SESIP3/PSA Level 2).

Protection against that occurring can be achieved by means such as commercial online services, which have a reasonable expectation of protection against accidental disclosure or intentional breach by an attacker with low attack potential. Examples of such services are Dropbox, Google Cloud and Apple iCloud services, (unencrypted) e-mail such as the content of TrustCB.com e-mail accounts, and remote conferencing solutions like Hangouts, Webex, and Skype for Business.

Typically treated as Sensitive/Confidential: Certification Identifier and product (code)names prior to publication of the certificate, procedural and progress updates, calendar entries, non-secret questions and discussions, applications/offers/purchase orders/invoices, information disclosed about customer and related products not already in the public domain, and internal TrustCB procedures.

Secret Information shall be labelled Secret if disclosure could result in serious harm to reputation, access to high-value assets (including those of Knowledge of TOE of Sensitive and higher, or enabling attacks at AVA_VAN.4/EAL5/SESIP4 or higher, including MIFARE), or a destabilising financial impact to an organisation.

Secret information must be available only in plain text form on permanently-offline systems.

All Secret information must be decrypted/encrypted on these permanently-offline systems with sufficiently-strong encryption. The decryption key shall be available only on these permanently-offline systems, and protected with a strong passphrase. PGP/GPG with at least 4096-bit RSA keys shall be used at the TrustCB side. The PGP/GPG keys of other, non-TrustCB, side should be at least 2048 bits. All permanently-offline systems shall use full disk encryption and encrypted containers to protect data at rest and isolate client data. Microsoft BitLocker, MacOS FileVault, PGPDisk or TrueCrypt/VeraCrypt shall be used with a strong passphrase.

As secret information can only be available in plain text form on a permanently-offline system, all secret information shared via email must be shared as an encrypted attachment (not encrypted email body) to enable the data to be encrypted in a package offline and then transferred to an online machine for transmission, and vice versa.