Classifications in SAS Model Risk Management: A Step-by-Step Guide to Configuring Classifications

For large organizations, managing data isn’t just about storing information—it’s about making sure the right people can find, use, and protect it. That’s where classifications come in. In SAS Model Risk Management (MRM), classifications act like smart labels that help organize data based on how a company is structured. Whether it’s by department, region, or business function, classifications make it easier to group related information and control who has access to it.

This post dives into the powerful role classifications play in SAS Model Risk Management (MRM)—from organizing data and enforcing security to shaping user access and experience. You’ll learn what classifications are, how they’re structured, and why they’re essential for managing models and findings in large organizations. We’ll walk through the process of adding a new classification node, “Early Career,” under the Human Resources dimension, and explore how to configure data loaders, security settings, and user roles to ensure precise control and governance. Whether you're new to SAS or looking to refine your MRM setup, this guide offers practical steps and insights to help you get started.

What Are Classifications?

Think of classifications like folders on your computer. Each folder represents a category, and inside each folder are files that belong to that category. In SAS MRM, classifications work the same way. They help organize models, findings, and other objects into logical groups.
Here are the key terms you need to know:

Classification Type: This is the main category or dimension, like “Business Lines” or “Geographies.”
Class Members: These are the items within a classification type, such as “Human Resources” or “Payroll.”
Named Trees: These define how class members are grouped into a hierarchy.
Named Tree Paths: These show the full path of where each class member fits in the hierarchy.
Translations: These allow labels to be shown in different languages.

Why Are Classifications Important?

Classifications are essential for two main reasons:

Organization: They help users find and group related data. For example, if you want to see all models related to Human Resources, you can filter by that classification.
Security: They control who can see or edit certain data. For example, only HR staff might be allowed to access models classified under Human Resources.

This system is especially useful in large organizations where different teams work with different types of data.

Understanding Classification Points and Areas

In SAS Model Risk Management, a classification point is a specific combination of values from different classification types (also called dimensions). Each classification type represents a category like “Entity” or “Geography,” and each value within that type is called a dimensional node.
A classification point is made up of one node from each classification type. It tells the system exactly where an object—like a model or a finding—belongs in the organization’s structure.

Example:

If your classification types are:

Business Lines: SAS Bank 1
Geography: US

Then your classification point would be:

{ "Business Lines": "SAS Bank 1", "Geography": "US" }

This point tells the system that the object is associated with SAS Bank 1 in the US region.
A classification area is a group of classification points. It’s useful when you want to apply the same access rules or reporting filters to multiple combinations of values.

Example:

Let’s say you want to give access to all models related to SAS Bank 1 in both the US and EU. You could define a classification area like this:

[
  { "Business Lines": "SAS Bank 1", "Geography": "US" },
  { "Business Lines": "SAS Bank 1", "Geography": "EU" }
]

This area groups both points together, making it easier to manage access and reporting for related data.
This structure is especially helpful in large organizations where models and data are spread across different departments and regions. It allows for precise control and flexible grouping.

The Role of Data Loaders

To manage classifications, SAS MRM uses Excel-based files called data loaders. These files contain different sheets that define how classifications are set up.
Here are the main data loaders used for classifications:

Understanding the Classification Data Loaders

SAS Model Risk Management uses a set of structured Excel-based files called data loaders to define and manage classifications. Each loader plays a specific role in building the classification system. Below is a breakdown of the most important loaders, their purpose, and what they typically look like in the data loader file.

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

Controlling Access with Classification Security Settings

In addition to organizing data, classifications in SAS Model Risk Management (MRM) play a critical role in controlling access to that data. This is where the concept of security contexts and selection modes comes into play.
Once you’ve defined your classification structure—using loaders like ClassType, ClassMembers, and NamedTreePaths—you can specify how those classifications are applied to objects (like models, findings, or reviews) and how they appear in the user interface. This is done using the RegistrationClassifications data loader.
This loader allows you to define:

