Before looking in detail at the subject of permissioning, customers should be aware of the concept of the “Root Administrator”. On taking out a Corterum subscription, a single “Root Administrator” account will be created for the customer. The “Root Administrator” account has full permission to access all areas of the customer’s Corterum account. Moreover, these permissions cannot be revoked. As such, we recommend that customers only use this account in order to complete their initial set-up – creating other accounts with the relevant permissions (which can be revoked) for use on a day-to-day basis.

To properly understand the way in which permissioning works within Corterum, it is necessary to understand six concepts:

A “User” account is nothing more than the basic login details which provides an individual with access to the Corterum system.

Each “User” must be allocated with one or more “Roles”. The “Role” determines precisely which parts of the Corterum system the individual can, or cannot, access.

“Entities” are standalone ‘things’ to which all information stored within the Corterum system is linked in some way. An entity could, in theory, be anything but the entities which currently exist within Corterum relate to “people”, “businesses” and “regulators”. More categories of Entities will be created as and when required.

An example of a ‘business’ Entity would be a member of staff’s previous employer, or an ex-staff member’s new employer (from which the firm had received a regulatory reference request).

It is best to imagine Entities as ‘free-floating’ above the level of users. Entities can be linked to other Entities within Corterum. This reduces duplication of information. Picking up on the example previously given, a ‘business’ Entity (“A”) may have been both (a) the previous employer of a user (“B”) who has recently joined the firm, and (b) the new employer of an ex-user (“C”) who has recently left the firm. In this case, A would be linked to both B and C in order to avoid duplication of information.

Each user of the Corterum system should also be created as an “Entity” – more specifically, as a person “Entity”. This is particularly useful where an individual works for more than one group company, both of which are subject to the SM&CR, as it allows the individual to be linked to both companies.

Each User of the Corterum system can be linked to an Entity. As discussed above, it would normally be the case that the ‘Joe Bloggs’ “User” would be linked to the ‘Joe Bloggs’ “Entity”. However, this does not have to be case as Entities exist within their own right. Hopefully it will be clear that not all Entities are Users within Corterum, even where the Entity is an individual. For example, an ex-employee will still have an Entity within the system (as the firm may be required to respond to a regulatory reference request in relation to that individual for up to six years after he/she ceases to work for the firm). However, that same individual will no longer be a User of the system in his/her own right.

“Groups” are a way in which Entities can be logically grouped together. Multiple Entities can be members of a single group. In addition, a single Entity can be a member of multiple Groups.

Groups are used as convenient ways in which to set permissioning rights for staff members. This is discussed in more detail below.

It is absolutely permissible to create a Group containing only one Entity if that is preferred.

Within Corterum, “Datasets” take two forms:

Conceptually, it is easiest to think of Form Datasets as ‘sheets of paper’ on which information is stored. An example of a Form Dataset within Corterum is the “Fit and Proper Assessment Record”. As the name suggests, this Dataset provides users with the ability to record the results of fit and proper assessments performed in relation to all staff.

A Table Dataset is best thought of as being akin to an Excel spread sheet.

All Datasets (whether Form Datasets or Table Datasets) are capable of having instances. To use the example of the “Fit and Proper Assessment Record” Dataset, if a version of this Dataset exists for a member of staff called Joe Bloggs and another version of this Dataset exists for a member of staff called Jane Smith, two “instances” of the Dataset are said to exist.

As such, hopefully it is clear to see how multiple “instances” of a single Dataset exist – capturing the same information, but about different Entities.

Whenever a Dataset instance is updated (whether it is a Form Dataset or a Table Dataset) the historic data is stored and forms part of the Dataset’s history. This allows Users of the Corterum system to “time travel” into the past to a particular version of that Dataset to see what changes were made, when they were made, and by whom. This is an important element in terms of evidencing compliance with the SM&CR.

Roles are the method through which a User is granted access within the Corterum system. In other words, each User is allocated at least one Role within the system.

Using Roles, access can be granted to an Entity (e.g. all of the information pertaining to a certain individual) or to particular Datasets (which may contain data relating to one or more Entities). A User can only see the information contained within Datasets to which that User has been explicitly linked.

The use of the concept of “Roles” allows users to be allocated more granular permissions. An example of where this may be necessary arises in the context of line management. Let’s assume that “Jane Smith” is the line manager of “Joe Bloggs”. It may be necessary to allow Jane Smith to view certain data relating to Joe Bloggs for the purposes of fit and proper assessment sign-offs (for example, providing confirmation that “Joe Bloggs” has indeed completed the required amount of training during the year). However, there may be legitimate reasons why the firm does not want Jane Smith to be able to see all information pertaining to Joe Bloggs. For example, the firm may not wish a line manager to be able to see whether a team member has a criminal record (a decision may have been taken to restrict that type of information to HR only). Through the use of “Roles” it is possible to allow Jane Smith to access some, but not all, of the information relating to Joe Bloggs. In doing so, the firm can balance its obligations under SM&CR against its obligations under, say, GDPR.

