Have a look at the [Group][1] module (commonly perceived as an alternative for [Organic Groups][2]).

[Group][1] allows for creating arbitrary collections of your content and users on your site, and grant access control permissions on those collections. It is available as of D7, and has a D8 version also. The [Group][1] module creates groups as entities, making them fully fieldable, extensible and exportable. Which also makes it integrate very well (out of the box) with commonly used modules such as [Rules](https://www.drupal.org/project/rules), [Views](https://www.drupal.org/project/views), etc.

Some more questions you may want to look at for more details:

- https://drupal.stackexchange.com/questions/197493, which explains the various types of roles that can be used. 
- https://drupal.stackexchange.com/questions/197489, a typical issue when adding this module to an existing site.
- https://drupal.stackexchange.com/questions/197618

# Sample configuration

Below is an example of a possible configuration, which may help to get you started with possible configurations (using the [Group][1] module):

    Group type ID ! Group type ! Group role ID ! Role
    --------------+------------+---------------+------------
     1            ! Class      ! 3             ! Instructor
     1            ! Class      ! 4             ! Student
     2 	          ! Customers  ! 5             ! Lead
     2  	      ! Customers  ! 6             ! Prospect
     2  	      ! Customers  ! 7             ! Licensed Customer
     2  	      ! Customers  ! 8             ! Sales
     2  	      ! Customers  ! 9             ! Support
     2  	      ! Customers  ! 10            ! Accounting
     2  	      ! Customers  ! 11            ! R&D
     3  	      ! Project    ! 12            ! Project Manager
     3  	      ! Project    ! 13            ! Developer
     3     	      ! Project    ! 14            ! Customer 

### Group Types

The above example consists of 3 ***group types***:

- Class.
- Customers.
- Project.

### Group Roles

For each of the 3 group types, there are specific ***Roles*** defined, some more details about some of them:

- for the *Class* group, these are the 2 roles that are configured:
  - Instructor.
  - Student.
- for the *Project* group, these are the 3 roles that are configured:
  - Project Manager.
  - Developer.
  - Customer.

These are the *Group Specific Roles*: these roles can be configured per group type and will only be available on groups of that group type. As an example, for group type "*Class*", the defined roles are **Instructor** and **Student** (which are not available for the other group types.

On top of the group specific roles, there are also *Special Global Roles*: These are the special (hardcoded) roles named **Outsider** (= a signed in user that did not join a group) and **Member**  (= a signed in user that did join a group). These cannot be defined by the Drupal administrator, and they are always available for any group. These roles can have different permissions sets for each group type. Special case: the role **Anonymous** is related to a user that is not signed.

### Groups
Each of the configured group types can have any number of ***Groups***.

Examples of groups:

- for the *Class* group type, there could be these **Groups**:
  - Getting started with Drupal.
  - Drupal for site builders.
  - Become an expert in using the Rules module.
- for the *Customers* group type, there could be these **Groups**:
  - Service Requests.
  - Order Processing.
  - Sales Orders.
  - Relationship Management.

### Permissions

For each of the configured group types, you can then also configure for each ***Content Type*** which ***Role*** has what kind of access (= none, view, create, edit, delete). Be aware: even though this looks similar to Drupal's permission configuration, these permissions are not the same permissions (they are specific to the Group module).

# Resources

- [Community documentation for the Group module][3].
- Video tutorial "[How to use the Group module in Drupal 8 to manage editorial access control to different areas of a web site][4]".

# Note

About your concern (as in your additional comment), which includes:

> ... having a list of permissions associated with each role multiplied so many times, editing and saving them taking extra processing power and stability issues. As well as the amount of work to the system each time the organization wants to add content. It just seems messy.

You're right, using standard Drupal permissions (with a zillion of roles) it would indeed become *messy*. But after you realize/discover how the Group module's roles/permissions work, your concern should be addressed ...

  [1]: https://www.drupal.org/project/group
  [2]: https://www.drupal.org/project/og
  [3]: https://www.drupal.org/node/2666972
  [4]: https://m.youtube.com/watch?v=GkiCLJk5n0s