CISA IT Governance: Strategy, Committees, Policies and Enterprise Architecture

IT governance is direction and oversight; IT management is execution within that direction. Governance is exercised by the board and its committees, which evaluate the options, direct the enterprise (strategy, priorities, the amount of IT-related risk it will accept) and monitor whether IT delivers the value expected within that risk. Management, led by the CIO and executives, then plans, builds, runs and monitors IT inside those boundaries. The evaluate–direct–monitor model comes from ISO/IEC 38500 and is built into COBIT 2019.

For an IS auditor the first question is whether governance exists at all. When direction, funding and the judgement of IT performance all sit with a single executive and nothing reaches the board or a board committee, there is no body independent of IT directing or monitoring it. The consequence is strategic rather than technical: IT spending can drift from the enterprise's objectives with nobody outside IT in a position to notice.

The second question is whether governance gets the information it needs. Measures of availability, service-desk performance or project status are management metrics: they help run IT, but they do not tell directors whether investments are paying off or whether IT risk sits inside the appetite they approved. Governance reporting links IT investment to the value actually realized and to risk against appetite, and it must reach the body accountable for governance, the board; a management-level forum receiving it is not a substitute. (Designing KPIs, KRIs and scorecards is covered in the IT management lesson.)

The IT strategy committee works at board level and advises the board on IT direction and value; the IT steering committee works at executive level and prioritizes and monitors IT investments and projects. The two names sound alike, which is exactly why they are tested together.

A steering committee does not approve the IT strategy or set risk appetite on the board's behalf, and it does not approve detailed technical designs, which belong to architecture and project governance. It also cannot give independent assurance: it is a management body and would be assuring its own decisions. Assurance comes from internal audit, which reports to the board's audit committee. The audit committee oversees assurance, financial reporting and internal audit; it does not advise on IT strategy, which would sit outside its role and could compromise its independence. A change advisory board is an operational management body that reviews and approves production changes.

A steering committee only works if the business sits on it with decision rights. A committee made up of IT managers alone has no way to weigh business needs when it ranks initiatives, so business priorities lose out; the root-cause fix is senior business membership with a vote. Giving the business a hearing without decision rights does not change who decides.

An IT strategy is aligned when it traces to the enterprise's business strategy and objectives, is developed with the business, and is visible in initiatives that each serve a stated business goal. The CISA task is to evaluate that alignment, so the auditor looks for evidence connecting what IT does to what the business is trying to achieve.

The strongest evidence is traceability: each major IT initiative maps to a stated business objective and has a business sponsor accountable for the benefit. Evidence is weaker whenever it measures something other than that connection. Assessments of plan quality, cost discipline or delivery performance can all be favourable for a portfolio of the wrong projects: a well-run project is not necessarily one the business needs.

Process matters as much as the document. When the business has no part in writing or approving the IT strategy, there is no mechanism to capture business priorities, so the most significant risk is that the plan does not serve them. Technical or financial weaknesses in a plan are narrower concerns that IT is usually well placed to catch itself; it is the business view that IT alone tends to miss.

A sound strategy process typically starts from the enterprise strategy, involves business leaders in setting IT goals (COBIT 2019 calls this the goals cascade: stakeholder needs → enterprise goals → alignment goals → governance and management objectives), is approved through governance, and is reviewed when the business strategy changes.

An effective IT organizational structure separates incompatible duties and places each function in a reporting line that does not create a conflict of interest. Both are part of the CISA task to evaluate the IT organizational structure.

Segregation of duties

Segregation of duties (SoD) ensures that no single person can both make and conceal an error or an unauthorized change. The classic incompatible pairs in IT are:

Many pairings are routine and not incompatible: a help desk analyst resetting passwords after verifying identity, or a network administrator who also monitors network performance. Severity depends on whether the combination gives one person end-to-end control over a sensitive process.

When duties cannot be split, which is common in small IT functions with limited staff and budget, the auditor looks for a compensating control that restores independence: typically, someone independent of the individual (such as their manager) regularly reviews logs of that person's privileged activity. The test for any compensating control is independence; a review performed by the person being reviewed adds nothing.

Reporting lines and conflicts of interest

Where a function reports shapes its priorities. When the executive who sets IT priorities also runs one of the units competing for IT resources, that unit's work tends to win; when a control function reports to the function it checks, the control gives way whenever that function is under pressure. The auditor recommends removing the conflict at its source rather than managing its symptoms:

