Post-Master Thesis
In-memory databases from an IT audit
perspective
Student Name: Chi Kin Cheng, MSc Studentnumber: 1203991
Thesis number: 2037
Email: [email protected]/[email protected]
Date: August, 2014
Thesis Supervisor VU: Dr. Wiekram B. Tewarie RE
Second Reader: Chiel Meulendijks (Manager IT Audit PwC) Postgraduate IT Audit, Compliance & Advisory
Faculty of Economics and Business Administration (FEWEB) Vrije Universiteit Amsterdam
Preface
This thesis is written as part of the Postgraduate program IT Audit, Compliance and Advisory of the Faculty of Economics and Business Administration of the Vrije Universiteit Amsterdam. Its students are required to conduct research and write a thesis in the field of IT auditing in order to finalize the program. This thesis is written at the PwC Amsterdam office.
I would like to thank Wiekram Tewarie, the thesis supervisor, for his patience, support and feedback during the process of writing this thesis. Many times I had different priorities in my life and work that lead to postponing and delaying the finalization of this thesis. Wiekram has kept me on track by supporting and motivating me to finish what I have started. I would like to thank the teachers and professors of the Vrije Universiteit for guiding me and teaching me valuable insights that I can use in my daily work.
Furthermore, I would like to thank PwC for providing me with the information and knowledge that has enabled me to perform this research. I would like to thank Chiel Meulendijks, manager IT audit at PwC, for co-reading this thesis and providing me with interesting insights that improved the quality of this thesis.
Finally, I would like to thank my family and loved ones for their patience and support. After a long time I am finally able to finish what I have started.
Chi Kin Cheng
Rotterdam / Amsterdam, The Netherlands September 2014
Abstract
In-memory databases (IMDB) are a type of databases where data is stored entirely on the main physical memory of the system (DRAM). This is different compared to traditional databases (TDB), where data is stored via a persistent disk storage mechanism. The main advantage of IMDB is this performance increase: Since data is directly available in memory, IMDB can provide much better response times and transaction throughputs compared to the TDB. In the recent years, due to the dropping prices for DRAM and increasing demand for higher database performance, several providers, such as SAP and Oracle, are introducing products that are based on the in-memory technology to meet their clients’ demand.
A lot of research has been conducted to the added (business) value of in-memory databases. However, when looking at IMDB from an IT audit perspective (in terms of database continuity and database security) as part of a financial statements audit, there are not many studies conducted on the impact of IMDB on the financial statements. Therefore, the main question of this study is: do the current audit standards and principles for databases cover the risk associated with the usage of IMDB?
In-memory databases introduce a number of risks that are inherent to the technology, which are not present in a traditional database environment. Firstly, from a data continuity perspective, data stored in the main memory is volatile of nature, which increases the risk of data loss at the event of system error/failure. Secondly, from a data security perspective, access to the main memory should be sufficiently restricted in order to prevent unauthorised access to the data. This study has noted that the two mentioned risks can be covered by the existing audit standards and principles. This is illustrated by one practical example: the SAP HANA IMDB environment. Within SAP HANA, traditional database controls, such as logging, access management and back-up and recovery measures are applicable. The theory is validated through the usage of the Expert Opinion method, where four experts in the field of IT audit are consulted. Based on interviews and open discussions, the findings of this study have been acknowledged by the experts.
This study concludes that the audit standards regarding traditional database controls are also applicable to an in-memory database environment; the audit standards also cover the risk associated with in-memory databases. The actual implementation (such as configuration settings, hardware set-up) of these controls may differ (i.e. due to the technical differences between traditional databases and IMDB), but the controls can be implemented in a similar way. It is recommended that during the definition of the IT audit approach, the risks should be carefully considered when the audit object is an IMDB. The findings of this study can provide guidelines to properly plan the IT audit approach as part of the financial statements audit.
This study has several limitations: the technical differences between traditional databases and IMDBs are not in scope for this research and therefore any risks related to the design differences are not regarded in this research. Furthermore, this study is conducted in the context of a financial statements audit. Other types of audits such as technical security audits or compliancy audits have different objectives compared to a financial audit and might provide new perspectives on the risks related to IMDB.
Table of Contents 1 Introduction ...5 1.1 Problem description ... 6 1.2 Research Objective ...7 1.3 Research Question... 8 1.4 Research Design ... 9
1.5 Research Scope & Limitations ... 9
1.6 Research Relevance ...10
1.7 Structure of Thesis... 11
2 In-Memory Databases ... 12
2.1 Traditional Databases (TBD) ...12
2.1.1 The Database Concept...13
2.1.2 The Physical Database design...13
2.1.3 Database Risks...14
2.2 In-Memory Databases ... 15
2.2.1 The History of IMDB – The need for IMDB ... 15
2.2.2 The Characteristics of IMDB...18
2.3 Main differences between traditional Databases and In-Memory Databases ... 20
2.4 Risks from associated with In-Memory Databases ... 22
3 Audit Standards and Principles regarding databases...25
3.1 IT audit as part of the financial statements audit... 25
3.2 Audit standards and principles for databases... 30
3.3 Audit standards applied to risks associated with In-Memory Databases ... 32
3.3.1 Control Implementation In-Memory Databases: Database Security ... 33
3.3.2 Control Implementation In-Memory Databases: Data Continuity ... 36
3.3.3 Summary of database controls – in-memory databases ... 38
4 Validation – Expert Opinion Method... 40
4.1 Define Problem Statement and Problem Background ...41
4.2 Select Experts based on a Set of Criteria ...41
4.3 Design Interview... 42
4.4 Elicit Opinion: Conduct Interview... 43
4.5 Aggregation of Collected Data ... 43
4.6 Analysis and Conclusion ... 48
4.7 Limitations and Validity Threat of the Expert Opinion Method ... 49
5 Conclusion... 51
5.1 Main Findings... 51
5.2 Limitations...53
5.3 Recommendations for Further Research ...53
6 References ...54
1 Introduction
As part of the Postgraduate IT audit course at the Vrije Universiteit Amsterdam, her students are required to conduct scientific research and write a thesis on a topic that is relevant to the Postgraduate IT audit course. The topic of this thesis is in-memory databases (IMDB) and the impact on the IT environment from a financial audit perspective.
While performing financial audits for the purpose of annual reporting as an external auditor, the IT audit component in such audits is increasing in importance; financial data and transactions are processed and stored in IT systems (such as ERP solutions), therefore the work performed by the IT auditor is of increased relevance for the auditing of financial statements. In the recent years, organizations are continuously developing and implementing new IT solutions in order to support and optimize their business processes by aligning the business strategy with the IT strategy (Business- IT alignment). Furthermore, technical developments are also impacting the design of the business processes and the function of IT within an organization, such as cloud based storage and services, mobile devices, social media and the improvement of access speed to management information via the introduction of in-memory databases.
In-memory databases (IMDB), also known as main memory databases (MMDB), are a type of databases where the storage of data relies on the main memory of the system; data is stored entirely on the main physical memory of the system (DRAM). This is in contrast with traditional databases (TDB), where data is stored via a disk storage mechanism and the memory is used for caching (storing temporary data) and other computational activities. The key difference between IMDB and TDB is that IMDB do not rely on persistent data storage and eliminate sub-systems (such as storage I/O control) that support that storage. IMDB keeps data in one place, in the main memory, during data processing rather than moving it around. TDB requires an application to read a piece of data from a traditional database, modify it and write that data back to the database. This process requires time and CPU cycles, which inherently cannot be avoided in a traditional database. In contrast, the same process using an IMDB entails a single data transfer from the database to the application, and back again. The main advantage of IMDB is this performance increase: Since data is directly available in memory, IMDB can provide much better response times and transaction throughputs compared to the TDB (Garcia-Molina & Salem, 1992). The access time for main memory is orders of magnitude less than for disk storage (Garcia-Molina & Salem, 1992).
Although this concept is not new, (research on this subject has been conducted dating back in the 1980s, such as DeWitt et al. 1984), this concept is becoming more relevant since more and more companies are implementing this concept as part of their ERP solution. Since the market price for memory is dropping, the economic incentive to use the memory for primary data storage is increasing. ERP suppliers have already made IMDB products commercially available, for instance
SAP introduced her product SAP Hana in 2010, Oracle came up with her own productline Oracle TimesTen In-Memory Database in 2005. The introduction of these new solutions is mainly focused on providing added value to the client in terms of dramatically improved performance and providing aggregated and complex management information in a real-time fashion. Furthermore, a lot of research has been conducted on the added value to the business based on the advantages of IMDB compared to the traditional databases (Loos et al. 2011). However, when looking at IMDB from an IT audit perspective (such as database continuity and database security), what are the differences between the traditional database and IMDB and the risks associated with this new technology?
This chapter will continue with the problem description, research objective and research question in order to further explore the differences between TBD and IMDB.
1.1 Problem description
In the current International Standard of on Auditing (ISA), it is described that IT also poses specific risks to an entity’s internal control and therefore, increasing the risk of material misstatements, such as unauthorized access to data or potential loss of data or inability to access data as required. (ISA315 revised, 2013). Therefore the IT environment is an important aspect as part of the entity’s internal control environment. Furthermore, according to ISA 315.18 and ISA315.21, it is required for the external auditor to ‘understand how the entity has responded to risks arising from IT, including the related business processes, relevant to financial reporting to maintain the integrity of information and security of data’(ISA315 revised, 2013).
The database is a crucial component of the IT infrastructure, as the database is the place where all financial transactions are initiated, recorded, processed and reported. Therefore it is important to assess the database controls as part of the IT audit.
Since the implementation of IMDB in the business is relatively new concept, a lot of organizations are exploring the possibilities of using IMDB for their business. On one hand, IMDB promises a lot of (business) advantages: faster (near real-time) data processing, response time and transaction throughput compared to traditional databases. On the other hand, from an IT audit perspective, not a lot of research has been conducted yet to address the technological consequences implementing IMDB and the differences between IMDB and the traditional databases. A lot of organizations are struggling at the moment to develop a business case for implementing IMDB.
The differences between IMDB and traditional databases in terms of the database mechanism may result to new risks that are not present in the traditional databases. For instance, one potential disadvantage of IMDB is that the data storage in the main memory highly volatile and is not persistent and therefore increasing the risk of data loss at the event of a system failure, whereas disk storage is considered passive/persistent and does not need active measures to store
and retain the data. As a result of the shift in technology and the inherent risks involved, this may lead to changes in the audit approach regarding database security and continuity aspects.
Regarding risks on traditional databases level (extracted from the PwC Audit Guide. 2013), the following risks might apply IMDB from an audit perspective:
Database Security: Risk of unauthorized access to the database - How is access managed in IMDB?
Database Continuity: Continuity risks such as accidental system shutdown or the incorrect restore of data: What are the measures available in IMDB to assure continuity of the data?
Access to data is a routine and essential aspect of operating most computerized accounting systems (often as part of an Enterprise Resource Planning solution, ERP). The Information Technology General Controls (ITGCs) will often contribute indirectly to the achievement of many or all financial statement assertions, such as completeness (all financial transactions are recorded) and accuracy (financial transactions and other data related to recorded transactions and events are recorded appropriately). This is because effective ITGCs ensure the continued effective operation of application controls and automated accounting procedures that depend on computer processes (PwC Audit guide, 2013, based on ISA330). IT poses specific risks to an entity’s internal control (PwC Audit Guide, 2013, based on ISA 315.A56), including:
Reliance on systems or programs that are inaccurately processing data, processing inaccurate data, or both
Unauthorized access to data that may result in destruction of data or improper changes to data, including the recording of unauthorized or non-existent transactions, or inaccurate recording of transactions. Particular risks may arise where multiple users access a common database
The possibility of IT personnel gaining access privileges beyond those necessary to perform their assigned duties thereby breaking down segregation of duties
Unauthorized changes to data in master files
Potential loss of data or inability to access data as required
The risks are addressed during the audit procedures performed during the IT audit, by testing the corresponding IT General Controls that cover these risks as part of the audit of the financial statements of a company. Do the differences between traditional DMBS and IMDB have impact on the risks identified in this section? Both elements will be combined in the next sections, where the research objective and research question will be formulated.
1.2 Research Objective
This section describes the objective of this research. The general objective of this research is to contribute to the development of a theory to provide insight to the development of IMDB in
relation to the IT audit as part of the financial statements audit. Furthermore, this research also contributes for organizations that are exploring the possibilities to implement IMDB. By researching the differences between the traditional databases and IMDB, this research will aim on identifying whether the current set of audit standards and principles regarding database audits are also relevant for IMDB.
1.3 Research Question
The purpose of this research is to identify the audit risk associated with IMDB. Based on these risks, the current set of audit standards and principles is used to map the current database security and database continuity controls to IMDB. Therefore, the main research question of this study is:
What existing audit standards and principles regarding database security and database continuity cover the risks associated with In-Memory Databases (IMDB)?
In order to address the main research question, the following sub questions are formulated, divided into the following sections:
Theoretical perspective:
Section 1: In-Memory Databases
1: What are the key differences between the in-memory database and the traditional database?
2: Based on these differences, what are the specific risks associated with in-memory databases?
The answer to the abovementioned sub questions in section 1 will lead to an identification of risks that are specifically applicable to IMDB, but not to the traditional databases.
Section 2: Audit Standards and Principles regarding databases
3: What are the current set of audit standards and principles regarding database security and database continuity that apply to the traditional databases?
4: Do these standards cover the specific risks associated with In-Memory Databases?
The research questions from section 1 and 2 are evaluated from a theoretical perspective. The output of section 1 and 2 will provide the theoretical background in order to answer the main research question. Thereafter, the output of the section 1 and 2 is used as a basis for validating the research from a practical perspective:
Practical perspective:
5: To what extent does the theory, as researched from sections 1 and 2, apply in a practical environment?
The validation of the theory will be conducted based on validation interviews with experts and experienced practitioners in the field of audit.
The results will lead to answering the main research question from a practical perspective, yet grounded in a theoretical perspective.
1.4 Research Design
In order to provide an answer to the main research question and its sub questions, the research will be conducted via a literature study. The answers to the sub questions in section 2 (see chapter 1.3) will result in the mapping of the current audit standards with the identified risks from section 1. Based on the results of section 1 and 2 (see chapter 1.3), a possible gap will be identified for auditing IMDB with the current set of audit standards. Based on the gap, recommendations will be formulated to address this gap.
The output of sections 1 and 2 will be used as input to conduct the research from a practical perspective. During the practical phase, the formulated theory (the answer to the main research question) will be validated on relevance based on interviews with experts in the field of IT database audit based on the Expert Opinion Method.
As a result of the research conducted from a theoretical and a practical perspective, the main research question will be answered. The conclusion and possible recommendations for further studies will be formulated.
1.5 Research Scope & Limitations
This scope of this research will be exploring the main differences between IMDB and the traditional databases, the associated risks that are involved with IMDB and the mapping these new risks to the current audit standards and principles of ISACA for database security and database continuity (ISACA, 2013). This study will focus on the differences between IMDB and traditional databases on conceptual level, thus the (technical) architectural differences, implementation consequences will not be discussed in this study.
This study will focus on the database risks and controls as part of the IT General Controls (ITGC) in the context of the audit of financial statements. The audit standards researched in the context of this study are based on the International Standards of Auditing (ISA). Several other standards are considered (such as Cobit, NIST), but these standards do not provide additional standards for databases that are not already covered by the ISA regarding the financial statements audit. Since this study is related to databases in the context of financial statement audits, this study will put an emphasis on databases where financial transactions are recorded. Typically, this will be databases that are part of an ERP solution, where transactional data such as purchase orders,
invoices and journal entries are recorded. Databases that are used for management information (such as data warehouses) will not be addressed in this study.
From an IT audit perspective, this study will only highlight the risks and controls regarding databases. This study is not meant to provide comprehensive guidelines on controls testing such as how to assess design, implementation and operating effectiveness of controls, nor presents an exhaustive list of database controls to support the financial statement audit.
Furthermore, other aspects regarding databases access and security will not be part of the scope for this research, as illustrated in the figure below. Only the database (represented as ‘data’ in the figure below) will be the object of this study:
Figure 1-1:Layers of security (PwC Audit guide 2013)
All adjacent layers, such as the Application layer, Operating System layer and the Network layers are not in scope for this research.
1.6 Research Relevance
This research is relevant for both academic world as well as the organizations that are exploring the possibilities to adapt the IMDB into their own business. At the moment, there are a number of providers that are introducing IMDB as platform as part of the ERP business solutions for their clients. Organizations are still struggling to discover and incorporate the advantages of IMDB that will help them reach a competitive advantage. This study will provide a comparison of the traditional databases and IMDB in terms of risks to facilitate organizations in their choice.
Furthermore, from an IT audit perspective, the introduction of IMDB may have consequences to the way an IT audit is currently performed as part of the financial statement audit. Since the technology of data storage and retrieval in IMDB is conceptually different to the traditional DMBS, the current audit standards may not be sufficient to address the risks related to IMDBs. This exploratory study will provide insight to IT auditors, such as an external IT auditor of an accounting firm, in order to address the risks related to an IMDB during an IT audit.
1.7 Structure of Thesis
The objective of this study is to provide insight in the IMDB risks compared to the traditional database environment. To reach this objective, this thesis is divided in the following chapters:
- Chapter 1 describes the problem description and research question. The research design, research scope and research outline are defined in this chapter.
- The first part of chapter 2 provides an overview of the traditional database concept: what is a database and what are characteristics of a database and what are the associated risks? The second part of chapter 2 describes the concept of in-memory databases in more detail. Chapter 2 concludes by comparing the differences between DMBS and IMDB and the associated risks.
- Chapter 3discusses the understanding of an IT audit as part of the financial statements audit. The different aspects of an IT audit (the different domains of the IT general controls) will be briefly explained. The second part of this chapter describes the risks and controls in an IT audit setting when auditing a traditional database environment. The differences between IMDB and traditional databases, as identified from chapter 2, will be applied to the risks of controls in order to provide an answer to the main research question of this study.
- Chapter 4 discusses the validation of the results of chapter 3. The validation is performed through peer review. The output of this research is feedback from the interviewees regarding the validity and reliability of results of this study.
- Chapter 5presents the conclusion and main findings of this study, as well as limitations of this research and also provides some recommendations for further research.
2 In-Memory Databases
In this section, the following two sub-questions will be answered, as described in the previous chapter:
1: What are the key differences between In-Memory Databases and the traditional database management systems?
2: Based on these differences, what are the specific risks associated with In-Memory Databases?
Based on the answers for these two research sub-questions, the main (conceptual) differences between IMDB and the traditional DMBS will be identified and the risks associated with In-Memory Databases will be highlighted.
Before focusing on answering the sub-questions, this chapter will commence with describing the characteristics of the traditional DMBS. Thereafter, this chapter will continue with providing an understanding of the IMDB and the differences between traditional databases and IMDBs. This chapter will conclude with identifying the risks that are associated with In-Memory Databases, based on the differences with the traditional databases in order to provide answer to the sub-questions.
2.1 Traditional Databases (TBD)
This section describes the characteristics of the traditional database management systems, the use of a ‘database’ and the supporting software known as ‘database management system’ that controls and oversees the ‘database environment’ (Gillenson, 2012). The relation to risks related to the audit of financial statements is described in the next chapter.
A database is a concept that represents the collection of organized information into data and assembled in a structured way to serve a particular purpose (Gillenson, 2012). The database provides a manner to manipulate, store and retrieve data in an effective manner with the use of specialised software called database management systems (DBMS). According to Elmasri & Navathe (2006), the DMBS is a collection of software application that allows the user to define, construct, manipulate and share databases amongst various users and applications. The collection of different databases and the supporting database management systems is called thedatabase environment.A database environment is designed to allow storage of large volumes of data and provides access to data, both to applications (such as Enterprise Resource Planning software solutions) as well as end-users. Furthermore, the database environment also supports a variety of functionalities, such as data sharing, controlling data redundancy, data accuracy improvement and provide tools to control data security/privacy and business continuity measures, such as back-up and recovery (Gillenson, 2012). The database as a concept is further elaborated in the following section.
2.1.1 The Database Concept
The database concept is not an isolated element, but is part of the information systems environment. This environment consists of a collection of components such as hardware, networks, application software, systems software and the database. The database concept allows access to data by an Enterprise Resource Planning (ERP) system as part of an enterprise resource. The ERP system is a collection of applications that supports the business processes of an organization, such as purchasing, sales and the financial administration. The database of an ERP provides centralised access to shared data within the database and therefore support multiple business processes from a centralized enterprise resource. There are two key principles that are relevant in the database environment in relation an ERP system: Data Integration and Data Redundancy.
Data integration is related to the ability to combine different data elements within an ERP environment. For instance, supplier master data (such as the supplier’s name, address and payment related information) is related to a purchase order that has been placed at this supplier (the types of items ordered, quantity and price information). Data integration allows the data to be combined and made accessible, therefore providing answer to the questions such as: what items are purchased at this particular supplier in the past month?
Data redundancy refers to the information that has been stored more than once in an information system. This is the exact opposite of data integration, as data redundancy is the storage of redundant data that leads to waste of precious storage space. Therefore the key is to optimize data integration and minimize data redundancy, which results in more efficient storage, and shorter seek/response times.
2.1.2 The Physical Database design
This section describes the physical design of the database concept. Typically, computers execute programs and process data using the CPU and stores temporary data in the main memory during processing. Since the main memory is usually very fast, this allows the performance of data processing to reach a desirable level (Garcia-Molina, H. & Salem, K., 1992). However, there are several disadvantages within this concept. First, the main memory is relatively expensive and therefore not suitable to install in large quantities in order to support the vast volume of business data. Secondly, main memory is not portable and therefore not transferable. Lastly, the main memory is not designed persistent storage of data and therefore the data in the main memory is highly volatile; if the power source is disrupted data in the main memory is lost.
Therefore, in a traditional database design, the data is stored on a secondary memory device, such as a physical disk (magnetic disks) or a portable medium such as magnetic tapes and optical media. Magnetic disks are often arranged in one or more platters on which data can be stored magnetically. Access to data on magnetic disks is handled using specialised I/O algorithms that handles the basis retrieval and manipulation of data, such as ‘read’, ‘insert’, ‘delete’ and ‘update’ activities.
2.1.3 Database Risks
In order to have a functioning operational database environment, there are certain risk areas regarding database control that needs to be addressed. These issues can be classified into the following two areas:
Database security
Database continuity
This section will provide more detail regarding these two risk areas in general. In the next chapter, these risk areas will be related to actual risks and controls relevant to the financial statement audit.
According to Sandhu & Jajodia (1993) and in line with international standards such as COBIT (2005) the objective of database security and database continuity is divided into the following three quality aspects:
Data Confidentiality is concerned with unauthorized disclosure of data and confidentiality of sensitive data;
Data Integrity is concerned with consistency (completeness and accuracy) of data, granting minimum access to data in order to prevent (un)intended modification or deletion of data;
Data Availability is concerned with availability of data and the continuity of the operational database, for instance by means of adding redundancy.
Database Security
Data is considered to be a corporate resource and an important asset of an organization. Data is critical to an organization to conduct business. Sensitive data, such as customer personal data, needs to be protected and not accessible to the rest of the world. It is the organization’s responsibility to protect the data. Furthermore, even within an organization, the data should usually not be accessible to everyone in within the organization, such as privileged data. Therefore, it is important to have a secured database environment in order to reduce the probability of unauthorized data access. In general, database security is concerned about protecting data from theft, unauthorized deletion and unauthorized modification.
To protect a database environment, database security controls can be designed and implemented into the database environment. There are different types of database security controls that protect against protect against its corresponding risk, such as physical security controls (to prevent unauthorized physical access to a database), network security controls (prevent unauthorized access on network level, for instance with the use of firewalls to block access) and security controls on database level (such as access controls on database level). The collection of database security controls implemented is used to ensure thedata confidentialityanddata integrityof the database. For the database controls regarding database security from an audit perspective, see chapter 3.
Database Continuity
The main objective regarding database continuity is to prevent potential loss of data or inability to access data as required (PwC Audit Guide, 2014). Regardless of how the database is designed, the risk exists that an event can occur that can affect or even destroy data (Gillenson, 2012). Such event can range from erroneous user input (leading to corruption the data in the database), interruption of the power supply (due to power black-out) to a full-blown disaster (destroying the physical database). Elmasri & Navathe (2006) have pointed out several types of failures that may occur that can be classified as transaction failures (a transactional error such as division by zero, an integer overflow or concurrency failure), system failure (a hardware, software or network error occurs during database transaction execution) or media failure (ranging from disk failure, physical problems such as power or air-conditioning errors to catastrophes such as fire or flood). Therefore, database recovery techniques can be designed and implemented to ensure the continuity of the database. In case of transaction failures, a system log can be kept in the database, which records the transactions and its changes applied to data items. In case of transaction errors, the system log can be used to restore the failure by rolling back the transaction that has caused the failure. In case of system and media failures, a database back-up can be used to restore the database. A database back-up can be made by periodically copy the database and the system log to an external location, such as to a back-up database server or to an external medium, such as a magnetic tape that can be stored in a secure location. The database back-up can be used to reload the data to the primary database and therefore restore the data. The collection of database security controls implemented is used to ensure thedata integrityanddata availability of the database. For the database controls regarding database continuity from an audit perspective, see chapter 3.
2.2 In-Memory Databases
This section describes the characteristics of In-Memory Databases (IMDB). This section will commence with describing the history of IMDB and the necessity of IMDB in order to meet the increasing demands of the database environment in terms of data volume, data accessibility and speed. Furthermore, this section will elaborate on the technological characteristics and the advantages of IMDB. The next section will focus on the main differences between traditional databases and In-Memory Databases.
2.2.1 The History of IMDB – The need for IMDB
There are several drivers that play important roles in the introduction of IMDBs. One of the reasons is that the market demands more and more of the database environment in order to keep up with the technological advancements (Plattner & Zeier, 2012). Modern hardware is subject to change and continuous innovation in order to meet the business requirements. These drivers can
be categorized into two perspectives: from a technical perspective and from a business perspective.
From a technical perspective, the emergence of client-server architecture (introduced in the ‘80s) allows the application to be run on multiple, relatively cheap clients whilst connected to central application server and database server. This is called the three-tier architecture. All processing activities requested from the clients (tier 1) are handled by the application server (tier 2). The database server (tier 3) handles all incoming data requests, such as insert, read and delete commands and processes these requests on the physical database through the DMBS. For a logical overview of the three-tier architecture, see diagram below:
Diagram 2-1: Three-Tier Architecture
The database was soon becoming the bottleneck: receiving data from and transmitting data to the increasing number of application servers created a huge performance bottleneck (Word, 2013). The bottleneck is not caused by the processing power of the database server: the problem lies in the Input/Output (I/O) of databases. All data handling (such as ‘read’, ‘insert’, ‘delete’ and ‘update’ activities) are processed by the database I/O and proved to be the bottleneck of the database process.
From a business perspective, the demand for reporting data is also increasing in the current fast-moving business environments. Enterprises required access to their data in order to analyse their data in a timely manner. However, the traditional databases are designed to process operational
data viatransactionsin an efficient manner based on the so-called Online Transaction Processing (OLTP). The concept of OLTP is to minimize the volume of data entry and speed up data handling (‘insert’, ‘delete’, ‘update’) by using high degree of normalization of the data in order to minimize redundancy (Elmasri & Navathe, 2006). This means that data is stored into multiple tables across the database, where the data is often stored according to an ‘entity-relational’ model. For enterprise reporting purposes, data needs to be retrieved and joined from multiple tables and multiple reads from the database is required, which further impacted the performance of the database in a negative manner. For the purpose of performing analytics on data, Online Analytical Processing (OLAP) systems were developed. The data in an OLAP system is defined in a different data structure compared to the OLTP traditional database, often in a ‘dimensional’ data mode. The OLAP system is designed as a separate environment solely for the purpose of quickening the processing of complex analytical queries. The database as part of the OLAP system is typically called a ‘datamart’ or ‘enterprise data warehouse’. All transactional data from the database are transferred and loaded in the OLAP data warehouse via the so-called ETL process (Extract, Transform & Load), where data is sorted, aggregated and deduplicated (Vassiliadis et al, 2002). The traditional OLTP database is focused on processing all transactional data, whilst the OLAP system could handle all reporting of data via the processing of analytical queries. The OLAP system provided the end-user a snapshot of the OLTP database, depending on the frequency of the ETL process (usually scheduled) to refresh the OLAP system. The relation between OLTP and OLAP is displayed in the diagram below:
Diagram 2-2: OLTP and OLAP (Qikkwit, 2014)
However, organizations were creating quantities of data that was getting larger and larger due to business processes getting more and more automated. This created a vicious circle: since more and more data was created and becoming available, more end-users demanded more data to use
and as a result, leading to the creation of even more data. Furthermore, end-users demanded more and more up-to-date data (preferably in real-time) in order to support their business decisions (Word, 2013), whereas the OLAP system could only present data as a snapshot of the last ETL process. The combination of OTLP databases for handling transactions and OLAP systems for reporting purposes was getting not sufficient anymore for the rapid increase of data creation and data (real-time) demand: one is unable to do real-time analytics as analytical queries are posed against a copy of the data in the OLAP system that does not include the latest transactions.
2.2.2 The Characteristics of IMDB
The concept of In-Memory database dates back to the early 1980, where possibilities of the usage of main memory as database is researched, see DeWitt et al. (1984). The advantage of using main memory as database was soon proven to be evident (see DeWitt et al, 1984): the access and read times for main memory is dramatically lower compared to disk. For the comparison between main memory and disk, see table below:
Action Main Memory Disk
Data Access 100 ns 5.000.000 ns
Read 1 MB sequentially 250.000 ns 30.000.000 ns
Table 2-3: Access and Read times for main memory compared to disk (Plattner & Zeier, 2012).
However, the commercial implementation of databases based on in-memory technology is relatively new. For instance, major ERP provider SAP has developed specific algorithms based on in-memory technology applied on their logistics planning module in early 2000 to increase the performance. Furthermore, the users of the SAP BW environment (SAP BW is the SAP OLAP module for analytics and reporting as part of the SAP ERP solution) were having significant performance issues in the mid-2000, since analytical reporting procedures on the SAP BW OLAP environments where taking longer (several hours) or even days, even though OLAP system was already specifically designed for analytical reporting purposes.
The turning point was the continuous decrease of price for storage: the prices for main memory and disk storage have decreased in the past in line with Moore’s Law, to the point that the price for main memory DRAM (Dynamic Random Access Memory) was becoming inexpensive enough to provide an affordable option for usage in large enterprise application systems (Plattner & Zeier, 2012). Therefore the cost : size ratio for main memory provided an excellent cost efficient opportunity to explore the possibilities for commercial use of in-memory technology. The large main memory is becoming cheap enough to load all information needed and therefore speed up the transactions (in the OLTP environment) and analytics (in the OLAP environment) significantly, which leads to cost reduction. Therefore, different suppliers (from ERP application providers to database developers) are currently developing and implementing solutions based on
in-memory technology. The following section provides a short overview of the in-memory solutions commercially available at the moment:
SAP HANA
ERP solutions provider SAP AG has introduced her SAP HANA platform, an in-memory database management system. HANA is an acronym for “High-PerformanceAnalyticAppliance”. HANA was introduced in 2010 and initially positioned to perform specific (niche) functionalities using IMDB. The performance increase of IMDB was a key selling point and used as business case for her customers (Word, 2013). In 2011, the SAP HANA platform was made available for the SAP NetWeaver BW environment (OLAP system) in order to speed up the analytical procedures. The SAP ERP transactional data (OLTP) is loaded into the SAP BW environment, which is run on an IMDB. The next step would be to move the SAP ERP environment to IMDB as well, creating one single platform where transactional as well as analytical data is readily available, diminishing the need of a separate enterprise data warehouse (EDW), see diagram below:
Diagram 2-4: the Vision of SAP HANA as a single platform for all business processing (Vital BI, 2011)
Oracle TimesTen
Oracle is well known for their traditional object-relational database management systems, supporting many applications and ERP solutions. In the mid-2000, Oracle has acquired the company TimesTen, who is specialized in IMDBs. Since then, Oracle was able to provide the IMDB solution for her customers, named Oracle TimesTen. This in-memory database was designed to store all data needed in the physical memory, unlike the disk-based databases of the traditional Oracle Database. In 2012, Oracle has introduced Oracle Exalytics to her customers. Oracle Exalytics provides an in-memory BI machine that delivering fast performance for business intelligence and planning applications (Oracle, 2014), similar to the SAP BW HANA platform.
The following section will provide a summary of the main differences between traditional databases and in-memory databases.
2.3 Main differences between traditional Databases and
In-Memory Databases
In order to determine the risks involved with the use of an IMDB, this section will describe the traditional databases and IMDB. The focus will be on the main differences between the traditional databases and IMDB. Based on the noted differences, the research sub-questions as described in chapter 1 will be answered in this section.
As discussed earlier in section 2.2.1, in a traditional client-server database system environment (Elmasri & Navathe, 2006), the end-user interacts with the application (such as an ERP) through one of the clients. User interactions with the application include data processing activities such as read and write information in the application. The user interactions in the application are processed by the database at the server-side and processed in the database. A DMBS is a collection of programs that enable users to create and maintain a database (Elmasri & Navathe, 2006).
The data is stored on persistent disk-based media and maintained in a database server. In this traditional set-up, access to data (I/O) is the bottleneck: Every user interaction on application level, such as querying for data, has to go through the DBMS and subsequently searched on disk. When the data is acquired, the data follows the same path back to the application and made available to the user. This process can be optimized by using database caching, whereby frequently access data is stored temporary in the database cache, which eliminates the access and seeking time on disk. However, for complex queries and processing large amounts of data, disk reads are still required.
In an in-memory database environment (Plattner & Zeier, 2012), the I/O sequences between application and the database (disk) is entirely eliminated: IMDB uses the main memory as the primary storage. The main drivers of using IMDB is the steadily falling prices of main memory, increasing CPU processing power and the increasing demand of real-time analytics and computation on the fly.
Fig 2-5: Difference between traditional and in-memory computing (Gartner, 2012)
The diagram above displays the main differences between traditional and in-memory computing. (Please note that the terms ‘in-memory database’ and ‘in-memory computing’ are interchangeable, since in-memory computing makes use of in-memory databases). The diagram shows a traditional approach of computing: the application is running on the application server (which consists of the CPU, main memory, among other elements) and communicates (I/O) with an external database. This external database holds the actual data (as database records). The yellow arrows represent the I/O communication lines between the application and the database disk. The in-memory computing on the right-hand-side of the illustration displays the IMDB situation: the database resides in the main memory and therefore accessed directly by the application. However, the in-memory database cannot fully replace the traditional disk-based database: the main memory is a storage medium and is still prone to system failures, such as system errors or power disruptions. This issue is also recognized in the research of Garcia-Molina & Salem (1992): “Although the probability of failure can be reduced by using techniques as battery-backed up memory, uninterruptable power supplies, error detection/correction and memory redundancy, the probability can never be zero. Thus, one will always have to have a back-up copy of the database, probably on disk“. Therefore, most IMDBs are also equipped with a traditional database for back-up and recovery purposes. Different approaches exist for backing up IMDB environment, such as recording transaction loggings on non-volatile media or periodic full data replications.
Main memory has different properties as that of traditional database disks that have implications on the design and performance of the database system. According to Garcia-Molina & Salem (1992) amongst other researchers, the main differences are summarized below:
(1) Access method: The data in the main memory is accessed directly by the CPU, while disks are not;
(2) Data Volatility: Main memory is highly volatile, while disk storage is persistent; (3) Access time / Performance: The access time for main memory is orders of
magnitude less than for disk storage, by eliminating the need for I/O to perform database transactions. This performance increase is also confirmed by other studies, such as Raja et al. (2008);
(4) Cost per Access:Disk storage has a high, fixed cost per access compared to access from main memory. Disk-based access is usually sequential in TBD. Data in memory is accessed randomly, however this does not pose as a disadvantage as access to memory is much faster compared to TBD, see also (3) ;
(5) Data structure/ Architecture: Since IMDB and the traditional DBMS are conceptually different; these differences have architectural consequences and differences in data structures, such as entity relational databases in traditional databases versus the column-oriented data structures commonly used in IMDBs. As described in the research scoping section, these technical differences in architecture will not be in scope for this study.
In this section, the main differences between the traditional DBMS and the in-memory databases (IMDB) are explored and summarized. The summary above provides the answer to sub-question 1 as described in the beginning of this chapter. In the next section, the risks associated with these database techniques will be explored in more detail.
2.4 Risks from associated with In-Memory Databases
In this section, the differences between IMDB and traditional databases (as identified in the previous section) are analysed and grouped from a risk-based perspective. These risks can be grouped into two categories: data security and database continuity, as based on the database control issues as described in section 2.1.3. The main differences in the previous sections are linked to one of these categories. Previously, we have noted five main differences between traditional databases and IMDB.
In the next chapter, the identified risks will be linked to the audit standards and principles regarding databases.
Database Security in In-Memory Database – Access Method
As discussed in the previous section, one of the differences regarding TBD and IMDB is the (1) access method. In case of the traditional DMBS, the data is stored on disk-based storage device. Typical access controls are in place that ensures that a user is only authorized to perform database operations for which that user is permitted (Sandhu & Jajodia, 1993). These access controls are
part of the access management of the DMBS, wherein user authorization and user authentication are managed by the DMBS.
In contrast, within an IMDB, the database resides entirely in the physical main memory. The question that rises with this situation is how access management to the physical memory is configured in order to ensure that only authorized users are allowed to access the database. Therefore the risk regarding database security for IMDB can be formulated as follows:
Risk 1: Access to the physical memory (wherein the IMDB resides) is not sufficiently restricted, which increases the risk of unauthorised access to the data
Database Continuity in In-Memory Database – Data Volatility
As described in the previous section, (2) data volatilityis a characteristic that is inherent to main memory. Main memory (DRAM) is designed to store temporary data as part of the CPU processing cycle and not intended to store persistent data. A disk-based storage device in a traditional database environment is specifically designed to be robust and persistent: even when the disk is disconnected from a power source, the data on the disk remains Therefore the risk of usage of IMDB can be formulated as follows:
Risk 2: Data stored in the main memory is volatile of nature, which increases the risk of data loss at the event of system error/failure
The remaining three differences (as identified in section 2.3.1) do not pose a risk in terms of performing an IT audit on a database:
(3) Access time / Performance:The differences in access time and performance are not relevant from a risk-based perspective regarding database security and database continuity, as the increased performance of IMDBs is considered a business advantage. Therefore there are no additional risks involved related limited access time and increased performance regarding the objectives of data integrity, data confidentiality and data availability;
(4) Cost per Access: This difference is closely related to the performance difference; The decrease of cost per access for IMDB is also a business advantage and is not related to any risks from a database security and database continuity-perspective;
(5) Data structure/ Architecture: As described earlier, the technical differences between traditional databases and IMDBs are not in scope for this research and therefore any risks related to the design differences are not regarded in this research.
# DB Characteristics Traditional DB IMDB IMDB New Risk
1 Access Method Access to data stored on
disk
Direct access from main memory
Access to the physical memory (wherein the IMDB resides) is not sufficiently restricted, which increases the risk of unauthorized access to the data
2 Data Volatility Low (persistent storage
on disk)
High (inherent to main memory)
Data stored in the main memory is volatile of nature, which increases the risk of data loss at the event of system error/failure
3 Access Time / Performance
Access Time is High (slow due to inherent I/O processing of disk) Performance is Low compared to IMDB
Access Time is Low Performance is High compared to TBD
Not applicable, business risk, no impact on the financial statement audit
4 Cost per Access High Low
Not applicable, business risk, no impact on the financial statement audit
5 Data Structure /Architecture
Commonly used: Entity Relational data structure (row-based)
Commonly used: Column-Oriented data structure
Not in scope
Table 2-6: Summary of differences and risks between TBD and IMDB.
The abovementioned identified risks related to IMDB will be further analysed from an IT audit perspective in the next chapter.
3 Audit Standards and Principles regarding
databases
In this chapter, the audit standards the following two sub-questions will be answered,
3: What are the current set of audit standards and principles regarding database security and database continuity that apply to the traditional databases?
4: Do these standards cover the specific risks associated with In-Memory Databases?
This chapter commences with described the IT audit as part of the financial statement audit. The different domains of the IT audit will be briefly described. Thereafter, the audit standards specifically for databases will be elaborated. Finally, this chapter will conclude with evaluating the audit standards for databases in relation to the auditing of In-Memory databases.
3.1 IT audit as part of the financial statements audit
This section describes how information technology (IT) is in scope in the context of a financial statements audit regarding test of controls. A brief explanation is given about the need to test IT General Controls (ITGCs) in the context of a financial statements audit. This chapter is particularly based on generally used auditing standards that are required when performing audits as part of a financial statements audit, such as the International Standard of on Auditing (ISA) and the PwC Audit guide (based on the ISA). This section describes the IT General Controls domains. In the next section, the controls related to databases will be described in more detail. Within ISA, it is described that IT also poses specific risks to an entity’s internal control and therefore, increasing the risk of material misstatements, such as unauthorized access to data or potential loss of data or inability to access data as required. (ISA315 revised, 2013). Therefore, as required in ISA 315.18 and ISA 315.21, as part of financial statement audit, the auditor is required to understand how the entity has responded to risks arising from IT, including the related business processes, relevant to financial reporting to maintain the integrity of information and security of data by performing the audit procedures on the IT General Controls. As per ISA 330.10(b) (also in the PwC Audit Guide, 2013), Information Technology General Controls (ITGCs) will often contribute indirectly to the achievement of many or all financial statement assertions. To summarize, according to ISA315-A63, the following risks arising from IT that can lead to lead to material misstatements in the financial statement:
- Reliance on systems or programs that are inaccurately processing data, processing inaccurate data, or both;
- Unauthorized access to data that may result in deletion of data or improper modification to data, including the recording of unauthorized or non-existent
transactions, or inaccurate recording of transactions. Particular risks may arise where multiple users access the same database;
- The possibility of IT personnel gaining access privileges beyond those necessary to perform their assigned duties thereby breaking down segregation of duties;
- Unauthorized changes to data in master files;
- Unauthorized changes to systems or programs;
- Failure to make necessary changes to systems or programs;
- Inappropriate manual intervention of automated transactions;
- Potential loss of data or inability to access data as required;
An organization may identify many controls in their risk assessment to address the abovementioned risks, including many IT controls that are focused on operations rather than financial reporting risks. However, the main distinction between financial statement IT audits and other IT related audits (such as operational IT audits and process improvement audits), is the fact that during a financial statement IT audits only those ITGCs are relevant that prevent or detect the risk of material misstatement in the financial statements.
Besides the ISA, the importance of IT in the financial statement audit is also confirmed by the Statement of Auditing Standard (SAS), Public Company Accounting Oversight Board (PCOB) and other authors, such as Brazel (2008), who also recognizes the importance of the enhanced role of IT audit on financial statement audits due to the organization’s adoption of increasing complex IT systems the support the financial reporting that is integrated with the financial statement audit. For reference purposes, see diagram below for the relation between the financial statement assertions and the IT environment.
Diagram 3-1: Relation between IT environment, IT General Controls and financial statement (PwC Audit Guide, 2013)
The IT General Controls consists of the following domains (adapted from the PwC Audit Guide, 6023): IT environment, Program Changes, Computer Operations, Program Development and Access to Programs and Data:
IT Environment
Understanding the IT control environment is to be considered first to determine the impact on the extent of testing of control activities as well as the impact on the total audit strategy and plan as early in the audit process as practical. The typical activity for the auditor in this domain is to understand the technical characteristics of the IT environment, such as gaining an understanding of the IT systems and infrastructure and how this environment relates to financial data. Furthermore, the auditor also needs to develop an understanding of the internal control environment regarding IT: how does management approach the organizational information technology needs and serves to promote the ongoing effectiveness of ITGCs that, in turn, preserve the integrity of key financial applications and data. Typical topics within this domain which have to be assessed include:
- Policies and procedures: How policies and procedures are designed to preserve the integrity of key financial applications and data, both within IT and outside the IT function where applicable;
- IT Governance: The manner of governance and oversight of the IT function (how IT operations is monitored);
- IT Roles and Responsibilities:How IT roles and responsibilities are designed that allows ownership and accountability regarding IT governance;
- Segregation of Duties: How segregation of duties is implemented in the key IT functions.
Program Changes
The domain objective is: "To ensure the changes to programs and related infrastructure components are requested, authorized, performed, tested, and implemented to achieve management's application control objectives." The controls within this domain ensures that changes to programs are performed on a controlled manner in order to form the basis for relying on the ongoing operating effectiveness of key automated application controls and IT manual controls in the current audit period.
Control categories that are assessed in this domain include:
- Management of maintenance activities: How change management is organized, such as formal policies and standard processes are defined for design, acquisition, configuration, modification, and management of infrastructure and software change/maintenance and development activities;
- Specification, authorization and tracking of change requests:How change requests are logged, analysed, tracked and approved before construction;
- Testing and quality assurance: Changes to programs, new releases (programs), and upgrades (including system software) are thoroughly tested (by IT as well as business users) before being rolled out in the live environment;
- Program implementation: Only authorized, tested and documented software and hardware changes are moved to production, after formal approval;
- Documentation and training: How end-users are instructed to work with the new program and the availability of support documentation;
- Segregation of duties:Segregation of environments (development, test, acceptance and production environment) to ensure segregation between construction, testing and production, therefore reducing the risk of errors in the production environment.
Computer Operations
The objective of the Computer Operations domain is: "To ensure that production systems are processed completely and accurately in accordance with management's control objectives, and that processing problems are identified and resolved completely and accurately to maintain the integrity of financial data." This domain related to the daily operations of the IT environment, which includes activities regarding technical and functional support, monitoring of performance and incident handling. The following control categories are assessed as part of the computer operations domain:
- Management of computer operations activities: Standard IT operating procedures are formally implemented;
- Batch scheduling and Real-Time processing:Batch jobs are scheduled, maintained and approved according to the business/IT needs. Interfaces are designed and implemented according to business/IT needs in order to ensure accuracy and completeness of interfaced data. Batch scheduling is an IT activity that could directly impact the completeness and accuracy of financial data if it were to break down;
- Fault Tolerance, Back-up and Recovery:How management has ensured the continuity of the IT processes by implementing fault tolerance measures, formal back-up procedures, including procedures for back-up handling, back-up retention and back-up restore test procedures;
- Incident & Problem Management:Management has implemented incident and problem management processes to report, classify, log, solve and analyse incidents and problems in order to take appropriate action;
- Disaster Recovery:The measures implemented by management to support continuity of the business during an enterprise disaster that has impact on IT and therefore information processing, such as implementing a disaster recovery plan and a business continuity plan that is aligned with the business in terms of agreed upon recovery times; - Service Level Management: Management has implemented procedures to monitor and
review service level agreements and underpinning contracts with third party service providers.
Program Development
The domain objective is: “To ensure that systems are developed, configured, and implemented to achieve management's application control objectives.” This domain is closely related to the domain ‘program changes’; however this domain encompasses larger program implementations where data migration and/or data conversion is involved.
Typical control categories that are assessed in this domain are:
- Management of development and implementation activities: How is program development aligned with the IT strategy and the business strategy, project management; - Project initiation, analysis and design: Formal approval for initiation of a project,
support for the project from the business, business case and formal approval;
- Construction / package selection:The chosen software development methodology and/or strategy to select an off-the-shelf IT solution based on the requirements;
- Testing and quality assurance:How testing activities are performed by developers and user acceptance test in order to assure quality;
- Data conversion: How legacy data is migrated to the new environment in a controlled manner;
- Program implementation:Go-live of the program, including all test approvals and formal go-live approval;
- Documentation and training: How end-users are instructed to work with the new program and the availability of support documentation;
Access to Programs and Data
The domain objective is: "To ensure that only authorized access is granted to programs and data upon authentication of a user's identity. Controls over access to programs and data include the processes used by the entity to add, delete, and change users (both business users and IT personnel).”
Typical control categories within this domain which have to be assessed include:
- Management of security activities:Security activities managed in terms of processes and procedures, including monitoring activities and security incident handling. Security policy and security baseline;
- File System access and management: How access to key IT components such as application, OS and database is granted, modified and removed, including monitoring procedures on authorisation and authentication of user access;
- Audit, Logging and Monitoring:The monitoring procedures and logging measures that management has implemented in order to enable auditability of the performed activities on the system (such as user transactions), therefore providing the ability to management for error correction and user accountability;
- Data security:The security measures that are in place to ensure data integrity;
- Operating system security:The security on operating system level, such as management of super users, security configuration, version and patch management;
- Network security: The security measures in place on network level, such as firewalls, monitoring of security events on network level, implementation of intrusion detection/intrusion prevention measures and remote connection support;
- Physical security:The security regarding physical IT components (such as server rooms), access control to the server rooms as well as measures for protection against environmental factors, such as climate control and fire extinguishing equipment;
In this section the importance of IT audit as part of the financial statement audit is described. The main domains in the IT General Controls are briefly described. The following section will describe the audit standards and principles for the auditing of databases that are used as part of a financial statement audit.
3.2 Audit standards and principles for databases
In the previous section, the IT audit related to the financial statement audit, including the IT General Controls domains are described. In this section, the different elements (the database concept, database risks, quality aspects) described in the previous chapters are combined in order to emphasize the importance of the database as audit object. Furthermore, the audit standards for databases will be elaborated in more detail in this section.
The database is a crucial component of the IT infrastructure, as the database is the place where all financial transactions are initiated, recorded, processed and reported. Therefore it is important to assess the database controls as part of the IT audit to ensure the data confidentiality, data integrity and data availability (as previously explained in chapter 2).
As identified in chapter 2.1.3, this study has recognized two relevant risk areas that are related to databases: Database Security and Database Continuity.
Furthermore, in the previous section, the audit principles and IT General Controls domains are elaborated. Therefore, during an IT audit (as part of a financial statement audit) is performed on a database, the identified database risk areas are mapped to the ITGC domain and control categories (PwC Audit Guide, 2014) in the following way:
Database Risk
Area Quality Aspect ITGC Domain Control Category
Database Security
Data Confidentiality
Access to Programs and Data
Audit, Logging and Monitoring
Data Integrity File System access and management
Database Continuity
Data Availability Computer Operations
Fault tolerance, back-up and recovery
Data Integrity
Table 3-2: Database risk areas, quality aspects and their corresponding ITGC domains and control categories
