Governance is often described as a set of committees and policies, but an auditor needs to know whether those arrangements produce decisions that protect the enterprise and support its objectives. Technology leaders can publish a risk appetite statement, appoint control owners and create polished dashboards while still leaving a critical business process exposed. The ISACA CISA certification treats Governance and Management of IT as a distinct domain because the controls that matter are shaped by leadership decisions, resource allocation and accountability. Audit work in this area asks whether priorities, responsibilities and risk decisions are clear, consistent and supported by credible evidence.
Separate governance, management and independent assurance
Governance evaluates stakeholder needs, directs priorities and monitors whether objectives are being achieved. Management plans, builds, operates and monitors activities within the direction established by governing bodies. Internal audit provides independent assurance on selected risks and controls; it should not quietly inherit responsibility for operational decisions simply because it identifies shortcomings. These boundaries are not always reflected cleanly in organizational charts, so an auditor must look at actual decision rights, approval histories and escalation behavior.
Suppose a company wants to introduce AI-assisted customer service. A board-level committee might set limits on privacy exposure and acceptable business risk. Management translates those limits into vendor selection, data-access controls, training and incident procedures. Audit assesses whether the controls are appropriately designed and operating. If the auditor starts approving individual AI prompts or configuring the application’s permissions, later assurance over that same activity can become compromised. Professional independence requires awareness of both formal reporting lines and day-to-day influence.
The distinction between audit and management also affects certifications and career roles. The CISA and CISM comparison provides useful context: CISM emphasizes security management responsibilities, while CISA emphasizes evidence-based assurance. An auditor must understand management well enough to evaluate it without assuming the management role.
Evaluate whether IT strategy supports business priorities
A technology strategy is meaningful when decisions about investments, architecture and service levels can be traced to business objectives. An organization promising uninterrupted online banking cannot treat disaster recovery as an optional infrastructure preference. A hospital operating clinical systems needs to understand the consequences of outages, data corruption and identity failures. Audit evaluation therefore begins with business goals and the services that deliver them, then asks whether technology priorities, budgets and measurable outcomes fit those goals.
Review strategic plans, portfolio decisions, architecture approvals and actual spending. A slide deck that names “innovation” as a priority is not evidence that investments are assessed consistently. Look for business cases with assumptions, benefits, risks and post-implementation reviews. Major projects should have accountable sponsors and decision criteria for continuing, pausing or cancelling work. When technical teams repeatedly replace platforms without showing business value, examine whether investment governance or benefits realization is weak rather than merely noting overspend.
Alignment also requires recognizing conflicts. A revenue team may favor rapid feature releases while a regulated operation requires rigorous validation. Leadership needs an explicit method for deciding when speed, cost, security and reliability compete. An auditor is not expected to choose the product strategy, but can assess whether material conflicts were escalated to someone with appropriate authority, whether the decision had reliable information, and whether risk consequences were acknowledged.
Assess enterprise risk appetite and IT risk ownership
Risk appetite expresses the nature and amount of risk an organization is willing to pursue or retain in support of its objectives. It is not the same as a numeric score printed on a risk register. Tolerance thresholds make that appetite operational: maximum downtime for a critical service, permissible levels of exposure for sensitive data, financial loss thresholds or escalation limits for unpatched critical systems. The auditor should assess whether those thresholds are understood by the managers who make day-to-day decisions and whether exceptions receive appropriate attention.
A risk register can describe an exposure, owner, impact, treatment and review date, but its quality depends on how it is used. Check whether assessments are refreshed after acquisitions, vendor failures, major releases and incidents. Trace one high-risk item from identification through evaluation and management response. Was it escalated? Was a budget approved? Did the mitigation actually occur? Did subsequent evidence show that residual exposure changed? A risk record that repeatedly says “accepted” without naming the person with authority to accept it may indicate that accountability is only nominal.
Risk ownership should remain with those able to influence the activity. The security team may advise on cloud misconfiguration, but the business owner must understand the operational consequences, and the platform team may have implementation responsibility. Avoid placing every risk with a central security officer who lacks authority over the affected system. Audit findings become more actionable when they identify which decision or handoff was missing.
Review the design of policies, standards and exceptions
Policies express organizational expectations; standards turn them into more specific requirements; procedures guide recurring work. Audit should verify whether each layer is appropriate, approved, communicated and periodically reviewed. An access-control policy may require least privilege, a technical standard may mandate multi-factor authentication for privileged roles, and a procedure may describe how access requests are checked and approved. A control environment can fail when one layer contradicts another or when employees do not know which document governs their work.
Policies should account for different technologies and risk classes without becoming unenforceable wish lists. Requiring identical retention periods for transient diagnostic logs and legally significant transaction records may create compliance or cost problems. An auditor tests whether deviations from policy are deliberate and governed. Exceptions should document business justification, affected assets, compensating controls, approver, expiry and reevaluation. A permanent exception used for routine operations often signals that the standard is inappropriate or that the organization has decided not to enforce it.
Do not equate the existence of written documentation with operating effectiveness. Choose examples that reveal whether rules affected real decisions: an administrator was denied excessive privileges; a critical exception expired and was remediated; a vendor failed minimum security due diligence. These behaviors demonstrate governance more reliably than an annual policy attestation alone.
Examine third-party and cloud risk governance
Outsourcing does not outsource accountability. A cloud provider or managed services company may operate infrastructure, but the customer still needs to understand contractual responsibilities, data access, incident notification, recovery obligations and oversight. Review whether vendor criticality is assessed before contract signature, whether the contract addresses consequential risks and whether ongoing performance evidence is obtained. A vendor with an attractive certification may still offer a service configuration that fails a specific business requirement.
Service organization assurance reports can help, but the auditor must examine their scope, period, exceptions and complementary user-entity controls. A provider may demonstrate data-center physical security while the customer controls cloud identity permissions, encryption settings and data sharing. If a customer assumes the provider manages every security layer, the gap can be severe. Likewise, subcontractors and data-processing locations can introduce dependencies not visible in the primary vendor dashboard. Governance should require a clear route for discovering and escalating such dependencies.
For a critical managed payment service, examine outage history, service credits, settlement controls, disaster recovery commitments and the availability of audit evidence. A monthly meeting with the vendor is not an effective oversight control unless issues are followed through to closure and business impacts are reported. The goal is to determine whether leaders can make informed choices about supplier risk, not to collect every certificate the supplier can produce.
Test resource governance, skills and organizational resilience
A strategy fails when resources are unavailable to execute it. Review whether staffing, budgets, skills and capacity planning match obligations for operations, security, projects and continuity. A company may rely on one engineer who knows how to restore a legacy application; the apparent savings can conceal a serious resilience risk. A competent auditor looks for documented handover, cross-training, tested recovery and succession planning rather than focusing only on headcount numbers.
Segregation of duties is another governance concern. Developers may need to deploy software, but unrestricted ability to create, approve and release production changes can undermine accountability. Smaller organizations cannot always separate every duty, so evaluate compensating measures such as independent log review, restricted emergency access and periodic oversight. Effective segregation is about preventing inappropriate unilateral control, not requiring an impractical staffing model. The reviewer should understand how responsibilities work during nights, holidays and incidents, when normal roles often collapse.
Training programs should be evaluated against actual responsibilities. An annual security-awareness module is not a substitute for engineers learning secure cloud provisioning or auditors understanding AI-generated evidence. Competence can be assessed through real incident exercises, peer reviews, certification where relevant and observed work quality. A governance dashboard showing that 100 percent of employees completed a course cannot by itself demonstrate that critical tasks are being performed safely.
Assess metrics that drive decisions rather than appearance
Governance reporting should make material risks, costs and outcomes visible. Useful metrics might include unresolved high-risk findings past due date, recovery-test success against objectives, changes requiring emergency approval, vendor incidents or repeated privilege exceptions. But every metric can be gamed. Counting closed findings may reward superficial closure; measuring incident response time without severity context can reward premature resolution. Evaluate definitions, source data, ownership and trends before accepting a dashboard as evidence of control effectiveness.
The board does not need every operational log. It needs enough reliable information to challenge management and understand whether objectives remain achievable within agreed risk appetite. A report showing green status for every system during a major outage suggests weak reporting governance. Ask whether bad news travels upward in time to support intervention, whether management actions are recorded and whether repeat issues are explained rather than normalized.
When assurance reports highlight deficiencies, trace follow-up. Was a material weakness assigned to an accountable owner? Were interim protections implemented? Did testing confirm the correction? An auditor who simply copies last year’s findings into a new report does not help stakeholders understand the current control environment. Follow-up assurance should evaluate whether the change addressed the root cause and whether risk has genuinely declined.
Apply governance reasoning to CISA cases
CISA questions in this area often present a management problem disguised as a technology problem. An organization may have sophisticated monitoring but no agreed risk appetite; a technically sound project may lack business ownership; a third-party contract may promise availability without tested recovery responsibilities. First identify the governance objective and accountable decision maker. Then determine which evidence can show that the relevant process works. Avoid assuming that buying a security tool automatically remedies a failure of authority or oversight.
A strong audit conclusion distinguishes design gaps from operating failures. Perhaps the company has no process for approving cloud exceptions; that is a design concern. Perhaps the process exists but managers routinely bypass it; that is an operating concern. Recommendations should identify the exposure, needed decision and reasonable verification of improvement. The purpose of governance auditing is to make better organizational judgment possible through evidence, not to substitute an auditor’s preferences for management’s legitimate strategy.