• For prioritization bias, the remedy is a prioritization mechanism that represents the whole business, such as a business-wide steering committee that ranks initiatives against enterprise objectives. Changing which single executive decides tends to move the bias rather than remove it.
• For a control function reporting into what it checks (information security under IT operations is the classic case), the remedy is a reporting line to senior management independent of the checked function, for example a risk executive. Internal audit is not a suitable home for an operational control function such as security: audit's independence depends on not running the functions it assesses.

A policy states management's high-level intent; a standard sets mandatory, specific requirements; a procedure gives the step-by-step method; a guideline offers recommended, discretionary practice. Together they form a hierarchy in which each level puts the one above it into effect.

Putting detail at the wrong level breaks the hierarchy. A policy that embeds product names, configuration values or operating steps goes stale with every technical change and needs senior approval each time, so it ends up ignored or out of date. The root-cause fix is structural: keep the policy at the level of intent and move the specifics down into standards and procedures that the owning teams maintain. Reviewing the policy more often does not fix a document written at the wrong level.

Approval, review and effectiveness

• Approval: policies carry authority only when senior management (and, for top-level policy, the board) approves them.
• Review: periodically and whenever the business, technology or risk changes significantly, for example adopting cloud services or remote working.
• Effectiveness: shown by practice that complies with the policy. Evidence that a policy is known, approved and current, or complete against a framework, shows it exists and is sound on paper; only testing what actually happens day to day shows that it works.

The auditor evaluates policies but does not write them. When a policy has gone unreviewed through significant change in the business or its technology, the auditor first determines whether it still addresses current risks and practices; a policy's age alone is not yet a supported finding. Writing the replacement would impair the auditor's independence when that policy is later audited.

Top-down policy development starts from enterprise objectives and cascades policies downward; bottom-up development derives policies from operational risk assessments of individual systems. Each delivers one strength and carries the opposite weakness.

When an organization wants both consistency with enterprise objectives and relevance to system risks, the best design combines the approaches in order: start top-down from the organization's own objectives, then refine the policies with the results of operational risk assessments. Starting from the enterprise's own objectives keeps the set consistent with its strategy, and feeding risk results in as policies are shaped keeps it relevant; occasional reconciliation after the fact leaves inconsistent policies operating in between.

Every deviation from a policy or standard should go through a formal, documented exception process in which the accountable owner accepts the risk, compensating controls are defined, and the exception expires or is re-reviewed on a set date. This is how the CISA task "determine whether the organization has defined ownership of IT risk, controls, and standards" shows up in practice.

A sound exception record contains:

1. the requirement not met and the reason;
2. a risk assessment of the deviation;
3. acceptance by the accountable owner of the system or business process (the party who bears the business risk, not IT operations, which carries out the work);
4. compensating controls, such as network isolation for a system that cannot be patched;
5. an expiry date or periodic re-review, and a remediation plan where one is feasible.

Two failures are common. First, deviations that are known but undocumented: risk is being accepted informally, with no record and no one clearly accountable. The recommendation is a formal exception process with owner risk acceptance; the answer to unmanaged deviation is to manage it, not to remove the requirement or act before the risk is assessed. Second, an exception that was handled correctly when granted but never expires. Owner acceptance and a compensating control were good practice at the time; the weakness is that threats and the environment keep changing, so a risk decision that is never revisited slowly becomes one nobody would make today.

Ownership applies to controls as well as standards. Each control should have a named owner who operates it or makes sure it operates, keeps evidence that it works and answers for it when it fails; a control without an owner tends to lapse unnoticed. Each standard likewise needs an owner who maintains it and decides, with the risk owner, on exceptions to it.

(How risk ownership and risk appetite fit into the enterprise risk management program is covered in the Enterprise risk, privacy and data governance lesson.)

An organization can comply only with requirements it has identified, so it needs an owned process that identifies the laws, regulations and contractual obligations that apply to its information systems and turns each one, and each change, into IT policies and controls.

Identifying requirements

The reliable mechanism is a register of applicable requirements, built with legal counsel and reviewed periodically and whenever the business changes. Awareness held informally by individuals is incomplete and unowned, and assurance work with a different scope does not establish which laws apply; what matters is a process someone is accountable for.