All new users of the Corterum system are provided with four standard ‘out-of-the-box’ “Roles”, being:

The exact permissions associated with each “Role” can be found here. Customers are free to use the standard “Roles” provided or to create new “Roles” to suit their specific needs.

It is worth noting that, in creating the four standard ‘out-of-the-box’ “Roles” and in the interests of maintaining confidentiality, we have deliberately made these permissioning rights conservative (on the basis that it was better to be ‘safe than sorry’). In other words, where we had any doubt as to whether access should be allowed or not, we deliberately chose NOT to allow access.

Consider the example where a customer of Corterum has multiple companies within its group structure, more than one of which is subject to the SM&CR. Corterum allows the customer to set up each such group company as a separate “Company” within the system. In doing so, it is possible to have a ‘single view’ of the entire group’s compliance efforts whilst maintaining confidentiality between group companies.

“Entities” (whether people, businesses or regulators) can be linked to multiple “Companies”. In doing so, it is possible to reduce the amount of duplicate data that must be inputted into the system (thus also reducing the risk of errors within that data).

Example of where this might be relevant include:

A diagram showing the inter-relationship between these concepts is provided below.

As previously noted, a “User” must exist in order to access the Corterum system. Follow these steps within the administration area in order to create a “User”.

In almost all cases, for individual “Users”, assign the “User” to his/her corresponding “Entity”. This will create a baseline set of permissions for the User – allowing him/her to see his/her own data within the datasets to which he/she has been linked. For example, link the “Joe Bloggs” User to the “Joe Bloggs” Entity.

With respect to Table Datasets that have been embedded within Form Datasets, a User must have access to both the Form Dataset and the embedded Table Dataset in order to see the data contained within the embedded Table Dataset.

Create the relevant “Entity”

We will create an “Entity” for an administrative user called “Jane Smith”.

Create “Groups” of Entities (if required, but NOT compulsory)

It isn’t necessary to create a group for all members of staff as the group called “All People” already exists. However, we add “Jane Smith” to the group.

Create a “Role” for the “Entity” (if a new “Role” is required)

The “Role” of “Compliance Administrator” already exists. As such, we do not need to create a new “Role” for Jane Smith. The “Role” has already been set up to give access to the required Groups, areas of the system (“Featured Permissions”), and Datasets.

Create the relevant “User”

We create a “User” for Jane Smith so that she can access the system (with the permissions we have set).

Link the User to the Companies

Finally, we link Jane Smith’s “User” to the FCA Company.

Charlie Chaplin has just joined our company. Charlie is a ‘standard’ user of the Corterum system in the sense that he does not have line management responsibility for any other member of staff. As such, we want to give Charlie access to all of his own datasets, but to no other datasets.

Below is a worked example of how Charlie should be set up within the Corterum system.

Step 1: Set up “Charlie Chaplin” as an Entity

Using an existing administration account:

Next, we would complete as many of the information fields about Charlie Chaplin as we can. Note that only one field within this section is mandatory – “The entity name” – in this case “Charlie Chapin”. Obviously, without a name, we cannot create an Entity.

All other remaining fields on the screen are optional. However, the more information we can provide at this stage the better. The reason why this is the case is that some of this information is used in reports such as Statements of Responsibilities and FCA Directory submissions.

Once the appropriate amount of information has been entered, click “save”.

The “Charlie Chaplin” Entity has now been created.

We must now link the “Charlie Chaplin Entity” to one or more “Companies” (remember – “Companies” are the firms within our group which are subject to the SM&CR). It is only necessary to link Charlie Chaplin to the “Companies” with which he is actually associated for SM&CR purposes. This may be none, one or more of the firms within the group which are subject to the SM&CR.

To link the “Charlie Chaplin Entity” to a “Company”:

Next, select the Company or Companies which which the “Charlie Chaplin Entity” is to be linked. In this case, Charlie Chaplin works at the Financial Conduct Authority (but not the Payment Systems Regulator), so we will choose only “Financial Conduct Authority” from the drop-down list.

Finally, click “Save”. The “Charlie Chaplin Entity” is now associated with his employer, the Financial Conduct Authority.

The next step would be to consider whether to allocate the “Charlie Chaplin” entity to a group.

We have previously noted that it is POSSIBLE to create “Groups” of Entities. However, it is not COMPULSORY to do so.

As a reminder, “Groups” are a way in which Entities can be logically grouped together. Multiple Entities can be members of a single group. In addition, a single Entity can be a member of multiple Groups.

In the case of Charlie Chaplin, our only real objective is to give Charlie permission to see his own datasets. We do not want him to see the datasets associated with any other member of staff. In addition (at least at this stage), it is not necessary to confer membership of a particular “Group” on Charlie.

As such, we can legitimately conclude that Charlie DOES NOT need to be allocated to a “Group”.

We mentioned previously how “Roles” are the method through which a User is granted access within the Corterum system. In other words, each User is allocated at least one Role within the system.

