RISK ASSURANCE FOR TRIPLE-BOTTOM LINE REPORTING USING SoDIS Krassie Petrova Auckland University of Technology, School of Computer and Information Sciences
[email protected] Rowena Sinclair Auckland University of Technology, Faculty of Business ( Accounting & Finance)
[email protected] Choon-Tuck Kwan Auckland University of Technology, School of Computer and Information Sciences
[email protected] Abstract Triple-bottom line reporting highlights the importance of social and community obligations in terms of indicators related to corporate governance and ethics, community and environment reporting, customer reporting, and shareholder value and extends the business goal of maximising profits and shareholder value to include the consideration of wider stakeholders’ interests. As an ethics-based analysis and inspection process that examines potential risks from the perspective of direct and extended sets of stakeholders, the Software Development Impact Statement (SoDIS) can be used as tool to achieve the objectives of triplebottom reporting and to highlight areas of potential modifications to business project definitions, requirements and implementation plans. The paper considers risk identification and assessment as two components of the broader process of risk management. A “risk assurance” approach towards the examination of risks is adopted, operating within the context of a business project activities serving as causal agents. Based on the assumption that business project success is enhanced by an appropriately high degree of risk assurance, the paper proposes a risk assessment framework aligned with the software auditing model of SoDIS and with the principles of triple-bottom line reporting. Key Words: Risk management; Risk assurance; Triple-bottom line reporting; SoDIS
1.
INTRODUCTION
Successful business information systems provide value-added information, which is used to manage the unique risks posed by information technology (IT). Information technology and information systems governance needs to be aligned with the overall corporate governance framework in order to facilitate meeting the business objectives and compliance obligations at the same time providing tools and mechanisms for managing risk and improving performance (KPMG, India, n.d.; KPMG UK, n.d.). Different architecture frameworks can be used to model and build a successful and dependable information system (Baskerville, 1993; Tang, Han & Chen, 2004). The
development cycle includes the stages of requirements gathering and analysis where the role of the framework is to provide and analyse systematically the information needed in the actual systems development. A substantial part of the information gathered is used for the evaluation of the risk related to the system and to the design of risk-minimising system controls. As business information systems become part of the security environment within which a contemporary inter- and intra-networked business operates, a paradigm shift can be observed. No longer is information security an afterthought, but a culture of security is actively being promoted by governments and governmental organisations. Information systems and networks are developed with a strong focus on security and “new ways of thinking and behaving when using and interacting” with and within information systems are adopted (OECD, 2002). The secure environment tends to make business stakeholders more dependent on the quality of information services, which need to provide reliable information. Therefore stakeholders’ interests need to be taken into account when designing effective systems where security related risks are managed based on informed decision making processes (ibid). This paper proposes a framework for deriving reliable and dependable information related to risk management, and is organised as follows: the first two sections define risk management and risk assurance and describes a performance measurement system called triple-bottom line reporting. The third section briefly discusses a software engineering -related framework for risk analysis. In the fourth section a framework for risk assurance is introduced. The conclusion section outlines directions for further research and some educational applications of the framework.
2.
RISK MANAGEMENT AND RISK ASSURANCE
There is no universally accepted definition for the term “risk” in business. However the Software Engineering Institute found that the characteristics “uncertainty” and “loss” were mentioned in many different definitions of risk (SEI, 2004). These terms put together can define risk as “the possibility that an event will cause an organisation to suffer unwanted consequences or losses”. A business needs to put in place a managerial mechanism to ensure that the business survives and continues to operate in the case of such an event. The successful implementation of the risk management plan depends on the reliability of the information gathered throughout the steps of the risk management methodology described below. 2.1 Risk Management Businesses need to assess the possibility of risk within their organisations both as a whole and for specific projects. Risk management is the methodology used for assessing the potential of future events to have adverse side affects. Hitchins, Hogg and Mallet (2001, p. 12-13) propose a four-step process for risk management (1) risk identification, (2) risk assessment and quantification, (3) risk limitation, (4) control evaluation. The first step (Risk identification) identifies the events that could cause loss in either the organisation being assessed or the particular project. The second step (Risk assessment and quantification) looks at the relevant information and assesses the likelihood of that particular event occurring. If the event happened then what would be the potential monetary effect for the organisation. Hall and Singleton (2004, p. 18) consider that a risk is essentially the potential threat to compromise the use or value of an organisation. The absence or weakness of a control is called an exposure. Exposures are essentially holes in the control shield of an organisation and increase the organisation’s risk to financial loss from undesirable events. This step is crucial in identifying what risks need to be actively limited. If not done effectively the potential risks will not be identified and major losses could result.
The third step (Risk limitation) involves organisations identifying what level of risk is acceptable and then minimising the likelihood of those events that could give rise to losses happening. As Greenstein & Vasarhelyi (2002) state a careful analysis of the risks must also be weighed against the cost of implementing associated prevention and detection devices. However, there must be a realisation that not all risks can be limited. For example to limit all risks in an eCommerce site would be to not allow access to customers! This leads to the balance between security and control versus risk. Finally, with Control evaluation the controls put in place to limit the risk need to be evaluated and tested to ensure they are adequate. The evaluation of controls is easier if a standardised approach is used which systematically identifies weaknesses and determines which are the most significant and require the greatest allocation of resources to correct them.
2.2 Risk Assurance As businesses today depend on information technology, of special interest are information security risk and its management. The methodology described previously can be applied to managing information security risk and thus can be used to address information security (Blakley, McDermott, & Geer, 2002). The process will depend on the quality and reliability of the information about risk which needs to be gathered in the first two stages as well as the information about the possibility and feasibility of prevention and/or protection (the third and the fourth steps). According to Gill, Cosserat, Leung and Coram (2001, p. 691) “assurance” is the level of satisfaction with respect to the reliability of information provided. The degree of satisfaction is determined by the objectivity of the evidence obtained. Both the information systems discipline and the accounting discipline provide assurances services – examples in the eBusiness domain include business-to-business assurance (SysTrust) and business-toconsumer assurance (CPA WebTrust). These services have started to extend the beyond the traditional “fairness of financial reporting” to include information quality and reliability assurance and business knowledge management assurance (Hunton, 2002). This paper uses the term “risk assurance” to identify the process of assessment and classification of risk by a method involves qualitative analysis and improves the reliability of the information provided. This is especially needed for performance measurement systems such as triple-bottom line reporting where there is a widening of the risks which businesses need to address.
3.
TRIPLE-BOTTOM LINE REPORTING
High-profile corporate failures such as Enron and WorldCom have highlighted a need to ensure that corporate governance needs to be more transparent. These examples of corporate greed and exploitation have, according to Tschopp (2003), created a renewed interest in compassion and sustainability. This has lead to the term “socially responsible” making a return to the global stage. Clikeman (2004) says how surprising it is that many leading organisation are increasing investor loyalty and enhancing their reputation by disclosing their “sustainable development” that is being socially responsible in terms of the environment and the society. There are numerous accounting information systems (AIS) whose purposes are to collect, process, and report information related to financial transactions (Gelinas, Sutton, & Oram, 1999, pp.1-15); in these, “risk” is in the domain of performance measurements systems that are solely financial. However, with the change to “social responsibility” there is a need to expand performance measurement systems to include both financial and non-financial
systems. One way of disclosing this is to ensure that corporate reporting goes beyond financial statements e.g. the profit and loss account which would be of interest to shareholders but include reporting of interest to the wider stakeholder community such as customers and the community. Triple-bottom line (TBL) reporting meets this need by reporting on environmental, social and economic performance. 3.1 Environmental Performance Sustainable development aims to maximise the efficiency with which energy and raw materials are used whilst minimising damage to the environment that the organisation’s products and processes could cause. Considering environmental impact includes looking at resources such as energy and water, and effects such as the generation of air pollutants and solid waste; some examples are given below. Energy: determining whether the organisation is efficient in the use of its energy. This looks at issues like what is the power source e.g. electricity, gas, solar and whether it is used with the minimal amount of wastage. Water: total water use and whether it is used appropriately. Emissions and waste: the waste coming from the products and processes of the organisation. What is the impact on the environment in terms of greenhouse gas emissions, pollution of water? What is the percentage of a product’s weight that is recyclable at the end of its useful life? 3.2 Social Performance Social performance is typically described in terms of the ramification of an organisation’s products and processes on people in the communities in which the company operates. This type of reporting deals with indicators related to business practices and responsibilities, as explained below: Labour practices: looking at the number of new jobs, number of work-related accidents and the training given to employees each year. Society: looking at corporate governance and the ethics of the organisation. Product responsibility: includes the monitoring mechanisms to ensure the product performs to expectation linking through to the results of customer satisfaction surveys. 3.3 Economic Performance This reporting indicator is similar to financial performance but is defined in terms of an organisation’s stakeholders, for example suppliers, employees, investors and the public sector. Suppliers: cost of goods, materials and services purchased. Employees: total salaries, wages and benefits paid. Investors: dividends paid, interest paid on loans and the change in retained earnings at the end of the reporting period. Public sector: taxes including income tax, goods and services tax, fringe benefit tax and charitable donations . 3.4 The Future of Triple-Bottom Line Reporting
TBL can improve risk management and lead to better business planning through sophisticated management systems, which also allow business to monitor performance (Environment Australia, 2003, p. 6). CPA Australia did a study into the top five hundred listed companies to determine the level at which TBL reporting is being used in Australia (Rice, 2004). Whilst only twenty-four of the companies produced TBL reports it was found that companies were realising that they would need to start reporting in terms of TBL under pressure from customers, shareholders and government to address factors such as environment and social performance - which are both features of TBL. In New Zealand, the Business Council for Sustainable Development has several members who have completed TBL reporting including The Warehouse Group Limited and BP Oil New Zealand Limited (NZBCSD, n.d.) However, Gray and Milne (2002) highlight that the quality of triple-bottom line reporting remains fairly poor. As reporting responsibilities grow wider, organisations need support in the effort of to assess an manage non-financial risks - where their expertise is not welldeveloped compared to the methodologies for dealing with financial risk already in practice. There is need for a risk assurance tool designed to improve the quality of information used by decision-makers - both financial and non-financial. This paper proposes a risk assurance framework based on the software auditing model of SoDIS (Software Development Impact Statement), which is described in the next section.
4.
SOFTWARE DEVELOPMENT IMPACT STATEMENT
Software development is a process that begins with the task of formulating requirements from the stakeholders of the finished software. Many software development failures can be attributed to poor requirements elicitation and specification. At the heart of this failure is the failure to completely identify all the stakeholders directly or indirectly affected by the software project and the finished product. Most software project managers would have little problem identifying the direct stakeholders of the project. They are usually the ones who pay for the development of or are the primary users of the software itself. The indirect users are a lot harder to identify. Under the tight constraints of time that most software development projects operate under, the developers or project managers usually do not make the effort to identify all the indirect stakeholders who will be impacted either socially or ethically by the software. Social and ethical impacts refer to those impacts that positively or negatively affect the circumstances, behaviours, livelihood or daily routine of others. Hence, for usability reasons, a dyslexic or a colour-blind person is a stakeholder in the development of a website that is to be widely used by the general public. The Software Development Impact Statements (SoDIS) process of software pre-audit (Gotterbarn, 2001) is based on research which indicated that the two primary causes of software project failures were poor risk analysis and too narrow an identification of project stakeholders. The latter was a key contributor to the former. The SoDIS process provides a practical method to help identify the direct and indirect stakeholders of a software project, analyse their concerns and the potential risks of the project and guide the formulation of risk mitigation measures. SODIS borrows from the concept of environmental impact analysis of sizeable engineering projects, which must satisfy the social and environmental concerns of communities impacted by the project. The SoDIS process consists of 5 phases (Gotterbarn, Clear & Kwan, 2004) as elaborated below. 4.1 Phase 1 (Context Scoping) In this phase, meetings are held between the SoDIS Analyst Team and the Software Development Project Team to understand the client’s perspective on the project and to identify the project’s direct and extended stakeholders. Project documents reviewed include the Project Plan, the Requirement Specifications and Tasks List. Meetings are held with the
technical project leader or developers to look at the technical issues while those with the business manager will look at the social and environmental issues surrounding the project. In addition to identifying the generic requirements and the list of affected stakeholders, the meetings would also yield some insight into potential problem areas (hotspots) and an initial list of concerns in the form of a Context of Concerns Statement. 4.2 Phase 2 (SoDIS Process Audit) Guided by the Context of Concerns Statement, the team would select the critical tasks or requirements for detailed analysis using the SoDIS Project Auditor (SPA), a software casetool. This tool will generate a list of ethics-related questions to examine the impact of each of the selected task or requirement on each of the stakeholders identified from Phase 1. This is a rigorous and iterative process aimed at identifying all the potential problems of the system as it relates to the stakeholders. Where such problems are identified, the team would examine the possible modifications to the project or the software product that will minimise the adverse impact on the stakeholders. This phase may also yield additional stakeholders that are overlooked from Phase 1. They should then be added to the Stakeholders’ List for analysis via the SPA. At the end of the iterative process, the tool produces the Software Development Impact Statement. This is a register of concerns and issues related to specific tasks and stakeholders. The actions for their potential resolution are also recorded in the project’s Positive Modifications Form. 4.3 Phase 3 (Concerns Clustering) The list of concerns generated from Phase 2 is then subject to further analysis to identify common threads running through them. Those with similar threads are grouped together and given appropriate cluster headings in a higher level abstraction. This cluster breakdown structure aids in effective communication with the Project Leader and Key Stakeholders. This taxonomy of clusters also allows for systematic evaluation of criticality and assignment of priority for further analysis and problem resolution by the project team and SoDIS analysts. 4.4 Phase 4 (Cluster-Guided SoDIS Analysis) Guided by the Software Development Impact Statement and the Taxonomy of Clusters, the analysis in Phase 2 and Phase 3 is repeated to see if there are any new concerns or stakeholders that are not evident initially. This iterative process is conducted until no new concerns or issues are identified. 4.5 Phase 5 - SoDIS Inspection Analysis Summary With the completion of the cluster guided SoDIS analysis, the SoDIS Inspection Analysis Summary is produced. This document shows the Cluster taxonomy with the priority of the clusters indicated. This will be used to determine what follow up actions need to be taken for the project to be continued in a positive direction or determine if it is to be terminated. It will also be used as a historical record for use on future similar projects. The SoDIS Inspection Analysis Summary including the list of positive modifications to the project will be given to management for further review. 5.
A FRAMEWORK FOR RISK ASSURANCE
The proposed framework for conducting risk assurance is shown in Figure 1, which is based on the five phases of the SoDIS methodology discussed above. A business analyst works with SoDIS to inform the SoDIS engine (question generator and reporting), introducing the triple-bottom line reporting contexts. The risk assurance methodology is based on the first two steps of risk management discussed earlier; notably “risk assessment” is extended to include qualitative assessment for the purposes of triple-bottom line reporting.
The risk identification process is facilitated by SoDIS assisted project scoping, audit and concerns clustering. The process produces and documents a set of outcomes: project requirements, projects tasks, project stakeholders (classified into “external”, “internal” and “extended”), and project risks. SoDIS uses these outcomes to perform cluster guided analysis – the stage at which risks are assessed qualitatively. Qualitative risk assessment enables risk classification according to the guidelines for triple-bottom line reporting (mostly social and environmental). At this stage risk severity is also assessed and priorities for risk minimization are assigned.
Figure 1. Risk assurance framework Based on the outputs achieved so far, SoDIS generates an inspection analysis summary, which is used as the basis of the risk assessment report. This report might include the results of a non-SoDIS based quantitative risk assessment, if appropriate. The reliability of the information presented in the report is achieved through an elaborate and detailed interaction between the team of analysts and SoDIS, and rigorous documenting of all intermediary steps. The interaction is open and allows external sources to be consulted and used when needed. Generating, managing and integrating business knowledge assisted by advanced IT tools and systems such as SoDIS is positioned at the high value end of the accounting value chain proposed by Hunton (2002). The risk assurance framework introduced above is designed to
add value to the business organisation by preparing the grounds for triple-bottom line reporting on a particular business project. First of all, a reliable and detailed classification of the risks pertinent to a business project is produced with all supporting information stored and available for re-inspection and re-assessment. Secondly, the framework builds a stakeholder identification and classification scheme and takes into account stakeholder “fairness’ considerations (Roberts & Mahoney, 2004). Among the drawbacks of the approach is the need for end-user training and cost- and time requirements (such as the initial setup cost for the acquisition of the software, and the need to spend a significant amount of time interacting with SoDIS and re-iterating some of the steps, as well the need for voluminous manual data input). 6.
CONCLUDING REMARKS
Pat Waite (2003) - a past president of the Institute of Chartered Accountants of New Zealand states that it is a shared responsibility of legislators, regulators, directors, management, auditors, investors, educators to improve corporate reporting. Organisations have started to adopt environment-related management procedures, including risk management (Frost & Wilmshurst, 2000; Boehm, Huang, Jain, & Madachy, 2004). This paper introduces and describes a framework for risk assurance, which aims to improve the quality of risk analysis. The framework is derived from the SoDIS methodology and completes the first two steps of the overall risk management cycle – risk identification and risk assessment. The framework identifies both man- and machine-produced outputs and shows the interactive and iterative nature of the IT- assisted process. The final risk assurance report incorporates the outcomes of the qualitative risk analysis and prepares the grounds for triple-bottom line reporting. Quantitative assessment can be added, based on sources external to the framework. The deployment of SoDIS for risk assurance provides several directions for further research such as: the redevelopment of the SoDIS engine to enable risk assurance for a broad range of business projects; the development of pre -defined reusable templates for risk identification based on questionnaires and other resources available in the literature (for example, Baskerville, 1993); the development of templates aimed specifically at information risk assurance as it is important to classify threats in information systems in order to minimise their vulnerability (Farahmand, Navathe, Sharp & Enslow, 2003) and build the foundation for the analysis of the return on security investment (Gordon & Loeb, 2002; Cavusoglu, Mishra, & Raghunathan, 2004). An educational institution might provide a suitable environment for testing the framework with regards to information security, including eCommerce settings. A useful synergy might be developed by forming a team of SoDIS and business analysts (Gotterbarn & Clear, 2004; Hunton, 2002). 7.
REFERENCES
Baskerville, R. (1993). Information systems security design methods: Implications for information systems development. ACM Computing Surveys, 25(4), pp. 375-414. Blakley, B., McDermott, E., & Geer, D. (2002). Information security is information risk management. Proceedings of NSPW’01, pp. 97-104. Boehm, B., Huang, L., Jain, A., & Madachy, R. (2004). The Nature of Information System Dependability: A Stakeholder/Value Approach. USC-CSE. Retrieved October 12, 2004 from www.cebase.org/hdcp/events/June04Workshop/ documents/boehm%20%20information%20system%20dependability.pdf Cavusoglu, H., Mishra, B., & Raghunathan, S. (2004). A model for evaluating IT security investments. Communications of the ACM, 47(7), pp. 87-92.
Clikeman, P. M. (2004). Return of the socially conscious corporation. Strategic Finance, 85(10), pp. 22-27. Environment Australia (2003). Triple-Bottom Line Reporting in Australia. A Guide to Reporting Against Environmental Indicators. Farahmand, F., Navathe, S., Sharp, G., & Enslow, P. (2003). Managing vulnerabilities of information security incidents. Proceedings of ICEC03, pp. 348-354. Frost, G., & Wilmshurst, T. (2000). The adoption of environment-related management accounting: An analysis of corporate environmental sensitivity. Accounting Forum, 24(4), pp. 344-365. Gelinas, U. J., Sutton, S. G., & Oram, A. E. (1999). Accounting Information Systems (4th Edition). Cincinnati: South-Western College Publishing. Gill, G.S., Cosserat, G., Leung, P. & Coram, P. (2001). Modern Auditing & Assurance Services (6th Edition). Milton, Queensland: John Wiley & Sons Australia Ltd. Gordon, L. & Loeb, M. (2002). The economics of information security investment. ACM Transactions on Information and System Security (TISSEC), 5(4), pp. 438- 457. Gotterbarn, D. (2001). Understanding and reducing project failure: The ethics of project management. A keynote paper delivered at the 14th NACCQ Conference, Napier, New Zealand. Gotterbarn, D.& Clear, T. (2004). Using SoDIS™ as a risk analysis process: A teaching perspective. Proceedings of ACE2004. Gotterbarn, D., Clear, T., & Kwan, C. (2004). Managing software requirements risks with software development impact statements. Proceedings of the 17th NACCQ Conference, pp. 71-78. Gray, R. & Milne, M. (2002). Sustainability Reporting: Who’s Kidding Whom? Chartered Accountants Journal, July, pp. 66-70. Greenstein, M. & Vasarhelyi, M. (2002). Electronic Commerce: Security, Risk Management, and Control (2nd Edition). New York: McGraw Hill. Hall, J.A. & Singleton, T. (2004). Information Technology Auditing and Assurance (2nd Edition). Ohio: South-Western Hitchins, J., Hogg, M. & Mallet, D. J. (2001). Banking: a regulatory accounting and auditing guide (2nd Edition). London: ABG. Hunton, J. (2002). Blending information and communication technology with accounting research. Accounting Horizons, 16(1), pp. 55-67. KPMG India (n.d.). Information Systems (IS) Governance. Retrieved October 12, 2004 from http://www.in.kpmg.com/services/services_assurance_nav2.html. KPMG UK (n.d.). Information Systems Governance. Retrieved October 10, 2004 from http://www.kpmg.co.uk/services/ras/irm/isg.cfm. NZBCSD (n.d.). New Zealand Business Council for Sustainable Development. Member Involvement. Retrieved October 16, 2004, from http://www.nzbcsd.org.nz/ sdr/content/asp?id=95 OECD (2002). OECD Guidelines for the Security of Information Systems and Networks: Towards a Culture of Security. OECD, Paris. Rice, M. (2004). Bottoming Out. Australian CPA, 74(8), pp. 26-31. Roberts, R. & Mahoney, L. (2004). Stakeholder conceptions of the corporation: Their meaning and influence in accounting research. Business Ethics Quarterly, 14(3), pp. 399-431. SEI (2004). Definition of Software Risk Management. Retrieved October 17, 2004, from http://www.sei.cmu.edu/programs/sepm/risk/definition.html. Tschopp, D. (2003). It’s time for Triple-Bottom Line reporting. The CPA Journal. 73(12), p.11.
Waite, P. (2003). Improving corporate reporting – a shared responsibility. Chartered Accountants Journal. June, p.1.
