CISA Audit Planning: Standards, Ethics, Risk-Based Planning and Controls

The audit charter is the standing document that gives the internal IS audit function its purpose, authority, responsibility and access rights, and it is approved by the board of directors or the board's audit committee. Approval at that level is what makes the mandate independent: anyone whose area the function audits could otherwise narrow it. The charter states that auditors have unrestricted access to the records, systems, premises and people relevant to their work. It also defines the kinds of engagements the function performs (assurance, and advisory if it does any) and sets the reporting line.

Because the charter is where access comes from, it is the authority an IS auditor relies on when access is disputed. A local procedure, a team's own classification of its data or an instruction from the auditee cannot override a mandate the board has approved. A cloud operations team that labels its logs "restricted" still has to give the auditors access, because the charter already grants it. Disputes the charter does not settle go through audit management to the audit committee.

A charter must also keep pace with the function's work. When the function is asked to do a kind of work its charter does not yet describe, such as consulting on a data-governance programme or carrying out investigations, the charter is amended first. The amendment defines the new role and its independence safeguards (for example, staff who advised on a system do not later audit it), and the audit committee approves it. Work done outside the charter has no formal authority behind it.

The charter governs the organization's own internal audit function. An outside firm engaged by the organization works under an engagement letter agreed with the client, which plays the same role for that one engagement: it records what the engagement will cover, who is responsible for what and what will be delivered.

ISACA's IT Audit Framework (ITAF) is the professional practice framework for IS audit and assurance, and its standards are mandatory while its guidelines are not. ITAF has three layers:

• Standards: mandatory requirements for IS audit and assurance work. They are grouped into general standards (including the audit charter, organizational independence, auditor objectivity, reasonable expectation, due professional care, proficiency, assertions and criteria), performance standards (including risk assessment in planning, scheduling, engagement planning, performance and supervision, evidence, using the work of other experts, and irregularities and illegal acts) and reporting standards (reporting and follow-up).
• Guidelines: direction on how to apply the standards. They are not mandatory, but a practitioner who departs from one must be able to justify the departure and must still meet the standard the guideline supports.
• Tools and techniques: white papers, audit programs and other aids that give practical examples.

Guidelines therefore leave room for professional judgement. When a guideline's procedure does not fit an environment, the auditor uses a procedure that does and records the reasoning in the working papers, so a reviewer can see that the standard's requirement was still met. The standards are the profession's baseline for IS audit and assurance work, whoever performs it and whatever its subject.

Audit criteria are the benchmarks the subject matter is evaluated against, and ITAF requires them to be suitable. The criteria standard describes attributes such as being objective, complete, relevant, reliable, measurable, understandable, widely recognized and authoritative. Three tests catch most unsuitable criteria:

• Is it in force? Criteria need current authority, such as a formally approved policy, standard or contract term, or a recognized external standard or regulation. A superseded version of a standard no longer has that authority.
• Is it independent of the subject? The yardstick cannot be the thing being measured. How a process actually runs is what the audit examines, so it cannot also be the benchmark.
• Whose requirement is it? Criteria should reflect the organization's requirements and obligations. A checklist the auditor wrote personally, with no basis in policy, regulation or a recognized standard, has no authority with the auditee.

Irregularities and illegal acts

When an IS auditor finds evidence of a possible irregularity, such as fraud or a conflict of interest, ITAF requires the auditor to communicate it promptly to an appropriate level of the organization above the people who may be involved. The auditor reports and documents. Investigating and deciding on legal consequences belong to people with that authority, supported by legal counsel.

Who counts as "appropriate" depends on who may be involved. Suspicion about a procurement officer splitting contracts to stay under approval limits can go to senior management. When the suspicion points at the executive team itself, the communication goes to those charged with governance, normally the audit committee, because executives cannot be relied on to act independently on a matter that involves them. Whether to notify regulators or law enforcement is decided by governance with legal counsel, according to the law that applies.

The auditor also considers the effect on the audit itself: whether the irregularity changes the risk assessment, the scope or the reliance placed on management's representations, and whether specialist (forensic) support is needed.

The ISACA Code of Professional Ethics binds every CISA holder to standards of conduct that include competence, confidentiality, due care, objectivity and full reporting of significant facts. Its tenets commit members to support appropriate standards and controls, perform their duties with objectivity, due diligence and professional care, serve stakeholders lawfully, maintain the privacy and confidentiality of information obtained in their work unless disclosure is required by legal authority, maintain competency and undertake only activities they can reasonably complete with the necessary skills, inform appropriate parties of the results of work while revealing all significant facts known to them, and support the professional education of stakeholders. Members who fail to comply can be investigated and disciplined.

Four applications come up repeatedly:

• Competence comes before the work. The Code allows only work the auditor can reasonably complete with the necessary skills. An auditor scheduled to review industrial control systems at a manufacturing plant without that background closes the gap before fieldwork, through training or a qualified expert whose work the auditor plans and evaluates. Telling people about a skills gap does not close it.
• Confidentiality has a legal exception. Audit information stays confidential unless an authority with legal power requires its disclosure, for example a court order in litigation or a regulator using its statutory powers. The auditor then provides what is lawfully required, through the organization's legal and audit channels.
• Information belongs to its owner. Working papers, diagrams and findings belong to the organization the work was done for. An auditor who changes employer takes their skills, experience and general methods, but no copies of documents. Changing the form of a copy, by editing it or protecting it, does not change who owns what is in it.
• All significant facts are reported. A significant weakness that management corrects during fieldwork is still reported, with the corrective action noted, because governance needs to know the control failed. One corrected instance also says little about the process behind it. A server found missing a critical patch suggests the patch process may have missed others, so the auditor checks its root cause and other instances before concluding. (Report writing and follow-up are covered in the Audit execution lesson.)

Independence means the IS audit function and each auditor are free from conditions that threaten their ability to perform audit work without bias, both organizationally and in attitude (objectivity). ITAF requires both, and it requires any impairment, in fact or in appearance, to be disclosed to the appropriate parties.

Organizational independence comes from the reporting line. The strongest arrangement combines a functional reporting line to the audit committee and an administrative line to a senior executive. The committee approves the charter and the plan, receives the results and decides on the head of audit's appointment. The executive handles day-to-day matters such as budgets and facilities. A functional line to any executive whose area is audited, or who could steer what is audited and reported, weakens independence.

Individual objectivity is threatened most often by a self-review threat: an auditor reviewing something they designed, built or operated. The rule is disclosure first. An auditor who wrote the organization's backup procedures in an earlier operations job, and is now assigned to audit backup and recovery, tells audit management about that role before the work starts. Audit management then decides how to handle it, for example by assigning someone else or by having an independent senior review the work. The disclosure has to happen before the work, because nobody can judge or manage an impairment they do not know about.

Advise, don't implement. Early audit involvement in projects is valuable, and auditors should give advice, for example in a pre-implementation review, by recommending the controls a system needs. Designing those controls in detail, configuring, approving or operating them is management's job. Suppose a data-migration project asks the auditor to write the reconciliation scripts that will prove the migration is complete. The auditor specifies what the reconciliation must prove and how its results should be evidenced, and the project team builds and runs it. Whatever an auditor builds, they cannot later audit objectively.

An audit is a systematic, independent examination against defined criteria that leads to a conclusion or opinion, and the type of audit is set by what is examined and why. CISA expects you to match the engagement to the need:

A forensic audit is chosen because of how the evidence may be used. When findings may support prosecution, litigation or dismissal, as when a departing employee is suspected of copying customer data, evidence must be collected under forensic discipline from the outset, with chain of custody and preserved originals. Evidence gathered informally first may not be admissible later. (Evidence handling and forensic techniques are taught in the Audit execution lesson.)

Assessments and reviews are lighter than audits and usually do not end in a formal opinion. A gap (readiness) assessment compares current practice with a standard's requirements before a formal certification or compliance audit, so that management can fix shortfalls first. The certification or attestation itself is a separate, later engagement by an independent, accredited party. A risk assessment identifies and rates risks; it does not measure conformity to a standard. Pre-implementation and post-implementation reviews look at a system before and after go-live, and the post-implementation review also asks whether the system delivered the benefits in its business case. Control self-assessment, covered below, is carried out by the process owners themselves.

Control self-assessment versus independent audit

Control self-assessment (CSA) is a process in which the business units that own a process identify and evaluate their own risks and controls, usually in facilitated workshops or through questionnaires. Its main benefit is ownership: business units become more accountable for monitoring their own controls, and control awareness spreads through the organization. Other benefits include earlier identification of risks and better communication between management and audit.

The IS auditor's role in CSA is that of a facilitator and adviser who designs the approach, guides the workshops and brings control expertise. The controls and the ratings remain the process owners'. The auditor adds structure without taking over management's responsibility.

Because CSA is not independent, it complements audit and never replaces it. CSA results are a useful planning input: they show where owners see weaknesses and can help the auditor focus scope. High-risk areas still need independent testing, however consistent the self-assessments have been, because governance needs assurance from someone other than the process owners.

A SOC report is an independent auditor's report on a service organization's controls, and the right one depends on which controls the user needs assurance over and whether it must cover a period. System and Organization Controls (SOC) reports are issued under AICPA standards. SOC 1 is issued under SSAE 18, and ISAE 3402 is the international counterpart for controls relevant to financial reporting.