Using Roles, access can be granted to an Entity (e.g. all of the information pertaining to a certain individual) or to particular Datasets (which may contain data relating to one or more Entities). A User can only see the information contained within Datasets to which that User has been explicitly linked.

We create a new “Role” for Charlie Chaplin. In reality, it is highly likely that a suitable “Role” would already exist for Charlie as he is not our first new member of staff. However, we will go through the process for demonstration purposes.

To create a new “Role” for Charlie Chaplin:

A dialogue box will appear, similar to the screen shot below.

We must now set out the parameters of the “Role” that will ultimately be assigned to Charlie Chaplin. These parameters will determine which parts of the Corterum system Charlie can – and cannot – access.

In order to do this we must complete the following information:

In this case, we will choose the name “Standard User”.

We will use the following description for the “Role” to be allocated to Charlie Chaplin:

“Any member of staff who is allocated the "Standard User" "Role" will be able to access the following:

Datasets: his/her own dataset only, but no other datasets.

Groups: No allocation to groups.

Feature Permissions: no access to Feature Permissions.

Dataset Permissions: Read-only access to all datasets.”

As previously discussed, we have decided that it is NOT necessary to associate Charlie Chaplin to a “Group”. As such, we leave this field blank.

As the name suggests, through the “Feature Permission” section, we are able to give users access to broad parts (“features”) of the Corterum system.

The following “Feature Permissions” exist:

1. Attestation Form Administration

2. Company Administration

3. Entity Administration

4. External Repot – Anti Money Laundering

5. Group Administration

6. Report – FCA Directory Report

7. Report – Fit and Proper Certificate

8. Report – Form H

9. Report – Regulatory Reference

10. Report – Statement of Responsibility

11. Roles Administration

12. Rules Administration

13. Task Administration

14. User Administration.

As we can see, in reality, many of the “Feature Permissions” should only be accessible by administration users. Charlie Chaplin is NOT an administration user. Rather, he is a ‘normal’ user. As such, we decide to give him access to just two “Feature Permissions”:

Finally, we must give Charlie Chaplin access to individual datasets. For each dataset, it is possible to give three types of permission:

We decide to err on the side of caution and give Charlie “read only” access to each dataset (if will be easy to ‘upgrade’ his access rights in the future if that is required).

In addition, we decide that, as a “Standard User” there are certain datasets that Charlie Chaplin does not need to see. Example of these include:

1. Boards and committee details

2. Boards and committees

3. Disciplinary Proceedings and Conduct Rules Breaches

4. Firms providing regulatory references

5. Fitness and Propriety Assessment Record

6. Management Responsibilities Map

7. Performance Reviews

8. Regulated Activities

9. Regulatory Matters

10. Regulatory Reference Requests Received

11. Regulatory References Obtained

12. Regulatory Reference Provided

13. SM&CR Classification

As such, we remove Charlie’s access to these parts of the application (see screenshot below).

A full list of datasets, as well as a dataset structure ‘map’ is provided elsewhere in this user manual.

Click “Save”

Having set our desired “Dataset Permissions”, we click “Save”.

The “Role” which will be assigned to Charlie Chaplin has now been created.

We must now create the “User” for Charlie Chaplin. This will give Charlie Chaplin access to the Corterum system.

You may wonder whether this step is really necessary. However, bear in mind that not all “Entities” will be “Users” of the Corterum system. As an example, the SM&CR will requires firms to effectively hold information about ex-employees for up to six years after they leave the employment of the firm. These ex-employee individuals will continue to be “Entities” within the Corterum system, but there will no longer be a “User” associated with that “Entity”.

In order to create a “User” for Charlie Chaplin:

A dialogue box this like should appear:

We select a username (in this case, “Charlie Chaplin”).

We provide an email address for the user. This is very important in terms of managing user password resets and for sending email task notifications.

We select “Charlie Chaplin” from the “Linked Entity” field. This links the “Charlie Chaplin Entity” to the “Charlie Chaplin User”.

Finally, we link the “Charlie Chaplin User” to his appropriate “Role” (in this case, the role of a “Standard User”).

To finish the process, click “Create”.

As a final step, we must link the “Charlie Chaplin User” to our “Company” (in other words, the legal entity that is subject to the SM&CR). Note that it is possible that multiple group firms may be subject to the SM&CR. It is also possible that Charlie Chaplin may work for multiple firms within the group. This is absolutely fine as it is possible to link the “Charlie Chaplin User” to multiple “Companies”.

In order to link the “Charlie Chaplin User” to the relevant company (in the case, the FCA):

Next, select the “Company” or “Companies” to which the “Charlie Chaplin User” is to be linked.

Next, click “Save”.

The process is now complete. Charlie Chaplin is linked to the relevant Company and has all of the desired permissions.

1. Create the relevant “Entity”.

2. Create “Groups” of Entities (if required, but NOT compulsory).

3. Create a “Role” for the “Entity” (if a new “Role” is required).

4. Create the relevant “User”