ETiCPA ATQE Exam cheat sheet

COBIT separates governance from management: governance domains are EDM (Evaluate, Direct, Monitor); management domains are APO, BAI, DSS, MEA.

COSO ERM defines risk as the possibility that events will occur and affect the achievement of objectives; inherent risk is assessed before controls, residual risk after controls.

Risk register fields: risk ID, description, owner, likelihood, impact, inherent score, control reference, residual score, treatment (accept/mitigate/transfer/avoid), review date.

Risk appetite is the amount of risk an entity is willing to accept in pursuit of objectives; risk tolerance is the acceptable variation around that appetite.

Three lines model: first line owns and manages risk, second line provides oversight and challenge, third line (internal audit) provides independent assurance.

IT risk assessment formula: risk score = likelihood x impact; heat maps typically use 3x3 or 5x5 scales, and scoring scales must be defined before assessment to avoid post-hoc bias.

Key risk indicator (KRI) thresholds usually have three zones: green (normal), amber (escalation), red (action mandatory and reported to the board or risk committee).

Segregation of duties is a preventive governance control: incompatible duties include authorization, custody of assets, recording, and reconciliation.

ITGC categories: access to programs and data, program changes, program development, and computer operations; they support reliance on automated and application controls.

COSO Internal Control framework has five components: control environment, risk assessment, control activities, information and communication, monitoring activities; 17 principles map to these components.

Control types: preventive (stops before occurrence), detective (identifies after occurrence), corrective (remediates); manual vs automated; key vs non-key controls.

A control deficiency exists when a control is designed, implemented, or operating so that it cannot prevent or detect misstatements on a timely basis.

Deficiency severity: deficiency, significant deficiency (less severe than material weakness but important enough to merit attention), material weakness (reasonable possibility of material misstatement not prevented or detected timely).

Automated controls depend on ITGC effectiveness; if ITGCs are ineffective, the auditor cannot rely on automated controls or system-generated reports without additional substantive testing.

Compensating controls may reduce the severity of a deficiency but do not eliminate it; the auditor documents the rationale for any reduced severity conclusion.

Frameworks commonly referenced: COBIT (governance and management objectives), COSO (internal control and ERM), ISO/IEC 27001 (ISMS), NIST CSF (identify, protect, detect, respond, recover).

Audit universe scoping ranks auditable entities by inherent risk, materiality, change velocity, prior findings, and regulatory exposure; results drive the multi-year plan.

Engagement planning outputs: objectives, scope (in and out), criteria, materiality, timetable, resource assignment, and information request list.

Materiality is set at engagement level; performance materiality is set below it (commonly 50-75 percent) to reduce the probability that uncorrected misstatements exceed materiality.

Risk-based audit approach: understand the entity and its IT environment, identify significant risks, design procedures responsive to those risks, then conclude.

Audit scope exclusions must be documented with rationale and disclosed in the report; scope limitations imposed by management may lead to a qualified opinion or disclaimer.

Walkthroughs confirm understanding of the process and verify that the control as described is actually performed; they are not tests of operating effectiveness.

Data analytics in planning (e.g., full-population transaction analysis) can refine risk assessment and identify anomalies for targeted testing.

Engagement risk is the risk that the auditor will be exposed to harm (reputational, litigation) from the engagement; it is assessed separately from audit risk.

Evidence must be sufficient (quantity) and appropriate (relevance and reliability); reliability hierarchy: auditor's direct observation and inspection > external confirmations > internal documents > oral representations.

Test of control attributes: population definition, sampling unit, control deviation definition, tolerable deviation rate, and expected deviation rate.

Attribute sampling formula for sample size uses confidence level and tolerable/expected deviation rates; deviations found are compared to the tolerable rate to conclude effectiveness.

Sampling risk is the risk the sample conclusion differs from the population; non-sampling risk arises from human error, wrong procedures, or misinterpretation.

Monetary unit sampling (probability proportional to size) is used for substantive testing of overstatement; each monetary unit has an equal chance of selection.

Statistical sampling allows quantified sampling risk; non-statistical sampling relies on auditor judgment and does not quantify sampling risk.

Evidence for automated controls: inspect configuration, re-perform the calculation, test the report logic, and verify change control over the relevant system.

Exceptions must be evaluated for root cause; a deviation does not automatically mean the control failed, but unexplained or systematic deviations do.

