Constructing a methodology for
implementing and maintaining
Sarbanes-Oxley 404 IT controls within
KLM FIM
Appendices
F.M. van der Schroeff University of Groningen
Appendices
Appendix A: Organigrams... 3
Organigram KLM ... 3
Organizational positioning FIM... 4
Appendix B: Control related documentation ... 5
KLM FIM CobiT control objectives... 5
11 Acquire and Develop Application Software... 5
12 Acquire Technology Infrastructure... 7
13 Develop and Maintain Policies and Procedures... 8
14 Install and test application software and technology infrastructure... 9
15 Manage Changes... 10
16 Define and Manage Service levels... 12
18 Ensure Systems Security... 13
19 Manage the configuration ... 15
20 Manage problems and incidents... 16
21 Manage data... 17
22 Manage operations ... 18
Sox- related KLM FIM Development project list... 20
FIM applications versus COBIT controls, GAP analysis & remediation... 21
Positioning KLM FIM controls within an end-to-end business process... 22
KLM FIM IT-dependent application controls ... 23
Prioritizing KLM FIM ITGC (Deloitte independent test) ... 24
Sox system landscape ... 25
Financial Statement Closing Process (FSCP)... 26
FSCP daily routine... 27
Appendix C: Testing related documentation ... 28
Testplan monitor FIM ... 28
Testplan monitor FIM (cont.) ... 29
Appendix D: KLM QA rapports ... 30
Quality Assurance on Test Procedures, Test Reports and Objectivity and Independence of Tester ... 30
Appendix E: Risk Navigator related documentation ... 37
Appendix A: Organigrams
Organigram KLMOrganizational positioning FIM
source: Organisation chart FIM 2006-01-12.ppt
Corporate BDO Board of Managing Directors Shared Services Facility Services Security Serv ices Arb o Services Corporate Control Control KLAS Corporate Information Office IS Personnel & Organization Passenger Business Commercial Network Inflight Services Flight Operat ions Ground Services Operat ions Control & Fleet Services Alliances KLM Cityhopper Cargo business Segments: fashion automotive sales & marketing pharma hi-tech Premium products: controlled VIC Express Specialties Engineering and maintenance
Wide body base maintenance Maintenence unit narrow body Line maintenance Enigine services Component services Charter/low cost business Transavia Holdings KAS KES KCS KFS Others Martinair Kenya Airways Others Financial information management Corporate Center General Secretariat, Legal & Government Affairs Finance Internal A udit Corporate Strat egy & Business Development Corporate Communications Corporate Procurement & Fleet Development
Appendix B: Control related documentation
KLM FIM CobiT control objectives11 Acquire and Develop Application Software
Risk: Unnecessary investments and inefficient ineffective and possibly incorrect financial
reporting (public opinion might be affected)
High –level control objective: Controls provide reasonable assurance that applications
and system software is acquired or developed that effectively supports financial reporting requirements.
Specific control objectives:
a) The organization’s SDLC (System Development Life Cycle) includes security, availability and processing integrity requirements of the organization.
b) The organization’s SDLC policies and procedures consider the development and acquisition of new systems and major changes to existing systems.
c) The SDLC methodology ensures that information systems are designed to include application controls that support complete, accurate, authorized and valid transaction processing.
d) The organization has an acquisition and planning process that aligns with its overall strategic direction.
e) IT management ensures that users are appropriately involved in the design of applications, selection of packaged software and the testing thereof (see control 14), to ensure a reliable environment.
f) Post-implementation reviews are performed on new systems and significant changes reported. (see control 14)
g) The organization acquires/develops systems software in accordance with its acquisition, development and planning process (see control 13).
FIM specific controls:
1) The Manager Development verifies that a specific Project Request is aligned with the strategic direction of Business and FIM and he checks the completeness of the requirements specification, before issuing a Project. For IS and AF sourced developments: IS and AF are regarded to be SOx compliant.
2) In the requirements of a project, the design decisions regarding i.e. the aspects security, availability, processing integrity and the application controls that support complete, accurate, authorized and valid transaction processing must be specified in the requirement or definition study.
3) The project plan and the requirement-specification is approved by the Client to make sure that they are adequate. Changes on requirements are logged within the project and reported to the Project Steering team or Client.
4) BC's and projects are evaluated by the business executive and approved within regularly held stakeholder meetings. For these meetings portfolio reports are available.
12 Acquire Technology Infrastructure
Risk: Risk of infrastructure conflict, high operational costs and low security control. High –level control objective: Controls provide reasonable assurance that technology
infrastructure is acquired so that it provides the appropriate platforms to support financial reporting applications
Specific control objectives:
a) Documented procedures exist and are followed to ensure that infrastructure systems, including network devices and software, are acquired based on the requirements of the financial applications they are intended to support
FIM specific controls:
1) If new applications are acquired KLM CIO IS is always involved in the project to ensure that IS infrastructural procedures are followed. An operating permit is required.
13 Develop and Maintain Policies and Procedures
Risk: Ineffective and inefficient Development process. All Development Sox controls
might become ineffective without working instructions.
High –level control objective: Controls provide reasonable assurance that policies and
procedures that define required acquisition and maintenance processes have been developed and are maintained, and that they define the documentation needed to support the proper use of the applications and the technical solutions put in place
Specific control objectives:
a) The organization's SDLC methodology and associated policies and procedures are regularly reviewed, updated and approved by management.
b) The organization ensures that its systems and applications are developed in accordance with its supported, documented policies and procedures.
FIM specific controls:
1) (Updates to) policies and procedures to develop, acquire and maintain systems and applications are reviewed and approved by management. A signed version is archived. NB: KLM CIO IS and Air France are considered to be Sox compliant. In case FIM executes projects and maintenance outside IS and AF, specific FIM procedures and policies are available
14 Install and test application software and technology infrastructure
Risk: Systems don’t perform as designed which may cause serious integrity and security
threats.
High –level control objective: Controls provide reasonable assurance that the systems are
appropriately tested and validated prior to being placed into production processes and associated controls operate as intended and support financial reporting requirements.
Specific control objectives:
a) A testing strategy is developed and followed for all significant changes in applications and infrastructure technology, which addresses unit, system, integration, and user acceptance-level testing to help ensure that deployed systems operate as intended
b) Load and stress testing is performed according to a test plan and established testing standards.
c) Interfaces with other systems are tested to confirm that data transmissions are complete accurate and valid.
d) The conversion of data is tested between its origin and its destination to confirm that it is complete, accurate and valid.
FIM specific controls:
1) Per applicable project a test-plan is available and filed. 2) Test and acceptation criteria are set up by Operations
3) The Operations business analyst and the Client (key-user) decide whether an application is ready for production based on the test results.
15 Manage Changes
Risk: Unauthorized or inadequately tested system changes are being moved to
production.
High –level control objective: Controls provide reasonable assurance that system changes
of financial reporting significance are authorized and appropriately tested before being moved to production.
Specific control objectives:
a) Requests for program changes, system change and maintenance (including changes to system software) are standardized, documented and subject to formal change management procedures
b) Emergency change requests are documented and subject to formal change management procedures.
c) Controls are in place to restrict migration of programs to production only by authorized individuals (addressed by KLM FIM specific control 19_1)
d) IT management ensures that the setup and implementation of system software do not jeopardize the security of the data and programs being stored on the system
FIM specific controls:
1) On a daily basis the Change Management coördinator registers the Change Requests that have been submitted by the appointed User Representatives. Registration is done in Clientele. The User Representative sents business approved Change Request to the Mailbox - Change Management SPL/BF. The incoming mails are stored in the same mailbox.
2) The change management coördinator check's if the change request is filled in correctly according to the Change Management procedure as set out in the Change management procedure document.
3) After registration the Change Request forms are sent to the User Representatives belonging to the application of the change. The User Representatives are
responsible to check the consequences of the change for the business. The evidence of the send Change Request from to the User Representatives can be found in Clientele.
4) After registration the Business analyst decides if the change request can be accepted by FIM. In case a Change Request is not accepted the status in Clientele will be set to "Cancelled" by the Business Analyst. An overview with change requests is available for all User Representatives.
5) After implementation or cancellation of the change the FIM employee informs the change requestor the Change Request can be closed. The Change coördinator will close the request after receiving an e-mail from the requestor stating that the
change is performed correctly and can be closed. The evidence can be found in the Change Management mailbox.
6) If a change makes a program change necessary the IS change procedures are followed.
7) Emergency changes or bug fixes are performed under strict supervision of Manager Operations plus Managers FAM
8) Emergency changes or bug fixes are documented in the Change Management directory via Change request form. The Manager operations and the teamlead have to approve before it is taken in production. This is done by Mail. The mail is printed and filed.
9) Software changes and releases that require more then 40 FIM hours are performed under projects. A Project Intake Form is written. See Cobit Areas 11 and 12. For smaller changes the User Representatives are responsible to check the impact of the change for their business. All involved User Representatives receive an e-mail with the change request from the Change management coördinator. See Cobit 15_04.
10) Standard changes are listed in the document: Fimdata/Change
Management/procedure/ Change management procedure.doc. In the application Clientele these changes are handled the same way as incidents.
16 Define and Manage Service levels
Risk: Services and performance levels are not clear or not in accordance with business
requirements.
High –level control objective: Controls provide reasonable assurance that service levels
are defined and managed in a manner that satisfies financial reporting system requirements and provides a common understanding of performance levels with which the quality of services will be measured.
Specific control objectives:
a) Service levels are defined and managed to support financial reporting system requirements.
b) A framework is defined to establish key performance indicators to manage service level agreements, both internally and externally.
FIM specific controls:
1) SLA with each business dept. in FIM service area, where Sox related applications are used, are completed, reviewed and signed by senior management (client and Manager Exploitation Management). Before the end of the SLA period, mngr Operations FIM checks, whether SLA's need to be added, cancelled or updated. 2) On a monthly basis the SLR is published on the financial portal.
3) On a weekly basis the continuity of business applications is evaluated with several KPI's in the Management Team meeting of FIM Operations (MT-O).
4) Business Services from Information Services to FIM are defined in a Business Agreement for each application. Business Agreement with each business
application (included SOx related applications), is completed, reviewed by senior management and approved (Manager Exploitation Management and Service Manager IS). By the end of each fiscal year, Manager Exploitation Management checks, whether application services in the Business Agreement need to be added, cancelled or updated.
5) The Business Agreement (SLA) between Corporate Control and KLM
Information services is managed by FIM Operations. Performance issues relevant for Information Services will be discussed with service manager KLM CIO IS. Minutes of meeting started from 2007.
18 Ensure Systems Security
Risk: Unauthorized access causing unauthorized financial transaction & corrupt database High –level control objective: Controls provide reasonable assurance that financial
reporting systems and subsystems are appropriately secured to prevent unauthorized use, disclosure, modification, damage or loss of data.
Specific control objectives1:
a) An information security policy exists and has been approved by an appropriate level of executive management.
b) Procedures exist and are followed to authenticate all users to the system to support the validity of transactions.
c) Procedures exist and are followed to ensure timely action relating to requesting, establishing, issuing, suspending and closing user accounts.
d) A control process exists and is followed to periodically review and confirm access rights.
e) Where appropriate, controls exist to ensure that neither party can deny transactions and controls are implemented to provide nonrepudiation of origin or receipt, proof of submission and receipt of transactions.
f) Controls relating to appropriate segregation of duties over requesting and granting access to systems and data exist and are followed.
g) Access to facilities is restricted to authorized personnel and requires appropriate identification and authentication.
FIM specific controls:
1) Each Division has appointed AO/IC representative e.g. key-user, controller, etc. who are responsible for requesting access rights for applications that are
maintained by FIM. This employee also checks if the requested authorization is in line with the set AO/IC rules as set out in the Accounting Manual. The request is send to FIM by E-mail to clientele helpdesk (FIM-ACS). The assigned FIM Application Manager will check that the request is done correctly. (Note: For various applications request forms are introduced since July 2006, an inventory was made of the users before this period)
2) Periodically a report is produced for all employees with the authorizations per division.
For FM2.0 authorization overviews are available monthly per division on the financial portal. For other applications this is done on various moments.
3) Segregation of duties and restriction of application functions within the
department FIM is monitored by Manager FIM operations according document FIM authorization matrix - signed.xls/pdf
4) Monthly a report is produced of all FIM employees with their authorizations per application.
5) Authorization Log file is maintained for FM2.0 application concerning admin rights as described in document: ‘procedure 6- en 4 sterren key BF.doc’
19 Manage the configuration
Risk: Corrupt data, unauthorized software is being used
High –level control objective: Controls provide reasonable assurance that all IT
components, as they relate to security, processing and availability, are well protected, would prevent any unauthorized changes, and assist in the verification and recording of the current configuration.
Specific control objectives2:
a) Only authorized software is permitted for use by employees using company IT assets.
b) Application software and data storage systems are properly configured to provision access based on the individual’s demonstrated need to view, add, change or delete data.
FIM specific controls:
1) Functional changes on configuration from Business Applications via projects are accepted by FIM Operations with signoff acceptation criteria document
AccepatiecriteriaKLM_BF xxxx.doc (xxxx = application name). Functional or corrective changes on configuration from Business Applications are described in CobiT 15_6, 15_7, 15_8, 15_9.
20 Manage problems and incidents
Risk: Problems and/or incidents are ignored, not recorded, resolved or investigated for a
proper resolution
High –level control objective: Controls provide reasonable assurance that any problems
and/or incidents are properly responded to, recorded, resolved or investigated for proper resolution.
Specific control objectives:
a) IT management has defined and implemented a problem management system to ensure that operational events that are not part of standard operation (incidents, problems and errors) are recorded, analyzed and resolved in a timely manner. b) The problem management system provides for adequate audit trail facilities,
which allow tracing from incident to underlying cause.
c) A security incident response process exists to support timely response and investigation of unauthorized activities (addressed by CobiT 18).
FIM specific controls:
1) Incidents are reported to the e-mail box FIM-ACS or by telephone on a daily basis. The intake desk registers the incident in the Call registration tool. 2) Performance reports of number of incidents, call to fix, etc are produced every
21 Manage data
Risk: Changes on storage data, done outside the process, may lead to incorrect or
incomplete data.
High –level control objective: Controls provide reasonable assurance that data recorded,
processed and reported remain complete, accurate and valid throughout the update and storage process.
Specific control objectives3:
a) Policies and procedures exist for the handling, distribution and retention of data and reporting output.
b) Management protects sensitive information, logically and physically, in storage and during transmission against unauthorized access or modification (covered by CobiT 18).
c) Changes to data structures are authorized, made in accordance with design specifications and implemented in a timely manner (addressed by 11, 14 and 15).
FIM specific controls:
1) In the HAP, guidelines for the handling, distribution and retention of financial data are given. Purging data is done under the strict rule that the Data owners give their authorization to purge. Strictly spoken the Data owner is responsible for archiving the necessary data for security reasons a back up of the data stored in the archive application is kept at FIM. The data is sent to the owners. Purging is an activity done on a yearly basis; the divisions give their approval by signing the purge document. This document is stored at FIM as E-mail and hard copy.
2) Patching the data, in a Business Application, is done according the documented patch procedure. The responsible FAM employee fills in the standard patch request form. This form must be approved by the Managers FAM (and Manager Exploitation Management in freeze period). After approval the patch can be executed, checked and the standard patch request form filed according the procedure.
22 Manage operations
Risk: Dump or run out of time from a scheduled program in which case the system is not available in time
High –level control objective: Controls provide reasonable assurance that authorized
programs are executed as planned and deviations from scheduled processing are identified and investigated, including controls over job scheduling, processing, error monitoring and system availability.
Specific control objectives:
a) Management has established and documented standard procedures for IT operations, including scheduling, managing, monitoring and responding to security, availability and processing integrity events.
b) System event data are sufficiently retained to provide chronological information and logs to enable the review, examination and reconstruction of system and data processing.
c) System event data are designed to provide reasonable assurance as to the completeness and timeliness of system and data processing.
d) End-user computing policies and procedures concerning security, availability and processing integrity exist and are followed.
e) End-user computing, including spreadsheets and other user-developed programs, are documented and regularly reviewed for processing integrity, including their ability to sort, summarize and report accurately.
f) User-developed systems and data are regularly backed up and stored in a secure area.
g) User-developed systems, such as spreadsheets and other end-user programs, are secured from unauthorized use.
h) Access to user-developed systems is restricted to a limited number of users. i) Inputs, processing and outputs from user-developed systems are independently
verified for completeness and accuracy.
FIM specific controls:
1) CobiT 22g and 22h are covered by CobiT 18 (FIM test of Controls 18_4) 2) All batches are scheduled and checked by checklist
3) To ensure that all data from all applications are processed and interfaced, the daily checklists provide all the checks, like JCL errors, record counts, rejections etc. 4) To ensure all authorized data is entered into and processed by the business
applications (by batch load job's) is done by providing the daily checklists. The checks are: record check on delivered vs. processed data, rejections, etc.
5) To ensure data entry design features contribute to data accuracy there're validation rules for programs.
6) To ensure data validation and editing are performed to identify erroneous data, see the checklists which provide checks on processing reports.
7) To ensure erroneous data are captured, reported, investigated and corrected this is done by using the checklists
8) To ensures that all daily input of transactions is processed in the financial accounts (e.g. Masterpiece and SAP the daily checklists are used
9) To ensure that all monthly input of transactions is processed in the financial accounts (e.g. Masterpiece and SAP) the monthly checklists are used. The checks are performed on working days -6 up to +7 by system managers.
10) To ensure that the accounting/reporting period is closed and complete, and also that the processed trial balance is in equilibrium (debit =credit) the monthly checklists are used.
11) To ensure that proper month rates have been used for revaluation of assets and liabilities from foreign currencies to reporting currency is done by using the checklists and working with a procedure.
12) To ensure the correct and complete downloads from Financial systems to reporting systems the checklist are used.
13) To ensure correct and complete implosion (summarization) of amounts on accounts from Posting level organizations to Division level organization specific checks are used.
14) To ensure that the accounting/reporting period is closed, is complete and that the processed trial balance is in equilibrium (debit =credit) the monthly checklists are used
15) To ensure that validated adjusting Journal entries are correctly input (via batch load jobs) and processed the checklists are used.
FIM applications versus CobiT controls, gap analysis and remediation
Positioning KLM FIM controls within an end-to-end business process = Scope KLM FIM ! " # $%%& '()*+,* ! * -) . / # 0 1 2 3 1 '' 4 , 5 * # , 6 ) '1 7 1 1 4 1 5 / . 1 8 1 9 :0; 9 2 < * ($ -) ( ( =&%> # ?< !""# 2 @ 9 ' 1 , 'A 1 " * 1 $ . / # B6 ('* ) ' % ' * & 1 ' ( * A, ' ( ( A 1 * A ) ) * + ,( - . ) /0 1 . / 1 ('& ( 'C ? 4 / 5 * * * + ( * 1 * 2 ' ( ''A # A ) -) A # ( A ' 9 ) 9 . / ('>$ ' / ! ' )A'
Sox system landscape = In scope for KLM FIM
FSCP daily routine
Appendix C: Testing related documentation
Testplan monitor FIMAppendix D: KLM QA rapports
Quality Assurance on Test Procedures, Test Reports and Objectivity and Independence of
Tester
Appendix E: Risk Navigator related documentation
Risk Navigator Process FlowExplaining Risk Navigator’s control documentation functionality
A. The ‘Control’ screen
Control screen (© 2005 Paisley Consulting)
Above, Risk Navigator’s control screen is pictured. In the control screen, an overview of all relevant control information is stated. All fields should be filled by the control owner. The screen shows eleven bullets, which will be discussed next.
a. Process Hierarchy
The process hierarchy shows the business process the control is related to. In the ‘Control’ screen, the related process is the Financial Statement Close, with Monthly Financial Reporting being the sub process.
b. Organizational Structure
Risk Navigator uses a layered structure in order to clearly define at which organizational level the control takes place. The organizational structure in the tool comprise five levels: Division, Business Unit, Region, Location and Process. A company thus is provided with a maximum of five levels to structure its controls. For example, CobiT 12 (‘Acquire Technology Infrastructure’) is a control related to organizational structure Air-France KLM, Royal Dutch Airlines, Corporate
uses five levels to clearly define where the control is situated within the Air-France KLM organization.
c. Scope
As Risk Navigator supports multiple corporate governance codes, a control can be related to more than one code. As the scope of this research solely comprises the Sarbanes-Oxley corporate governance code, it will not be further discussed here.
d. Control Detail:
The control detail comprises four elements: the associated Risk- and Control Models, the Control
Title and the Control Description. The risk model contains the information about the risk related
to the control, whereas the control model contains information about the Control Group and – Category it belongs to. For example, CobiT 15 (‘Manage Changes’) belongs to control group ‘CobiT’ and to control category ‘Manage Changes’. The control title and -description can then be used to describe the ten KLM FIM specific sub controls belonging to CobiT 15.
e. Control Rating:
The control rating screen consists of many parameters, some of high importance for ongoing documentation and testing purposes. It will be discussed separately below.
f. Issues:
In Risk Navigator, control deficiencies are called issues. Since issues concern control remediation, this subject will be discussed in paragraph 5.4.
g. Self Test:
Self-testing enables the control owner to review the quality of his or her own work. As the person performing the quality check is not independent of the tester, however, the external auditor cannot use the outcomes of self testing in its assessment of effectiveness of internal control over financial reporting.
h. Independent Test:
This concerns not only testing by the external auditor, but also by other employees independent of the work to be reviewed. Hence, in Risk Navigator’s terminology, KLM FIM business testing (discussed in paragraph 3.2) should also be addressed here. The ‘Independent Test’ concept will be discussed in the next paragraph.
i. Supporting Files and Links:
With the tool, it is possible to save evidential testing documentation by either storing the data in a database, or by providing a link where the test evidence is located.
j. Assignments:
Assignments can be compared to issues, although they are not specifically linked to control deficiencies. As assignments are not directly related to a required Sox 404 activity, they will not be further discussed in this thesis.
k. Historical Information:
Every time a control is changed, an archive is created in order to store all the previous versions of the control. In this way, the evolution of the control over time can be monitored.
As all eleven bullets have been discussed by now, the control rating bullet can be further explained. This will be done next.
B. The ‘Control Rating’ screen
Control rating screen (© 2005 Paisley Consulting)
The figure above shows the ‘Control Rating’ screen, which contains several parameters for documenting ongoing testing activities. Again, all fields should be filled by the control owner. Because of their relevancy for performing these activities, all eleven subjects will be explained below.
1. Control Type:
The control type specifies whether a control is for management review, reconciliation, authorization or other purposes. Only one control type can be selected. If a control concerns multiple mitigating functions, they can be chosen in the ‘Related Assertions’ field.
2. Control Classification:
Here, the control owner can appoint the control as operating either preventive or detective. Although not specified in paragraph 4.3.1 as a separate control category, the PCAOB (2006, p.185) calls the difference between preventive and detective controls important in assessing the extent of testing (2006, p.185): ‘Controls that are relatively more important should be tested more extensively. For example, some controls may address multiple financial statement assertions, and certain period-end detective controls might be considered more important than related preventive controls’.
3. Control Frequency:
The control frequency corresponds to the equally named control category, assessed in paragraph 4.3.1.
4. Control Automation:
This field corresponds to the ‘nature of the control’ category, discussed in paragraph 4.3.1. The control owner can assign that the control is performed either manual, automated or IT-dependent.
5. Importance:
This refers to the control category ‘importance of the control’, which can be high, medium or low.
6. Cost Rating:
This refers to the control category ‘materiality’. As the cost rating is associated with the
significance of the control, this field can be assigned as inconsequential, substantial, or material.
7. Design Effectiveness:
Although design effectiveness does not directly affect the extent of testing and hence does not relate to a previously defined control category, it is highly relevant to the documentation phase. After all, control documentation is completed only if all controls have been designed effectively. This field can be set at either high, medium or low.
8. Operational Effectiveness:
This field corresponds to the ‘operating effectiveness of the control’ category. Like design effectiveness, this field can be set at either high, medium or low. The control category, however, has been designed with operating effectiveness being either ‘yes’ or ‘no’. In this case, ‘yes’ equals high operating effectiveness, whereas ‘no’ equals low operating effectiveness.
9. Related Assertions:
With the related assertions field, the control owner can emphasize which information the control carries. For instance, the ‘completeness’ assertion addresses whether all transactions and accounts that should be presented in the financial statements are included. Within KLM FIM, CobiT 22 (‘Manage Operations’) is a good example of a completeness related assertion. As transactions are managed by the accounting system in batches, this CobiT control verifies that the complete batch has been processed. Note, that multiple assertions can be checked.
10. COSO Model Elements:
Here, the five elements of the COSO model can be picked. As the CobiT model has been used by KLM FIM instead of the COSO model, this field is not relevant here.
11. Control Conclusion:
Explaining Risk Navigator’s control remediation functionality
In Risk Navigator, control remediation comprises the elimination of issues. In paragraph 5.2, the subject was already touched upon when discussing the ‘Control’ screen (Appendix E, ‘explaining Risk Navigator’s control documentation functionality’). Here, it will be explained further.
Issue screen (© 2005 Paisley Consulting)
Above, the issue screen is pictured. It comprises eight bullets, of which five are editable (Process Hierarchy, Organizational Structure and Historical Information are all inherited from the ‘Control’ screen (Appendix E)). These five editable bullets will be discussed next.
a. Scope:
Already discussed in paragraph 5.2, the scope concerns only one corporate governance code: Sarbanes-Oxley.
b. Issue:
The issue consists of four parts: the ‘Issue Title’, the ‘Issue’ itself, ‘Recommendation’ and ‘Supporting Files’. The issue title is automatically copied to the issue screen, as can be seen in the ‘Issue’ screen. The issue itself comprise a clearly defined description of the deficiency, whereas the ‘recommendation’ field contains the suggested remediation. Finally, any documentation supporting the root cause of the deficiency can be linked to the issue screen by using the ‘Supporting Files’ feature.
c. Issue Coordinator:
The issue coordinator screen comprises three fields. The ‘Issue Coordinator’ field shows the person designated as responsible for the issue. For people, who are in any way involved with the remediation of the deficiency, an ‘Additional Readers’ section has been created. Here, personnel designated as additional readers have read-only access to the associated Issue form. Finally, a ‘People To Send Email On Close’ field has been included, so that personnel can receive email notification on the close of the related issue.
d. Action Plans:
When a recommendation for remediation has been written, an appropriate action plan has to be put into place. In this field, these plans can be written down.
e. Issue Status:
Issue Status screen (© 2005 Paisley Consulting)
As can be seen in the ‘Issue’ screen, the issue status concerns both ‘Status’ (the issue will remain open until the Process Owner closes it) and the ‘Expected Completion Date’, the date that the issue is expected to be completed. Although not a required field, and hence not visible in the ‘Issue’ screen, is the ‘Issue Priority’ field. This field is shown in above, and ranges from low to high. The issue can be even further categorized, using the ‘Issue Type’ and ‘Issue Group’ fields.
