Separation of duties

In large organizations, to meet the demands of internal processes, security, and the requirements of regulatory bodies, there is often a need for separation of duties. 

To support these requirements, access to data, particularly live production data, should always be on a need-to-know basis.

The degree of separation is an internal decision for each organization. That decision can be influenced by many factors, such as resourcing or the complexity of the site. Anaplan can support separation of duties, as defined by an organization, with:

• Workspaces
• Data flows
• Model roles
• Selective access

This example shows how to use separation of duties in the Application of Lifestyle (ALM) process.

The purpose is to explain the concepts behind separation of duties and the factors to consider when you design and build environments to support it. These concepts can easily be ported to other scenarios, such as workspaces for different geographic locations or to separate functional areas such as sales and marketing.

Separation of duties in ALM begins at the workspace level. A robust design places production and non-production activities into separate workspaces. It’s then necessary to design data flows between those workspaces that ensure data, particularly live production data, is available in only  workspaces where it's required.

A basic implementation of Application Lifecycle Management contains three workspaces: Development, Test, and Production.

Data flow design should ensure that no live production data is present in either the Development or Test workspaces. Plans for separation of duties may include processes to sanitize and anonymize live data to be used in the Development and Test workspaces.

When you deploy to the live Production workspace, only structural information is copied from the Development workspace to the Production workspace, using model synchronization.

Live data in the Production workspace may be imported from either an Anaplan Data Hub or from external third-party sources. This table shows the data inputs to each workspace in this example:

Workspace administrators can use source models to remap production data import sources. For example, the models in the Test workspace might obtain data from a sanitized data model in the Development workspace.

When a model in the Development workspace is synchronized with a model in the Production workspace, Production workspace administrators will need to remap production data import sources to Production rather than Development sources. To do this, those workspace administrators will require access to both the Development and Production workspaces.

Create meaningful model roles that realistically represent the activities of user groups. You might permit some model roles to have a greater level of access than others, which ensures that data is secured on a need-to-know basis.

The model roles in a Development workspace may not need to be the same kinds of model roles that are in a Production workspace. Think about the activities different user types will undertake, and design roles accordingly. This will make separation of duties much easier to implement.

Selective Access can also be used to control access to data. Selective Access applies at the list level, using Read and Write permissions. The default is No Access. If lists are set to No Access, lists aren't accessible until an administrator specifies which roles should have access.

Access to workspaces, and consequently, models is limited by the model role each user is assigned. Access can be limited at a more granular level by applying selective access to lists. All access rights need to support the processes undertaken in the workspace, for example:

• The Production workspace administrator may need access to the Test workspace to remap imports after synchronization.
• The administrator in Test may need access to Development to import sanitized data.
• The administrator in Production may apply selective access to those non-production lists comprising the structural information for the model.
• Selective access can be used to prevent users accessing any lists that comprise structural information.

This table illustrates a high level of segregation of duties.

You can see that:

• The greatest number of roles have access to the Development workspace, where changes are made to existing models and new models are built. Whilst the data in this workspace is sanitized, and has no commercial value, the model’s structural information is meaningful and should be protected by restricted access.
• In the Test workspace, access is limited to workspace administrators and testers. Testing is undertaken by those users having access to the workspace and the appropriate role in the model (perhaps model builders from the Development workspace or business users from the Production workspace). The data in this workspace is also sanitized and the model’s structural information should be protected. Make sure the test models are in deployed mode.
• Although a greater number of users will access live production data, that access is limited to those assigned a role within the model. Internal IT resources may also need access to the workspace for maintenance purposes but should not have access to the models in the workspace.
• Workspace administrators require access to more than one workspace to remap import sources.

This diagram shows the user architecture together with the synchronizations and data imports for the workspaces. At no point is production data accessible in theTest or Development workspaces. Model roles ensure the site complies with separation of duties.

In environments where a data hub is deployed, the data flow might look like this:

As you can see, production data is still inaccessible to users on other workspaces.