Проверяющий в Рабдоке по МСА

Коллеги!

Интересует ваше отношение к вопросу отражения в РД проверяющего. ФИО, дата проверки.

Т.е. как вы считаете нужно ли в РД указывать проверяющего и дату проверки?

По ряду РД, которые выполняли члены аудиторской группы, руководитель задания обязан сделать обзорную проверку, также в МСА есть требования о завершении всех процедур за небольшими исключениями до даты выпуска заключения.  Подтверждением выполнения первого требования МСА является фио проверяющего, второго - дата проведения им проверки. Внутренними правилами фирмы могут быть установлены и более жесткие требования: например, проверка всех РД руководителем задания/контролером качества ит. А вообще не вижу причин не сделать в электронном РД стандартную функциональность - записывать уникальный логин-идентификатор пользователя и дату/время сохранения им документа и выводить эту информацию и в печатную форму и на экран.

Escapist, спасибо за обратную связь.

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

Т.о. в печатной форме РД проверяющего не будет. В программе, конечно, эта информация будет то справочно, т.е. не в шапке РД. И отдельный РД на проверяющего для выполнения требований МСА.

Думаем таким образом упростить шапку РД. Минимализм 

Вот и возник вопрос: Насколько это приемлемо для аудиторов?

Полагаю, что это рационально.
В материальных рабдоках не нужно будет вбивать проверяющего (внутренний ВККР). Экономится время. Часто аудиторы не знают, кто будет проверяющим. Кого вбивать?
Внутренний проверяющий свои разделы заполнять будет. В рабдоках аудиторов имя проверяющего и дата этой проверки будут появляться автоматически.

Проверяющий в каждом РД вводит в ступор..
Особенно когда к тебе на проверку приходит 1 аудитор: он и копирайтер, он же и руководитель проверки...Кто тогда проверяющий  ? не понятно...
Еще и программы разделов подкорректировать - а то там тоже 100 раз  указано проверено...
Тоже не очень понятно- это программа или итоговый какой документ..
Исправлений: 2; последнее - в 06.11.2019, 07:30.

Vovan®
Проверяющий в каждом РД вводит в ступор..

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

Vovan®
Проверяющий в каждом РД вводит в ступор..
Особенно когда к тебе на проверку приходит 1 аудитор: он и копирайтер, он же и руководитель проверки...Кто тогда проверяющий  ? не понятно...

Совершенно с этим согласен.

SvetЛАНА

Vovan®
Проверяющий в каждом РД вводит в ступор..

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

Основная проблема со сводным РД - контроль актуальности «визы» (что руководителем задания проверена последняя редакция документа и он не изменён после проверки). Это кстати важно и проверяемому и проверяющему, не говоря уж о внешнем контроле качества. Если каждый РД составляется и проверяется в электронном виде, то легко обеспечить, что проверяющий проверил именно последнюю редакцию документа. Его электронный «след» просто должен быть по времени последним. В сводном документе в электронном виде это конечно тоже можно сделать, но уже сложнее. А в бумажном виде такой сводный документ контролёра, это просто индульгенция
 к «перетряске» аудиторского файла после проверки.

Escapist

SvetЛАНА

Vovan®
Проверяющий в каждом РД вводит в ступор..

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

Основная проблема со сводным РД - контроль актуальности «визы» (что руководителем задания проверена последняя редакция документа и он не изменён после проверки). Это кстати важно и проверяемому и проверяющему, не говоря уж о внешнем контроле качества. Если каждый РД составляется и проверяется в электронном виде, то легко обеспечить, что проверяющий проверил именно последнюю редакцию документа. Его электронный «след» просто должен быть по времени последним. В сводном документе в электронном виде это конечно тоже можно сделать, но уже сложнее. А в бумажном виде такой сводный документ контролёра, это просто индульгенция
 к «перетряске» аудиторского файла после проверки.

Согласен. Есть такой риск.
Можно ли обеспечить неизменность бумажных документов после проверки? Думаю нет.
РД в электронном виде с ЭП изменить невозможно.

Грэг, а как ВККР отнесется если в РД не будет проверяющего, а будет отдельный РД с указанием, что проверили?

И как быть с замечанием Escapist, по контролю неизменности РД, если проверяющего нет в РД?

