COBIT BAI06 and ITIL 4: Five Break Points at the Database Layer

Two frameworks measure change management maturity almost everywhere in enterprise IT: COBIT 2019 and ITIL 4. Both describe clearly how a change process should operate. Neither addresses the database layer separately. This article reads the expectations of both against work that touches the database, and shows exactly where the process breaks.

Why the Frameworks Do Not Name the Database Separately

COBIT and ITIL are written to be technology neutral. When they say change, they treat a server configuration, a firewall rule, an application release and a database object as the same kind of thing. That is deliberate, so the framework outlives the technology.

In practice the result is this: the organisation implements the framework, and the example in its head while implementing is an application release. The process is designed around application releases, tested around application releases and audited around application releases. The database sits inside the scope of the process but was never the subject of its design. That is where the break begins.

What COBIT BAI06 Expects

In COBIT 2019, BAI06 is the objective covering managed IT changes. Its essence is that change requests are evaluated, prioritised and authorised in a controlled way. On the practice side this includes the following.

Logging and classification. Every change is logged, categorised, assessed for impact and risk, authorised, planned and scheduled. All of these steps must be traceable.

Managing emergency changes. A controlled route is defined for emergency changes, and it is verified afterwards that changes taking that route were appropriately assessed and authorised. Being an emergency does not mean there is no record, it means the record arrives in a different order.

Tracking and reporting (BAI06.03). A system tracks and reports change status. That system also documents rejected changes, communicates the status of approved and in flight changes, and closes completed ones.

The MEA domain sits alongside it: continuous monitoring of the internal control system and continuous tracking of compliance with external requirements are expected. Evidence assembled once a year during an audit window does not meet that expectation; the word continuous is in the text.

What ITIL 4 Change Enablement Expects

ITIL 4 renamed change management to change enablement. That is not only a name change; it marks a move from meeting based gatekeeping to risk based assessment. Three concepts are decisive.

Change types. A standard change is low risk, repeatable and its procedure is pre authorised; each instance does not need separate approval. A normal change is less frequent, broader in scope or touches a critical component. An emergency change must be implemented quickly, follows an expedited approval route and requires a post implementation review.

Change authority. The person, team or automated mechanism responsible for assessing and authorising specific types of change. The phrase automated mechanism is in the text: ITIL 4 does not require authorisation to be a meeting of people.

Delegation. ITIL 4 explicitly recommends distributing approval authority according to risk, and calls routing standard and minor normal changes through a central board an anti pattern. The reason is simple: it creates a bottleneck without improving change quality.

Five Break Points at the Database Layer

1. The assessment happens but cannot be reproduced

Both frameworks expect the impact and risk of a change to be assessed. In practice that is a dropdown on a ticket form, filled in by someone drawing on their own experience. Two senior database administrators classify the same script differently. The assessment was performed but has no written basis, so it cannot be reproduced.

An auditor asks two questions here: on what basis was this level set, and would the same script receive the same level tomorrow. If neither can be answered, the control depends on a person, and in audit language that is a weakness. The way to fix it at the database layer is a rule based assessment derived from the content of the script itself: which object it touches, whether there is an unqualified update, whether the object is on the critical list, whether it can be rolled back. Because the rules are written down, the decision becomes reproducible.

2. Authorisation is recorded but not enforced

The ticketing system has an approval step and keeps an approval record. At the database layer, the person who runs the script is whoever can connect to the server. There is no technical link between the approval state in the ticket and the database connection. The approval produces a record, not a gate.

The same gap shows in segregation of duties. Policy says the approver and the executor must be different people; if no technical control enforces it, the person who wrote the script is usually also the person who runs it. The rule exists in the document and not in the flow.

3. Rejected requests are never recorded

BAI06.03 expects the tracking system to document rejected changes as well. At the database layer this is almost never met, because rejection is usually a conversation. The database administrator looks at the script, says it will not do, the developer fixes it and sends a new version. Only the accepted final version appears in the system.

The effect in an audit runs the other way. A record showing only approved requests suggests not a rigorous control but one that never filters anything. The record of a rejected request is the strongest evidence that a control operates, and that is exactly the evidence missing.

