Указания за одит на информационни системи за управление на публичния дълг



страница1/4
Дата25.10.2018
Размер0.55 Mb.
#97170
  1   2   3   4

МСВОИ 5450

Международните стандарти на Върховните одитни институции или МСВОИ се издават от

ИНТОСАЙ, Международната организация на върховните одитни институции

За повече информация виж www.issai.org


ИНТОСАЙ

Указания за одит на информационни системи за управление на публичния дълг

Декември 2016
Комитет за професионални стандарти на ИНТОСАЙ
Секретариат на КПС

Rigsrevisionen • Store Kongensgade 45 • 1264 Копенхаген K • Дания

Tel.:+45 3392 8400 • Fax:+45 3311 0415 •E-mail: info@rigsrevisionen.dk

ИНТОСАЙ


EX PERIENT IA MUTU A
OMNIBUS PRODEST

Генерален секретариат на ИНТОСАЙ - RECHNUNGSHOF


(Австрийска сметна палата)

DAMPFSCHIFFSTRASSE 2


A-1033 ВИЕНА
АВСТРИЯ
Tel.: ++43 (1) 711 71• Fax: ++43 (1) 718 09 69
E-MAIL: intosai@rechnungshof.gv.at;

WORLD WIDE WEB: http://www.intosai.org



ИНТОСАЙ

Работна група по одит на публичния дълг

РЪКОВОДСТВО ЗА ОДИТ НА ИНФОРМАЦИОННИТЕ СИСТЕМИ ЗА УПРАВЛЕНИЕ НА ПУБЛИЧНИЯ ДЪЛГ

декември 2016

СЪДЪРЖАНИЕ

ПРЕДГОВОР 5


СПИСЪК НА СЪКРАЩЕНИЯТА 7
ВЪВЕДЕНИЕ 8
1. ПЛАНИРАНЕ 9
2. ОБЩИ КОНТРОЛИ 11
3. КОНТРОЛИ НА ПРИЛОЖЕНИЯТА 15
3.1. СТАНДАРТИ ОТНОСНО ДОКУМЕНТАЦИЯТА 15
3.2. КОНТРОЛИ НА ВХОДНО НИВО 16
3.3. КОНТРОЛИ НА ОБРАБОТКАТА 19
3.4. КОНТРОЛИ НА ИЗХОДНО НИВО 20
3.5. ТЕСТВАНЕ НА КОНТРОЛИТЕ НА ПРИЛОЖЕНИЯТА 21
3.6. ДОКЛАДВАНЕ НА ОДИТНИТЕ РЕЗУЛТАТИ 22
Приложение I: Таблица за планиране 23
Приложение II: Матрица за тестване на общи контроли 26
Приложение III: Матрица за тестване на контроли на приложението 32
Фиг. 1: Одити на публичен дълг от ВОИ: Случаят на Бразилия 48
Фиг. 2: Одити на публичен дълг от ВОИ: Случаят на Молдова 51
БИБЛИОГРАФИЯ 52

ПРЕДГОВОР

Публичният дълг стои в центъра на всяка дискусия относно управлението на публичните финанси. В стремежа си за разширяване на икономиките и подобряване на социалните услуги в своите държави, повечето правителства изпитват големи финансови потребности. На теория, държавният (или публичният) дълг представлява ефективен инструмент за икономически растеж и за равномерно разпределение на данъчната тежест между настоящите и бъдещите поколения от данъкоплатци. Но поради значимостта му за икономическото салдо, изключително важно е държавният дълг да се измерва и управлява с голямо внимание.


Основната цел на управлението на дълга е да се осигури стабилно финансиране на възможно най-ниска цена и на разумни нива на риска с цел осъществяване на правителствените дейности. Преработените насоки за управление на държавния дълг на Световната банка и Международния валутен фонд (МВФ) предоставят набор от стабилни практики по отношение на вътрешните контроли за управление на дълга. Сред тях е и определението, че „дейностите по управление на дълга следва да бъдат подкрепени от точна и всеобхватна управленска информационна система с подходящи защити”. Държавите, които искат да гарантират ефективно управление на държавния дълг, трябва да си поставят за приоритет развиването на надеждни системи за регистриране и докладване на дългова информация. Необходимо е не само да разработят данни относно дълга и да се осигурят навременните плащания във връзка с обслужването на дълга, но също и да се подобри качеството на отчитането на бюджета и прозрачността на публичните финансови сметки, което дава възможност на лицата, които разработват политиките и тези, които управляват дълга да постигат целите относно държавния дълг.
Одитът на информационните системи за управление на публичния дълг се стреми да гарантира ефективността и ефикасността на управлението на държавния дълг. По тази причина, всеки подобен одит следва да бъде определен като одит на изпълнението. Въпреки това, уместно е тази одитна работа да се разглежда и в контекста на финансовите одити, чийто акцент е върху установяване дали финансовата информация, която подава правителството е в съответствие с нормативната рамка, приложима към представянето на финансовите отчети, както и дали информацията е надеждна, без измами и грешки. В този контекст, тази работа придобива голяма значимост, тъй като има принос за установяване на информационна система, която събира и генерира точна и надеждна информация за един от най-важните елементи на държавните финанси – държавния дълг.
Настоящото ръководство предоставя на одиторите насоки относно извършването на одит на информационните системи за управление на държавния дълг. Тъй като Международната организация на Върховните одитни институции (ИНТОСАЙ) вече разполага с документи относно одити на информационните технологии (ИТ), разработени от Работната група по ИТ одити (РГОИТ), настоящото ръководство се концентрира върху контролите на приложенията, които следва да бъдат специфични за информационните системи за управление на държавния дълг.

