End-User Computing and Data Governance

End-user computing and data governance. This lesson is about the systems that are not on the system inventory, and about who actually owns the organisation’s data.

The scene. The month-end close depends on a spreadsheet. It has grown for years, it contains formulas only one analyst fully understands, and its output drops straight into the financial statements. It has never been tested by anyone else, has no version history, and if the analyst is on leave when a figure looks wrong, nobody can safely touch it. On the system inventory, it does not appear at all, because a spreadsheet is not considered a system. That last assumption is the whole problem.

Because a spreadsheet can be an application. End-user computing is applications built and maintained by business users outside I-T’s control, classically spreadsheets and user-built databases. They are enormously useful and often business-critical, and that is exactly why a critical one is a recognised audit risk.

Here is what it lacks. First, change management: anyone can alter a formula with no review, no approval.

Second, testing and input validation: there is no independent testing, so errors are found by luck if at all, and no validation, so a mistyped or malformed value is simply accepted.

And third, version control: which copy is authoritative is anyone’s guess, and the knowledge lives in one person’s head, complete key-person dependency. So when such a spreadsheet feeds the financial statements, an undetected error, a wrong formula, a dragged cell, a transposed input, flows straight into the accounts.

So what is the first step to control it. Not to ban it, that destroys tools the business relies on, and not to assume I-T already manages it, it does not, by definition. It is to identify and inventory the critical ones: which spreadsheets and user-built databases feed financial or otherwise critical processes.

Because you cannot apply controls to what you have not found. This is the same principle as identifying applicable obligations before managing compliance in Domain two: discovery comes first. Find the critical ones first.

Once they are known, apply proportionate controls: access restriction, version control, input validation, independent review of key formulas, and backup, scaled to how critical each one is. Not every spreadsheet needs this. The ones feeding the accounts do.

Now data governance, and one distinction the exam tests. The data owner is a business role, accountable for the data: its classification, its quality, and decisions about who may access and use it. The data custodian, usually I-T, holds, secures and maintains the data on the owner’s behalf.

So the line is: the business owns, I-T custodies. Accountability rests with the business data owner; I-T holds and protects it. It is the same shape as Domain three’s point that the business, not I-T, owns what a system is for, applied to the data itself. When a question asks who owns a dataset, it is the business data owner, not the team that stores it.

So carry this away. A spreadsheet feeding critical figures carries the risk of an application with none of the controls, and the fix begins with finding and inventorying the critical ones. And the business data owner is accountable for data; I-T is only its custodian.