Procore for Government (iOS)

AC-2(a), AC-2(b), AC-2(c), AC-2(d), AC-2(e), AC-2(f), AC-2(g), AC-2(h), AC-2(i), AC-2(j), AC-2(k), AC-2(l)

The customer is exclusively responsible for Company Account Management within PfG. Upon signing a contract, the customer must create an account using an email address and appoint an Administrator. Access to PfG is tightly controlled through customer-defined user groups, which are composed of fine-grained permissions (e.g., hiring manager, recruiter, administrator groups).

The customer must establish conditions for group and role membership and is responsible for creating, managing, modifying, disabling, and removing subsequent accounts for individual users, vendors, and partners in accordance with their organizational policies and procedures. The customer is responsible for authorizing access based on valid authorizations, intended system usage, and other attributes defined by the organization.

Finally, the customer bears the full responsibility for monitoring and auditing account activity, including:

• Performing reviews of user accounts against organizational requirements at least annually.

• Developing and implementing processes to ensure they are notified of application account changes (termination/transfer/need-to-know changes) within strict timelines (e.g., 24 hours when accounts are no longer required, 8 hours when users are terminated or transferred).

• Aligning account management processes with organizational personnel termination and transfer procedures.

AC-2(1), AC-2(4), AC-2(5), AC-2(7)(a), AC-2(7)(b), AC-2(7)(c), AC-2(7)(d), AC-2(9), AC-2(12)(a), AC-2(13)

The customer holds the sole responsibility for the lifecycle and security management of all PfG user accounts within their tenancy, adhering to their organization's policies.

• Account Creation and Administration: The customer is responsible for creating PfG accounts for individual users (including vendors and partners), and must establish and administer all user accounts—particularly privileged accounts—in accordance with the organization's role-based access scheme. They are also responsible for establishing the process for reissuing shared and group account credentials when individuals are removed from the group.

• Account Maintenance and Lifecycle: The customer must modify, disable, and remove accounts, including those for privileged users, in accordance with their organizational policies and procedures. They are encouraged to utilize automated mechanisms to support these management functions.

• Monitoring and Control: The customer is fully responsible for monitoring the use of all their PfG accounts. This includes monitoring the use of administrator accounts and monitoring account enabling, disabling, and removal actions within the application.

• High-Risk Incident Response: The customer must follow their internal process for incident handling and reporting and is specifically responsible for disabling accounts for individuals determined to pose significant risks to their organization within 1 hour.

• Session Management: The customer is responsible for requiring users to log out according to their internal access control policy.

AC-3

The customer is responsible for establishing and maintaining the logical access policy, defining user roles and privileges (like ensuring least privilege and separation of duties), and actively assigning and managing those roles to the personnel.

AC-5(a), AC-5(b)

The customer is responsible for defining and documenting Separation of Duties (SoD) for individuals authorized to access the PfG application within their organization. Access control is implemented by the customer through custom roles designed to ensure SoD is enforced.

AC-6

It is the customer's responsibility to define PfG access authorizations to support the principle of least privilege within their organization.

AC-8(a), AC-8(b)

When using identity federation and Single Sign-On (SSO) to log into PfG, the customer is responsible for ensuring that their Lightweight Directory Access Protocols (LDAP) and/or Active Directory (AD) systems display a compliant system use notification message or banner. Furthermore, the customer must ensure the notification message or banner meets FedRAMP requirements and remains on screen until users acknowledge the usage conditions and take explicit action to log on or further access the system.

AC-19(a), AC-19(b), AC-19(5)

For the Procore for Government Mobile App, the customer bears responsibility for enforcing all mobile device policies (including those applicable to their subcontractors) to ensure responsible use.

CA-6(a), CA-6(b), CA-6(c), CA-6(d), CA-6(e)

The federal customer, or agency, operating within the Procore for Government environment holds the final responsibility for Authorizing System Operation.

This involves:

• Designating the Authority: Each customer is responsible for designating its own Authorizing Official (AO).

• Risk Acceptance and ATO: The AO reviews the results of the security assessment (issued in the Security Assessment Report, or SAR), examines the Plan of Action and Milestones (POA&M), and determines if the remaining known vulnerabilities pose an acceptable level of risk to agency operations before issuing an Authority to Operate (ATO).

