Security in Contracting Guide

1.0 Requirement

In accordance with the Policy on Government Security, and the various policies, directives and standards issued under it, contracts must include the appropriate security provisions, and suppliers and their personnel must have the required security screening and access permissions in place.

2.0 Overview

One of the main goals in security in contracting is the protection of personal information about Canadians. Protected information is pertinent to the department due to the data which is maintained under various programs such as the Canada Pension Plan, Employment Insurance and Old Age Security.
The information in this Guide provides key indicators in security screening, general guidance on security requirements for ESDC, and covers the roles and responsibilities of the ESDC Client Authority (Project Authority), CFOB Procurement Specialist (Procurement Specialist), ESDC Chief Security Officer (CSO) and its representatives/designates (e.g. Regional Security Offices or RSO), IT Security Coordinator, ESDC Personnel Security Officer (PERSEC), and the Contract Security Program (CSP), formerly Canadian Industrial Security Directorate (CISD), of Public Services and Procurement Canada (PSPC).

3.0 Key Indicators in Security Screening

Personnel Security Screening
A Personnel Security Screening is for individuals who are working under a contract who will or may require access to Protected or Classified information or assets or to secure work sites. Standard Reliability Status screening is the basic screening when duties require access to government information and assets, and unescorted access to Operations Zones in government facilities.
Designated Organization Screening (DOS)
A DOS is required for an organization to access contract opportunities at the Protected level. It allows an organization to obtain security screenings for their personnel at the Reliability Status level.
Facility Security Clearance (FSC)
An FSC is required for an organization to access contract opportunities at the Classified level in order to access classified information, assets and secure work sites. Note that an FSC does not include document safeguarding capability (as covered below). In some cases, an FSC is required before an organization may bid on a contract.
Document Safeguarding Capability (DSC
Organizations with a valid DOS or FSC that are required by contract to store and handle Protected and/or Classified information at their own work sites will require a DSC. An approved DSC for a contractor's site does not mean that they also have the physical or technical safeguards in place to adequately protect IT assets and ESDC information. A separate and specific DSC inspection or approval process must also take place for a supplier to be granted the Authority to Process IT, meaning the authority to work on sensitive documents on their electronic systems. The DSC is site-specific and is required for each of the work sites that an organization will be performing work with security requirements.
Authority to Process Information Technology (Authority to Process IT)
1. The Authority to Process IT is a designation that may be granted to organizations to allow them to store, process and/or transmit sensitive electronic data on their information technology systems for a specific contract.
2. A DSC or an Authority to Process IT is not required for contractor personnel who are using secure remote login such as AppGate, or for a contractor to work on non-sensitive documents. The Authority to Process IT is obtained through an organization screening process and by the completion of a successful inspection by an authorized IT security specialist.
Supplier Clearance
While not part of the TB security framework, Public Services and Procurement Canada (PSPC) performs supplier clearances and links personnel clearances with a particular supplier as part of their management practices for the CSP.

4.0 General Guidelines

Security Requirements Check List (SRCL)
1. All requisitions for contracts or standing offers that contain a security requirement must include a Security Requirements Check List (SRCL) (form TBS/SCT 350-103) and associated security guides/documents along with the appropriate security clauses.
  (Note: It is preferred that the Project Authority use either the common services SRCLs or the electronic SRCL as per the Security in Contracting - Quick Steps. The above link is provided for reference purposes as it has instructions on pages 5 to 14).
2. The Project Authority is responsible for completing the SRCL and to include IT security requirements in the Statement of Work (SOW).
3. For tips on completing an SRCL, see Annex A. Note that the SRCL form itself contains instructions.
4. See the Security in Contracting - Quick Steps for the process of completing, approving and distributing an SRCL.
9200 Requisition
When there is a security requirement for a contract to be awarded by PSPC, the Procurement Specialist must check "Security Provisions" and "SRCL required" boxes in SAP to ensure the security requirement question in the 9200 requisition is completed with a "yes" response.
No Security Requirements
If there are no security requirements then it is recommended that the purchase requisition (PReq) state in the SAP header text, "No Security Requirements."
IT Security Requirements
For IT related requirements, IT Security will provide an IT Technical Assessment with guidance and instructions for managing the requirement. This IT Technical Assessment contains instructions, which the contractor must follow, on the identification, proper use of the contractor's networks, accessing sensitive data, storage, and disposal of IT Media. The contractor will, when cleared, receive an "Authority to Process" letter, from the Contract Security Program (CSP) at PSPC, allowing the contractor to use its IT systems to process, handle and store ESDC's information.
Solicitation
1. When there are security requirements the solicitation documents must clearly state whether:
  - the security requirements must be met before solicitation closing date; or
  - the security requirements must be met before contract award.
  Note: ESDCs default position is that bid solicitations should indicate that security requirements must be met prior to contract award, not the solicitation closing date.
2. The Procurement Specialist should be fully aware of the time frames required for the appropriate security clearances to be granted, and whether or not the solicitation document will contain conditions or a time limit in which suppliers must obtain the required security clearance, following the solicitation closing date. The choice of such time frames must not unfairly discriminate between potential suppliers.
3. The completed SRCL must be attached as an annex to the solicitation, though the signature page may be omitted in order to keep suppliers from contacting the project authority during the solicitation stage.
Security Screening
1. If the supplier is not yet registered with the program then a Private Sector Organization Screening (PSOS) form will need to be completed. Please see the Security in Contracting - Quick Steps for more details on this process
2. If the selected bidder has not met the mandatory security requirements at time of contract award, and Canada cannot delay award due to operational requirements, Canada may declare that bidder non-responsive and award a contract to the next responsive bidder.
3. If the proposed personnel have the appropriate level of security but under a different supplier, the selected supplier needs to request from PSPC a transfer of the security level, known as "duplication".
  While awaiting this transfer, the Director of Corporate Security can approve an extension (typically 3 months) to allow PSPC time to complete it. Supplier personnel cannot have a higher level of screening than the supplier itself. For example, if the proposed person has a secret clearance with company A and he is working for company B who has a Reliability Status, he can only transfer the Reliability Status under company B.
Exceptions
1. For cases where the security must be obtained by bid closing, the Procurement Specialist should discuss with their procurement manager, noting that once the procedures are laid down in the solicitation, they cannot be changed after bid closing during the evaluation stage.
2. For exceptional cases, where the solicitation stipulates that the security must be met before contract award, and one may need to award a contract before the security clearance has been fully received, or other exceptions, discuss with the Regional Security Office (RSO) for their guidance on how to proceed. The Project Authority must advise the Procurement Specialist before proceeding with the work (or the award of the contract). Risk mitigation strategies are temporary arrangements to begin the work while the security requirements are being meet. Should the risk mitigation strategy permit an un-cleared resource to perform work as part of the contract, their roles and any limitation should be documented by Integrity Services and agreed upon by the Project Authority, the contractor and any applicable subcontractors. The Procurement Specialist must include such measures in the contract. The approval of these measures by both the RSO and the Project Authority are to be documented on the procurement file.
Contract Award
Once the Procurement Specialist confirms that the proposed contractor and all personnel requiring access to sensitive data or to departmental locations have the required security clearances, the Procurement Specialist may proceed with contract award, with the fully signed SRCL attached as an Annex.

5.0 Subcontracting

Where the contractor intends to subcontract some of the work to a subcontractor that will need access to Protected or Classified information or assets, then the contractor must first request approval to subcontract from the Project Authority. The subcontractor must meet the security requirements of the contract and obtain the appropriate security screening for its personnel prior to the subcontracting arrangements.

6.0 Roles and Responsibilities

Project Authority
The Project Authority is typically the fund centre manager responsible for the project. The roles and responsibilities of the Project Authority include:
1. determining the security requirements;
2. determining the required Level of Security Screening and Access Permissions in accordance with Appendix B of the Standard on Security Screening;
3. ensuring the IT security clauses are incorporated into the SOW;
4. informing the Procurement Specialist of any possible bidders that are not registered with CSP;
5. filling out the PSOS form and sending it to PERSEC;
6. completing and signing the SRCL. By signing, the Project Authority is acknowledging his/her role to ensure that the security requirements are respected by the contract and to confirm that the SRCL accurately reflects the security requirements of the work;
7. reviewing the final contract to ensure it meets the security requirements, and identifying any discrepancies to the Procurement Specialist;
8. managing all security aspects throughout the contract period;
9. ensuring throughout the contract period that all contractor or subcontractor personnel who will have access to any sensitive, Classified or Protected information, assets or departmental locations, or to government systems are identified as working under the contract, have been appropriately security screened, and have been verified with the Contract Security Program;
10. ensuring that the contractor organization and facilities, as applicable, meet the security requirements; and
11. taking privacy into account when making contracting decisions.
Procurement Specialist
The Procurement Specialist supports the Project Authority and facilitates the application of the security requirements by committing to ensure:
1. the SRCL is completed;
2. that, by signing the SRCL, the proposed personnel will be security cleared prior to contact award, and that the appropriate clauses will be included in the contract;
3. liaising with PERSEC to ensure that potential bidders identified by the Project Authority, not currently registered with CSP, are registered, and completes and signs the PSOS form when received from the project authority;
4. the appropriate security clauses are included in the solicitation and contract;
5. the security checks on the proposed contractor and personnel doing the work, who need a security clearance, are completed prior to contract award; and
6. the related security procedures and requirements are followed and appropriate security clearances are documented on file before contract award.
ESDC Chief Security Officer (CSO) or Designate (e.g. Regional Security Officer (RSO))
CSO/RSO is responsible for managing the departmental security program by:
1. ensuring that their department adheres to all security policies and standards;
2. reviewing the SRCL to ensure it reflects the Project Authority's security requirements as well as respecting the departmental security policy and signing the SRCL;
3. reviewing the SOW; and
4. supporting the Project Authority and contracting authority by identifying the relevant security clauses required (this item may differ by region).
IT Security
The IT Security Coordinator serves as the department's principal IT security contact and:
1. determines the extent of the IT security requirements;
2. produces an IT Security Assessment document;
3. provides recommendations for items to go in the SOW as per the IT Security Assessment document;
4. reviews the IT security related portions of the SOW and any related requirements documents;
5. recommends approval of all contracts for external providers of IT security services;
6. works closely with the Project Authority to:
  - ensure their IT security needs are met;
  - provide advice on safeguards;
  - advise of potential impacts of new and existing threats; and
  - advise on the residual risk of a program or service.
7. monitors departmental compliance with ITS standard and associated documentation.
The IT Security Coordinator, together with the Departmental Security Officer, ensures that physical, personnel and IT security stakeholders coordinate their efforts to protect information and IT assets and ensure an integrated, balanced approach.
PERSEC
PERSEC is responsible for:
1. signing the PSOS form, once completed, for proposed contractors not yet registered with CSP;
2. receiving requests from the Procurement Specialist for the verification of organization and personnel security levels specified in the Online Industrial Security Services (OLISS) database and providing the security confirmation of the proposed contractor and contractor personnel to the Procurement Specialist; and
Contract Security Program, PSPC
1. PSPC is the government authority responsible for ensuring compliance with Canadian and international security agreements, arrangements and memoranda of understanding (MOU), and providing advice and guidance to departments, contractors and potential contractors on the security requirements of contracts that involve access to government sensitive information and assets.
2. The role of CSP is to:
  - review the SRCL (when engaged) and the Request for Private Sector Organization Screening (PSOS) forms and any attachments which contain security provisions, such as the SOW, for accuracy, completeness, and authorized signatures;
  - complete security checks on suppliers and personnel when requested;
  - ensure, for potential international contracts, that the participating countries have the appropriate security MOU arrangements or agreements with Canada. If foreign-based suppliers are expected to bid, a list of the applicable country of origin should be provided to CSP, and the appropriate clauses related to foreign-based suppliers will be provided;
  - sign the SRCL form as the Contracting Security Authority and provide the applicable security clauses to ESDC when requested;
  - provide information to the Procurement Specialist on the security clearance of each potential bidder, contractor, or offeror, as applicable; and
  - provide to Canadian-based bidders, contractors, or offerors, information on the preparation and transmission of classified or protected information or assets.

7.0 Reference Documents

Employment and Social Development
Security in Contracting - Quick Steps

Chief Security Officer (CSO) Services

Summary of the revised Security Standard

Information Categorization Tool
Public Services and Procurement Canada

Industrial Security Manual

News and updates about contract security
Treasury Board

Policy on Government Security

Security and Contracting Management Standard

Standard on Security Screening

Guidance Document: Taking Privacy into Account Before Making Contracting Decisions

Operational Security Standard: Management of Information Technology Security (MITS)

Directive on Departmental Security Management

Annex A

General Tips on completing the Security Requirements Checklist (SRCL)

Box 11d is checked "yes" by the Project Authority when the contractor will need to work on protected or classified information on their own IT systems. Note that it is unlikely that, as per box 11e, that ESDC will have a fixed link (e.g. leased line) with a contractor site.
Box 13 is signed by the Project Authority.
Box 15 is checked "yes" or "no" by Project Authority. Unless there is a separate security requirement guide, this box is usually checked "no" by the Project Authority. The Project Authority then sends the SRCL and the SOW to the RSO as per the list of contacts below. Most requirements are managed by the RSOs, being delegates of the CSO.
See the list of contacts for RSOs.
See also NHQ Security Contacts.
Box 14 is signed by the appropriate RSO. (For national contracts, it is sent to the CSO for signature).
Box 14 will then also be signed by the Director of IT Security when there are IT security requirements.
Box 16 is signed by the CFOB Procurement Specialist in ESDC or, where PSPC is the contracting authority, Box 16 is signed by the PSPC Contracting Officer.
Where the Contract Security Program (CSP) of PSPC is involved in reviewing the SRCL, Box 17 is signed by the PSPC security authority. The signed SRCL is subsequently returned to ESDC, along with any legal clauses that need to be integrated into the contract.