The Auth Codes established for Contracts and Procurement can be divided into two sets:
-
-
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.
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.
