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) |
Account Management |
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.
|
Create and manage system-level accounts (admin, service, maintenance); enforce least privilege and disable inactive accounts; integrate with IdP where applicable. |
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) |
Account Management |
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.
|
Manage the underlying infrastructure, operating system, and security configurations required to support customer accounts, including system-level resource allocation and protection. This ensures the foundational platform is secure and available for the customer to perform all mandated user-level account administration and access enforcement. |
| AC-3 |
Access Enforcement |
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. |
Implement role-based access controls (RBAC) on Procore systems; enforce policy through IAM, console permissions, and MFA; verify access prior to granting privileges. |
AC-5(a),
AC-5(b) |
Separation of Duties |
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. |
Assign distinct roles for system administration, security operations, and compliance; enforce through IAM group policies. |
| AC-6 |
Least Privilege |
It is the customer's responsibility to define PfG access authorizations to support the principle of least privilege within their organization. |
Restrict Procore staff access to only the resources required for operational duties; regularly review elevated privileges; enforce just-in-time access for sensitive actions. |
AC-8(a),
AC-8(b) |
System Use Notification |
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. |
Display login banners on Procore systems notifying of authorized use only, per FedRAMP and agency guidance. |
AC-19(a),
AC-19(b),
AC-19(5) |
Access Control for Mobile Devices |
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) |
Authorization |
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.
|
Obtain and Maintain FedRAMP ATO. Ensure the SSP, SAP, SAR, and POA&M remain current; notify the PMO and AO of significant changes or incidents. |