SOC 2 Academy: Assigning Roles and Responsibilities

by Joseph Kirkpatrick / February 8th, 2019

Common Criteria 6.3

During a SOC 2 audit engagement, an auditor will validate that an organization complies with the common criteria listed in the 2017 SOC 2 Trust Services Criteria, which means that they will assess an organization’s compliance with common criteria 6.3. Common criteria 6.3 says, “The entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties, to meet the entity’s objectives.” How can organizations comply with this requirement? It comes down to three things: assigning roles and responsibilities, implementing the concept of least access necessary, and creating a separation of duties.

Assigning Roles and Responsibilities for SOC 2 Compliance

In order for organizations to ensure that they have effective internal controls in place, they need to assign roles and responsibilities. Why? Because assigning roles and responsibilities allows organizations to mitigate the risk of unauthorized persons accessing sensitive information. When organizations assign roles and responsibilities, they implement the concept of least access necessary. This means that employees only have the bare minimum access needed to fulfill their job duties. Similarly, assigning roles and responsibilities assists organizations in ensuring that there is a separation of duties so that there are no conflicts of interest within the organization. For instance, a network administrator who is responsible for ensuring that the internal controls over the network they created are functioning correctly should not be the same person who is responsible for monitoring those internal controls. Instead, the organization would need to assign roles and responsibilities to two separate individuals to make sure that no conflict of interest or fraudulent activity occurs.

Complying with Common Criteria 6.3

When making the journey toward SOC 2 compliance, organizations can use the following questions to determine if they comply with common criteria 6.3:

  • Does your organization have processes in place to create or modify access to protected information assets?
  • Does your organization have processes in place to remove access when it is no longer required?
  • Does your organization utilize role-based access controls to ensure that there is a separation of duties and the concept of least access necessary is implemented?

More SOC 2 Resources

SOC 2 Academy

Understanding Your SOC 2 Report

SOC 2 Compliance Handbook: The 5 Trust Services Criteria

I’d like to focus on common criteria 6.3 for SOC 2 compliance on a few key words in this particular criterion: roles and responsibilities, least privilege, and separation of duties. These are really the operative terms in this requirement. Let’s start with roles and responsibilities.  Everyone shouldn’t be an administrator. Everyone should have specific roles and responsibilities that translate into the level of access that you give them to your system or to your sensitive data. You don’t want everyone to have access to that kind of data, so thought has to be given to roles and responsibilities. The concept of least privilege also applies to that.  You need to make sure that you start with a default deny attitude. For example, a person starts by having access to nothing and then an administrator would consider what is the least access necessary to fulfill their job duties. Lastly, there’s separation of duties. If you have a conflict of interest in a particular area, there needs to be separation of duties. We’ll use developers as an example. Developers are developing code, but they shouldn’t also be promoting code to production. You don’t want the to use the same username and password to log into the test environment and also the production environment. You need to make those duties separate and ensure that there’s a developer role and a production role just so things don’t get messed up and remain separated, so that there is no room for a conflict of interest to occur.