How to complete SOX compliance testing w.r.t. Anaplan Releases?

Stacey_Gibbens

I have just asked this question in the form of an email to the SuccessCentral team, but I wanted to see if anyone on the Community has dealt with this situation. Assuming the folks at SuccessCentral get back to me, I will reply and post their answer in the comments.

I have a general question about how to handle SOX compliance for an Anaplan model if it becomes necessary. My understanding is that unless a copy of a customer's PROD Anaplan model can be evaluated and pass validations in a “pre-release” Anaplan-as-a-PRODUCT environment before a functional engine enhancement release is live, then the client model would fail to meet SOX compliance requirements.

Therefore, my question is, “How would an Anaplan customer gain access to a “pre-release” environment to validate their PROD model prior to a platform enhancement release?” For example, we have been notified of a maintenance window this weekend that is specific to infrastructure enhancements, but some releases (like the one on April 22) do include specific functional Anaplan-as-a-PRODUCT enhancements. My understanding is that to comply with SOX audit requirements, the client's model would need to be validated within a "pre-release" functionally enhanced PRODUCT environment prior to the functional release being applied to Anaplan's "production" PRODUCT environment.

Is there a special request process by which a customer may be granted access to a “pre-release” environment in order to test their model(s)? This is something that may end up being important in the overall plan my company has for its Anaplan footprint.

Thanks in advance!

Stacey Gibbens

Stacey_Gibbens

I suppose because Anaplan is a platform where the application can be designed and built by the customer and not an application per se, this may be very different from a cloud-based application like Salesforce or Oracle EPM. I guess the controls related to the application functionality (built by the customer) are what would require adherence to audit specifications.

This is what I received back from Anaplan Customer Support:

We also have other customers that have SOX compliant applications running on Anaplan and release process is not an issue. Anaplan performs extensive regression testing before any new product release and new features to ensure there is no impact to customer models. We also have Early Access program where customers can apply to the program and be part to test features before release.

Anaplan does not provide advisory services for legal or regulatory compliance. Anaplan encourages customers to consult with their own internal and external auditors, legal teams, and/or risk advisors when designing controls.  Both Anaplan’s SOC 1 and SOC 2 reports contain a section “User Control Considerations” which describe the controls customer organizations need to have in place, such as user training, user management, access controls, etc.  Customers need to ensure these User Controls are properly designed and operating effectively—these are entirely within the customer’s control. 

Having said this, if the customer’s auditors/legal/risk advisors have determined that multiple copies are necessary, they may want to consider using ALM to manage multiple versions of the model. The basics are you create separate Models - generally in separate Workspaces for segregation of duties and Users. Alternatively, Anaplan’s model History provides an audit trail of every change to a model.  History is automatically enabled, cannot be disabled, and is retained for the life of the model. History can be used to roll a model back to any point in time and can be exported to text file.  https://help.anaplan.com/history-1af91b89-11bb-4c58-9ca6-cbe7ca8a9275