ITIL service lifecycle (v3) phases: strategy, design, transition, operation, continual service improvement; ITIL 4 reframes these as service value chain practices.

Incident management restores service quickly; problem management finds and eliminates root cause; a known error is a problem with documented root cause and workaround.

Change management categories: standard (pre-authorized), normal (requires approval), emergency (expedited approval with retrospective review).

Service level agreement (SLA) defines measurable service targets; operational level agreement (OLA) supports an SLA internally; underpinning contract supports it with a supplier.

Recovery metrics: RTO is the maximum acceptable downtime; RPO is the maximum acceptable data loss measured in time; both drive backup and replication design.

BCP/DR test types in increasing rigor: checklist review, tabletop exercise, simulation, parallel test, full interruption test; results must be documented and issues tracked.

Backup controls to test: schedule adherence, successful completion logs, offsite/immutable copies, restore testing evidence, and media rotation.

Capacity and performance monitoring should include defined thresholds, alerting, and evidence that threshold breaches were investigated.

CIA triad: confidentiality, integrity, availability; controls are mapped to each objective and to the threats they mitigate.

Identity controls: unique user IDs, joiner-mover-leaver provisioning, least privilege, periodic access recertification, privileged access management, and multi-factor authentication.

Authentication factors: something you know, something you have, something you are; MFA requires at least two different factor types.

Encryption: symmetric (AES) for bulk data, asymmetric (RSA, ECC) for key exchange and signatures; hashing (SHA-256) provides integrity, not confidentiality.

Vulnerability management cycle: asset inventory, scan, prioritize (CVSS score plus exploitability and business criticality), remediate, verify, report.

Patch management evidence: patch inventory, risk-based SLAs by severity, deployment reports, and exceptions with approved risk acceptance.

Logging and monitoring: centralized log retention, time synchronization, review evidence, and alert triage records; SIEM correlation supports detection.

Security incident response phases: preparation, detection and analysis, containment/eradication/recovery, post-incident lessons learned.

SDLC phases: requirements, design, build, test, deploy, maintain; gates should require approval before the next phase begins.

Segregation in change: developer, tester, and person who promotes to production should be different roles; developers should not have production write access.

Change evidence to test: request, risk assessment, approval, testing results, user acceptance, implementation record, and post-implementation review.

Emergency change controls: pre-approved criteria, retrospective review within a defined window, and documentation of the emergency rationale.

Project governance: charter, business case, steering committee, stage gates, RAID log (risks, assumptions, issues, dependencies), and benefits realization tracking.

Agile delivery audit considerations: backlog traceability, definition of done, automated test evidence, sprint reviews, and controls over continuous deployment pipelines.

Data migration controls: field mapping, reconciliation of record counts and totals, cutover sign-off, and rollback plan.

Baseline configuration and version control provide evidence that only authorized code reaches production; compare repository commits to deployed artifacts.

Data lifecycle: create/acquire, store, use, share, archive, destroy; controls should exist at each stage and destruction must be evidenced.

Data quality dimensions: completeness, accuracy, timeliness, consistency, uniqueness, validity.

Privacy principles commonly tested: purpose limitation, data minimization, accuracy, storage limitation, integrity and confidentiality, accountability.

Data subject rights may include access, rectification, erasure, restriction, portability, and objection; response timelines are set by applicable law.

Cross-border transfer mechanisms include adequacy decisions, standard contractual clauses, and binding corporate rules, depending on jurisdiction.

Privacy impact assessment (PIA/DPIA) is triggered by high-risk processing such as large-scale sensitive data, systematic monitoring, or new technology.

Emerging technology risks: AI model bias and drift, third-party/cloud concentration risk, shadow IT, and IoT device inventory and patch gaps.

Third-party data processing requires due diligence, contractual security and privacy clauses, and ongoing monitoring evidence.

Report structure: objectives and scope, approach, summary of results, detailed findings, management responses, and overall conclusion or opinion.

Finding elements: criteria (what should be), condition (what is), cause (why), effect/risk (so what), and recommendation.

Finding ratings are defined by the audit function's methodology (e.g., high/medium/low) and must be applied consistently across engagements.

Management responses should include a named owner, a committed action, and a target date; vague responses should be escalated before report issuance.