Whether a classification is required (must be selected)
Whether users can select multiple nodes (multi-select)
Whether the classification is used for security enforcement
How classification points are generated (via selection mode)

These settings ensure that classifications are not only meaningful for organizing data, but also enforce the right level of control and usability.

Security Contexts: What They Are and Why They Matter

A classification context defines how a classification is used. The most important context is:

default – This is the primary context used for positional security. If a classification is assigned in the default context, it controls who can view or edit the object based on their role and the object’s classification.

Other contexts (like “discovery” in Global Compliance Management) may be used for tagging or reporting but do not affect access.

Example:

If a model is classified as:

{ "Entity": "SAS Bank 2", "Geography": "EU" }

and this classification is in the default context, only users with access to SAS Bank 2 in the EU will be able to interact with the model.

Selection Modes: How Classification Points Are Created

SAS MRM supports two selection modes that determine how classification points are generated when users select nodes from different dimensions:

1. Collection of Points Mode

Users select specific combinations of classification nodes. This is useful when only certain combinations are valid.
Example:

[
  { "Business Lines": "SAS Bank 1", "Geography": "US" },
  { "Business Lines": "SAS Bank 2", "Geography": "EU" }
]

Only these two combinations will be used.

2. Cross Product Mode

Users select a list of nodes for each classification type, and the system automatically creates all possible combinations between them.
Example:

{
  "Business Lines": ["SAS Bank 1", "SAS Bank 2"],
  "Geography": ["US", "EU"]
}

The system will generate:

[
  { "Business Lines": "SAS Bank 1", "Geography": "US" },
  { "Business Lines": "SAS Bank 1", "Geography": "EU" },
  { "Business Lines": "SAS Bank 2", "Geography": "US" },
  { "Business Lines": "SAS Bank 2", "Geography": "EU" }
]

This is helpful when you want broad coverage without manually listing every combination.
To modify these modes, refer to the RegistrationClassifications data loader.

RegistrationClassificationsTrees: Key Fields and Their Purpose

The RegistrationClassificationsTrees loader defines how classifications are applied to specific object types and how they behave in the UI. Here are the most important fields:

Field	Purpose	Example
registration.sourceSystemCd	Identifies the system the object belongs to	MRM
registration.id	The object type being classified	Model, Finding, ModelReview
classifications.contextName	Defines the classification context. Use default for security enforcement.	default
classifications.namedTree[0].sourceSystemCd	Source system for the named tree	MRM
classifications.namedTree[0].id	The ID of the named tree (dimension)	mrm_business_lines
classifications.namedTree[0].classTypeSourceSystemCd	Source system for the class type	MRM
classifications.namedTree[0].classTypeId	ID of the class type	mrm_10000
classifications.namedTree[0].multi	TRUE if users can select multiple nodes; FALSE for single-select	TRUE
classifications.namedTree[0].required	TRUE if selection is mandatory; FALSE if optional	TRUE

Example: Enforcing Security and UI Behavior

Let’s say you want to classify models by Business Lines, and you want users to:

Always select at least one business line
Be able to select more than one
Have the classification enforce security rules

Your RegistrationClassifications entry might look like this:

{
  "registration.sourceSystemCd": "MRM",
  "registration.id": "Model",
  "classifications.contextName": "default",
  "classifications.mode": "crossProduct",
  "classifications.namedTree[0]": {
    "sourceSystemCd": "MRM",
    "id": "mrm_business_lines",
    "classTypeSourceSystemCd": "MRM",
    "classTypeId": "mrm_10000",
    "multi": true,
    "required": true
  }
}

This configuration ensures that:

The classification is used for security (because the context is default)
Users must select at least one business line
Users can select multiple business lines
The system will generate all combinations of selected nodes using the cross product method

When to Use Required and Multi-Select Settings

Setting	Use When...
required = TRUE	You want to ensure every object has a classification (e.g., every model must belong to a business line)
multi = TRUE	You want users to be able to assign an object to multiple nodes (e.g., a model used by both HR and Finance)
multi = FALSE	You want users to choose only one node (e.g., a model must belong to one region only)
required = FALSE	Classification is optional (e.g., for tagging or metadata purposes only)