• Change Review: The customer AO is also responsible for reviewing any significant changes proposed by Procore, and subsequently reviewing and approving any updates to FedRAMP package based on additional testing by the 3PAO.

IA-2(1), IA-2(12)

The customer is responsible for selecting an Identity Provider (IdP) that supports Multi-Factor Authentication (MFA), including support for hardware-based smartcards like the Personal Identity Verification (PIV) card or Common Access Card (CAC). Agency customers who are required to use these hardware smartcards are responsible for integrating the PIV card or CAC with the Procore for Government environment, typically by using identity federation through SAML (Security Assertion Markup Language) with their Single Sign-On (SSO) capability.

IA-4(a), IA-4(b), IA-4(c), IA-4(d)

The customer is responsible for approving access before provisioning unique user IDs to its user base. Specifically, the customer must ensure that user IDs are assigned to individuals in a secure manner and are prevented from being reused for at least two years.

IA-5(a), IA-5(b), IA-5(d), IA-5(f), IA-5(g), IA-5(h), IA-5(i), IA-5(1)(a), IA-5(1)(b), IA-5(1)(c), IA-5(1)(d), IA-5(1)(e), IA-5(1)(f), IA-5(1)(g), IA-5(1)(h), IA-5(6)

The customer is responsible for approving access before provisioning unique user IDs to its user base. Specifically, the customer must ensure that user IDs are assigned to individuals in a secure manner and are prevented from being reused for at least two years.

• Credential Setup and Distribution: The customer is responsible for establishing the initial authenticator content and verifying user identity before distributing user IDs and temporary passwords to their user base. They must also establish and implement administrative procedures for initial authenticator distribution; for lost, compromised, or damaged authenticators; and for revoking customer authenticators.

• Password Configuration and Strength (IA-5): Customers are responsible for configuring the customer application user's password requirements in accordance with their agency's guidelines. They must allow user selection of long passwords and passphrases (including spaces and all printable characters) and employ automated tools to assist the user in selecting strong password authenticators.

• Compromised Password Management: The customer is responsible for maintaining and updating a list of commonly used, expected, or compromised passwords, and for verifying that new or updated passwords are not found on this list.

• Security and Transmission: When using their own Identity Provider (IdP), the customer is responsible for protecting their IdP authenticator content from unauthorized disclosure and modification, and for transmitting and storing only encrypted authenticators.

• Session and Account Management: Customers are responsible for configuring the password expiration policy for their own agency, configuring the session timeout duration, and the permitted amount of unsuccessful logon attempts. Additionally, they must require the immediate selection of a new password upon account recovery and require individuals to take specific security safeguards to protect any authenticator they configure via their own IdP.

IA-8, IA-8(1), IA-8(2)(a), IA-8(2)(b), IA-8(4)

Customers are responsible for ensuring that passwords are obfuscated during the authentication process to protect the information from possible exploitation or use by unauthorized individuals.

IA-8, IA-8(1), IA-8(2)(a), IA-8(2)(b), IA-8(4)

The customer is responsible for integrating the Procore for Government accounts with their agency's Single Sign-On (SSO) capability using their Identity Provider's (IdP) identity federation.

For agency customers mandated to use a hardware-based smartcard, the system supports integrating this card (such as a PIV card or CAC) with SSO through SAML identity federation. The customer holds the responsibility for successfully completing the integration of the PIV card or CAC with the Procore for Government environment.

IA-11

Customers are responsible for configuring their Identity Provider (IdP) to ensure users are re-authenticated following periods of inactivity and to strictly enforce mandatory session timeouts as required by security policy.

IR-6(a), IR-6(b)

The customer is responsible for reporting all suspected security incidents or system events to Procore via email at security@procore.com.

Additionally, Federal government customers must adhere to their separate reporting obligations, which include reporting incidents to CISA as required by OMB Memo M-07-16.

IR-9(b)

Customers are responsible for identifying the specific information involved in the information system contamination and for notifying Procore of potential information spillage within their tenant environment via established communication methods within the cloud service agreements.

RA-2(c)

Each government customer utilizing the PfG system is responsible for designating an AO. The AO must review the SSP, which includes the determined security categorization, as part of the FedRAMP package for the PfG system and authorize the system for their organization's use.

SA-4(10)

Customers can integrate PfG with their SSO through SAML 2.0. Customers are responsible for using only PIV or CAC credentials that are on the FIPS 201-approved product list.