When the business enters a new jurisdiction, identifying that jurisdiction's legal and regulatory requirements comes first. Data protection laws differ on consent, cross-border transfer, residency, breach notification and retention, so any control chosen before the requirements are known may turn out to be unnecessary or insufficient.

From identification to implementation

Identification alone is not compliance. When requirements are recorded but policies and controls never change to reflect them, the root cause is a missing hand-off: nothing assigns each identified requirement to an IT owner and tracks the resulting policy and control changes to completion. Improving one link in the chain does not repair a break between the links.

Where obligations come from

Not every obligation comes from a statute. PCI DSS is primarily a contractual obligation: an industry standard published by the PCI Security Standards Council, which the major card brands founded; merchants are bound to it through their agreements with the acquiring bank and the card brands, and non-compliance brings contractual penalties or loss of card acceptance (a few jurisdictions, such as some US states, also reference it in law). Compensating controls under PCI DSS are documented on a compensating control worksheet in the Report on Compliance (ROC) or self-assessment questionnaire (SAQ). An auditor identifying obligations therefore reads contracts as well as statutes.

Frameworks and what they cover

A framework or certification is not proof of legal compliance. ISO/IEC 27001 requires an organization to identify its legal and contractual requirements, and certification shows the management system conforms to the standard; it does not certify that each specific law in each country is met. Checks on the certificate itself (accreditation of the certification body, currency, scope) decide how far it can be relied on for what it covers, but legal compliance still has to be verified directly.

Enterprise architecture (EA) describes how the enterprise's business processes, information, applications and technology fit together, so that IT investments support the enterprise's strategic goals. TOGAF (The Open Group Architecture Framework) organizes architecture into four domains, business, data, application and technology, and develops them through its Architecture Development Method. The Zachman Framework is a classification schema instead: a matrix of six interrogatives (what, how, where, who, when, why) against six stakeholder perspectives, from the executive planner down to the working enterprise.

An architecture has three parts, and its governance value depends on all of them:

• a current (baseline) state describing what exists today;
• a target state describing what the enterprise needs to support its strategy;
• a roadmap of transitions from one to the other.

A repository that documents only the current state is useful for operations but gives governance no yardstick: without a target state, nobody can judge whether a proposed investment moves the enterprise toward its goals, so investments can drift or duplicate one another. EA is also not the same as configuration records, network topology diagrams or an asset inventory; those are detailed IT artefacts an architecture may draw on, maintained by configuration and asset management.

The CISA task asks the auditor to conduct periodic review of information systems and EA for alignment with organizational objectives. A typical finding is overlapping systems acquired separately for the same capability, such as several document management or HR platforms in different units. The root cause is that acquisitions bypass the architecture, so the recommendation is a preventive gate: proposed acquisitions are reviewed against the target architecture before approval. A periodic review that finds the overlap after purchase is detective; by then the money is spent.

Adopting an emerging technology needs governance first: management assesses its benefits and risks, sets direction through policy, and names who is accountable for its use before choosing controls. Two CISA tasks cover this: evaluating the opportunities and risks of emerging technologies, regulations and industry practices, and evaluating the role and impact of automated and decision-making systems.

Unmanaged adoption

When staff begin using a new externally hosted tool before any policy exists, for example a public AI service to summarize internal documents or write code, the governance gap is that nobody has decided whether and how it should be used. The first step is for management to assess its risks (data leaving the organization, inaccurate output, intellectual property and reputational exposure) and benefits, and set direction through an acceptable-use policy. Technical restrictions, licensing and training are follow-on controls that implement a decision, not substitutes for making it.

Automated decision systems

When a system makes business decisions automatically, such as a model that sets insurance premiums, prioritizes fraud cases or screens job applicants, the key governance control is a named business owner accountable for the model's decisions: someone who sets acceptable outcomes and tolerances, reviews monitoring, and acts when the model drifts or treats customers unfairly. Supporting controls an auditor would look for include an inventory of models in use, documented purpose and data sources, change control over model updates, ongoing monitoring of outcomes for accuracy and bias, human review or override for contested decisions, and explainability sufficient for the regulators and customers affected. Regulation is moving here too: the EU AI Act, for example, classes uses such as credit scoring and recruitment screening as high-risk.

Evidence about a model's technical quality or the operation of its platform is narrower than accountability: it shows the system worked when tested or keeps running, not that someone answers for whether its decisions remain fair and appropriate.