Follow-up tracks remediation status against agreed dates; overdue high-risk items are escalated to the audit committee.

Communication during the engagement includes opening meeting, status updates, and a closing/exit meeting to confirm factual accuracy of findings.

Report distribution is restricted per the audit charter; confidentiality and data protection requirements apply to report contents.

A follow-up audit may re-test remediated controls; closure requires evidence of sustained operation, not just a management assertion.

IT strategy alignment is evidenced by an approved IT plan traceable to business objectives and by IT steering committee minutes.

IT balanced scorecard perspectives commonly used: business contribution, user orientation, operational excellence, future orientation.

Key IT performance indicators: project delivery on time and budget, incident resolution within SLA, availability percentage, patch compliance rate.

Risk treatment options: avoid, reduce/mitigate, transfer/share, accept; each decision requires documented approval at the appropriate authority level.

Emerging risk monitoring includes regulatory change tracking, threat intelligence review, and technology obsolescence assessment.

Board or audit committee oversight evidence includes charter, meeting frequency, attendance, and documented challenge of management.

Access control testing: review user lists for terminated and transferred users, privileged accounts, generic/shared IDs, and periodic recertification evidence.

Change management testing: select changes from the population, verify authorization and testing, and confirm segregation between development and production.

Operations testing: batch job monitoring, backup success and restore tests, incident tickets, and job failure resolution evidence.

ITGC failure does not automatically mean financial misstatement; the auditor assesses the effect on reliance on automated controls and reports deficiencies.

Control self-assessment (CSA) results supplement but do not replace independent testing.

Framework mapping: COBIT for governance objectives, ISO/IEC 27001 for ISMS controls, NIST CSF for cybersecurity functions; mapping avoids duplicate control testing.

Audit risk model: audit risk = inherent risk x control risk x detection risk; detection risk is managed by the nature, timing, and extent of procedures.

Significant risk is an identified risk requiring special audit consideration; it often relates to complex transactions, estimates, or fraud risk.

Fraud risk assessment includes management override of controls, incentives and pressures, opportunities, and rationalization.

Preliminary analytics compare current-period balances and ratios to expectations; unexplained variances become targeted test areas.

Engagement budget and staffing plan should reflect risk level and required specialist skills (e.g., cybersecurity, data analytics).

Prior-year findings and management letter items inform the current scope and are tracked for repeat findings.

Population completeness must be verified before sampling; an incomplete population invalidates the sample conclusion.

Systematic selection uses a fixed interval; if the interval aligns with a data pattern, bias can result, so random start is used.

Stratified sampling divides the population into homogeneous groups and samples within each stratum to reduce variability.

Sample size increases with higher confidence, higher expected deviation rate, and lower tolerable deviation rate.

Re-performance and recalculation provide strong evidence for automated calculations; observation is limited to the time of observation.

External confirmation evidence is stronger when the auditor controls the confirmation process directly.

Availability is measured as uptime divided by total scheduled time; scheduled maintenance is often excluded by agreement.

Mean time to repair (MTTR) and mean time between failures (MTBF) are used to trend service reliability.

Business impact analysis (BIA) identifies critical processes, dependencies, and RTO/RPO targets before the BCP is written.

DR site types: cold (space and power), warm (partial equipment), hot (fully mirrored); recovery time decreases as site readiness increases.

Problem management outputs include root cause analysis, known error records, and permanent fixes linked to change records.

Service desk metrics: first-contact resolution rate, average handling time, backlog age, and reopened ticket rate.

Access review evidence: reviewer identity, date, scope of accounts reviewed, decisions recorded, and timely removal of inappropriate access.

Privileged access controls: separate admin accounts, session logging, just-in-time elevation, and periodic review of administrative groups.

Network segmentation limits lateral movement; firewall rule reviews should confirm business justification and removal of stale rules.

Security awareness training effectiveness is measured by completion rates plus phishing simulation click and report rates.

Data loss prevention, endpoint detection and response, and email filtering are detective/preventive controls whose alerts require triage evidence.

Third-party security assessment includes questionnaire review, independent assurance reports (e.g., SOC 2 Type II), and remediation tracking.

Waterfall gates require documented phase approvals; agile substitutes working software reviews and sprint acceptance for phase gates.

User acceptance testing evidence should show test cases derived from requirements, results, defects, and sign-off by business owner.

