IT Governance Starts with Obligations, Not Frameworks

Ask an IT department how it approaches governance, and the conversation may quickly turn to frameworks. Which one should we adopt? How mature are we? Which controls have we implemented? How do we measure our progress?

Those are useful questions. But there is a more immediate question underneath them:

What is this organization actually obligated to do?

An IT department inherits responsibilities from contracts, internal policies, business commitments, regulatory requirements, and decisions made by authorized leaders. Those responsibilities exist before anyone selects a framework. They also tend to be more specific than the framework discussions happening around them.

A particular application must recover within an agreed period. A vendor must provide evidence of an independent security assessment each year. A customer-facing service must meet applicable accessibility requirements. A contract requires notification when certain events occur.

These are concrete responsibilities with consequences. Governance needs to make them visible, assign ownership, and establish whether they are being fulfilled.

A framework provides structure. Applicability requires a decision.

Frameworks help organizations organize their thinking. They provide common language, identify areas that deserve attention, and make it easier to assess practices consistently.

They can also help uncover responsibilities an organization has overlooked.

But selecting a framework does not, by itself, establish exactly what applies to each application, vendor, service, or contract. Someone still needs to connect general expectations to the organization’s actual circumstances.

Consider a framework that calls for recovery planning and testing. That expectation is useful, but it leaves operational questions open.

Which applications require a recovery test? What recovery targets apply? How frequently must testing occur? What dependencies must the exercise include? Who reviews the results? What happens when the target is missed?

The answers may come from several sources: a business impact analysis, an internal standard, a contractual commitment, or an approved recovery plan.

Until those connections are made, the organization has a category of concern. It still needs an actionable obligation.

Start with a responsibility someone can explain

An obligation should be understandable to the person accountable for it.

“Support organizational resilience” expresses an objective. “Demonstrate annually that the licensing application can be restored within its approved recovery target” describes a responsibility that can be assigned and evaluated.

That statement still needs context. The organization should be able to explain:

• Why it exists: the authority, commitment, or decision establishing it.

• Where it applies: the application, vendor, service, contract, or other subject covered.

• Who owns it: the person or role accountable for its fulfillment.

• What satisfaction requires: the criteria and evidence used to evaluate it.

• When it matters: its deadline, recurrence, or evaluation period.

Precision matters here. A framework recommendation, an internal improvement goal, and a binding contractual requirement may all deserve attention, but they carry different authority. Recording the basis for an obligation helps people understand those differences and route decisions appropriately.

Activity is only part of the picture

Once an obligation is clear, the organization can identify the work needed to fulfill it.

That work might include conducting an assessment, obtaining a vendor report, testing recovery procedures, or correcting an accessibility defect. Projects and tickets can coordinate those activities.

Governance must also address the result.

A recovery exercise can be completed and still demonstrate that the recovery target was missed. A vendor report can be received and still leave important questions unanswered. An accessibility assessment can be finished while identifying barriers that require remediation.

Tracking the obligation separately preserves that distinction. It allows the organization to record completed work, evaluate the evidence, identify gaps, and make an explicit determination about its current position.

It also keeps the responsibility visible after the project closes.

Framework mapping becomes more useful with concrete obligations

Starting with obligations does not diminish the value of frameworks. It gives framework mapping something specific to describe.

A single recovery exercise might support several requirements. Several obligations might rely on the same evidence. A framework assessment might reveal an expectation that has no corresponding owner or established practice.

Those relationships are easier to evaluate when the underlying records explain what must happen and why.

They also make change more manageable. If an organization adopts a different framework, its contractual commitments and internal responsibilities do not disappear. The mappings can change while those obligations retain their ownership, evidence, and history.

Conversely, when a contract or policy changes, the organization needs to examine the affected obligations even if its chosen framework remains unchanged.

Begin with a small, consequential set

An organization does not need a comprehensive framework implementation before it can improve governance.

It can begin with one important application or service and identify a manageable set of obligations. Confirm their sources. Decide what applies. Establish ownership. Define acceptable evidence. Evaluate the current position and record unresolved gaps.

That exercise will likely expose practical questions quickly: an unclear requirement, an unassigned responsibility, an outdated document, or a conclusion that nobody formally reviewed.

Resolving those questions produces useful governance immediately.

This is the perspective behind IT GO: make obligations explicit and traceable, then connect the work, evidence, and decisions needed to manage them.

Frameworks can help an organization understand the breadth of its governance responsibilities. A clear obligations register helps it answer for those responsibilities, one by one.