C&P Auth Codes

The Auth Codes established for Contracts and Procurement can be divided into two sets:

Basic C&P Auth Codes
Package Specific Auth Codes

Basic C&P Auth Codes

Three basic C&P auth codes have been defined to group sensitive information as follows:

Auth Code Name	Description
Submitted Bid	Locks information submitted during the bidding process. (Applicable to information in SPF, but not SMat) This information includes priced data.
Internally Released Bid	Locks information for the purpose of bid reviews. This information is typically comprised of redacted information.
CP Sensitive Info	Locks internally generated sensitive information such as contracts, contract plans, Contract Approval Forms, Variations, Change Forms, and Payment Certificates.

Table 1: Sensitive Information Groupings define the Basic C&P Auth Codes

Package Specific Auth Codes

Package Specific Auth Codes are defined as new packages are awarded based on the name of the package.

Distribution of the Keys

Access to sensitive information is based on roles as shown in the matrix below:

Business Roles	User Account Auth Codes
HBJV procurement agent HBJV contracts formation SP HBJV C&P manager HBJV procurement manager HBJV expeditor HBJV Logistics HBJV VQMS HBJV Site Materials HBJV package coordinator HBJV area manager HBJV SPF Administration	Submitted Bid Internally Released Bid CP Sensitive Info
HBJV package engineer	Internally Released Bid CP Sensitive Info
HBJV discipline leads HBJV Project Services HBJV project director HBJV engineering manager HBJV Document Control BHP document controller BHP procurement manager BHP Procurement BHP Contracts BHP contracts manager BHP area manager BHP Project Services BHP project director BHP engineering manager BHP VP Projects BHP head of projects - C&P	CP Sensitive Info
Applicable to any of the business roles listed here	Package Specific Auth Codes

A report with the user distribution can be found here.

Note: It is recommended to open the report using the command Open in App and to refresh the data.

Securing Information

Going forward, commercially sensitive information should be restricted using the combination of one of the three basic C&P auth codes plus the package specific auth code. This ensures that access to information is based on: Organization plus Permission to Access Sensitive Info of the Group listed in Table 1 plus Permission to Access that Information for that Specific Package.

Practices

There are a few important practices that need to be observed to ensure that sensitive information is adequately secured:

Package Creation

As new C&P packages are created in SPF, a package specific auth code should also be created. The name of the auth code should match the name of the root package. Document stubs for CP-PLN, CP-CON, and CP-RFA should be created for the package. The stubs should be created associated to the appropriate package object within the package structure and each stub should carry the CP Sensitive Info auth code and the package specific auth code. While the package will be created by the SPF Admin team, the stubs are the responsibility of Document Control.

Package Award

As packages are awarded, the package delivery team must decide on which users will be handling sensitive information for the package. The team must file a support ticket with the SPF team listing all internal and external users that will need access to the sensitive information within the package. The admin team will then provide the internal users with the package specific auth code and the external users with both the package specific auth code as well as the CP Sensitive Info auth code.

C&P Documents

Documents other than bids, CP-PLN, CP-CON, and CP-RFA may be created within the package, including, but not limited to variations, change forms, and payment certificates. The C&P team should ensure to apply the Package Specific and CP Sensitive Info auth codes as this information is created within SPF.

Refer to the help material on Documents for specifics on the document creation and file upload processes.

Refer to the help material on Managing Auth Codes for specifics on how to add / remove auth codes from documents.

Changes to User Access

As users change over the course of the project, the delivery team can request changes to the assignment of auth codes. The SPF team will validate such requests through the package owner of the pertinent package specified within the pertinent Package Register. The delivery team can review auth code assignments with the report found here.

Note: It is recommended to open the report using the command Open in App and to refresh the data.

Bids

Bids are imported into SPF to facilitate the bid review process. Two auth codes are used to discern information as submitted (Submitted Bid) from information released for review by the package engineers (Internally Released Bid). In both cases, package specific auth codes are used to ensure that only users with access to bid information for the specific package can manage or review the bids. Users with access to all bid information can see both submitted bids and internally released information, while package engineers can review only the information that has been released.

Management of the auth codes is depicted below.

Refer to the chapter on Importing Bid Submissions for step by step instructions.

Limitation

The limitation of the established C&P Auth Codes is that users who have been provided with access to bids on one package must be provided with the same access to bids on all packages for which they have access. They cannot be provided with access to Internally Released Bids on one package and no access or access to Submitted Bids on others. Should a situation arise where this is a true requirement, additional auth codes will need to be discussed with the SPF administration team.