IT governance determines how an organization directs and oversees its use of technology. ISO/IEC 38500:2024 provides guidance for governing bodies and those supporting them. This article explains how to translate that purpose into clear decisions, responsibilities and review evidence. A practical purchasing example shows how governance connects business priorities with technology without replacing day-to-day IT management.
Understand the standard and its limits
The ISO catalogue identifies ISO/IEC 38500:2024 as the third edition, published in February 2024. Its guidance covers current and future technology use across organizations of different types and sizes. The intended audience includes governing bodies, rather than only technology specialists. Consult the current document when assessing alignment; an old summary is not an adequate assessment basis.
This article provides an editorial application example, not a clause-by-clause interpretation of the standard. A course completion certificate, a consultant's assessment and an organization's governance arrangements are different things. Do not present personal training credentials as proof that an organization's technology decisions align with the guidance.
Separate governance from management
Governance addresses direction, accountability and oversight. Management organizes delivery within that direction. The governing body should understand why technology is needed, what exposure is acceptable and who is accountable for results. Management develops options, implements approved work and reports performance and exceptions.
In a small organization, one person may perform both roles. The decisions still need separation. Approving the business purpose of a system is different from choosing its configuration. Record which role a person is exercising, especially when a supplier recommendation is also being approved by the person who negotiated it.
| Decision | Governance concern | Management work |
|---|---|---|
| Replace a customer system | Business purpose, accountability and acceptable exposure | Requirements, options and implementation plan |
| Change access arrangements | Authority and protection expectations | Configure access and review accounts |
| Continue a delayed project | Remaining value, alternatives and conditions | Explain causes and prepare a revised delivery plan |
Outsourcing does not remove the organization’s accountability. A provider may operate the platform, but the organization still decides who can accept risk, approve material changes and verify the promised benefit. Name these decision owners before signing, and agree what evidence the provider must supply.
The table is a practical division of work. It is not a universal assignment of statutory responsibilities. Adapt the authority arrangements to the organization's actual structure.
Begin with a decision that needs attention
Consider a fictional service company replacing its customer relationship management system. Its current system is slow, but users also enter inconsistent information. Buying faster software may improve response time without fixing the information problem. A governance discussion should distinguish these issues before approving an investment.
Write the business problem, affected users and intended outcome in ordinary language. Include the option of improving the current process. Ask what happens if the organization postpones the purchase. This creates a meaningful comparison instead of treating the supplier's proposal as the only possible answer.
Name a business owner for the expected benefit. The IT manager may deliver the system, while the sales manager owns how customer information is used. If nobody accepts responsibility for changed working practices, the proposal is incomplete even when the technical design is convincing.
Request evidence that supports the choice
Each option should explain costs, dependencies, delivery demands and material uncertainties. Include migration, training, support and exit considerations. A low subscription price can coexist with expensive data preparation. Compare options over a consistent period and explain what has been excluded.
Separate observations from assumptions. A demonstrated export function is different from a supplier's statement that migration will be easy. A pilot with a few users is useful evidence, but it does not automatically establish organization-wide performance. Record what remains to be tested and who will verify it.
Address people as well as systems. Ask whether users can complete their work, whether responsibilities change and how support will be provided. Review accessibility and training needs with the affected teams. A technically available feature has little value when staff cannot use it reliably.
Make approval conditions explicit
An approval should identify the chosen option, responsible owner, resources and conditions. Conditions might require a tested export, an agreed migration reconciliation or a successful recovery exercise. Describe the evidence needed to satisfy each condition. Avoid phrases such as “IT to ensure everything is safe.”
Specify which changes require escalation. A different supplier, a material scope change or an unresolved data concern may need another decision. The thresholds should match the organization's authority framework. They are management choices to document, not universal numerical limits supplied by this article.
Maintain a decision record containing the question, alternatives, evidence, decision and review point. Record significant dissent and unresolved uncertainty. This helps a later reviewer understand why an option was chosen without reconstructing the reasoning from scattered emails.
Monitor outcomes after the purchase
Track whether the original business problem improves. System availability alone does not show that customer information is reliable. Examine data completeness, user adoption and the business process alongside technical service measures. Define each measure and its baseline before interpreting a trend.
For the fictional company, sample completed customer records and examine how staff use them during handovers. Discuss errors with the process owner. If duplicate records remain common, identify whether the cause is configuration, unclear responsibility or a workflow people cannot follow.
Make the review measurable. In this hypothetical example, 70 of 100 sampled customer records contain all agreed mandatory fields: completeness is 70%. The business owner sets a target of at least 95% by the end of the third month. At that point, 92 of 100 comparable records are complete: 92%, an improvement of 22 percentage points, but still 3 percentage points below target. This key performance indicator (KPI) shows progress against a defined objective; it does not yet show that the objective was achieved.
Use the same field definitions and sampling method in both checks, and record exclusions. Complete fields can still contain incorrect information, so check accuracy separately. The sales manager owns the corrective work, supported by IT, and reports the next review date. These figures are illustrative choices, not ISO thresholds or ATMACSS client results.
Review unexpected consequences too. Faster entry might introduce more incorrect records. A successful launch does not end oversight. Decide whether to continue, adjust, pause or retire an arrangement using evidence about current value and remaining exposure.
Start with a focused governance review
Select one significant technology decision and reconstruct its purpose, owner, alternatives and evidence. Identify missing responsibilities and unresolved assumptions. Use the findings to improve decision records, escalation rules and reporting before expanding the approach across the technology portfolio.
Read about IT management for the delivery responsibilities that support governance. For work connecting priorities with accountable measures, explore strategic planning and KPIs. The useful next output is an agreed decision and review process, supported by evidence people can actually maintain.