Option 1: Specify, Perform/Manage, and Verify are fully separated.
Option 2: Specify and Verify are separated from Perform.
Option 3: Specify, Perform/Manage, and Verify are separated in a per function basis.
Option 4: Specify, Perform/Manage, and Verify are separated to limit risk aggregation effects.
Option 5: Specify, Perform/Manage, and Verify are not separated.
IF the enterprise is small and private AND maturity level is Initial or less, THEN Specify, Perform/Manage, and Verify are not separated.
OTHERWISE IF maturity level is Repeatable or lower, THEN Specify and Verify are separated from Perform/Manage.
OTHERWISE IF Risk is Low or Medium AND maturity level is Managed or greater, THEN Specify and Verify are separated from Perform/Manage. AND Specify, Perform/Manage, and Verify are separated to limit risk aggregation effects.
OTHERWISE Specify, Perform/Manage, and Verify are separated in a per function basis. AND Specify, Perform/Manage, and Verify are separated to limit risk aggregation effects.
The following assignment sets are typical of options 1, 2, or 3, with contact identified for options 1, 2, and 3 in that order only:
|Business||Policy||1||23||1||AB, BC, BC|
|Business||Control Standards||1||23||1||AB, BC, BC|
|Business||Procedures||13||2||13||AB, BC, BC|
|Business||HR||13||2||13||AB, BC, BC|
|Business||Legal||13||2||13||AB, BC, AB|
|Business||Risk Management||1||23||1||AB, BC, AB|
|Operations||Testing||13||2||13||AB, BC, AB|
|Operations||Change Control||13||2||13||AB, BC, AB|
|Operations||Physical technical safeguards||13||2||13||AB, BC, AB|
|Operations||Logical technical safeguards||13||2||13||AB, BC, AB|
|Operations||Incident handling||13||2||13||AB, BC, AB|
|Assurance||Audit||1||23||1||AB, BC, BC|
|Assurance||Knowledge||1||23||1||AB, BC, AB|
|Assurance||Awareness||1||23||1||AB, BC, AB|
|Assurance||Documentation||1||23||1||AB, BC, AB|
Fill in the following table detailing alternatives for Specifying (S), Performing/Managing (P), and Verifying (V) systems for Low, Medium, and High risk systems following the rules here:
IF Risk is Low,
THEN Separation of duties is not required. (SPV)
IF Risk is Medium,
THEN Specify and Verify OR Perform/Manage the same element, but not both. (SV) OR (P)
IF Risk is High, THEN
|Operations||Physical technical safeguards||.||.||.|
|Operations||Logical technical safeguards||.||.||.|
Separation of duties has long been a fundamental of protection. For example, in accounting, the same person cannot specify and approve a transaction without the risk of them specifying that they should be sent all the money and approving of sending it to themselves, unless they are authorized to make that aggregated risk decision. Thus in a small business owned by an individual, there is really no problem with no separation of duties, while in a public company where people are handling other peoples' money, separation is critical to proper control.
The analysis here separates those who Specify, Perform/Manage (operations), and Verify.
Note that single points of failure can be largely mitigated by this approach, but for multiple points of failure (e.g., a collusion between any two of the three functions) this breaks down. For that reason, in high consequence environments, separation has to be augmented with risk disaggregation so that even collusions are limited in their effect. Of course at some level of collusion (e.g., all participants are colluding), this will also break down.
Specify, Perform/Manage, and Verify are fully separated: In this approach, nobody can participate in more than one of these activities. In essence, audit covers verification, a director of some sort specifies, and operations performs operational tasks.
Specify and Verify are separated from Perform/Manage: In this mode, an individual, typically a CISO or similar titled party (we will call this the Information Proteciton Lead (IP Lead)), specifies what is to be done and verifies that it is done, and a different party, typically the Chief Information or Operations Manager or the equivalent carries out the operations. This is typically for medium sized organizations or larger ones with a more powerful information protection lead.
Specify, Perform/Manage, and Verify are separated in a per function basis: In this case, different business functions involve different sets of individuals who specify, perform/manage, and verify, and the same individual cannot do all three (or often more than one) for any given area. So a manager in one area may be able to perform while they are also able to specify in another area and verify in a third area.
Specify, Perform/Manage, and Verify are separated to limit risk aggregation effects: For entities large enough for individuals to not be dominant (typically any enterprise with more than 100 or so people moves away from individual responsibility toward positions and groups with responsibilities), the potential for harm associated with aggregated risks should be considered. Separation of duties is one aspect of this, however, as consequences grow and organizations become more diverse, limits on consequences of individual actions are typically put in place, and these should include separation of duties actions to limit aggregated risks associated with being able to specify too much, perform too much, or verify too much of the total value of the enterprise, particularly at levels of management below the very top levels, where these controls are typically very indirect and operating through others.
Specify, Perform/Manage, and Verify are not separated: For very small individually owned organizations, separation of duties is a waste of effort. Since one individual can cause systemic failure and bears the burdens associated with such failures as this produces, there is no top-level requirement for such separation. However, many such owners decide to separate duties among workers so as to limit consequences of errors, omissions, and malice.