Can Your Organization Define Materiality?

Order a reprint of this story
Close (X)


To reprint an article or any part of an article from Hospitality Upgrade please email Fee is $250 per reprint. One-time reprint. Fee may be waived under certain circumstances.


October 26, 2006
Software | Compliance
Dorian Cougias -

View Magazine Version of This Article

© 2006 Hospitality Upgrade. No reproduction without written permission.

Regulators, lawyers and auditors habitually throw around the word ‘materiality’ in the context of both compliance and legal matters. A contract can be legally broken if enough change has occurred to materially breach the agreed upon boundaries. Sarbanes-Oxley auditors are looking for financial misstatements on the level of materiality. And the NFPA, HIPAA, PCI and a few other regulations are looking for ‘material weaknesses’ or enough ‘material change’ in policies to warrant a bad audit report or an overhaul of an organization’s information management controls.

However, it seems most organizations don’t have a good definition of materiality they can work with. When I ask for a succinct definition of the term, the answer I most often get is “that’s one of those words that are hard to define, but I know it when I see it.” The definition of materiality in most organizations and in most auditors' minds is very close to being wholly subjective–but it doesn’t have to be.

In general, think of materiality as a measure of impact. In our case, it is a level of weakness in either the design or the operation of information controls that are significant enough to be greater than the risk the organization is willing to take. The key here is correlating risk with the level of impact that a weakness carries with it. The question that your organization has to answer is how to measure the impact of a weakness in order to determine if it is significant enough to be called material. Buried within the reams of regulations, there are a few golden nuggets that will help us create a working definition that even the pickiest auditors should agree with.

The U.S. Government’s Financial Audit Manual, ¶ 230.02 - .13, and the Information Systems Audit Control Association’s IS Standards, Guidelines and Procedures for Auditing and Control Professionals § 2.1.3 – 2.1.5 define three levels of granularity when defining materiality; planning materiality, design materiality and testing materiality.

Planning materiality can be thought of an the aggregate level of error or downtime acceptable to your organizational management. The GAO guide suggests that 3 percent of the base measurement be used as a general guideline for materiality. Information systems, data, devices and processes possess materiality if they do one of two things:
  1. Provide reports by which decisions are made. For example, if the data in a report was the basis for future business direction, it is most certainly material. Thus, the data and processes must ensure accuracy.
  2. Provide a critical business function. Criticality can range from loss of life to loss of significant revenue. If the absence of an information process, system or IT asset would result in loss of revenue that exceeded operating costs, the process is most certainly material.

For a simple scenario we’ll look at a Web site that nets $2 million in sales per year, spread across 200 "cycle" or actual selling days with an average of a 12-hour cycle day (because the Web site only supports U.S. traffic, which means it isn’t busy 24 hours per day). That means that the net per day is $10,000 and the net per hour is $833.

Base Figures for Measuring the Materiality of a Web Site
With 3 percent as a rough guide, material loss would be estimated at $60,000. Therefore, the aggregate days and hours of downtime that could accumulate over the year total six days (remember these are 12-hour "cycle" days), or a total of 72 hours.
Materiality for an E-commerce Web Site
This sample only shows downtime as measured by the loss of e-commerce-based sales. In reality, there are several key measures you’ll want to assess when determining materiality.

>> Criticality of the business processes supported by the system or operation
>> Cost of the system or operation (hardware, software, staff, third-party services, overheads or a combination of these)
>> Potential cost of errors (possibly in terms of lost sales, warranty claims, irrecoverable development costs, cost of publicity required for warnings, rectification costs, health and safety costs, unnecessarily high costs of production, high wastage among other potentials)
>> Number of accesses/transactions/inquiries processed per period
>> Nature, timing and extent of reports prepared and files maintained
>> Nature and quantities of materials handled (e.g., where inventory movements are recorded without values)
>> Service level agreement requirements and cost of potential penalties
>> Penalties for failure to comply with legal and contractual requirements
>> Penalties for failure to comply with public health and safety requirements
>> Consequences to shareholders, organization or management of irregularities going unresolved
Design materiality is the portion of planning materiality that has been allocated to line items, accounts, or classes of transactions. In other words, design materiality is the value of the potential for the cumulative effect of small errors or weaknesses to become material. The GAO suggests that materiality should be based upon one-third of the base of planning materiality. This allows you to determine the maximum allowable downtime for each asset within the system (the database, the application, the OS, the storage array, the CPU, etc.). In this scenario, materiality would be reached at 24 hours of downtime due to the lack of discrete operations, such as a drive array malfunctioning.

Test materiality is the materiality actually used by your team (and the auditor) in testing specific controls. A material control can either be a single control (check the logs for unauthorized changes), or a grouped set of controls (such as disk- and tape-based backup and moving tapes off site) without which there is no reasonable assurance that the design materiality goals of maintaining confidentiality, integrity or availability would be met. In other words, if someone wasn’t examining the logs for unauthorized changes, how would you know if a breach occurred? If you aren’t backing up the system, how would you restore damaged or lost files?
This means that you will have to test for both design deficiencies (to account for vital controls being missing or not properly addressing the right issues) as well as operating deficiencies (to account for people not knowing how, or just not doing their job).

Dorian Cougias works with Network Frontiers, LLC. He can be reached at

Questions to Ask
• Have you met with the business units to determine their appetite for risk so that you can quantify a set of base numbers for materiality? Those base numbers should include allowable downtime (availability), data corruption (integrity) and what constitutes a privacy breach (confidentiality).
• Have you defined which systems and applications hold information that is material to your organization’s well being?
• Have you checked to see if the application’s creator even put the necessary tools in place to assure there are no control design deficiencies that could lead to a material loss of the system or the information in the system?
• Have you thoroughly tested your policies and procedures (operational controls) to ensure that the system is operating as designed and that the staff is performing those procedures?

want to read more articles like this?

want to read more articles like this?

Sign up to receive our twice-a-month Watercooler and Siegel Sez Newsletters and never miss another article or news story.