Materiality in an IS Audit

Materiality in an information systems audit. A financial auditor can tell you materiality for the engagement in a number, a percentage of revenue or of total assets. This lesson is about what you do when there is no number.

Here is the situation. You are auditing logical access to an identity provider. There is nothing to denominate in currency, no figure to put a percentage on. So does that mean nothing here is material? Financial audit gives you a threshold. IS audit rarely can.

The reason the number disappears is simple. Financial materiality asks whether a misstatement could influence the decisions of users of the financial statements, and it works because those statements are measured in money. The absence of logging on a privileged account has no monetary value at all.

So IS audit materiality is assessed against the objectives the system or process serves, and it is largely qualitative. A deficiency is material because of the consequence it creates for those objectives, not because of a price you can attach to it.

Take the scenario that catches people out. A system processes four tenths of one per cent of transaction volume, almost nothing. But it authorises payment releases above one million, and it has no audit logging. Is that immaterial, because the volume is negligible? No. It is material, because the system performs a critical control function, and the missing logging removes accountability over exactly those high-value releases.

So what makes an IS deficiency material. First, and the one candidates get wrong most, the criticality of the process supported. A small system doing something essential outranks a large system doing something peripheral.

Second, the sensitivity and classification of the data. Personal data, payment data and material non-public information all raise materiality sharply. Third, regulatory and legal exposure. A deficiency that could breach a law, a licence condition or a reporting obligation is material largely by virtue of that exposure.

Fourth, whether other controls depend on it. And fifth, the reputational and operational consequence, including public visibility and the ability to keep operating. These are the factors, and notice that not one of them is a number.

That fourth factor deserves its own moment, because it is the general-control multiplier. A general control weakness that undermines your reliance on many application controls is material because of everything it invalidates downstream. A weak change management process is material for exactly this reason: it is not one broken control, it is every automated control you can no longer trust.

There is a move in the other direction too. Individually minor findings can be material in aggregate. Six small access weaknesses in one application may each sit below any reporting threshold, while together they support a conclusion that access control over that application is not effective. That aggregate judgement is yours to make. Listing six low-severity observations and leaving the reader to connect them is weaker work than stating the conclusion they support.

Which brings us to the traps. The dominant error is reaching for size. Transaction volume, user counts and system cost are all proxies for importance, and all three are unreliable. The payment system with four transactions a month and a one million pound threshold is more material than the intranet with nine thousand users. What actually matters is criticality, consequence, what a deficiency invalidates, and how pervasive it is across systems.

So carry this away. Materiality in IS audit is not a threshold you apply mechanically at the end of the engagement. It is a qualitative judgement you make throughout, and it shapes how much testing an area gets in the first place.