На практике при проведении ВККР запросят "стандартный" комплект документов по каждому попавшему в выборку заданию. В скан-копиях с необходимыми подписями (во всяком случае, если программное обеспечение, используемое аудиторами, не имеет должных степеней защиты от несанкционированных изменений). Такие документы, лучше сразу подписывать проверяющим работником АФ собственноручно. Что касается прочих РД  - все зависит от степени автоматизации их оформления. Что касается проблемы контроля неизменности РД - то тут дело не в подписи проверяющего. Сам проверяющий может потребовать внесения в них изменений, и подпись свою тоже поменять...

Сам проверяющий может потребовать внесения в них изменений, и подпись свою тоже поменять...

Ни одна система контроля не может быть рассчитана на противодействие _всех_ ее основных субъектов целям контроля. Есть в МСА обязательная проверка, чтобы руководитель задания проконтролировал работу группы и соответствие итогов работы мнению в заключении (за которое и отвечает руководитель), значит должны быть инструменты фиксации исполнения проверки именно как итогового шага. Контроль за руководителем задания (в тех случаях когда он предусмотрен МСА) носит принципиально иной характер из-за другого баланса ответственности и вовлечённости в выполнение задания руководителя и контролеров над ним.

SvetЛАНА
В скан-копиях с необходимыми подписями (во всяком случае, если программное обеспечение, используемое аудиторами, не имеет должных степеней защиты от несанкционированных изменений).

Тут даже интереснее. Дело не в том имеет или не имеет степеней защиты. Дело в законности ЭП, которая ставится программой.

Не уверен, но думаю, никто из разработчиков ПО для аудиторов даже не задумывается об этом. Даже не о конкурентах речь. Есть самописное ПО у многих. Так вот если в нем есть подписание РДА ЭП, то у разработчика должна быть соответствующая лицензия.

Если лицензии нет, то вопрос законности подписи на РДА встает остро. Лично я не уверен, что ответить проверяющим, которые решили докопаться по этому поводу.

Александр Орлов
Грэг, а как ВККР отнесется если в РД не будет проверяющего, а будет отдельный РД с указанием, что проверили?

Вряд ли я уполномочен отвечать за всех контролеров всех органов, которые занимаются ВККР. Лично я не вижу в этом нарушения ни одного стандарта. В таком документе будет указание не только что проверили, но и когда проверили, и кто проверил. Почему бы и нет?

МСА 230
   
9. При документировании характера, сроков и объема выполненных аудиторских процедур аудитор должен зафиксировать:
...(c) кто проверял выполненную аудиторскую работу, с указанием даты и объема такой проверки

Конкретный способ такой фиксации - в одном сводном документе или в виде отдельной надписи в каждом проверенном документе - стандарты не регламентируют.

Александр Орлов
Грэг, а как ВККР отнесется если в РД не будет проверяющего, а будет отдельный РД с указанием, что проверили?

И как быть с замечанием Escapist, по контролю неизменности РД, если проверяющего нет в РД?

А давайте посмотрим в МСА 230

     
A13. МСА 220 <8> требует от аудитора проверять выполненную аудиторскую работу путем проверки аудиторской документации. Требование документировать, кто именно проверял выполненную аудиторскую работу, не означает необходимости отражать в каждом рабочем документе подтверждение того, что он был проверен. Это требование, однако, означает, что следует документировать то, какая аудиторская работа проверялась, кто проверял эту работу и когда она была проверена.


Ну и где нарушение стандарта в рассматриваемом случае?

Если комментарий обращён ко мне, то я никогда не утверждал, что сводный документ контролера -нарушение стандарта, а только то что его использование может сделать крайне проблематичным выполнение совокупности требований 220 и 230 стандартов на практике. Нужно фиксировать выполнения процедур даты по исполнителю, даты и объём проверки по проверяющему, вторые даты должны быть после первых, и те и другие увязаны с датой заключения для ключевых процедур/выводов, срок датой +60 дней для прочих процедур, плюс контроль дат выпуска и утверждения отчетности для документации событий после отчётной даты .
А ведь ещё и очень желательно))), чтобы дата выполнения процедур или проверки была настоящей, а не просто подходящей.
 Поэтому в варианте ведения РД в электронном виде все удобно и реализуется стандартными инструментами: дата выполнения =дата последнего сохранения РД исполнителем, дата проверки = дата последнего сохранения РД контролёром. ФИО исполнителя и контролера определяется по имени пользователя в системе. Контролёру осталось при необходимости дописать, что он проверял, если объем поверки не было изначально определён на этапе планирования.