СПИСЪК НА СЪКРАЩЕНИЯТА

ПНД – планиране на непрекъснатостта на дейността


CAAT – компютърни техники за одит
CS-DRMS – Система на Секретариата на Британската общност за записване и управление на дълга
СУДФА – Система за управление на дълга и финансови анализи

СУД – Служба за управление на дълга


ПВБ – план за възстановяване при бедствия
ИСУФ – Информационна система за управление на финансите

МВФ – Международен валутен фонд


ИНТОСАЙ – Международна организация на Върховните одитни институции

ИТ – информационни технологии


ИСУПД – информационна система за управление на публичния дълг

ВОИ – Върховна одитна институция


СИД – Интегрирана система на федералното правителство на Бразилия относно дълга

УНКТАД – Конференция на ООН за търговия и развитие

РГОИТ – Работна група по одит на ИТ
РГОПД – Работна група по публичния дълг

ВЪВЕДЕНИЕ
Съгласно заданието, разработено от Управителния съвет на ИНТОСАЙ, на Работната група по одит на публичния дълг (РГОПД) е възложено да публикува указания и други информационни материали, които върховните одитни институции (ВОИ) да ползват за насърчаване на правилното докладване и доброто управление на държавния дълг.
Настоящото ръководство повишава капацитета на РГОПД за осигуряване на обща рамка, която да се използва в одити на ВОИ за оценка на общите контроли и контролите на приложенията на информационните системи за управление на публичния дълг (ИСУПД). Важно е да се обърне внимание, че в заданието, ИСУПД включва една или повече информационни системи, използвани за управление на публичния дълг.
С напредъка в областта на ИТ, държавните организации все повече зависят от използването на ИТ за извършване на своите дейности и предоставяне на услуги, както и за обработка, поддръжка и докладване на основна информация. Съгласно Работния документ на МВФ, „ИСУФ (Информационна система за управление на финансите) най-общо се отнася до компютризацията на процеса на управление на публичните разходи, в това число формулиране, изпълнение и отчитане на бюджета с помощта на напълно интегрирана система за финансово управление на ресорните министерства и другите разходни организации.”
Стандарт 1471 на Института на инженерите по електрически и електронни системи дефинира системите като „набор от компоненти, организирани така че да изпълняват конкретна функция или група от функции.” По-конкретно, основната дейност на дадена система в служба по дълга е да поддържа кредитната база с данни относно заемите на публичния сектор като използва софтуер, който адекватно изпълнява работата по записване и изпълняване на аналитичните функции на службата за управление на дълга (СУД).
ИТ одитите могат да бъдат класифицирани във връзка с преобладаващите подходи по следния начин:


  • Управление на ИТ;




  • Одит на данни;




  • Одит на информационни системи;




  • Договаряне във връзка с ИТ, и




  • Информационна сигурност.

Най-общо казано, ИТ одиторът прилага повече от един подход; обаче одиторът може да избере преобладаващ подход. В настоящите указания преобладаващият подход е одит на информационни системи.


Указанията са разделени на три раздела: планиране, оценка на общите контроли и оценка на контролите на приложенията.


1. ПЛАНИРАНЕ
ИСУПД може да бъде разгледана като набор от взаимнозависими части (физически структури, персонал и технологични инструменти), които си взаимодействат с цел записване, контролиране, оценка и управление на транзакции, които се извършват при набиране, поддръжка и клиринг на публичния дълг.
Този етап помага на одитора да вникне в свързаните операции и контроли на системата и свързаните рискове по отношение на присъщите за публичния дълг рискове в оперативния поток. На базата на това одиторът прави оценка на цялостната контролна среда, идентифицира системите, които се използват в управлението на публичния дълг, проучва цялата документация, която се отнася до тези системи и извършва предварителна оценка на риска. Резултатът от оценката ще определи обхвата на процедурите, които ще се използват в етапа на тестване.
ВОИ прави също и проверка на всички структури, отнасящи се до службата по публичен дълг, като персонал, процеси, видове дълг, сигурност на данните, технологични инструменти и други.
На този етап одиторът следва да включи предварителна оценка на структурата и оперативния поток на службата по публичния дълг, като обърне внимание на следното:


  • Как е организирана ИСУПД: какви системи се използват за записване, обработване, докладване, контролиране и управление на публичния дълг и кои са основните процеси и функции, извършвани от всяка от системите;




  • Функционирането на вътрешния одит;




  • Резултати от предишни одити (вътрешни или външни) на ИСУПД;




  • Физическо съхранение на документите от операциите;




  • Използването на компютърен хардуер и софтуер и отговорността за поддръжката им;




  • Операциите, които се обработват от информационните системи и

