IT basics for non-IT auditors

Today’s heavy reliance on Information Technology (IT) requires internal auditors to have a basic level of IT knowledge, sufficient to:

  • Understand the related opportunities and risks within their organisations
  • Ask the right questions of the right parties and draw the right conclusions

IIA Global has produced a suite of Global Technology Audit Guidance (GTAGs)

And a risk-based approach to assessing the scope of IT General Controls:

GAIT for business and IT risks

GAIT for IT general control deficiency assessment

GAIT methodology

GAIT template


This information guidance is designed in three parts to help direct you to the information you need. 

Part 1: Understanding the language of IT

Part 2: Exploring IT risk

Part 3: Getting started

Bits, Bytes and Basics

Digitalisation

The IT department

IT risk appetite

IT risk frameworks

 

Questions for an audit test plan

 

Part 1

This section aims to provide high-level knowledge to enable you as an internal auditor to speak and understand the language of your IT colleagues.

Bits, Bytes and Basics

This diagram shows that IT is central to our organisations.

  • The outer ring defines typical generic business processing objectives.
  • The middle ring indicates the risks to the objectives.
  • The inner circle illustrates typical departments developing and operating the systems to enable the objectives.

Overarching this is IT governance: The processes in place to ensure the efficient and effective achievement of the business objectives. 

Processed information is known as data. It is stored in bits and bytes using something called binary form. To delve deeper into the details click here.

Differentiating between what you can physically see and touch, versus what you cannot, is key to understanding the basics of IT. Physical devices are known as hardware. Programs (and data) stored on those devices are known as software. The software that controls the computer is known as the operating system (eg, Unix, IBM z/OS, AS/400, Google Chrome OS, Android, Apple macOS, IOS).

Application software handles the day-to-day business processes (eg, customer orders and accounting). This might be developed ‘in-house’ by the organisation’s own programmers or perhaps purchased as a package from a third-party software supplier. Some developers use opensource a model of sharing free-to-use software available via the internet.

IA notes:

  • When scoping an engagement be clear between hardware and software
  • Internal audits often talk about auditing ‘up to’ and ‘around’ the box. The box being the hardware which contains the software. Significant technical expertise is required to provide assurance related to the workings of hardware and software

The brain and main memory of the computer hardware sit within the Central Processing Unit (CPU).

Computers process information in various modes, eg:

  • Online - where the host computer receives/sends input/output from/to other computers over a network
  • Real-time - where the online updates to the host computer system occur instantly as new data is entered
  • Batch - where the data input is captured at a point in time but posted to the host system at a later stage.

Many online systems might appear to be real-time, but technically are not, eg, Internet banking systems might show an update to your account directly after the transaction is entered; however, the true update may not take place until the batch processing run, which often takes place overnight. 

Computers are linked together (physically or wirelessly) into networks, so that they can communicate and share resources such as data and software. Most organisations use the internet to communicate (eg, between their own systems, staff, departments and regions) and externally (eg, with customers, suppliers and stakeholders).

Virtual Private Network (VPN) technology is increasingly being used as a means of enhancing security when communicating over the Internet. The VPN creates a secure tunnel between locations across the Internet, via an intermediate VPN server, employing dynamic IP addressing and data encryption (disguise) in the process. The use of VPNs can nonetheless be controversial, eg, they can be used to mask location and to inhibit logging (such as by the Internet Service Provider - ISP).

Networks typically incorporate control facilities such as demilitarised zones (DMZs) and firewalls. Generally a DMZs segregates internet servers from the organisation’s internal servers and firewalls are used to monitor traffic to allow or deny progress based on configurable rules.

IA notes:

  • Ensure you fully understand the network being used within any process, the operational difference between real-time and batch can have a material significance on the assurance you provide.

Systems architecture brings everything together. It is the term used to describe the overall design and structure of a computer network or system. There are four main components to any system architecture: processing power, storage, connectivity, and user experience. Complexity varies widely depending on the business processing objectives of the organisation and resource availability. It must be flexible enough to meet changing needs; a structure that is too rigid will not be able to accommodate new software or hardware.

IA notes:

  • There is often an architecture diagram which can be useful for internal auditors.

Some organisations run all of their IT in-house, while others outsource the running of some or all of it to third-parties. Most organisations use cloud services operated by third-parties.

IA notes:

  • It is essential for GDPR compliance that organisations fully understand where their data is stored and processed.

Digitalisation

Digitalisation is an ongoing transformation for organisations. Often known as Industry 4.0. Its competitive advantage was brought into sharp focus by the pandemic.

