4.1 Cybersecurity, IT General Controls, Privacy, and Data Security

Key Takeaways

  • If the activity under review depends on access, data, or system integrity, cybersecurity and IT controls belong in the engagement risk assessment even when the engagement title is operational.
  • IT general controls (access, change management, computer operations, and system development) are the foundation for relying on application controls; weak ITGCs change work-program design.
  • NIST CSF, COBIT, and ISO/IEC 27001 help the planner map completeness and talk to IT; The IIA does not require one commercial framework.
  • Purpose limitation, data minimization, access, and retention are privacy principles that sit in scope whenever the activity processes personal data.
  • When cybersecurity is in scope of an assurance engagement, the Cybersecurity Topical Requirement (effective 5 February 2026) requires a documented applicability assessment of each requirement, with rationale for exclusions.
Last updated: August 2026

CIA Part 2 does not ask you to sit a cybersecurity professional exam. Official 2025 expanded test spec A3c asks you, as the engagement planner, to recognize existing and emerging cybersecurity risks, common information security and IT controls, IT general controls, the purpose and benefits of an IT control framework, principles of data privacy, and data security policies and practices. That recognition is a planning skill: it changes the engagement risk assessment (Global Internal Audit Standard 13.2) and the procedures you later put in the work program (Standard 13.6). You are not writing the work program in this chapter. You are deciding which technology and privacy risks are real for the activity under review so the program will not be blind.

Why "this is not an IT audit" is usually the wrong scoping call

The highest-yield trap on this objective is scoping an operational engagement as "not IT" because the title says warehouse receiving, claims, payroll, or loan origination. If receipts post through a warehouse management system, if claims pay from an automated engine, or if payroll calculates in an HR application, the activity's integrity depends on who can log in, who can change configurations, whether interfaces are complete, and whether the data is protected. Access failure, data corruption, and processing integrity are engagement risks of that activity, not a courtesy topic for a later IT audit.

That recognition changes work-program design. You add procedures for privileged roles on the application, for change tickets that affect calculation tables, for interface reconciliations, and — if personal data is processed — for privacy and retention. You do not convert every operational engagement into a penetration test, and you do not omit IT solely because "IT audit will cover it next year" unless you have evidence that residual IT risk for this activity is already acceptably addressed and you document that conclusion. Annual-plan coverage of cyber across the organization is a Part 3 concern. Whether this engagement's plan notices the systems it depends on is Part 2.

Existing and emerging cybersecurity risks

Existing risks you should expect in planning interviews include unauthorized access, excessive privileged accounts, phishing that yields credentials, unpatched systems, shared or never-rotated passwords, unsanctioned vendor remote access, and leakage from shared drives or report extracts. Emerging risks that should change the same interviews include ransomware treated as a business-interruption event rather than only a confidentiality event, cloud and SaaS misconfiguration (public storage, overly broad identity roles), API exposure between the activity's system and a partner, identity as the perimeter when staff work remotely, and AI-enabled social engineering aimed at payment or access approvers.

The planning question is not "are we scheduled to audit cyber?" It is "what could go wrong with the systems and data that run this activity, including threats that did not exist when the last engagement was performed?" Emerging risk belongs in Standard 13.2 because a change in the threat landscape changes control reliance. A user-access review designed three years ago around on-premise passwords is not automatically responsive to a cloud identity model.

Common information security and IT controls

Information security controls cluster into prevention, detection, and correction. Preventive examples that show up in almost every activity: unique IDs, least privilege, multi-factor authentication, encryption in transit and at rest for sensitive data, and identity or network segmentation that keeps a warehouse clerk out of the general ledger. Detective examples: logging and alerting, failed-login monitoring, periodic access recertification, and exception reports from the application. Corrective examples: incident response, timely patching, account disablement, and restoration from known-good backups.

Your planning job is to identify which of these actually protect the activity under review, who owns them (the activity, IT, a shared service, or a vendor), and whether the engagement can rely on them. A polished enterprise security policy is not a control over this activity until you see it operating on the systems in scope. If the claims unit exports unencrypted files to a vendor every Friday, the encryption standard on the intranet is not the control that matters.

IT general controls versus application controls

IT general controls (ITGCs) are the foundation controls over the computing environment:

  • Logical and physical access to operating systems, databases, infrastructure, and administrative tools
  • Change management for programs, configurations, and job schedules
  • Computer operations: job monitoring, incident handling, and backups
  • System acquisition or development, including segregation of developers from production

Application controls sit inside a specific business application: input edits, automated calculations, workflow authorization of a transaction, completeness of an interface file, and output reviews.

This distinction drives the work program. If ITGCs around access and change are weak, automated application controls can be bypassed or silently altered. Planning then either treats the automated control as unreliable (more compensating or substantive procedures) or brings in IT audit skills to test the ITGCs first. If ITGCs are strong, you can design more efficient tests of the application's automated controls. Mixing the two categories is a common exam error: a credit-limit hold or overtime calculation edit is an application control; a required approval to move code to production is an ITGC. Privileged access to the database that stores the application's tables is an ITGC even though it can undo every application edit.