В принципе также стандартными средствами все эти даты можно свести в одну сводную форму, для удобства распечатки и предъявления ещё каким-нибудь контролёрам))). Главное чтобы в сводную форму даты не от балды любым пользователем набивались или не проставлялась бы автоматически тупо дата заключения (или более ранняя). Это уже было бы нарушение цели стандарта. На уровне аудиторской программы так делать нельзя (хотя помешать пользователям изменить системную дату в операционной системе разработчик конечно не может).

Вот как мы реализовали документирование контроля в сводном документе

Грэг

Александр Орлов
Грэг, а как ВККР отнесется если в РД не будет проверяющего, а будет отдельный РД с указанием, что проверили?

И как быть с замечанием Escapist, по контролю неизменности РД, если проверяющего нет в РД?

А давайте посмотрим в МСА 230

     
A13. МСА 220 <8> требует от аудитора проверять выполненную аудиторскую работу путем проверки аудиторской документации. Требование документировать, кто именно проверял выполненную аудиторскую работу, не означает необходимости отражать в каждом рабочем документе подтверждение того, что он был проверен. Это требование, однако, означает, что следует документировать то, какая аудиторская работа проверялась, кто проверял эту работу и когда она была проверена.

Ну и где нарушение стандарта в рассматриваемом случае?

Тоже самое и я в МСА естественно видел.

Вопрос был скорее из-за того, что я не считаю себя спецом в МСА, и могу что-то существенное упускать... Какую-то незначительную норму в других МСА, которая существенно влияет на требования к РДА, хотя "в лоб" вроде бы и не должна.

Напротив, Вас, я таким Спецом считаю! Поэтому и адресовал этот вопрос непосредственно Вам. Зная критичность Ваших суждений. Собственно я и надеялся услышать какой-то неожиданный для себя факт, который перевернул бы мое представление об этом вопросе.

Про ВККР естественно я упомянул не имея ввиду, что на форуме я хочу услышать официальный ответ руководства ВККР СРО РСА. Для этого есть более правильные канали связи. Просто некорректно выразился...

auditsoft, у Вас в этом РДА специально того, кто этот документ сделал нет? Или просто на скриншоте не видно?

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

Тут вообще видел новость про редактирование даты файла при проверке Казначейством. Суть коротко в том, что т.к. Казначейство смотрит на дату создания РДА, то ее можно подменить.

А Вы говорите "На уровне аудиторской программы так делать нельзя". Оказывается можно, даже еще круче фальсифицировать.

Escapist
хотя помешать пользователям изменить системную дату в операционной системе разработчик конечно не может

Не может, а даже обязан.

Если, конечно, этот разработчик не хочет лишиться лицензии. Есть требования ФСБ к лицензиатам, занимающимся разработкой собственных систем с использованием СКЗИ.
Вот неплохая статья наших партнеров на эту тему. В ней только суть, без воды.

Подмена даты документа это существенное нарушение, если вообще не преступление.

Рисковать ради непонятно чего считаю полным бредом.
Получить лицензию на этит вид деятельности реально не просто. А потерять можно за секунду. Не говоря уж о УК РФ.

Честно говоря не понял, причём здесь лицензия ФСБ. Речь про то, что пользователь меняет системную дату в Windows на дату заключения, открывает рабочий документ на редактирование в аудиторской программе и сохраняет его системной датой, которая записывается аудиторской программой, как дата последнего редактирования РД = дата его выполнения.
Вот итоге таким способом пользователь может изготавливать или существенно дорабатывать РД после даты выдачи заключения в нарушение МСА (например узнав, что он попал под внеплановую проверку). 
А уж сводный документ контролера, в который самим пользователем вносится дата проверки для таких манипуляций максимально удобен. 

Escapist
Честно говоря не понял, причём здесь лицензия ФСБ. Речь про то, что пользователь меняет системную дату в Windows на дату заключения, открывает рабочий документ на редактирование в аудиторской программе и сохраняет его системной датой, которая записывается аудиторской программой, как дата последнего редактирования РД = дата его выполнения.
Вот итоге таким способом пользователь может изготавливать или существенно дорабатывать РД после даты выдачи заключения в нарушение МСА (например узнав, что он попал под внеплановую проверку). 
А уж сводный документ контролера, в который самим пользователем вносится дата проверки для таких манипуляций максимально удобен. 

