IT Governance in Practice: Committee, Metrics and Vendors

IT governance is the set of roles, decision rules and metrics that ensures technology delivers business value with controlled risk. In practice, it answers four questions: who decides, based on what, how results are tracked, and what is expected from each party (the internal team and vendors).

This guide is written for CTOs, IT managers and technology leaders at mid-sized and large companies. It offers a committee model, a metrics dashboard, a checklist for software development contracts and a 90-day roadmap to get started.

What IT governance is?

IT governance sets the direction for the IT function and monitors whether results are delivered; IT management plans and executes day to day. This separation is explicit in COBIT 2019, from ISACA: the EDM domain (evaluate, direct and monitor) covers governance, while APO, BAI, DSS and MEA cover management. In total, the framework organizes 40 governance and management objectives.

Another reference is ISO/IEC 38500, which sets out six principles for senior leadership on the use of IT: responsibility, strategy, acquisition, performance, conformance and human behavior. It does not prescribe tools; it guides how the board should evaluate, direct and monitor.

To avoid confusion, it helps to distinguish the three levels:

Governance should not be confused with certification, either. COBIT and ITIL are useful references, but no company needs to adopt them in full. The starting point is simpler: clear decisions, reliable numbers and a review routine.

How to set up an IT governance committee

An IT governance committee works when it has the authority to decide, a fixed agenda and business participants, not only technology staff. Without these three elements, it becomes a status meeting.

A study presented to the Brazilian Computer Society on an agile IT governance committee highlights two ideas that apply to any organization: the committee needs the power to change processes, and it is worth starting with the process that has no metrics yet. Because the context is public sector, the lessons should be adapted to a private-sector reality.

An example of real responsibilities appears in the 2025 report of the IT Governance Committee of the Brazilian Federal Senate (in Portuguese): policies, plans and performance indicators are part of its scope. The structure belongs to a public institution, but the agenda logic is transferable.

Five steps to structure the committee

1. Define the purpose and authority. Write on one page what the committee decides (investment prioritization, risks, policies) and what stays with management.
2. Choose the participants. Include the CTO or head of IT, a representative from each relevant business area, information security and finance. In mid-sized companies, four to six people are usually enough.
3. Set the cadence. Monthly or bimonthly for the main committee; quarterly, in the lean version, for companies with a smaller IT function.
4. Standardize the agenda and materials. The metrics dashboard is sent before the meeting; the meeting is for deciding, not for presenting slides.
5. Record decisions and owners. Every resolution leaves with an owner, a deadline and a completion criterion, reviewed at the next meeting.

Sample 60-minute agenda

• 10 minutes: pending decisions from the previous meeting
• 15 minutes: metrics dashboard (deviations from target)
• 15 minutes: portfolio and priorities (new requests, scope changes)
• 10 minutes: risks and security
• 10 minutes: vendors and contracts (performance, renewals, alerts)

IT governance metrics: what to measure

Good metrics connect IT to business results and have a definition, formula, source, owner and frequency. A lean dashboard with 6 to 10 items works better than dozens of metrics without an owner.

A survey published in the Brazilian journal Revista Formadores (2015), focused on an educational institution, found that the most valued indicators were service continuity, IT planning and logical security. The data is old and context-specific; it serves as a starting point, not as a rule.

Suggested dashboard, organized in five levels:

For the delivery level, the DORA metrics are the most widely used bridge between the committee and engineering: deployment frequency, lead time for changes, change failure rate and time to restore service. The 2024 edition of the research also began to consider rework rate. Before quoting figures from the report, confirm the edition on the site.

Common mistakes with metrics

• Vanity metrics: numbers that rise without reflecting results (hours worked, lines of code).
• Excess: dashboards with dozens of items that nobody reads.
• No owner: a metric without a responsible person does not change.
• No target: an isolated number does not say whether things are good or bad.
• No review routine: the dashboard needs to be discussed, adjusted and, sometimes, discarded.

What to expect from the internal team

From the internal team, expect clear roles, minimum engineering practices and review discipline. Governance fails less for lack of a framework than for ambiguous responsibilities.

• Defined roles: product owner, architecture lead, security lead and a manager for each relevant contract.
• Minimum practices: version control, code review, automated tests on critical flows, a delivery pipeline and a record of architecture decisions.
• Review routine: data-based retrospectives, quarterly dashboard updates and an annual review of the governance model itself.
• Transparency: the team publishes the metrics; the committee does not depend on manual reports.

What to expect from software vendors

From a development vendor, expect measurable contract criteria, transparent metrics and the right to audit. COBIT 2019 addresses the topic in two objectives: APO09 (managed service agreements) and APO10 (managed vendors), including ongoing monitoring of vendor performance (APO10.05).

In practice, governing a software contract comes down to ten items:

1. Scope and deliverables described in a verifiable way.
2. Measurable SLAs: delivery deadlines, incident response time and fix time.
3. Quality criteria: definition of done, test coverage and code review.
4. Shared delivery metrics: lead time, failure rate and rework, in the same format as your dashboard.
5. Security: secure development practices, data handling and compliance with data protection regulations (such as GDPR or Brazil’s LGPD, as applicable).
6. Ownership of code and documentation staying with the contracting company.
7. Transparency: access to repositories, backlog and environments.
8. Contract governance: periodic meetings, monthly reports and a defined escalation path.
9. Key-people management: replacement rules and knowledge continuity.
10. Exit: a transition plan and handover of all material if the contract ends.

This set is easier to meet when the delivery model is structured from the start. In a software factory, for example, scope, metrics and review routine are agreed upfront, which narrows the gap between what the committee wants to see and what the vendor reports. NextAge’s Software Factory operates in this format, with teams that deliver software according to the scope and metrics agreed with the client.

How to start in the next 90 days

The safest path is to start small: a diagnosis, a pilot committee and a dashboard with few metrics.

Days 1 to 30: diagnosis

• Map today’s IT decisions (who decides what) and identify gaps.
• List vendor contracts and the metrics that already exist.
• Choose the process with no metrics to start with.

Days 31 to 60: committee pilot

• Define the purpose, participants and cadence.
• Hold two meetings using the sample agenda.
• Record decisions and owners.

Days 61 to 90: dashboard and vendors

• Publish the dashboard with 6 to 10 metrics.
• Review contracts using the ten-item checklist.
• Evaluate the delivery model: in-house team, staff augmentation or a software factory, depending on the level of control and predictability the company needs.

Frequently asked questions

What is IT governance?

It is the set of roles, decisions and metrics that aligns IT with business goals, controls risk and ensures return on investment.

What is the difference between IT governance and IT management?

Governance sets direction and monitors results; management plans and executes day to day. In COBIT 2019, governance sits in the EDM domain.

How do you set up an IT governance committee?

Define the purpose and authority, invite business, IT, security and finance, set a cadence (monthly or bimonthly) and adopt a standard agenda with metrics and decisions.

Which IT governance metrics should you track?

Value delivery, delivery performance (DORA metrics), availability and incidents, risk and security, and vendor performance.

What should you expect from a software development vendor?

Measurable SLAs, quality criteria, security, metric transparency, code ownership and periodic reports.

Are COBIT, ITIL and ISO 38500 mutually exclusive?

No. They are complementary: ISO 38500 provides the principles, COBIT organizes governance and management objectives, and ITIL details service management.

Do mid-sized companies need IT governance?

Yes, in a lean version: a quarterly committee, 6 to 8 metrics and vendor contracts with clear criteria.

Next step

If your company wants more predictable software delivery without losing visibility, it is worth talking to a team that already operates this way. Learn more about NextAge’s Software Factory or talk to a specialist.