Type 1 versus Type 2. A Type 1 report gives an opinion on the design of controls, and on their implementation, at a point in time. A Type 2 report also tests and gives an opinion on their operating effectiveness over a period, commonly six to twelve months. Choosing a report is therefore two decisions. The subject decides the report number: controls relevant to financial reporting are SOC 1, and the Trust Services Criteria are SOC 2 or SOC 3. The evidence needed decides the type: evidence that controls operated across a period, with the tests that show it, needs a Type 2 that covers that period.

Gaps in the period. When the report period ends before the user's year-end, the service organization can issue a bridge (gap) letter. This is management's written assertion that the controls have not changed materially since the period ended. It is not audited, so the user's auditor still decides whether the gap months need more work, such as inquiry, testing at the user's end or obtaining the next report when it is issued.

Complementary user entity controls (CUECs). A SOC report lists controls the service organization assumes each client operates. Examples are limiting which of the client's staff can submit files to the provider and reviewing the user-access listings the provider sends. The opinion holds only if those controls work, so a clean opinion is not enough on its own. The user's auditor tests whether the client actually performs its CUECs, which are the client's responsibility by definition. The auditor also checks the report's scope (the systems and locations covered, and any subservice organizations carved out) and any exceptions in the test results.

A risk-based audit plan allocates limited audit resources to the areas where risk to the organization's objectives is greatest, and it starts with a risk assessment of the audit universe. The steps are:

1. Define the audit universe: the auditable areas (systems, processes, projects, locations, third parties).
2. Assess the risk of each, considering business impact and strategic importance, complexity, the volume and value of transactions, regulatory exposure, recent changes, new systems, previous audit results and the time since the last audit.
3. Prioritize and allocate resources to the highest risks, then add any audits required by regulation or the charter.
4. Obtain audit committee approval of the plan and resources.
5. Revisit the plan when risk changes during the year.

The risk assessment comes first because everything else depends on it. Management's suggestions and last year's plan are useful inputs to it, but the audit function makes the choice, which is part of what independence means.

Protected, controlled and providing value. The CISA task asks the auditor to plan audits that determine whether information systems are protected, controlled and provide value to the organization. So objectives are not only about security and control. A plan can include objectives on whether a system supports the business strategy and objectives it was approved for, whether it is used efficiently, and whether it has delivered the benefits in its business case. These are operational or performance objectives, and post-implementation reviews and IT governance audits are the usual vehicles. Strategic importance belongs in the risk assessment for the same reason: a system the business depends on for its goals deserves attention even when its controls look sound.

Ranking by risk, not by size. No single factor sets the ranking. Priority rises with impact, novelty, recent change, external exposure and a lack of recent assurance. It falls with stability, a recent clean result and imminent retirement, because an audit of a system that is about to disappear protects little. A large system with recent assurance and no changes can therefore rank below a smaller one that is new and has never been examined.

Changing the plan. The plan is a living document. When a significant new risk appears during the year, such as an acquisition, a major outsourcing decision or a new regulation, the chief audit executive reassesses priorities and presents a revised plan to the audit committee for approval, because the committee owns the plan. Resources then follow the reassessed priorities.

Planning an individual engagement

Planning an individual IS audit begins with understanding the business: the process, its objectives, the systems that support it and the risks to those objectives. Only then can the auditor set the objectives, scope and criteria, assess risk and design the audit program. Typical planning inputs are walkthroughs and interviews, process and data-flow documentation, prior audit reports, the organization's policies, relevant regulations and the results of the risk assessment.

The auditor sets scope on risk. The auditee can ask for a change but cannot impose one. A request to exclude an area is judged by the risk the area carries, not by the reason given for excluding it. An exclusion that the auditor accepts, or that is imposed over the auditor's objection, is documented. Where it limits the conclusion, it is reported as a scope limitation.

Audit programs must reflect the current environment. Reusing a prior program saves time, but its main risk is that it misses exposures that did not exist when it was written. If the organization has since given an outside support vendor remote access to its servers, the old program has no procedures for that access path, the vendor's contract or the monitoring of its sessions. A prior program is a starting point only after the risk has been reassessed and the procedures updated.

Execution steps such as audit project management, sampling, evidence collection, data analytics, reporting and quality assurance are covered in the Audit execution lesson.

Audit risk is the risk that the IS auditor reaches an incorrect conclusion, for example reporting that controls are effective when a material weakness exists. It is commonly modelled as the product of three components:

Because the auditor controls only detection risk, the response to the other two runs through it. To keep overall audit risk acceptable:

• When inherent and control risk are high, the acceptable detection risk is low. Controls judged weak cannot carry much reliance, so the auditor increases substantive testing: larger samples, tests closer to period-end, and more direct verification of balances and transactions.
• When inherent and control risk are both low, the auditor can accept the highest detection risk and do less substantive work.

