Systems Auditor Examination key terms

A formal document approved by senior management or the board that defines the internal audit function's purpose, authority, and responsibilities, including its right of access to records and personnel.

A written agreement between the audit function and the auditee stating the engagement's objectives, scope, timing, and reporting arrangements, used to prevent later disputes about what was covered.

A documented plan listing the specific procedures, tests, and sampling steps an auditor will perform to achieve the engagement objectives, along with who performs them and when.

The state of being free from conditions that could impair, or appear to impair, objective judgment, such as auditing a system the auditor designed or reporting to a manager whose work is being audited.

The risk that an auditor gives an inappropriate opinion because a material error or weakness was missed. It combines inherent risk, control risk, and detection risk, and drives how much testing is needed.

The level of risk that exists in a process or system before any controls are considered, driven by factors such as complexity, volume of transactions, and sensitivity of the data.

The risk that audit procedures fail to uncover an error or control weakness that exists. Auditors reduce it by using better-designed tests, larger samples, and more reliable evidence.

Procedures that check whether prescribed controls are actually being applied, for example observing whether change tickets are approved or re-performing a reconciliation to confirm it was done.

Procedures that look directly for errors or misstatements in data, such as recalculating amounts, confirming balances with third parties, or inspecting source documents, rather than testing the controls themselves.

Software tools an auditor uses to analyze large data populations directly, for example extracting exceptions, matching files, recalculating totals, or testing for duplicate payments across a full transaction ledger.

The set of structures, processes, and relationships through which the board and management direct and control IT so that technology supports the organization's objectives and manages related risk.

A structured reference model of IT processes and control objectives that organizations use to design governance arrangements, assign accountability, and give auditors a benchmark for assessing IT management practices.

A cross-functional management group that prioritizes IT initiatives, allocates resources, resolves conflicts between business units, and monitors whether IT investments deliver the expected business value.

A performance measurement approach that translates IT goals into measurable indicators across perspectives such as business value, user orientation, operational excellence, and future readiness, and reports them to management.

A quantifiable measure chosen to show how well a process or service is achieving a defined objective, such as percentage of changes implemented without a rollback or average time to resolve incidents.

Splitting incompatible tasks among different people so no single individual can both commit and conceal an error or fraud, for example separating authorization, custody of assets, recording, and reconciliation.

The process of assessing, contracting with, monitoring, and periodically re-evaluating external service providers, including reviewing their control reports and defining exit and data-return arrangements.

A contract provision giving the organization, or its appointed auditor, the ability to examine a vendor's relevant controls, records, and facilities, so assurance does not depend solely on the vendor's own claims.

A contract between a service provider and its customer that specifies measurable service targets such as availability, response time, and support hours, together with remedies for failing to meet them.

A documented justification for an IT investment that sets out expected benefits, costs, risks, and alternatives, and provides the baseline against which the project is later evaluated after delivery.

The decision-making structure for an IT project, defining who approves scope changes, who accepts deliverables, how risks are escalated, and how progress is reported to sponsors and oversight bodies.

The phased sequence of activities used to build or acquire an information system, typically including feasibility, requirements, design, development, testing, implementation, and post-implementation review.

Testing in which business users confirm that a system performs required functions and meets agreed requirements in realistic conditions before it is approved for live operation.

A structured assessment after a system goes live that compares actual costs, benefits, and performance with the original business case and records lessons learned for future projects.

The controlled process for requesting, assessing, approving, testing, and implementing modifications to production systems, so that no change reaches live operation without authorization and a rollback plan.

An urgent modification made outside the normal change schedule to restore service or fix a critical defect, which still requires documented approval, testing where feasible, and retrospective review.

A recorded, approved snapshot of a system's components and settings against which later changes are compared, so unauthorized or undocumented alterations can be detected.

The discipline of identifying, recording, controlling, and verifying the components of IT infrastructure and their relationships, so accurate and current information exists about what is deployed where.

The process of detecting, logging, prioritizing, resolving, and closing disruptions to service, with the aim of restoring normal operation quickly while preserving records for root-cause analysis.

The process that investigates recurring or significant incidents to find and eliminate their underlying causes, reducing the number and impact of future disruptions rather than just restoring service.

A structured investigation that traces an incident or failure back to its fundamental cause, often using techniques such as the five-whys or fault tree analysis, so corrective action prevents recurrence.

An assessment that identifies critical business processes, quantifies the effect of their disruption over time, and establishes recovery priorities and targets that drive continuity and recovery planning.

The maximum acceptable elapsed time to restore a process or system after a disruption, used to select recovery strategies and to judge whether continuity arrangements are adequate.

The maximum acceptable amount of data, measured in time, that may be lost in a disruption, which determines how frequently backups or replication must occur.

Documented procedures and arrangements for restoring IT infrastructure, data, and applications at an alternate site or configuration after a major disruption, aligned with recovery objectives set by the business.

The organization-wide plan for keeping critical business functions running during and after a disruption, covering people, facilities, suppliers, and communications as well as technology recovery.

Mechanisms that restrict who can use which systems, data, and functions, implemented through identification, authentication, authorization, and logging of activity within software and networks.

The principle that users and processes receive only the access rights needed for their assigned tasks, and only for as long as needed, limiting the damage from error or misuse.

Access rights that allow administrative control over systems, such as creating accounts or changing configurations, which requires stronger approval, monitoring, and periodic review than ordinary user access.

Assigning information to categories such as public, internal, confidential, or restricted according to its sensitivity and legal obligations, which then determines the protective controls applied to it.