съответната им значимост;


  • Връзката между компонентите на информацията относно публичния дълг;




  • Методи и процедури за прилагане на нови или ревизия на съществуващи процедури;




  • Предишни оценки на вътрешните контроли на СУД. В случай, че вътрешните контроли на СУД не са били оценявани до момента, ВОИ следва да извърши тази оценка. Това е много важна процедура за оценка на степента на съществуващите рискове, а оттам и за определяне на необходимите одитни тестове.

Равнището на сложност на системата няма значение за оценката на общите контроли, която следва да бъде извършена във всички случаи. Тя определя одитните процедури, които ще се извършват и показва колко ИТ специалисти са необходими за осъществяване на одитната работа. Препоръчително е да има поне един ИТ специалист в екипа, който да извърши работата, отнасяща се до системите. За одиторите в екипа, за които извършването на ИТ одит е новост, е важно да придобият знания относно широко използваните термини. В този случай си струва ВОИ да инвестира в добър технически речник в областта на информационните технологии. Полезен в този смисъл е документът на РГОИТ „Одит на информационни системи – речник на термините”. От полза могат да бъдат и някои онлайн речници: вж. напр. http://www.webopedia.com или http://whatis.techtarget.com.


Одиторите, които са запознати с ИТ терминологията трябва също да познават и терминологията, използвана от СУД, особено акронимите и съкращенията (видове заглавия, сектори на СУД, кредитори, наименования на системите, софтуер ползван от СУД и т.н.). Изключително важно е тези знания да са усвоени преди провеждането на интервюта. Полезен речник, разработен от Конференцията на ООН за търговия и развитие (УНКТАД) може да намерите на следните интернет връзки:


  • http://unctad.org/en/Docs/pogiddmfasm3r3.en.pdf – Речник на понятията в областта на дълга и СУДФА (версия на английски език)




  • http://www.unctad.org/sp/docs//pogiddmfasm3r3.sp.pdf– Glosario de la deuda y del SIGADE (версия на испански език)

За да можете да разберете ИСУПД в детайли, трябва да познавате присъщите информационни (данни) и оперативни потоци. Следователно на етапа на планирането е много важно да изготвите карта на основните процеси относно публичния дълг (записване, обработване, контрол, сигурност, докладване и анализ), както и да разберете как се извършват тези процеси посредством информационната система. След това е необходимо да се проведе оценка на риска за идентифициране на по-големите рискове, свързани с основните оперативни и управленски процеси по отношение на публичния дълг, като се има предвид тяхното въздействие и вероятност от появата им. Оценката на риска е решаваща за определяне на обхвата на процедурите, необходими за управление на свързаните нива на риск. МСВОИ 5410, Указания за планиране и извършване на одит на вътрешните контроли относно публичния дълг предоставя указания относно провеждането на оценка на риска. В допълнение, оценката на риска може да бъде поставена в контекста на финансовите одити.