Я не про аудиторов говорил, а про разработчиков софта.
Для использования в программе СКЗИ нужно быть Лицензиатом ФСБ.

Если РДА хранится в электронном виде, а тем более, если он подписан ЭП, внесение в него изменений недопустимо.

Дата же создания файла, о которой говорите Вы, не говорит о том, когда документ создан. Это дата создания самого файла. Она может отличаться от даты формирования РДА. Конечно если речь об аудиторском ПО, а не работе в файлах изначально.

Вообще при использовании ЭП можно вообще исключить любое изменение РДА после подписания. Можно и надежную метку времени ставить. Мы метку не ставим по двум причинам:
1. В МСА нет таких требований
2. Для постановки метки нужен доступ в Интернет (она берется с сервера УЦ и вообще не может быть изменена).

Электронную подпись под электронным документом можно вообще ставить в отдельной программе, имеющей все насвете лицензии и сертификаты ФСБ, и она  будет существовать в виде отдельного файла. И потом в аудиторской программе хранить отдельно документ, отдельно его подпись. Сам электронный документ может быть создан где угодно, подписан где угодно, без всякой привязки к программе. Программа используется только как место хранения, и ей самой никакие лицензии ФСБ не нужны.

Грэг
Электронную подпись под электронным документом можно вообще ставить в отдельной программе, имеющей все насвете лицензии и сертификаты ФСБ, и она  будет существовать в виде отдельного файла. И потом в аудиторской программе хранить отдельно документ, отдельно его подпись. Сам электронный документ может быть создан где угодно, подписан где угодно, без всякой привязки к программе. Программа используется только как место хранения, и ей самой никакие лицензии ФСБ не нужны.

Аудитор, конечно, может купить, например, КриптоПро Office Signature и подписывать РДА в приложениях Word и Excel. И хранить эти документы в какой-нибудь программе ЭДО или вообще на диске в виде тех же файлов оставить.

Тогда, конечно, лицензий у разработчика места хранения быть не должно. Но речь то об аудиторском ПО.

Является ли набор файлов Word и Excel автоматизацией аудита? Убежден, что нет. Помимо хранения РДА аудиторская программа должна контролировать их неизменность и обеспечивать их взаимосвязь (данные из одного РДА должны переноситься в другой без каких либо искажений).

Можно ли обеспечить неизменность РДА и их взаимосвязь в программе, которая только хранит данные в виде файлов?

Можно ли быть уверенным в том, что данные, которые содержатся в одном РДА совпадают с теми же данными в другом? Например, как понять, что уровень существенности в РДА с расчетом существенности совпадает с другим РДА, где он сравнивается с выявленным нарушением?

Можно, конечно, сравнить эти показатели в двух РДА "вручную". А если таких РДА 100? А если их 500?

Думаю, можно сделать программу, которая будет сверять эти данные автоматически. Т.е. искать какие-то метки в этих файлах, по ним понимать, что это одни и те же данные и они должны быть равны. А если они не равны выдавать ошибку.

Т.о. получаем программу, которая формирует файлы РДА, например в формате Excel. Аудитор вносит в них какие-то данные. Подписывает их в каком-нибудь Средстве ЭП. Кладет обратно в программу. Потом запускается проверка совпадения данных.

Правда для проверки ЭП нужно опять файлы в Средство ЭП передавать. Ну эту задачу тоже можно решить.

А если и метки были нарушены, что делать? Написано в ячейке существенность, а метка удалена.

В итоге получаем программу, которая вроде работает, но уверенности все равно нет. И это я еще придумал, что эта "аудиторская" программа сверяет файлы. В реальности ни кто ни чего не сверяет.

А вот если данные РДА хранятся непосредственно в виде данных в базе самой программы, и при их изменении они меняются во всех РДА сразу (это же одни и те же данные). Даже теоретически не может быть никакого расхождения. Если при подписании РДА ЭП программа блокирует документ на изменение. Если используются алгоритмы шифрования данных при работе программы через Интернет. Ну и т.д.

Уверенности немного больше будет? Правда?

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

Эко меня бомбануло