Blockchain is both enabled by and an enabler of digitalisation. It makes use of internet-based de-centralised processing and encryption facilities, potentially to reduce transaction costs, increase security and eradicate single points of failure (since there is no reliance on a central system/server). Click here to read a technical blog on the topic.

Artificial Intelligence (AI) applications, which are designed to learn from the organisation’s data and ‘think’ like humans, are now commonplace. One use of AI that everyone will have encountered is the chatbot on websites. From a data perspective AI can rapidly interrogate huge databases and is used in a host of environments from online shopping and factory management to money-laundering.

5G (telecommunications technology) with lower latency (response times) and increased download speeds provides services around ten times faster than 4G. In addition to the expected faster operations and enhanced virtual reality applications there is the potential to replace physical wires with wireless connectivity in many locations.

IA notes:

  • Search engines will return a variety of interesting reads for your sector using digitisation and/or industry 4.0. It is important to stay abreast of technology trends.

The IT department

There is no one size fits all for IT functions. The earlier diagram is illustrative.

Likewise, the information below is a guide.

Effective segregation of IT Operations and Systems Development is key to many basic IT controls.

IT controls are part of the first line of the three lines model.

There are valid arguments for and against including areas such as ‘IT risk’, ‘change management’ and ‘IT security’ within IT itself. The solution will depend on the nature and requirements of the organisation. Nonetheless, it is generally recognised that ‘change management’ and ‘IT security’ should not sit within ‘systems development’. Regardless of the way in which IT is organised, the effectiveness of segregation and control is largely dependent on culture, standards and the competence of the IT staff. 

IA notes:

  • Understand the organisational structure of your own IT function. Consider the information in this section in the context of your own organisation – substituting department names and breaking up activities.

IT management and administration

Administration often supports all areas within IT, particularly those within IT management.

Management:

Overseeing all aspects of IT staffing, development, processing and governance

Budgeting, costing, charging

Management reporting (eg, for the board, risk committee, stakeholders, audit committee and regulators)

Devising and maintaining standards

Recording software/hardware ownership

Managing vendors/third parties and related contracts

Creation of an information asset register

Regularly processing updates / system patches

Requesting and actioning third part penetration testing eg denial of service attacks

Training

Risk

Identification and documentation of IT related risks

Monitoring IT-related risks, in liaison with user management and the risk function

Change management

Handling the secure transfer of resources between the development and production environments (and vice versa)

Overseeing the controls to ensure that all production software is up-to-date and bona fide

Cyber security

Overseeing (and to some extent managing directly) the security of the organisation’s networks and systems, including segregation of environments/duties, user access rights, penetration testing (also see Part 2, Cyber Security, within this guidance).

Operations 

Operators

Starting-up and shutting-down machinery

Executing production jobs (input, processing and output)

Managing back-up and restore procedures

Handling storage devices (eg, disks and tapes)

Issuing system commands in the process of the above (eg, to list directories/files, show active jobs, compress/decompress files, copy files)

Scheduling:

Determining the what, why, who, how, where and when of processing jobs.

Network management

Handling internal and external telecommunications links (including firewalls and DMZs).

PC management

Setting-up and maintaining personal computers

Database management

Handling the set-up and maintenance of the system databases

Technical support

Setting-up and configuring the hardware and operating systems software (potentially including some basic systems programming duties)

Supporting computer operators and users

Managing emergencies

Writing command language, which enables a set of commands to be grouped into a mini-program

Researching emerging technologies

Systems programming:

Maintaining the operating systems software (dependent on the amount and nature of systems programming required, this service might be provided by the third-party operating system supplier or reside in-house within Technical Support, Systems Development or as a discrete function)

User Liaison:

· overseeing the day-to-day interaction between IT Operations and the application systems users

Technical project teams

Handling specific IT Operations projects (eg, the upgrade of an operating system or network component, or the IT Operations side of ongoing Systems Development projects)

OAT

‘Operations acceptance testing’ - testing the system on behalf of IT Operations prior to ‘go live’

Systems Development

Project Control

Overseeing the business development/change projects

Project teams (including programmers):

Developing, changing and testing application software

Systems analysis

Converting user requirements into a specification document for the programmers (like an architectural drawing, for use by builders)

Systems testing

Overseeing the testing of suites of programs after individual program and ‘link’ testing, and prior to UAT

UAT

Overseeing the ‘user acceptance testing’ prior to ‘go live’

 


Part 2

This section gives you a high-level overview of how risk is managed within the IT function and the relevant frameworks that may be mentioned.

IT risk appetite