Потоците в ИСУПД почти винаги се уреждат в СУД. Други служби също би могло да отговарят за въвеждането на данни относно дълга, например в случай на договорни дългови задължения. Когато СУД се състои от „бек офис”, междинен офис и „фронт офис”, всяка основна функция работи със собствен поток от данни и информация. Обикновено фронт офиса отговаря за извършване на транзакциите на финансовите пазари, в това число управление на аукциони и други форми на заеми, както и всички други операции по финансиране. Бек офисът се занимава с приключване на транзакциите и поддържането на финансови регистри. Отделен офис – междинен или по управление на риска, обикновено извършва анализ на риска и мониторинг и докладва рисковете, свързани с портфейла, както и оценява ефективността на лицата управляващи дълга спрямо стратегическите цели/референтните показатели. Основната част от потоците от данни, свързани с публичния дълг, в това число и външните данни, протичат в бек офиса, който е натоварен със записване и контролиране на въведените данни.
При положение, че много държави използват готови системи, които се предлагат на пазара и които са разработени и актуализирани от трети страни/международни организации (напр. Система за управление на дълга и финансови анализи (СУДФА) или Система на Секретариата на Британската общност за записване и управление на дълга (CS-DRMS) за управление на публичния дълг, използването на доклади за изпълнението, напр. искания за системна поддръжка и записи на инциденти, е изключително важно.
При програмата СУДФА, разработена от УНКТАД, ударението пада върху дейностите „надолу по веригата”. Тези дейности включват: управление на базите с данни относно дълга, валидиране на данни относно дълга, дългови операции, вътрешно и външно докладване относно дълга, статистика за дълга и базов анализ на дълга, както и изграждане на системни връзки между софтуера за управление на дълга и софтуера за другите финансови дейности. Те допълват дейностите „нагоре по веригата”, като анализ на устойчивостта на дълга, който се извършва от други организации, напр. Световната банка. В допълнение, програмата все повече помага на страните да установят връзки между СУДФА за управление на дълга и друг правителствен софтуер (напр. софтуер, който се използва при изготвянето на бюджета, управление на кешовите наличности и на държавната помощ), или вътре в сложни, интегрирани системи за финансово управление, като елемент на цялостната дейност на дадена страна за управление на финансите. За допълнителна информация вижте: http://unctad.org/dmfas.
Приложението CS-DRMS, което се предоставя от Секретариата на Британската общност, подпомага ВОИ при записването, управлението и анализирането на дълга от холистична гледна точка. Осигурява централизирано „хранилище” на няколко категории държавно или частно секюритизиран външен или вътрешен дълг, включително и краткосрочен дълг. Системата борави също и с безвъзмездната помощ, държавното кредитиране и преотдаване на кредити. За допълнителна информация вижте: http://www.csdrms.org.
Когато имаме държави, които използват СУДФА или CS-DRMS в управлението на публичния дълг, докладите от одити на ИСУПД, извършени от други държави (други ВОИ) могат да бъдат полезни за идентифициране на най-често срещаните недостатъци, на тези които имат най-голямо отражение, или и двете.
Приложение I съдържа таблица във връзка с изискуемата информация, процедури и въпроси на които ВОИ да отговори и което може да се използва от одитния екип на етапа на планирането на работата по одита на системите относно публичния дълг.


2. ОБЩИ КОНТРОЛИ
Общите контроли представляват рамката на цялостния контрол върху ИТ функциите.1 Тези контроли са разработени за справяне с проблеми, свързани с разработването, операциите и поддръжката на средата. Задачите на общите контроли са да опазват данните, да защитават програмните приложения и да обезпечат непрекъснатата работа на компютрите в случай на неочаквано прекъсване.
Въпреки че одитът на системите относно публичния дълг изискват верификация на общите ИТ контроли, настоящият документ не се спира подробно на тези контроли, тъй като ИНТОСАЙ вече е публикувал документи относно ИТ одити в които подробно се засяга въпроса за общите контроли.
Препоръчва се при извършване на одит на система, одитният екип да използва МСВОИ 5310, Указания за одити на сигурността на информационните системи (ISec), който дава насоки относно прегледа на сигурността на информационните системи на правителствените организации.
Друг документ, който също може да бъде полезен при планирането на общите контроли е изданието на РГОИТ „Наръчник на ИИР по ИТ одити за Върховни одитни институции”, където е представена основна информация и са засегнати ключови въпроси във връзка с ефективното планиране на ИТ одити.
В Приложение II може да видите матрица за тестванията с някои общи контроли и предложения за процедури на тестване, която да подпомогне одитора при тестване на общите контроли.
Всеобхватният набор от различните категории общи контроли включва описаните по-долу елементи.
Организационни контроли
Организационни контроли са политиките, процедурите и организационната рамка, установени с цел обезпечаване на стабилни политики за човешките ресурси и управленските практики, разделение на задълженията и политики за сигурност на информацията, както и за осигуряване на методи за оценка на ефективността и гарантиране на оперативните контроли и ефикасността.
Контроли на физическия достъп
Контролите на физическия достъп включват правила и практики за предотвратяване на неразрешен достъп и намеса в ИТ услугите, в това число административните процедури, като изискване от персонала да удостоверява самоличността си чрез баджове и контрол на посетителите, както и физически мерки като електронни ключалки и врати, камери и други способи за ограничаване на физическия достъп до сървъри и други елементи на критичната инфраструктура.
Контроли на логическия достъп
Контролите на логическия достъп използват системата за сигурност вградена в компютърните системи за предотвратяване на неразрешен достъп до файлове и данни, съдържащи поверителна информация, както и за гарантиране, че всички потребители притежават права за достъп, които се ограничават до изискванията, произтичащи от длъжностната им характеристика. Тези контроли включват защитни стени, антивирусен софтуер и разкриване на проникване и зловреден софтуер.
При модерните системи тези контроли се получават по множество и най-разнообразни начини. Те се внедряват чрез приложен софтуер, оперативна система, система за управление на базата данни, софтуер за контрол на достъпа, мониторинг на обработването на онлайн транзакциите, мрежата, локалната мрежа и вероятно и друг софтуер.2
Контроли на околната среда
Контролите на средата са правила, практики и вградени условия за предотвратяване на вреди, причинени от нестабилност на електрозахранването, пожар, прах, вода, храна, екстремни температури, влажност или статично електричество.
Въпреки че акцентът при тези контроли пада върху центъра, където са данните (или зоната отделена за ИТ оборудването, която поставя специфични изисквания към заобикалящата я среда, или най-малкото защита от кражба), те са приложими и към средата, заобикаляща цялото офисно пространство.
Контроли на смяната на програми
Контролите на смяната на програми включват правила, които гарантират, че всички промени в конфигурацията на системата са извършени по правилния начин, цялостно и своевременно.
Актуализациите и промените трябва да спазват официален процес, който гарантира регистрирането на всички промени и осигуряването на възможност за отказ в случай на проблеми с новата версия.
Би следвало да се изисква официално одобрение преди програмите да преминат от нивото на тестова библиотека към производствена библиотека, а цялата документация за системите, операциите и програмите следва да бъде пълна, актуална и в съответствие със стандартите, политиките и процедурите.
Планиране на непрекъснатост на дейността и план за възстановяване при бедствия
Планирането на непрекъснатостта на дейността (ПНД) и свързаният план за възстановяване при бедствия (ПВБ) са насочени към постигане на целта за разполагаемост. Планирането за извънредни ситуации и възстановяване при бедствия, план за жизнеспособност, тестване и мониторинг, както и необходимостта от постоянно актуализиране на плановете са фактори от решаващо значение.3
ПНД е цялостен подход за осигуряване на алтернативни възможности в подкрепа на критичните за дейността процеси в случай на аварии, бедствия или други подобни обстоятелства. Ударението пада върху оцеляване на цялата система, свързана с дейността, а не само на ИТ системата. Обаче цялостният план трябва да включва конкретни съображения относно изискванията на информационните системи и на телекомуникационната мрежа. Тази част от ПНД е също и ПВБ.
ПНД и свързаният ПВБ може да бъдат разработени едновременно, така че всички аспекти да бъдат взети под внимание в синхрон. Като минимум, планът трябва да включва процедури и критерии за определяне кога дадена ситуация представлява бедствие, лицето, което отговаря за това и как официално да се обяви бедствено положение и да се задейства планът.
3. КОНТРОЛИ НА ПРИЛОЖЕНИЕТО
Контролите на приложението са автоматизирани контроли в приложенията на информационните системи с чиято помощ се осигурява оторизиране, интегритет, точност и валидност на транзакциите. Те са вградени в програмирането на приложенията и са преобладаващи при входящите, обработващите и изходящи операции на приложенията. Целта им е да гарантират целостта, надеждността и точността на обработването на данните.
Сред примерите за контроли на приложението са проверките, които приложението прави на формата на въвежданите данни с цел предотвратяване въвеждането на невалидна информация, контроли на обработването, които предпазват потребителите от постване на неразрешени транзакции и подробни доклади и контроли върху общия брой на транзакциите за гарантиране, че всички те са пълно и точно регистрирани.
Контролите на приложението могат да бъдат класифицирани по следния начин:


  • входящи (на „входа”),




  • на обработката, и




  • изходящи (на „изхода”).




  1. СТАНДАРТИ ОТНОСНО ДОКУМЕНТАЦИЯТА

Стандартите относно документацията гарантират, че се съхранява адекватна и актуална документация. Внимателното актуализиране на документацията също е важно.4


Подходящата документация е важна за определяне на това какви са или какви трябва да бъдат контролите.
Добрата документация относно приложенията намалява също и риска потребителите да не спазват процедурите за контрол по начина, предвиден от ръководството. Прегледът на всеобхватната, актуализирана документация помага на одитора да разбере как работи всяко приложение и може да е полезно за идентифициране на конкретни одитни рискове.


  • Документация на приложенията: Помага на програмистите по поддръжката да разберат приложението, да отстранят проблемите и да направят подобрения. Документация се създава на всеки етап от процеса на разработването и може да има разнообразна форма, като схеми, графики, таблици или текст. Документацията може да включва подробности относно източника на данните, реквизити на данните, входни екрани, валидиране на данните, процедури за сигурност, описание на изчисленията, програмен дизайн, интерфейс с други приложения, контролни процедури, справяне с грешките, операционни инструкции, процедури за архивиране, резервни копия, съхраняване и възстановяване. Документацията на приложенията следва да се актуализира при модифициране на което и да е приложение.




  • Потребителска документация: Включва описания както на автоматизирания, така и на ръчния работен поток в помощ на първоначалното обучение, а и за текущи справки.

Във всички случаи, потребителската документация подлежи на актуализация при модифициране на приложенията.


Документацията следва да включва:


  • общ преглед на приложението;




  • спецификация на потребителските изисквания;




  • описания и списъци на програмите;




  • описания „на входа”/”на изхода”;




  • описания на съдържанието на файловете;




  • ръководства за потребителя;




  • настолни инструкции;







  • скорошни резюмета на оценките на сигурността;




  • скорошни решения относно сигурността и препоръчани действия, и




  • състояние на препоръчаните действия.




  1. КОНТРОЛИ НА „ВХОДА”

Контролите на входящо ниво са изключително важни за намаляване на риска от грешка или измама при компютризираните приложения. Контролите на входа са от решаващо значение за интегритета на данните.


Контролите на входящо ниво помагат за гарантиране на оторизацията, точността, целостта и навременността на данните, въведени в приложението. Оторизацията се гарантира посредством вторично одобрение на транзакциите, които надвишават определен праг. Точността се гарантира чрез редакционни проверки, които валидират данните преди приемане на дадена транзакция за обработка. Целостта се гарантира чрез процедури за справяне с грешките, които се отнасят до регистриране, докладване и отстраняване на грешки. Навременността се гарантира чрез мониторинг на потока от транзакции, регистрирането и докладването на изключения.
Контролите на входящо ниво могат да бъдат при:


  • екраните на входящи данни;




  • рутинните процедури за подготовка на данни;




  • оторизацията на входящи данни;




  • съхранението на входящи документи;




  • валидиране на входящи данни;




  • процедурите относно грешки при въвеждане на данни, и




  • подкрепящите механизми при въвеждането на данни.

Контролите, описани по-горе биха могли да бъдат заобиколени в случай, че подобно заобикаляне е възможно, посредством въвеждане или промяна на данните извън самото приложение. Необходимо е да съществуват автоматизирани проверки на интегритета на приложението, които разкриват и докладват всяка промяна на данните от външен източник. Например, трябва да има заложена проверка, която да разкрива и докладва всяко неразрешено изменение, направено в основната база данни на транзакциите.


Екрани за входящи данни
Стандартизираните екрани за входящи данни могат да осигурят последователност при въвеждането на данните.
ИСУПД може да включва следните функции:


  • входни екрани в стандартизиран формат и оформление;




  • полета за въвеждане на данни, които налагат ограничения върху това, което е разрешено да въвеждат потребителите;




  • определени задължителни за попълване полета; и




  • функция „помощ” (напр. F1), която подпомага потребителите при попълване на полетата за въвеждане на данни.


Рутинни процедури за подготовка на данни
Целта на рутинните процедури за подготовка на данни е да се избегнат неуспехи по време на процедурите по въвеждане на данни.
ИСУПД може да включва вградени среди за процедури за споделяне на данни с цел прехвърляне на данните към други приложения.
Оторизация за въвеждане на данни
Разрешението за въвеждане на данни цели да гарантира, че всички въведени данни са записани и оторизирани от подходящото лице.
ИСУПД може да включва следните функции:


  • изискване на парола за достъп;




  • запис на файла за достъп, когато има ръчно въвеждане на данни, и




  • изискване за двойно одобрение на някои чувствителни операции (напр. задействане на договори, промени в нивата на лихвени проценти, изменения в стойностите по договори).


Запазване на входящите документи
Тази област от контролите на входящи данни се отнася до поддръжката и контрола върху оригиналните документи в подкрепа на записите на данни за дълг. В случай, че има автоматично прехвърляне на файлове между приложенията, ИСУПД трябва да съхранява данните получени от други приложения за период от време, който е предварително определен от СУД.
Валидиране на входящи данни
Контролите за валидиране на данни се разработват с цел да се гарантира, че входящите данни са валидни и точни.
ИСУПД може да включва следните функции:


  • автоматизирани контролни листове проверяват липсата на стойности (напр. при изтегляне на историческа серия от показатели, ИСУПД проверява дали липсва дневна, месечна или годишна стойност);




  • Всички екрани за входящи данни ясно показват кои са задължителните полета, а приложението разрешава потвърждаване на операцията единствено, когато е въведена цялата задължителна информация;




  • Всяка таблица с база данни трябва да съдържа конкретно правило относно полетата, където не е разрешено дублиране на данни;




  • Ако приложението счете, че са въведени дублирани данни, то няма да приеме въвеждането, докато не бъде отстранено дублирането;




  • Приложението не позволява изменението на определени данни след като веднъж са въведени (напр. обменен курс на датата на операцията). По отношение на други данни, приложението би могло да разреши изменения при положение, че са изпълнени определени условия (напр. когато даден договор е със статут „заключен” или „сключен”, данните не могат да се променят).




  • При попълване някои полета изискват да бъдат попълнени и други полета (напр., ако потребител въведе таксата за ангажимент по договор, този потребител трябва също да попълни и данъка за ангажимент).




  • Полетата за дата са изключително важни за общия контрол върху договорите за дълг. Те са особено полезни при изчисляване на вноските, за да се избегне забавяне на плащания, налагане на глоби и т.н. В този смисъл, приложението трябва да има определени правила относно вмъкването на датата.




  • С изключение на симулираните операции, системното приложение не позволява регистриране на данни за бъдеща дата, напр. разплащане, обратно разплащане, отмяна на договор или добавяне на договор.


Грешки при въвеждане на данни
Одитната следа или одитния регистър е от значение за сигурността и представлява хронологичен запис, набор от записи, или дестинация или източник на записи, които предоставят документални доказателства за последователността от дейности, които във всеки момент са повлияли върху конкретна операция, процедура или събитие. Одитната следа или файловете от регистъра/архива следва да бъдат достъпни само за подходящия персонал.
ИСУПД може да включва следните функции:


  • СУД следва да определя отговорността по отношение на необработени/”чакащи” файлове;




  • Програми за грешни действия при регистрацията, докладване на грешки и записване на корекции на грешки следва да бъдат вградени в приложението;




  • При процес на автоматизирано сваляне на данни, когато приложението идентифицира пропуски в сериите, автоматично електронно съобщение се изпраща до подходящите потребители с цел последващи действия; и




  • Приложението следва да изпраща на подходящия персонал периодични доклади относно неотстранени грешки, включително и колко време грешките са останали неотстранени и техният приоритет.


Подкрепящи механизми при въвеждането на данни
Тези контроли са свързани с подкрепящите процедури в СУД, които помагат на потребителите да въвеждат данни в компютърното приложение, повторно инициализиране на приложения и мониторинг на потребителските дейности за избягване на евентуални отклонения от установените правила.
Тези механизми често са включени в общите контроли.


  1. КОНТРОЛИ НА ОБРАБОТКАТА

Контролите на обработката гарантират точността, пълнотата и навременността на данните по време на партидна или онлайн обработка. Тези контроли помагат да се гарантира точната обработка на данните чрез приложението, както и че няма добавяне или промяна на данни по време на обработката.5


Пълнота
Пълнотата може да бъде осигурена при партидната обработка чрез балансиране на транзакциите, получени в системата с транзакциите, изпратени от спомагателна система.
Балансирането следва да се осъществи между приложения, които споделят общи данни, чрез създаване на съгласувателен доклад, който описва данните от двете приложения и докладва наличието на различия за дадена потребителска група.6
Балансовите общи стойности трябва да включват брой на транзакциите и общи стойности за всички количествени полета, както и обобщени стойности за полетата с подробности към полетата с общи стойности.7
При файлове в които няма смислени общи стойности, може да се създадат хеш стойности, които да събират всички цифри в дадена колона, за да се потвърди, че същата стойност е приета от следващия процес. Например, обща стойност на номерата на споразуменията за дълг не е смислена стойност, но тя може да се използва, за да се провери дали всички коректни номера на споразумения за дълг са включени в обработката.8
ИСУПД може да включва следните функции:


  • В интерфейса с други системи между приложенията, в случай на грешка в обработката на файлове се генерира файл за грешка, който се записва в системното приложение. Потребителите трябва да развият по-задълбочен оперативно-съвместим подход спрямо техническите профили и обучението в съответната организация.




  • Приложението съдържа планирана партидна обработка на множество задачи, напр. актуализация на запасите, финансово планиране, показатели/индекси и бъдещи плащания. Потребителите трябва да оценяват „меките” изходящи данни от системата в реално време, фокусирайки се върху базираните на партиди регистри, както и „твърдите” способности в реално време за измерване на обработката на актуална информация.




  • В случай на грешка при обработката на партидите, приложението изпраща съобщение да потребителя с информация за грешката. Потребителят може да провери консолидиращите възможности вътре в системата за изпълнение на политиките относно коригирането на грешки и за конфигуриране на контролните процедури.




  • След приключване на операция, приложението показва съобщение, което потвърждава, че обработката е успешна и представя резюме на въведените данни.




  • След модифициране на вече регистрирани данни, приложението показва съобщение, че модификацията е успешна и представя резюме на модифицираните данни.




  • След изтриване на вече регистрирани данни, приложението показва съобщение, че изтриването е успешно и представя резюме на изтритите данни.




  • В случай, че изтриването на запис засяга релационния интегритет на базата данни, приложението не разрешава изтриването и показва съобщение, че записът не може да бъде заличен. Например данните на банка-кредитор не могат да бъдат заличени от таблицата на кредиторите, ако този кредитор има договори в процес на изпълнение в приложението.




  • Приложението извършва някои проверки на данните на фронт офиса и на бек офиса. Например, изисква от бекофиса да валидира входящите данни от аукциони. Потребителите могат да проверят комуникациите за взаимовръзки на архитектурата на данните между компонентите и системите, за да верифицират потоците данни съгласно диаграмата за оперативна съвместимост.




  1. КОНТРОЛИ НА „ИЗХОДА”

Контролите на „изхода” гарантират интегритета на резултатите и коректното и своевременно разпределение на генерираните резултати.9 Слабости в обработката могат понякога да бъдат компенсирани със засилени контроли „на изхода”. Дори и добре контролираното приложение „на входа” и при обработката има вероятност да се обезсмисли напълно, ако липсва контрол „на изхода”.10


Пълнотата и интегритета на докладите „на изхода” зависят от ограничаване на възможността за промяна на резултатите и включване на проверки за пълнота, като напр. номера на страници и проверки на сборовете.11
Файловете с резултатите/ „на изхода” трябва да бъдат защитени, за да се намали риска от неразрешени промени. Възможните мотиви за внасяне на изменения в компютърните резултати включват прикриване на неоторизирана обработка или манипулиране на нежелани финансови резултати.12
Изходните резултати от едно ИТ приложение биха могли да формират входящи данни за друго приложение. Когато това е така, авторът трябва да види контролите, за да гарантира, че изходните резултати са правилно прехвърлени от един етап на обработка към следващ етап.13
В ИСУПД контролите „на изхода” могат също да бъдат програмирани да идентифицират критична информация, която изисква приоритетни действия от страна на управлението на публичния дълг. Например във връзка с договори, които изтичат през текущия месец, приложението би могло да показва ежедневни напомняния на първия екран на системата за договорите, чиито дати на плащане изтичат през следващите 5 дена.
Приложението може също да позволява на някои профили на потребители да генерират доклади в приоритетен режим, като по този начин дава възможност на приложението да подрежда по приоритет докладите, които се генерират.
ИСУПД може да включва следните функции:


  • Приложението предоставя автоматизирано сравнение на сумите от първоначалните данни със сумите от обработените данни;




  • Приложението трябва да информира потребителите за статуса на искането за генериране на доклад, например „не е стартирано”, „в процес на извършване” и „приключено”; и

- в края на процеса на генериране на доклад, приложението изпраща съобщение на потребителя, който е подал искането, като го информира, че задачата е изпълнена.




  1. ТЕСТВАНЕ НА КОНТРОЛИТЕ НА ПРИЛОЖЕНИЯТА

След идентифицирането на контролите, следващата стъпка е одит за проверка на ефективността им.


Това може да се постигне чрез:


  • Подаване на набор от тестови данни, които, когато приложението работи

правилно, ще произведат познати резултати;


  • Разработване на независими програми за повторно изпълнение на логиката на приложението; и




  • Оценяване на резултатите от приложението.

Горните процедури тестват интегритета на програмата вградена в ИСУПД, а не интегритета на данните.


Ако приложението има тестваща среда, това може да се използва за тестване на контролите, стига тестващата среда да е потвърдено копие на производствената среда.
За тестване на правилата на изчисляване, като тези, които се отнасят до актуализиране на запасите или обслужването на дълга, одиторът може да има нужда от компютърни техники за одит (CAAT), които включват множество видове инструменти и техники, като напр. генерализиран одиторски софтуер, помощен софтуер, тестови данни, приложен софтуер за проследяване и картографиране и експертни одиторски приложения. Може да бъдат включени и инструменти, които правят анализ за точност на логиката и изчисленията в електронните таблици. Инструменти могат да се ползват и за анализ на приложенията на базите данни и за изготвяне на логически схеми. Генерализираният одиторски софтуер може да се използва за анализ на данни, произведени от повечето приложения.
Одиторът следва да оцени необходимостта от ползване на CAAT. Използването им трябва да се основава на сложността на приложението за управление на публичен дълг.
Настоящият документ съдържа предложение за тестваща матрица (вж. Приложение III), която евентуално да се ползва от одиторския екип за справка при тестване на контролите на приложенията. Тази матрица идентифицира някои от изискванията и функциите, които системите в областта на публичния дълг следва да предоставят, заявки, които да може да изпълняват, както и минималните изисквания относно капацитета на подобни системи.
Важно е да отбележим, че тъй като дългът на всяка страна има различен състав и характеристики, системите за управление на дълга също имат различни характеристики. В този смисъл, одитният екип отговаря за идентифицирането, коригирането, при необходимост, и използването на елементите, приложими към дълговата система на своята държава.


  1. ДОКЛАДВАНЕ НА ОДИТНИТЕ РЕЗУЛТАТИ

В допълнение към спазването на Декларацията от Лима относно указанията за одитните насоки, когато е подходящо, докладването на одити на ИСУПД трябва да отговаря на изискванията на МСВОИ 5440, Указания за извършване на одит на публичен дълг – използване на тестове по същество при финансови одити, раздел 2.6 Докладване на одитни резултати.


Както беше отбелязано, одитът на ИСУПД е одит на изпълнението, затова е важно докладът да спазва стандартите за докладване на одити на изпълнението, както е указано в МСВОИ 3000, Стандарти и указания за одит на изпълнението на базата на стандартите и практическия опит на ИНТОСАЙ (част 5), и МСВОИ 300, Основни принципи на одита на изпълнението (стр. 16).

Каталог: articles -> download
download -> Закон за върховната сметна палата на 14 декември 2005 г се навършват 125 години от приемането на първия Закон за Върховната сметна палата
download -> Одитен доклад №0400005712 за извършен одит за съответствие на декларираните приходи
download -> Одитирани обекти и дейности от сметната палата І. Първостепенни и второстепенни разпоредители с бюджетни кредити
download -> Закон за върховната сметна палата на българия уважаеми господин председател на Народното събрание
download -> Указания за финансов одит
download -> За извършен финансов одит на годишния финансов отчет
download -> Сборник документи издател на поредицата "архивите говорят": главно управление на архивите при министерския съвет


Сподели с приятели:
  1   2   3   4




©obuch.info 2024
отнасят до администрацията

    Начална страница