How to build an IT governance framework that actually works

Most organizations can produce an IT governance document when an auditor asks for one, but not all of them can show that anyone consults it when a department signs up for a new SaaS tool, a project team spins up cloud infrastructure, or a vendor contract renews without review. Gartner predicts that by 2027, 75% of employees will acquire, modify, or create technology outside IT’s visibility, up from 41% in 2022.

That’s what happens when governance adds friction without giving people a faster, clearer path to a decision. A framework that actually works looks very different. Here’s everything you need to know to create one.

Why most IT governance frameworks get ignored

Governance frameworks rarely fail because the policies are wrong. They fail because the people expected to use them can’t tell where governance ends and day-to-day IT work begins, so decisions either skip the process entirely or get dragged through it unnecessarily.

Operational problems like a failed patch tend to be local and fixable by the team that owns them. Governance problems show up as patterns that repeat across teams regardless of who’s involved.

For example, if the fix is to perform a known task better, it’s an operational problem. If the fix is to decide who should have made the call in the first place, it’s a governance problem.

Additionally, here are some common failed governance symptoms:

• The same decision gets made in several places, or nowhere: Security approves a SaaS tool, finance rejects the spend, and the business unit buys it on a company card anyway. Nobody owns the final call.
• Routine changes wait as long as risky ones: When a standard software request sits in the same approval queue as a core network change, governance scope has crept into work that should be delegated.
• Exceptions never expire: Temporary exemptions from a standard accumulate with no owner or review date, until the exception list becomes the real policy.
• Investment decisions follow influence instead of criteria: Projects get funded because a senior sponsor pushed hardest, with no business case to measure benefits against later.
• Audit findings recur: The same control gap appears in consecutive IT audits because remediation was assigned to a team rather than an accountable owner.
• Escalations land at the wrong level: Executives approve minor purchases while major architecture choices get made inside a single project team.

When two or more of these appear together, adding process on top won’t resolve them. The decision-rights model underneath needs rework.

» Here’s how to prepare for a software license audit

Why frameworks get bypassed

Most governance frameworks are built as artifacts, such as a policy set or RACI matrix stored on a shared drive. Teams encounter them only when something needs approving, and that encounter is almost always friction.

Without a visible line from each control to the risk it manages, the control reads as bureaucracy (something most people hate). It doesn’t matter what industry you operate in, a golden rule for all is that people will always route around bureaucracy if they can.

Knowing a rule also isn’t the same as following it. According to Gartner, over 90% of employees who admitted to unsecure actions at work knew those actions increased risk to the organization and did them anyway. For governance design, that means awareness alone won’t close the gap. Controls get followed when the governed path is also the fastest one, and when the people using it understand what business risk each checkpoint exists to manage.

What IT governance actually is

IT governance is the framework of leadership, organizational structures, and decision-making processes that ensures an organization’s technology sustains and extends its broader strategy and objectives, rather than operating on its own track disconnected from business goals.

It sets the boundaries that everyone who does those things works within, so that technology choices trace back to business priorities and acceptable risk rather than to whoever happened to be closest to the problem. A framework is simply that system written down and built into how work actually moves.

Governance only works when each layer stays in its lane, since the three layers (IT governance, IT management, and IT operations) answer different questions and belong to different people:

When governance reaches down into operations, approvals pile up on routine work. When operations fills a gap governance left open, major decisions get made without anyone accountable for the risk.

» Make sure you know these AI governance standards for IT teams

What a working IT governance framework looks like

Consider a sales team requesting a cloud-based customer analytics platform. Here’s how that single request moves through a working framework:

1. Principles set the criteria: The request is weighed against the organization’s standing principles, considering business value, data protection, security, regulatory compliance, and cost control.
2. Ownership is fixed up front: The head of sales owns the business outcome and the benefits case. The IT governance committee owns technology alignment and risk oversight. They know this implicitly, and if not, it’s decided on before anything is purchased.
3. Decision rights determine who reviews it: Since the platform will hold customer data, security and legal reviews are mandatory. Leadership has to sign off on the investment because the annual contract value exceeds the executive approval threshold (say, $50,000 in this organization).
4. Standards define what “approved” means: The vendor has to meet existing requirements for single sign-on, encryption, data residency, vendor risk assessment, backup, and integration.
5. The workflow carries it through existing tool: The request is logged as a ticket in the same service management and procurement process the team already uses. Its data classification and cost fields automatically route it to the right reviewers.
6. Exceptions are documented: If the vendor can’t support single sign-on until its next release, the gap is logged with a justification, an accountable risk owner, and an expiry date tied to that release.

Now compare a design team requesting a small, low-cost font management tool that handles no customer data. It sits below every threshold and matches an existing standard, so it clears standard approval without needing a committee to check. That contrast is the point. A working framework applies scrutiny in proportion to risk. So no risk, no extra eyes.

» Worried about costs? Here’s our guide to building an IT cost optimization framework

How to build and maintain an IT governance framework stage by stage

Governance that IT builds on its own authority can’t bind the rest of the business. So before actually starting to build a framework, confirm these three things:

• A named executive sponsor: Someone above IT has to agree that technology decisions are a business governance responsibility.
• A governance owner: One person has to be accountable for the framework itself.
• Funding and participation: Business, finance, security, legal, and operations stakeholders need both.

A practical test is to ask the sponsor who would win if the framework blocked a request from a senior business leader. If the answer is unclear, the framework will be negotiable from day one.

Stage 1: Assess where you are and size the framework to fit

Stage one is an honest inventory of existing policies, approval routes, controls, and gaps. It usually shows that some governance already exists informally, often as one person everyone checks with. That’s worth capturing rather than replacing.

This is also where you decide how heavy the framework needs to be. Headcount is a poor guide, so base the decision on these factors:

• Technology complexity
• Regulatory exposure
• The number of business units and jurisdictions
• How dependent the business is on IT.

Those factors push an organization toward one of two models, and the practical difference between them looks like this:

Signs that a lightweight model is outgrowing itself include:

• A second business unit or jurisdiction
• A first external audit obligation
• Vendor decisions that exceed any single person’s authority
• Recurring disputes over who approves what

» Learn more about enterprise IT management

Stage 2: Decide what governance covers and what it doesn’t

This stage defines the target state, and scope is the most important decision in it. Governance attention should go to decisions that materially affect risk, compliance, cost, architecture, or service continuity. Routine work should be delegated explicitly, with the delegation written down, because an unstated boundary gets filled by whoever is most cautious.

More specifically, things that should be governed by a formal framework include:

• Technology investment and prioritization
• Cybersecurity controls and access management
• Data governance and data protection
• Enterprise architecture and major infrastructure changes
• Vendor selection and cloud adoption
• Disaster recovery and regulatory compliance

The stuff that just needs to be delegated to IT management and operations include troubleshooting, incident resolution, workstation configuration, or software deployments from an approved catalog.

Pro tip: If something is borderline, just ask whether getting it wrong would create material business risk, or just rework? Rework belongs with operations.

» Check out our guides to autonomous incident response and building an IT troubleshooting framework for training

Stage 3: Assign decision rights and set approval thresholds

This turns scope into a working decision model. For every governed decision, define five things:

• One accountable owner
• The approval threshold
• The stakeholders who must be consulted
• The escalation path
• The evidence required

A RACI or decision-rights matrix makes this explicit. The two failures to watch for are decisions with more than one accountable owner and long lists of consulted parties. Multiple owners stall decisions and long consultation lists turn every approval into a meeting.

Thresholds are where risk appetite becomes operational. Start from the business services that matter most, the regulatory obligations that apply, and the level of risk leadership will accept. Then express them as tiers similar to this:

Stage 4: Pilot the framework before rolling it out

Run realistic scenarios through the proposed process before anyone depends on it, such as:

• A change to a critical system
• A SaaS request involving customer data
• A vendor failure
• A time-limited exception
• A simulated security incident

Tabletop exercises with executives, IT, security, risk, and business owners will quickly show where the design breaks.

During the pilot, measure time to decision for each tier, the number of handoffs, and how often participants can’t name the accountable owner.

Stage 5: Build checkpoints into the tools teams already use

This is the actual implementation stage, and the rule that determines adoption is simple: governance should never require a separate system. Map each checkpoint to the ticketing, change management, project, and identity tools teams already work in.

For example, a standard change proceeds on its pre-approval, while a high-risk change automatically routes to security or architecture review.

Exception requests should go through the same ticket or workflow as everything else, with four mandatory fields:

• The risk
• The business impact
• An accountable owner
• An expiry date

An exception without an expiry date is a new policy nobody approved.

Atera gives IT teams and MSPs a direct way to run these checkpoints inside day-to-day work. Here’s how:

• Alerts: Threshold-based alerts in Atera’s RMM can automatically create tickets, depending on site, customer, device, or severity settings, so governed events enter the same queue as everything else.
• Routing and escalation: Ticket automation rules assign work to specific technicians or technician groups based on rule conditions or AI auto-tags. Time-based rules escalate tickets that stay open too long.
• Response targets: SLA policies attach response and closure targets based on group, customer, contract, and priority, and re-evaluate when ticket properties change.
• Approvals: With Playbooks, technicians describe a workflow in plain English, such as sending any software request outside the approved catalog for manager sign-off. Robin generates the executable workflow, including creating approvals, assigning technician groups, and sending communications. MSPs can assign different Playbooks per customer or site. Start with low-risk workflows and review the outcomes before extending Playbooks to higher-stakes approvals.
• Standards enforcement: Automation profiles keep patch deployment on its approved schedule, and remote scripting lets technicians push a standard configuration to selected device groups on demand.

» Learn more about automated ticket routing and automated ticket escalation

Stage 6: Review, adapt, and handle edge cases

Keep a record of these KPIs along the way:

• Approval cycle time by tier: This tells you if scrutiny is proportional to risk. Standard requests shouldn’t take days and high-tier approvals shouldn’t wait through multiple meetings.
• Change success rate: Tells you if controls are improving outcomes. If this declines while approval volume rises, controls are adding delay instead of quality.
• Unsanctioned tools discovered: Keeping track of how often people bypass the framework keeps you prepared if there’s a spike after a new control is introduced.

Then do regular reviews to prevent drift and constant rework. Here’s an example of the frequency of reviews, as well as who should lead it and what the purpose is:

• Quarterly: This should be led by the IT governance committee and chaired by the CIO or equivalent. Check KPIs, risk exposure, major exceptions, and shifts in business priorities.
• Semi-annual: Led by a committee with component owners. Check policies, standards, decision rights, thresholds, and emerging technology risks such as AI tool adoption.
• Annual: Should be led by executive leadership or the board. This is a place to review the whole framework against the original strategy, regulation, audit findings, and changing industry standards.
• Event-driven: This is only triggered by the CIO when there are new regulations, major incidents, acquisitions, or technology changes that warrant it.

Build governance into the tools you already use

An IT governance framework earns compliance by being the fastest legitimate path to a decision while minimizing its risk. Leadership still owns what no platform can decide for it, including risk appetite, decision rights, approval thresholds, and who can sign off on an exception. What makes those decisions stick is enforcement inside the tools where work already happens.

Atera gives IT teams and MSPs that execution layer with threshold-based alerts that open tickets automatically, ticket automation and escalation rules, SLA policies, and approval worklows built in Robin’s Playbooks.

» Take control of your organization’s IT governance with Atera’s free trial