The level of audit risk the auditor accepts is set during planning and stays fixed. Changes in the assessed risks are absorbed by changing the work, not by accepting a weaker conclusion.

Materiality in IS audits

Materiality in an IS audit is the significance of a control weakness or error to the conclusion the audit supports, judged by what depends on the control and the potential effect of its failure, not only by monetary amounts. In a financial audit, materiality is often set as a monetary threshold. IS controls rarely map to a single amount, so the IS auditor asks which processes, transactions and decisions rely on the control, how pervasive it is and what could go wrong if it failed.

• Pervasiveness. A control that many systems depend on carries their combined significance. A weakness in the identity provider that handles single sign-on for every finance application affects all of them at once, so it is likely material before any monetary error is found. A weakness confined to one low-impact system, or a failure that was short-lived and has been contained, has a bounded effect.
• Relevance to the audit objective. Materiality is judged against what the audit is for. In IS control work that a financial auditor will rely on, controls over financial systems matter most. A gap on the public marketing website may matter in a security review but not in this audit.
• Consequences, not price tags. Materiality measures what a failure could cause. Monetary figures that have nothing to do with that effect, such as what the asset cost to buy, do not measure it. How often an exception occurred is evidence about frequency, which still has to be judged for its effect.
• Cumulative effect. Several weaknesses that are each immaterial can be material together. In a claims system, missing input validation, no reconciliation of interface totals and no review of rejected-record reports together let wrong claims be paid without anyone noticing. The auditor assesses their combined effect before deciding how to report them.

Controls are classified by when and how they act on a risk: preventive controls stop an undesired event, detective controls identify it after it occurs, corrective controls reduce its impact and restore normal operation, and deterrent controls discourage it.

A deterrent works on a person's decision, not on the system: it blocks nothing. It only discourages, by making the consequences visible. Controls can also be described by how they are implemented: administrative (policies, procedures, reviews), technical or logical (system settings, access controls) or physical (locks, guards). They can be manual or automated as well, which matters for how they are tested.

Prefer prevention to faster detection. When a risk can be prevented at reasonable cost, the strongest recommendation removes the root cause. Suppose staff can email customer files to personal addresses and a weekly data-loss report spots it afterwards. A rule that blocks those transfers at the mail gateway stops the event, where any improvement to the report only finds it sooner. Detective and corrective controls still matter, because prevention is never complete, but they are the second line of defence, not the first choice.

Compensating controls for missing segregation of duties

A compensating control is a control that reduces risk to an acceptable level when a primary control, such as segregation of duties, is missing or cannot be implemented. Segregation of duties separates incompatible functions (initiating, authorizing, recording and reconciling, or custody of assets) so that one person cannot both commit and conceal an error or fraud. Small units often cannot afford separate staff, so they need a substitute.

The best compensating control for missing segregation is an independent, regular review of the conflicting person's work by someone who does not perform those duties. Two properties make it work. Independence: the reviewer is outside the conflict and has nothing to conceal. Regularity: the review happens often enough to catch a problem before it grows, rather than now and then. In a two-person IT team where one administrator both grants system access and keeps the access logs, a monthly review of all access changes by the IT manager, against approved requests, provides both.

Test before relying. A compensating control only compensates if it is designed to address the specific risk and it actually operates. Before concluding, the IS auditor tests both. For design, the auditor checks whether the review covers the risky transactions. For operation, the auditor checks for evidence that it was performed throughout the period, for example a manager's signed-off monthly reviews of user-access changes, with follow-up on the exceptions. If the review works, the residual risk may be acceptable. If it does not, the conflict is reported together with the failed compensating control.

IT general controls (ITGCs) are controls over the IT environment that support every system, while application controls operate within one application on its transactions.

Why ITGCs decide reliance. An automated application control behaves the same way every time, as long as its logic and configuration do not change and nobody can bypass it. ITGCs provide those conditions. Change management stops the logic or configuration being altered without approval, and logical access stops unauthorized people changing settings or data. To rely on an automated control across a whole period, such as a loan system's interest calculation, the auditor therefore needs effective change management and logical access over that system for the same period. A test showing that the control worked on one date says nothing about the rest of the period unless those ITGCs held throughout.

Benchmarking. Because an automated control behaves consistently, it does not need a large sample the way a manual control does. Suppose it was tested and found effective in a prior period, the ITGCs have been tested effective in this period, and the change records show no change to its configuration. The auditor can then compare its current configuration with the previously tested baseline (benchmarking) instead of retesting it in full. The baseline comparison is what links the earlier test to the current period. If the ITGCs were weak, benchmarking is not available and the control must be retested.