Separation of environments (development, test, production) prevents unauthorized code from reaching production.

Project risk log entries include likelihood, impact, owner, mitigation, and status; unresolved high risks should be escalated to the steering committee.

Post-implementation review compares actual benefits, cost, and schedule to the approved business case.

Source code repository controls: branch protection, peer review before merge, and audit trail of commits.

Data classification tiers (e.g., public, internal, confidential, restricted) drive handling, encryption, and retention requirements.

Retention schedules must reflect legal, regulatory, and contractual requirements; deletion must be verifiable across backups and archives.

Data governance roles: data owner (accountable), data steward (operational quality), data custodian (technical controls).

Cloud shared responsibility: the provider secures the infrastructure; the customer secures data, identities, and configuration.

AI governance controls include model inventory, training data provenance, bias testing, human oversight, and monitoring for drift.

Privacy breach response includes containment, assessment of risk to individuals, notification where required, and documented lessons learned.

Root cause analysis techniques for findings: five whys, fishbone diagram, and process mapping to distinguish symptom from cause.

Findings should be discussed with management before the draft report is issued to confirm facts and agree on responses.

Repeat findings indicate remediation failure and should be reported with the original finding reference and escalation history.

Follow-up status categories commonly used: open, in progress, closed, risk accepted, overdue.

Audit committee reporting summarizes themes, high-risk findings, remediation status, and resource or scope issues.

Quality review of the report checks evidence support for each finding, consistent ratings, and clear, actionable recommendations.

IT risk universe segmentation often uses business process, system, location, and third-party dimensions.

Key control indicators (KCIs) measure whether a control is operating as designed, distinct from KRIs which measure risk exposure.

Risk aggregation considers correlation between risks; individually acceptable risks can combine into an unacceptable portfolio exposure.

Policy exception management requires documented approval, compensating controls, and an expiry date.

Governance reporting cadence: operational metrics monthly, risk profile quarterly, full board reporting at least annually.

Control design vs operating effectiveness: design evaluates whether the control can achieve the objective; operating effectiveness tests whether it actually did throughout the period.

A key control is one that, if it fails, materially affects the achievement of the control objective; testing focuses on key controls.

Interface controls verify completeness and accuracy of data transferred between systems (record counts, hash totals, error reports).

Automated control testing includes verifying the configuration once and testing the related change controls, rather than re-testing every transaction.

ITGC scope should cover systems supporting significant financial or business processes, determined by scoping analysis.

Documentation standards: control description, owner, frequency, type, evidence source, and test procedure.

Understanding the business includes industry, regulatory, organizational structure, IT landscape, and key third-party dependencies.

Inherent risk factors for IT include complexity, volume of transactions, degree of automation, change frequency, and prior incidents.

Multi-location scoping selects locations based on coverage of the population (e.g., locations covering a defined percentage of total activity).

Time budget overruns on high-risk areas should trigger reassessment of scope, not automatic reduction of testing.

Use of a specialist (e.g., penetration tester, data scientist) requires documented competence and evaluation of their work.

Audit plan approval by the audit committee provides authority and independence for the engagement scope.

Evidence documentation should allow an experienced auditor with no prior connection to the engagement to re-perform the work and reach the same conclusion.

Interviews provide corroborating evidence but are insufficient alone for control effectiveness.

Observation of a control at a single point in time does not evidence operation over the whole period.

Inspection of physical or digital records is strong evidence of existence but not necessarily of completeness.

Analytical procedures use expectations and thresholds; differences beyond the threshold require investigation and explanation.

When deviations exceed the tolerable rate, the control is concluded ineffective and the auditor expands substantive testing.

Incident severity classification should be defined in advance, with escalation paths and communication plans per severity.

Major incident review should occur after resolution, with actions tracked to completion.

Backup restore testing frequency should be risk-based; evidence includes restored data validation, not just job success logs.

BCP maintenance triggers include organizational change, system change, and significant incident lessons learned.

Vendor and cloud dependency mapping is part of BIA; single points of failure should be identified and mitigated.

Capacity management evidence includes trend analysis and documented action when thresholds are approached.

Security governance elements: policy framework, roles and responsibilities, risk appetite, and performance reporting to management.

Vulnerability severity SLAs commonly differentiate critical, high, medium, and low, with shorter remediation windows for internet-facing assets.

