The guidelines provided in this article are dated April 8, 2024 and therefore reflect Pigment features as of this date.

This article contains an overview of Pigment features and recommendations for customers who might want to use Pigment as an environment subject to Sarbanes-Oxley (SOX) Compliance. It is not intended to be an exhaustive guideline and any questions can be directed to Pigment through your CSM or Pigment Support.

It is the responsibility of the customer, and not of Pigment, to own the set of policies and procedures when using Pigment to ensure compliance with SOX.

Customer responsibility

The Customer is responsible for the following:

managing user access rights, including design of the access control and privilege matrix according to the business roles, attribution of appropriate roles to users, access requests approval workflows, terminations and role changes.
performing periodical access reviews.
selecting the appropriate authentication methods amongst those offered by Pigment, performing password controls such as password robustness, password sharing, password reuse or password compromise.
the deployment and management of MFA.
selecting the appropriate data center location amongst those offered by Pigment.
the performance of change management activities pertaining to the User Entity's use of Pigment. This includes testing of changes or releases in their Pigment environment (data, models, formulas, Boards, etc.) and the performance of User Acceptance Testing pertaining to those changes.
the ingestion, long term storage, event correlation and alerting of activity logs produced by Pigment.

For more details, please refer to our SOC2 Complementary User Entity Controls (CUECs) document/report, available in the Pigment Trust portal (https://trust.pigment.com/).

Program and data access

There are two steps for managing Member access to Pigment:

First, a Member needs to login and be assigned an Account Type at Workspace level.
Next, the Member is granted a Role in each individual Application to access the Boards and reporting.

The following Pigment features are available to customers in order to manage their Member access:

Workspace level:

SSO: Pigment supports SAML 2.0 Single Sign-On. Contact Pigment to set up SSO on a Pigment Workspace. Alternatively, it’s possible to set up Pigment with a login and password.
Export Members to CSV: Exports a list of all Members with access to Pigment at Workspace level, and their status (active / inactive).
Audit Logs API: This feature provides logs detailing Member activity that’s related to access changes.
Workspace-level Account Types: This Account Type is a Workspace-level role that determines the permissions a user is able to use across the Pigment Workspace.

Application level:

Export User Roles metric per relevant app as CSV: Generates a list of all Members with a Role in the Application.
Application, Block and Item History UI: Displays specific modifications, with both previous and current values, which can be filtered on a precise date for the impacted Application role. It’s recommended to take a screenshot of these values for reference later.
Roles and Permissions UI: Use this to view what each Role is able to do in Pigment at Application level. It’s recommended to take a screenshot of these values for reference alter.

Access recommendations for customers

Access Traceability. For overall management of Member access in Pigment, you should implement processes with tooling, for example a ticketing tool, to ensure there is traceability of Members with access to Pigment, and the reasons they have been assigned access. You can also demonstrate to auditors that SSO is enabled for their Workspace.
Pigment Member Access Information. To gather information related to Member access, you can use a combination of UI exports, audit logs, and screenshots of audit trail and access rights screens in the Pigment UI.
Pigment Member Information. To obtain a list of Pigment Members, you can export this information directly from the Pigment UI:
1. At the Workspace level, you can export a list of Members with the following Member information: Name, Account Type, Status (active / inactive). See here for more details.
2. At Application level, for each relevant Application, you can export the Users role Metric with user name and Role in CSV format. See here for how to download data from a Metric.
Audit Log - Member Details. The Pigment Audit Logs API has a 180-day lookback period. We recommend ingesting the audit logs for at least a full year into a separate system in case the auditor requires logs for a longer period than 180 days.
1. The audit log functionality in Pigment allows customers to provide the following information for users at both the Workspace and the Application level:
  1. the invitation date of the user at Workspace level
  2. date of any Account Type assignment modification
  3. name of Member that invited a new Member to Pigment
  4. last connection date of the Member to Pigment
2. It’s strongly recommended to refer to the Audit Logs API documentation to fully understand all the events that can be tracked in audit logs, and how to call the API.
Application History - Application Details. Using the Application History and screenshots, you can obtain additional information at Application level:
- last Role assigned and the history of Roles assigned to a Member to the Application
- the user who created the Role in the Application
- date of any Role modifications
Roles and Permissions page. It’s recommended that you take screenshots of the Roles and Permissions page showing what each existing Role can do in Pigment.
In order to get details on access rights, depending on the level of detail needed, you can take a screenshot of either:
- the rules setup
- View Detailed Access by Member screen This is specifically for an area of interest in the Application. For example, for a particular View for a Block displayed on a Board.

Change management (editor environment)

Pigment’s SOC1 report covers this section, which is available in the Pigment Trust portal (https://trust.pigment.com/). The controls relevant to this section are: 5.1, 5.2, 5.3.

Change management (client environment)

Pigment provides the following features related to change management in model updates.

Test and Deploy. Track all structural changes in Dev, Test, and Prod environments at Workspace-level, and track any changes pushed into a Production Workspace. Take screenshots of any changes pushed into Production with a record of requests on those effected changes, for example a ticket.
Application, Block and Item History UI. Displays specific modifications, with both previous and current values, which can be filtered on a specific date or the area of the impacted model. For example, Blocks displayed as widgets on the Board. It’s recommended to take a screenshot of these values for reference later.
Export Boards to PDF. Customers can use this to share changes were made according to the request.
View configuration setup UI. This UI includes Calculated Items, Filters, Show Value As, and Page Selectors on Views. It’s recommended that customers take a screenshot of these changes, as it proves that any changes were made according to request.
Formula bar UI on the Block. It’s recommended that customers take a screenshot of the formula bar UI in addition to screenshots of the Application, Block and Item History UI filtered on formula updates.
Snapshots. Customers can save a frozen record of the Application, and all of its configurations at a specific time. This ensures that financial data reported from the Application has not been altered.

Change Management Recommendations for Customers

Change Request Traceability. For oversight of change management, customers should implement a specific change management monitoring or control process. For example, a ticketing system to record all requests for changes to the model within the Pigment Workspace or Application.
Traceability Resources in Pigment. Customers should be aware of the different levels of historical traceability available in Pigment depending on where changes are made at which level in their Pigment model:
1. Workspace-level model changes. These include formula updates, model structure and architecture updates:
  - Can be tracked through Test & Deploy with screenshots. Granular-level changes are not tracked. That is, if a value was updated in a workflow, the old value compared to the new value won’t be tracked.
  - Audit logs track all changes, and the Member responsible for the change. However, the details of the old value and new value of the change aren’t tracked.
2. Application-level model changes. These include formula updates, updates to values at cell-level through inputs, model structure changes, and imports.
  - Audit logs track all changes, and the Member responsible for the change. However, the details of the old value and new value of the change aren’t tracked.
  - The Application section in History displays all changes, and the Member responsible for the change. It also includes details of the old value and new value of the change.
  - It’s recommended that customers take a screenshot of the configuration page before and after the change is made. This is the most complete way to record changes.
3. View-level changes. These impact how the data is visualized on a Board or on a Block, for example Calculated Items, Filters, Show Value As, Page Selectors.
  - Audit logs track all changes, and the Member responsible for the change. However, the details of the old value and new value of the change aren’t tracked.
  - No tracking is available in the Application section in History.
  - It’s recommended that customers take a screenshot of the configuration page before and after the change is made. This is the most complete way to record changes.
4. Application Variables: No tracking is available. It’s recommended that customers take a screenshot of the configuration page before and after any changes are made. This is the most complete way to record changes.
Modeler Tracking. Every time a model change request is submitted through the ticket, modelers should :
1. First, implement the model change as requested on the ticket
2. Next, take a screenshot of the implemented changes.
This provides evidence of traceability of implemented changes in the event of an impacted financial figure.
We also recommend that after customers make relevant changes, that they export their Pigment Boards to a PDF file. These serve as a record of the changes at that time.
Audit Logs. Customers can use audit logs to track a history of all changes, and the Member responsible for the change. However, the details of the old value and new value of the change aren’t tracked. Audit logs are a useful tool for customers to provide evidence that no impactful changes were made to a model since a specific date. Pigment audit logs have a 180-day lookback period. We recommend ingesting the logs into a separate system if a longer period of logs are needed for auditing purposes, for example, a full year.
Snapshots. Customers can use Snapshots to save a frozen record of their model, and all the configurations that were used for reporting financial data at a specific time. This assures that reported financial data has not been altered.

IT operations

Section 4.1 of Pigment’s SOC1 report covers this, which is available in the Pigment Trust portal (https://trust.pigment.com/).

Security & Compliance

Product

Use Cases

Resources

Company

Follow