Organisations with mature risk management processes will have clear definitions of their risk appetite in all relevant areas, including IT-related risks. IT environments are typically dynamic and volatile. A ‘zero tolerance’ is unlikely to be helpful.

An example of how this could be addressed is to consider the appetite for the failure of the business processing objectives (think back to the earlier diagram):

  • 30 minutes downtime for ‘x application’ in a single event
  • 70 minutes downtime for ‘x application’ across a rolling 60 day period
  • 97% tolerance for batch run’s relating to process ‘x’

It is important that the risk appetite statements enable the IT function and users to operate within a framework of expectations and tolerances. This guides the priority of resources to fix problems as they arise and targets development to improve known issues.

IA notes:

  • Internal auditors should use the risk appetite statements to establish the benchmark for reporting findings. Depending on risk maturity, some organisations may have such measures in place as operational targets or internal service level agreements without explicitly calling it a risk appetite statement. Use whatever is available and help improve risk understanding.

IT risk frameworks

Your organisation is likely to have a process in place, which it is essential to familiarise yourself with.

The IPPF defines risk as ‘the possibility of an event occurring that will have an impact on the achievement of objectives.’ A simple model to help you to recognise, express, assess and ultimately contribute to the management of your organisation’s IT-related risks is set out below.

  1. Identify your organisation’s business processing objectives.
  2. Identify events which might threaten those objectives.
  3. Assess the likelihood of those events occurring.
  4. Assess the impact of those events on your organisation.

Risks are often inter-related, where one can lead to another. This is very much the case within IT.

IA Notes:

  • Internal auditors should always try to get to the root cause of any identified issue. As in this example, ineffective access controls are due to a lack of security standards. Why are there no security standards? It is important to address the identified issue and the root cause.
  • Bow-tie analysis and fish-bone diagrams can be useful for IT risks as there can be many issues arising from a single cause.

 

The following is a list of common types of IT risks. 

Architecture risk

IT structures fail to support operations or projects

 

AI risks

Misinformation or operations resulting from technologies that learn and self-improve

Asset management risk

Failure to control IT assets such as loss of mobile devices

Audit Risk

The chance that an IT audit will miss things such as security vulnerabilities or legacy risks and potentially provide a false assurance

Availability Risk

Downtime of IT services

Benefit Shortfall

Investments in IT that fail to achieve projected return on investment

Budget Risk

IT programs, projects or operations teams that exceed budget.

 

Capacity Risk

Capacity management failures such as an overloaded network that causes inefficiencies such as a process failure.

Change Control

A failure to control change to complex systems including practices such as change management and configuration management.

Compliance Risk

Potential to violate laws or regulations

Contract Risk

A counterparty that fails to meet its contractual obligations such as missed service level agreements

Data Loss

Loss of data that cannot be restored

Data Quality

Poor quality data that causes losses due to factors such as process failure, compliance issues, GDPR regulatory breach or declining customer satisfaction

Decision Quality

Sub-optimal decision automation or inaccurate decision support analytics

Design (Technical) Debt

A low quality design or weak implementation that results in future costs

Facility Risk

Risks related to facilities such as data centres

Infrastructure Risk

Failures of basic services such as network, power and computer resources

Innovation Risk

Risks associated with research and development, experimentation aggressive rates of change (disruptors). Typically involving novel approaches using agile methods to fail early/fail forward.

Integration Risk

Potential for integration of organisations, departments, processes, technology or data to fail

Legacy Risk

Technology that is out of date such that it is difficult to maintain or out of support and the associated risks of failure

Operational (or Process) Risk

The potential for technology failures to disrupt business activities

Partner Risk

Associated with technology partners such as service providers – cloud in particular

Physical Security

Related to IT such as at data centres, locks on hardware.

Project Risk

IT projects often have a high failure rate due to a variety of risk factors such as scope creep, estimation errors and resistance to change

Quality Risk

Failures of quality assurance and other quality related practices such as service management

Regulatory Risk

Potential for new IT related regulations

Resource Risk

Inability to secure employees or contractors with the appropriate expertise

Security Threats

Specifics such as malware and hackers

Security Vulnerabilities

Specifics such as weak passwords and poorly designed software

Single Pont of Failure

A small component (such as a switch or cable) of a large system that has the potential to bring down an entire system when it fails

Strategy Risk

Associated with a particular IT strategy, including risk appetite

Transaction Processing Risk

Inability to effect transactions

Vendor Risk

Potential for an IT vendor to fail to meet obligations

 

IA notes:

  • It is the responsibility of internal audit to provide assurance over the management of risk, not to identify all IT risks. Use the typology table above to help you challenge the risks that have been identified to make an assessment regarding completeness.

