Разработка структуры контроля: затраты и доходы

Постоянные данные: данные, которые являются долговременными и влияющими транзакциями, текущими в и из системы.

Оценка риска: определение потенциальной частоты появления проблемы и потенциального повреждения, если возникнет проблема. Используется, чтобы определить стоимость / прибыль средства контроля.

Информационные системы могут сделать исчерпывающее использование всех механизмов контроля, предварительно обсужденных. Но они могут быть настолько дорогими для создания и настолько сложными для использования, что система станет экономически или операционно невыполнимой. Должен быть выполнен некоторый анализ стоимость / прибыль, чтобы определить, какие механизмы контроля обеспечивают наиболее эффективную защиту без того, чтобы жертвовать операционной эффективностью или стоимостью.

Один из критериев, который определяет, сколько контроля должно быть встроено в систему - важность ее данных. Главные финансовые и учетные системы, например, такие как системы платежной ведомости или прослеживания продаж и покупок на бирже, должны иметь более высокие стандарты средств контроля, чем система обучения служащего навыкам инвентаризации или справочная система зубной клиники для поиска пациентов и напоминания им о необходимости по прошествию шести месяцев пройти проверку.

Постоянные данные, данные, которые являются долговременными и важными транзакциями, текущими в и из системы (например, коды для существующих продуктов или центры стоимости) требуют более тщательного контроля, чем разовые транзакции. Единственная ошибка в данных транзакции воздействует только на транзакцию, когда ошибка в постоянных данных может воздействовать на многие или все транзакции каждый раз при обработке файла.

Финансовая эффективность средств контроля будет также зависеть от эффективности, сложности и затрат на каждую методику контроля. Например, полная взаимно однозначная проверка может потребовать много времени и быть операционно не возможной для системы, которая ежедневно обрабатывает сотни тысяч коммунальных платежей. Но может быть допустимым использование этих методик, чтобы проверить только критические данные типа сумм в долларах и номеров счета, при игнорировании имен и адресов.

Третье соображение - уровень риска, если определенное действие или процесс должным образом не контролируются. Разработчики системы могут выполнить оценку риска, определяя вероятную частоту проблемы и потенциального повреждения, если она возникнет. Например, если событие, вероятно, произойдет не более, чем один раз в год, с максимумом потерь в организации в $1000, нет необходимости тратить $20,000 на проект и обслуживание средства контроля, чтобы защитится от этого события. Однако, если то же самое событие может происходить по крайней мере один раз в день, с потенциальной потерей из более чем $300,000 в год, $100,000 потраченные на средства контроля будут полностью оправданы.

Таблица 18.5. поясняет примерные результаты оценки риска для системы обработки заказа в режиме реального времени, которая обрабатывает 30,000 заказов в день. Вероятность сбоя питания в течение года - 30 процентов. Потеря транзакций заказа во время сбоя питания может колебаться от $5000 до $200,000 для каждого случая, в зависимости от того, насколько будет приостановлена обработка. Вероятность хищения в течение года - приблизительно 5 процентов, с потенциальными потерями в пределах от $1000 до $50,000 для каждого случая. Ошибки пользователя имеют шанс появления - 98 процентов в течение года, с потерями в пределах от $200 до $40,000 для каждого случая. Средняя потеря для каждого события может быть взвешена умножением на вероятность его появления за год, чтобы определить ожидаемую ежегодную потерю. Как только риски будут оценены, разработчики системы могут сконцентрироваться на контрольных точках с самой большой уязвимостью и потенциальной потерей. В этом случае, средства контроля должны сосредоточиться на способах минимизации риска ошибок пользователя и сбоев питания.

В некоторых ситуациях, организации не могут знать точную вероятность угроз, встречающихся в их информационным системам, и они не способны определить величину воздействия событий, которые разрушают их информационные системы. В этих случаях, управление может решить описывать риски и их вероятное воздействие качественным способом (Ramer, Snyder, and Carr, 1991).

Таблица 18.5. Оценка риска обработки заказа в режиме реального времени

Опасность	Вероятность возникновения в течении года (%)	Потери диапазон/среднее число ($)	Ожидаемая ежегодная потеря ($)
Сбой питания	50	5000-200,000 (102,500)	30,750
Хищение	5	1000-50,000 (25,500)	1,275
Ошибка пользователя	98	200-40,000 (20,100)	19,698

Эта таблица показывает результаты оценки риска трех выбранных областей в системе обработки заказа. Вероятность каждой опасности, происходящей в течение года, выражена в процентах. Следующая колонка показывает самую высокую и самую низкую возможную потерю, которая может ожидаться каждый раз при возникновении опасности, и среднюю потерю, которая вычисляется сложением самых больших и самых малых значений данных вместе и делением на 2. Ожидаемая ежегодная потеря для каждой опасности может быть определена, умножением среднего числа потери на вероятность ее возникновения.

Чтобы решить, какие средства контроля использовать, разработчики информационных систем должны исследовать различные методы контроля относительно друг друга и относительно их финансовой эффективности. Слабость средств контроля в одной точке может быть возмещена сильными средствами контроля в другой. Может быть не эффективным создание жестких средств контроля в каждой точке цикла обработки данных, если области самого большого риска безопасны или компенсируются средствами контроля в другом месте. Комбинация всех средств контроля разработанных для определенного приложения определит его общую структуру контроля.