Control typeExample in the activityPlanning implication
ITGC — accessJoiner-mover-leaver for OS, database, and application administratorsIf privileged access is unmanaged, automated controls in the activity's system are not reliable
ITGC — changeProduction changes require a ticket, approval, and segregation from the requesterUncontrolled changes can alter calculations without a business trail
ITGC — operationsMonitored batch jobs and tested backups for the activity's systemFailed jobs or unrestorable data undermine completeness and continuity
Application controlAutomated matching, credit hold, or payroll tax calculationTest the rule and who can override it
PrivacyRetention schedule; purpose limitation on extractsIn scope if the activity stores personal data
Data securityEncryption of files at rest; controls over downloads and vendor transmissionsIn scope if sensitive data leaves the system

Purpose and benefits of an IT control framework

You are not required to memorize control catalogs at CISSP depth. You are required to recognize why a framework helps. NIST Cybersecurity Framework 2.0 organizes work into Govern, Identify, Protect, Detect, Respond, and Recover — vocabulary boards and CISOs already use. COBIT 2019 connects IT governance and management objectives to enterprise goals. ISO/IEC 27001 describes a risk-based information security management system with policies, risk assessment, and continual improvement.

Benefits for the engagement planner:

  • A completeness map so you do not test passwords and ignore asset inventory, logging, or recovery
  • A shared language with IT management and the activity owner
  • A way to map management's claimed controls to an independent structure
  • A method to spot gaps before you lock scope

The IIA does not mandate one commercial framework. The Cybersecurity Topical Requirement user guide maps the Requirement to NIST CSF 2.0, COBIT 2019, and NIST SP 800-53 so functions can demonstrate coverage. Referencing those mappings does not mean The IIA requires NIST or COBIT. If management already uses a suitable framework, use it as evaluation criteria (Standard 13.4) rather than inventing a parallel checklist. If management uses no framework, that absence is itself a planning risk: control design is harder to evaluate consistently.

Privacy principles and data security practices

When the activity processes personal data — employees, customers, patients, students, or citizens — privacy is a key risk even if the engagement title never says "privacy." Principles you must recognize at the planning table:

  • Purpose limitation: collect and use data for specified, legitimate purposes, not because the application can store extra fields or marketing wants a convenient extract.
  • Data minimization: keep only what the process needs.
  • Access: both data-subject access and correction where law requires it, and least-privilege internal access so a clerk cannot export the whole customer file.
  • Retention: keep data only as long as the purpose and legal retention rules require, then dispose of it securely.

Integrity, confidentiality, transparency, and accountability sit alongside those four. They change planning. A customer-operations engagement that sends full account files to a vendor for "analytics" is a privacy and security issue even if the stated objective is service levels. Data security policies and practices should cover classification, encryption, access recertification, logging, secure disposal, and handling of portable media, downloads, and period-end report dumps. Planning procedures include obtaining the policy, identifying the activity's high-risk data stores, and asking whether practice matches policy at the points data actually leaves the system.

Topical Requirements when cybersecurity is in scope

Topical Requirements are mandatory IPPF material for assurance engagements when a risk assessment leads to the topic being (1) the subject of an engagement in the internal audit plan, (2) identified while performing an engagement, or (3) the subject of a requested engagement that was not on the original plan. The Cybersecurity Topical Requirement became effective 5 February 2026. Conformance is mandatory for assurance and recommended, not required, for advisory services.

Planning implication: if cyber is in scope, assess each requirement in the Topical Requirement for applicability and retain that evidence. Not every individual requirement applies to every engagement; exclusions need a documented rationale. Do not skip governance requirements solely because the engagement feels "technical," and do not skip technical controls solely because you interviewed the CISO. Quality assessments look at this documentation in connection with Standards 13.2 and 13.3. The IIA's published exam policy is that scored CIA questions on a new Topical Requirement appear no earlier than six months after its effective date, so by August 2026 the Cybersecurity Topical Requirement is inside the exam window.

Keep the Part 3 boundary clean. How often the function audits cyber across the annual plan, and how the chief audit executive reports residual cyber risk to the board, are not this objective. Part 2 tests whether this engagement's plan recognizes cyber, ITGCs, privacy, and data security when the activity depends on them.

Loading diagram...
Planning decision: when IT, cyber, and privacy enter the engagement
Test Your Knowledge

An engagement is planned on warehouse receiving. Management tells the auditor that this is an operations review, not an IT audit. Receiving quantities post automatically from a warehouse management system, vendor IDs are system-generated, and the three-way match is an automated application control. What is the most appropriate planning response?

A
B
C
D
Test Your Knowledge

While planning an engagement of the payroll activity, which item is an IT general control rather than an application control?

A
B
C
D
Test Your Knowledge

Cybersecurity is in scope of an assurance engagement of customer operations. According to the Cybersecurity Topical Requirement, what must the planner do?

A
B
C
D