4. Post hoc review of emergency changes piles up

Both frameworks require an emergency change to be reviewed afterwards: COBIT expects verification that it was appropriately assessed and authorised, ITIL expects a post implementation review. In practice the emergency fix happens at night, by morning the situation is stable and the review is postponed. The postponement is invisible because nothing counts the outstanding records.

Making it measurable is simple: every change taking the emergency route produces a post hoc review record, and that record stays on an open list until it is closed. If the list grows, the emergency route has become a shortcut, and that is a number that belongs on a dashboard.

5. The standard change concept has no counterpart in the database

ITIL defines a standard change as repeatable work whose procedure is pre authorised. At the database layer most organisations never built the counterpart. Rebuilding an index, updating statistics, adding a row to a lookup table: these either go through the full approval process every time, or happen with no record at all. Both are wrong.

The right answer is to pre authorise low risk repeatable database work by risk band while still leaving a record. Work speeds up, the record survives, and the change board sees only what genuinely needs assessment. That is not a departure from the framework, it is what the framework actually says.

Expectation to Evidence Mapping

The table below is meant to be filled in before an audit meeting. The middle column is what happens in your organisation today; the right column is the evidence an auditor will ask you to produce.

Turning It Into Practice

None of the evidence in the right hand column is produced by reading a framework. All of it comes out of a shared record that work touching the database passes through. If that record does three things at once, all six rows are covered.

It derives risk from the script. The assessment comes from written rules rather than human judgement, its basis is written into the record, and it becomes reproducible. Reproducibility is the single property that removes key person dependency.

It ties approval to a gate. Approval is a condition rather than a field: execution does not open until approval completes, an approver cannot execute their own request, and the number of approvals required rises with the risk band. For low risk repeatable work, pre authorisation is defined and the work never reaches the board.

It freezes the decision with the rule of that day. The rule set in force is written into the record at the moment the request is opened. When the rules change later, a past decision can still be read in its own context. The hardest question in an audit, which rule was in force that day, becomes answerable.

SQL Change Guard produces these three behaviours for every piece of work that touches the database, and runs alongside your existing ticketing system. The aim is not to reinterpret the framework, it is to produce the evidence the framework already expects without assembling it by hand.

Frequently Asked Questions

Do COBIT and ITIL mandate database change control separately?

No. Both are written to be technology neutral and treat a database object within the same scope as any other change object. That is precisely where the problem starts: the scope includes it, but because the process was designed around an application release, database specific routes were never described. An auditor reads the framework by whether the control actually operates, not by technology, and the database falls inside that reading.

Our change board sees every change. Is that not safer?

ITIL 4 explicitly calls this an anti pattern, on the grounds that it creates a bottleneck without improving change quality. It has two practical effects. First, a board cannot examine hundreds of items, so approval degrades into a formal click. Second, as waiting time grows, work drifts to other channels. The safer model is to distribute authority by risk and reserve board capacity for work that genuinely needs assessment.

An emergency change cannot be approved in advance. How does the framework expect this to work?

The framework does not expect prior approval; it expects the record to arrive in a different order. The emergency route is defined, changes taking it are logged with a stated reason, and afterwards it is verified that they were appropriately assessed and authorised. What is unacceptable is not the urgency, it is never coming back after it. The measure is clear: the number of outstanding post hoc reviews should stay close to zero.

Why does recording rejected requests matter so much?

Because what demonstrates that a control operates is the rejections it produces. A record showing only approvals suggests the absence of a control rather than its rigour. COBIT's tracking and reporting expectation explicitly includes documenting rejected changes. In practice the way to achieve it is to move revision rounds out of chat and into the request's own history.

Can we meet these expectations without buying another tool?

Some of them. Recording rejected requests, counting outstanding reviews for emergency changes and defining low risk work as standard changes are process decisions you can take today. What cannot be met that way is the technical part: proving the text that ran is the text that was approved, tying approval to an execution gate and deriving risk from the content of the script all require a layer that work touching the database passes through. Starting with the process decisions and then measuring the technical gap is the healthiest order.