Incident response evidence: incident log, timeline, containment actions, notification records, and lessons-learned actions.

Cryptographic key management includes generation, distribution, storage, rotation, and destruction; key custody should be segregated.

Physical security controls include badge access logs, visitor management, and environmental monitoring for data centers.

Security metrics should be outcome-based (e.g., time to remediate) rather than activity counts alone.

Change advisory board (CAB) reviews normal changes; membership and quorum should be defined in the change policy.

Change success metrics: percentage of changes resulting in incidents, emergency change ratio, and rollback rate.

DevOps pipeline controls: code review, automated testing gates, artifact signing, and deployment approval records.

Project stage-gate criteria should be documented before the gate review to avoid moving targets.

Benefits realization should be measured after go-live against the business case assumptions.

Data conversion testing includes record count reconciliation, exception handling, and business sign-off before cutover.

Data lineage and metadata management support traceability from source to report, which is essential for report reliability testing.

Master data management controls reduce duplicate and inconsistent records across systems.

Privacy notice requirements typically include purpose, legal basis, recipients, retention, and data subject rights.

Consent management requires records of consent, withdrawal mechanisms, and evidence that processing stopped after withdrawal.

Cloud exit and portability planning mitigates vendor lock-in and supports data return obligations.

Emerging technology adoption should include a risk assessment, pilot controls, and defined approval authority before production use.

Management responses should address the root cause, not only the specific instance found.

Action plans with unrealistic dates should be challenged; the auditor documents the rationale for accepting or escalating.

Interim reporting of high-risk findings should occur before the final report to enable timely action.

Follow-up testing should be performed after the agreed remediation date, using the same test procedure where possible.

Closure decisions require evidence attached to the finding record and approval by the engagement lead.

Reporting to the audit committee should distinguish closed items, open items within date, and overdue items.

Enterprise risk management integrates IT risk with business risk; IT risk should be expressed in business impact terms.

Risk culture is evidenced by escalation behavior, incident reporting rates, and management tone in communications.

Third-party risk management lifecycle: due diligence, contracting, onboarding, ongoing monitoring, and offboarding.

Concentration risk arises when critical services depend on a single vendor or a single geographic region.

Scenario analysis and stress testing are used to evaluate low-frequency, high-impact IT risks.

Risk acceptance must be at the authority level defined in the risk appetite statement, not by the risk owner alone.

User access provisioning controls: approved request, appropriate approver, timely creation, and role assignment consistent with job duties.

Termination controls should include timely disabling of access; audit tests compare HR termination dates to system disable dates.

Password and authentication settings (length, complexity, lockout, expiry) are configuration controls verified by inspection.

Batch processing controls include job scheduling authorization, output distribution controls, and restart/recovery procedures.

Incident and problem management records support the operations control objective when resolution is timely and documented.

Control testing should cover the full period of reliance, using a combination of interim and roll-forward procedures.

Audit objectives should be stated as questions the engagement will answer, with criteria for each.

Scope statements should define systems, locations, time period, and processes included and excluded.

Information request lists should be issued early and tracked; delays should be documented as potential scope constraints.

Risk assessment should be refreshed during the engagement if new information emerges.

Reliance on the work of others (internal audit, specialists, other auditors) requires evaluation of competence, objectivity, and scope.

Engagement letters or charters define authority, responsibilities, and access rights for the audit team.

Samples should be selected from a complete population obtained directly from the system, not from a management-prepared list.

Documentation of the sampling methodology includes population size, sample size, selection method, and evaluation basis.

When a selected item cannot be tested, the auditor documents the reason and treats it as a deviation or selects a replacement per the defined methodology.

Test scripts should specify the attribute tested, the evidence expected, and the pass/fail criterion.

Evidence obtained from a system report requires verification of the report's completeness and accuracy.

Conclusions should state the test performed, results, exceptions, and the resulting assessment of control effectiveness.

Service catalog defines services offered with owners, targets, and dependencies.

Availability reporting should reconcile monitoring tool data with incident records to identify unrecorded outages.

Disaster recovery testing should include application recovery, data integrity verification, and business user validation.

Crisis communication plans should define spokespeople, channels, and contact lists that are regularly updated.

Problem management should link incidents to problems to enable trend analysis and prevention.

Supplier management reviews should assess performance against SLAs and track remediation of service credits or issues.