Adding a New Classification Node in SAS Model Risk Management

Let’s walk through how to add a new classification node—for example, Early Career—under an existing hierarchy like Human Resources within the Business Lines dimension.

Step 1: Open Your Classification Data Loader Workbook

Start by downloading then opening the Excel workbook used for managing classification data. This can be found on the Data Load page of SAS Model Risk Management on the Files tab. This file will contain multiple sheets not limited to:

ClassTypes - specifies the classifications names (Not changed in this demonstration)
ClassMembers
ClassMemberTranslations
NamedTreePaths
NamedTreePathTranslations

Note: The data loader you download may contain all data loaders for entire solution. Simple delete the unnecessary sheet tabs until you only have the four that are above. You can also download each individual data loader file on the Data Load tab > View Available Loaders.

Step 2: Add a New Class Member

In the ClassMembers sheet:

Add a new row to represent the new node.
Assign a unique classMember.id (e.g., bl_custom_01).
Set the classMember.name to a lowercase identifier (e.g., earlycareer).
Set the classMember.label to the display name (e.g., Early Career).
Optionally, add a description.

This step registers the new classification node in the system.
Here's an example:

Step 3: Add a Translation for the New Node

In the ClassMemberTranslations sheet:

Copy the row you just added in ClassMembers.
Set the languageCd to en (or your preferred language code).
Set the label to the user-facing name (e.g., Early Career).

This ensures the node is properly labeled in the user interface.

Step 4: Define the Node’s Position in the Hierarchy

In the NamedTreePaths sheet:

Add a new row to define where the new node fits in the hierarchy.
Use the namedTreePath.path field to specify the full path (e.g., InternalBusinessLines.SAS.CorporateServices.HumanResources.EarlyCareer).
Set the namedTreePath.label to a readable identifier (e.g., SASEarlyCareer).
Set the namedTreePath.parentPath to the path of the parent node (e.g., InternalBusinessLines.SAS.CorporateServices.HumanResources).

This step places the new node in the correct location within the classification tree.

Note: Columns A thru E were cut off for the sake of showing columns I and J.

Step 5: Translate the Full Path for Display

In the NamedTreePathTranslations sheet:

Add a new row for the new path.
Set the languageCd to en.
Set the label to a list of readable names for each level in the path, such as:

  ["Internal Business Lines", "Company Name", "Corporate Services", "Human Resources", "Early Career"]

Note: Columns A thru E were cut off for the sake of showing columns I and J.

Step 6: Load the Data into SAS Model Risk Management

Once your Excel workbook is updated:

Go to the Data Load page in SAS MRM.
Choose:
- Action: Load
- Processing Mode: Preview results
- Excel Workbook: Select your updated file
Click Data Load to validate the file.
Check the Progress column for a breakdown of the contents.
If no errors appear, switch the mode to Process all valid records and click Data Load again.
If errors do appear, click the Download link in the Results column.

This step applies your changes to the system.

Step 7: Verify the New Classification Node

To confirm your update:

Navigate to the New Model or relevant object page in SAS MRM.
In the Classifications section, click the pencil icon to edit.
Search for the parent node (e.g., “Human Resources”).
You should now see the new node (e.g., “Early Career”) listed.

Congratulations—you’ve successfully added a new classification node to your hierarchy!

Defining Roles, Permissions, and Positions in Your SAS MRM Solution

Once you’ve structured your classifications and configured how they appear in the UI, the final step in securing your SAS MRM environment is defining who can do what with the objects in your system. This is where roles, permissions, and positions come into play.

These elements work together to enforce instance-level access control—ensuring that users can only perform actions on the objects they’re authorized to access, based on both their role and the object’s classification.

Security Data Loaders Overview

To configure this layer of security, you’ll use three key data loaders:

Loader	Purpose
Roles	Defines named sets of capabilities (e.g., MRM: Read Models, MRM: CRUD Findings)
RolePermissions	Specifies the actions (Create, Read, Update, Delete) that each role can perform on specific object types
Positions	Combines a role with a classification scope to define what a user or group can do at the object instance level

Let’s walk through each one.

1. Roles Loader

The Roles loader defines the roles available in your system. Each role is associated with a specific object type and a set of capabilities.

Example entries:

role.id	role.name	role.description
mrm_CRU_models	MRM: Create, Read, and Update Models	Can create, read, and update models
mrm_R_findings	MRM: Read Findings	Can read findings
mrm_CRUD_modelReviews	MRM: Create, Read, Update, and Delete Model Reviews	Full access to model reviews

These roles are referenced in both the RolePermissions and Positions loaders.

2. RolePermissions Loader

The RolePermissions loader defines what each role is allowed to do. It links a role to a specific object type and action.

Example entries:

role.id	capablity.id	registration.id
mrm_CRU_models	instance.create	Model
mrm_CRU_models	instance.read	Model
mrm_CRU_models	instance.update	Model
mrm_R_findings	instance.read	Finding

This loader ensures that each role has clearly defined permissions for each object type.

3. Positions Loader

The Positions loader is where roles meet classification. It defines which roles are assigned to which users or groups, and under what classification scope.

Example entries:

role.id	role.name	scope
>mrm_CRU_models	MRM: Create, Read, and Update Models	Everywhere
mrm_CRU_models	MRM: Create, Read, and Update Models	Entity = Retail

This is the loader you’ll use to assign roles to your custom groups—scoped to the appropriate classification nodes.

How to Define Your Own Groups and Positions

Whether you’re using a customizable or non-customizable solution, you’ll likely want to define your own custom groups and assign positions to control access. Here’s how to do it effectively.

Scenario: Restricting Access by Entity

Let’s say your organization has an Entity dimension structured like this:

                Head Office
               /           \
     Retail Division   Commercial Division

You want:

Retail analysts to access only retail data
Commercial analysts to access only commercial data
Head Office users to access both

You also want to use the same workflow for all analysts.

Step 1: Create Custom Groups

Create two new groups:

MRM: Data Analyst (Retail)
MRM: Data Analyst (Commercial)

Then, make both groups members of a parent group:

MRM: Data Analyst

This allows you to reference the parent group in your workflow, while still controlling access at the subgroup level.

Step 2: Do Not Assign Positions to the Parent Group

Avoid assigning any positions to the MRM: Data Analyst group. If you assign a position with a scope of Entity = Head Office or Everywhere, all members—including the retail and commercial subgroups—will inherit that access. This would give them access to all data, which is likely not what you want.

Step 3: Assign Positions to the Subgroups

Assign positions directly to the subgroups using the Positions loader.

For MRM: Data Analyst (Retail):

Role: mrm_CRU_models (scope: Everywhere)
Role: mrm_CRU_models (scope: Entity = Retail)

For MRM: Data Analyst (Commercial):

Role: mrm_CRU_models (scope: Everywhere)
Role: mrm_CRU_models (scope: Entity = Commercial)

This setup ensures that:

Retail analysts only access retail data
Commercial analysts only access commercial data
Both groups can use the same workflow
Head Office users (if needed) can be assigned broader access separately

Why This Approach Works

By defining your own groups and assigning positions at the subgroup level, you maintain precise control over who can access what. You also avoid unintentionally granting broad access through inherited permissions. This approach is scalable, secure, and aligns with how SAS MRM is designed to support enterprise governance.

Final Thoughts

By mastering classifications, you're not just organizing data—you’re laying the foundation for secure, scalable, and efficient model governance. Whether you're adding a new node like "Early Career" or defining access roles for different teams, each step strengthens your organization’s ability to manage risk and maintain compliance. As your data landscape evolves, a well-structured classification system ensures that your SAS MRM solution remains adaptable, transparent, and aligned with your business needs.

For more information on SAS Model Risk Management, click here.

Find more articles from SAS Global Enablement and Learning for SAS Model Risk Management here .