From my professional experience, I have found quite a few companies prefer to prepare a certain kind of matrix, or a listing, of the Delegation of Authority/Accountability as part of the evidence that such Delegation of Authority/Accountability is in place across the organization for their internal control assessment/testing purposes.
However, such a matrix/listing would be redundant because the Delegation of Authority/Accountability itself is NOT a control but something that must be reflected in designing each internal control, often as part of each control owner’s competence.
In other words, each internal control must be designed to reflect the fact that proper Authority (and Accountability as the flip side of the Authority) is delegated to the control owner (and that the control owner is competent enough to be “delegated”).
Accordingly, the Delegation of Authority/Accountability factor of each internal control should be effectively and efficiently discussed on the Risk Control Matrix (RCM) (instead of the matrix/listing of the Delegation of Authority/Accountability).
For example, let’s say a company wrongly designs such an internal control as “Senior AP Accountant approves a wire cash disbursement batch (on the bank’s web-portal which lists the payments due input by AP Accountant).” (Note that the description of “the bank’s web-portal which lists the payments due input by AP Accountant” is a critical data-path or a LSPM (Likely Source of Potential Misstatement). See my blog post here.) And let’s further assume that the company included a related delegation of the approval authority (from AP Manager to Senior AP Accountant) on the Delegation of Authority(/Accountability) Matrix somehow.
The problem about the hypothetical control and the Matrix above is, first and foremost, the approval authority should not be delegated to a non-manager.
Oftentimes, however, people are somehow easily confused and wrongfully conclude that the control should be effective simply because, on the face of the Delegation of Authority Matrix, the approval authority appears to be delegated from AP Manager to Senior AP Accountant .
In this example, a correct control should be something like, “AP Manager approves a wire cash disbursement batch on the bank’s web-portal.”
Also, the company should clearly define the AP Manager’s (delegated) approval authority (and accountability) in their Roles and Responsibilities document, which must have been “authorized” by the Board of Directors (instead of such a Matrix as illustrated above).
Then, the Delegation of Authority/Accountability, or the part of the design, of the control is effective as the company’s AP Manager (i.e., the control owner) is adequately competent to such an extent that the proper approval authority has been delegated to him/her, which is evidenced by the Roles and Responsibilities.
The same is true about the Segregation of Duties (SoD).
Listing SoD’s by control would be redundant, or wouldn’t provide a meaningful piece of information; instead, the SoD should be factored in when designing each internal control.
Using the same example control mentioned above, it is clearly redundant to list the fact that the SoD is accomplished between AP Manager and AP Accountant, which must be assessed as part of the Test of Design, or Walkthrough, anyway.
If AP Manager input the payments due data and at the same time approved the data, the design of such an control would be ineffective and deficient due to breaching the SoD principle.
In other words, discussing the SoD by itself would not directly provide the conclusion as to whether a related internal control is effective or not; i.e., the SoD is just one of the control attributes that must be analyzed to assess the effectiveness of the control in question: e.g., “AP Manager approves a wire cash disbursement batch.”
That is why I said that listing SoD’s (by control) would lead us nowhere but redundancy.