COBIT (Control Objectives for Information & Related Technology) is a risk governance framework, created by the Information Systems Audit and Control Association (ISACA).

There are five main components of COBIT:

  • COBIT framework | Designed to help organisations organise and categorise all of their objectives when it comes to IT governance. It also helps companies following good practices of the IT domain and integrates it with the business requirements as a whole
  • Process descriptions | Provide organisations with a process model and create a common language for all departments across the enterprise
  • Management guidelines | Used to assign job roles and responsibilities for IT governance. This helps in creating a uniform structure across the company and helps departments work together and agree on their business objectives as well as to measure overall performance. The guidelines also showcase the relationship COBIT has with all other processes in the organisation
  • Maturity models | Used to better understand the capability and maturity level of each process and work on any gaps found in the same
  • Control objectives |Provide organisations certain requirements they need to meet so that they can manage their control of IT processes effectively in the company.

IA notes:

  • Internal auditors should use independent processes to test frameworks, as it is important to strike the right balance between demonstrating adherence to a process vs. demonstrating effective management of all significant risks.

Part 3

This section provides you with generic questions to include in a high-level test plan.

1. Determine where the lines of responsibility are drawn between the business and IT. Question why, as appropriate:

Are the set-up and maintenance of user accounts, functionality, standing data (eg, limits), parameters etc managed by the business? If not, why not?

Similarly, does the responsibility for auditing the live business applications and the user side of IT projects sit in the first line? If not, why not?

2. Are themed audit engagements, across departmental boundaries, feasible and occurring in your organisation?

Consider whether audit scope is being restricted according to the organisation of your business and IT departments.

3. Look for Systems Overview documentation, explaining the ‘what, why, who, how, when and where’ of your core processing in layman’s terms, including the flow of data between those systems.If this documentation is lacking, consider, how do employees gain the necessary understanding without it?

4. Look for, and assess, the organisation’s IT strategy. This should specify, clearly and concisely, how the organisation’s IT strategy/plan will support the achievement of the organisation’s business objectives over a suitable period. The highest level of user management, IT management, and other key stakeholders should sign off the plan.

5. Is an effective process in place to manage the organisation’s IT-related risk appetite? Consider:

· the involvement and alignment of the business and IT in the process

· the clarity of the processing objectives and the associated risks

· reporting of IT-related risks and weaknesses to the risk committee and executive management.

6. Consider, how does the Board gain ongoing assurance that systems are secure, compliant and processing as intended?

7. Is the terminology employed during communication between IT and the users clearly understood?

8. Has the business formally accepted that, regardless of the technology, third-parties and outsourcing employees, it owns the data, and is ultimately responsible for the achievement of its processing objectives?

9. Does the business take day-to-day responsibility for the checks/reconciliations to confirm the achievement of the organisations processing objectives?

10. Is the business appropriately involved in the definition of all business application user requirements, including systems security facilities, at the development stage?

11. Are IT standards effective?

Consider the degree of exceptions to the standards being identified (eg by Internal Audit, Risk, Cyber Security and IT)

12. Is a methodology document or equivalent in place to explain to business and IT personnel, in simple terms, how the business applications and data will be secured?

13. Is effective analysis being undertaken to identify and address the root causes of IT control weaknesses?

14. Is data interrogation undertaken (eg to assess completeness and accuracy, and highlight trends)? If this is being undertaken by internal audit alone, consider whether this is appropriate based on available skills.

15. Consider, in the case of every check that internal audit undertakes (or wishes to), is a similar check already being carried out within the business and, if not, why not?

16. Is the business appropriately involved in the preparation, testing and sign-off of contingency/disaster recovery plans?

17. Is effective change management exception reporting in place?

18. Are IT vendors and third-party contracts subject to appropriate control/review? Consider:

· assignment clauses, escrow agreements governing access to third-party source code, cross-border processing requirements etc

· vendor suitability, compliance with your standards and values.

19. Are IT budget/accounting processes subject to appropriate control/review? Consider how the IT budgets are set and monitored.

20. Is end-user computing subject to effective control/review?

Consider the appropriateness of IT facilities (such as spreadsheets and databases) that sit outside the control of IT function but may impact the organisation’s processing objectives.

21. Are business user/audit personnel involved in any due diligence and divestiture exercises (if undertaken)?


Conclusion

In the same way as you do not have to be a marketeer to audit marketing risks, you do not have to be an IT expert to audit IT risks.  


Further reading

Auditing IT change management

ISACA glossary is a useful reference guide for terminology and ‘buzz-words’  

Content reviewed: 9 September 2021