DAILY WAGEHired TodayPaid Today

Новости

Контрольный список внутреннего аудита доступа к заработанной зарплате: 50 контрольных точек и доказательств

tat Nien Cong Ty Nhan Kiet 2019  4

Контрольный список внутреннего аудита доступа к заработанной зарплате: 50 контрольных точек и доказательств, которые необходимо сохранить

Внутренний аудит доступа к заработанной зарплате должен проверить всю цепочку правильный человек – правильная работа – правильные права – правильная сумма – правильный счёт – правильный статус – правильный период зарплаты. Каждое заключение должно основываться на отслеживаемых доказательствах, а не только на интервью или снимках интерфейса. Контрольный список из 50 контрольных точек ниже поможет компаниям построить программу регулярных проверок.

> Кратко: Проводите аудит по 10 группам, каждая из которых содержит пять контрольных точек: управление; персонал; учёт рабочего времени; формулы/лимиты; транзакции; банки; расчёт зарплаты; персональные данные; безопасность/инциденты; изменения/непрерывность бизнеса. Выбирайте образцы на основе рисков и проверяйте от исходных данных до конечного результата.

> Предупреждение: Это справочный контрольный список, а не стандарт аудита или юридическое мнение. Компании должны адаптировать его в соответствии с масштабом, контрактами, политиками, системами и фактической оценкой рисков. Наличие в коде не само по себе доказывает, что контроль работает эффективно.

1. Цели аудита

(Подробнее: Досье оценки доступа к заработанной зарплате.)

Программа должна ответить на следующие вопросы:

  1. Могут ли пользоваться только квалифицированные лица?
  2. Создаются ли доступные суммы только за выполненную и утверждённую работу?
  3. Правильно ли утверждены/применены формулы, лимиты и резервы?
  4. Есть ли защита от дублирования транзакций, ошибок в идентификации и неясных статусов?
  5. Совпадают ли банковские выписки с журналом транзакций?
  6. Поступают ли полученные суммы в правильный расчёт зарплаты и не накапливаются ли они?
  7. Обрабатываются ли персональные данные в соответствии с целями/правами?
  8. Контролируются ли инциденты и изменения?
  9. Полные и точные ли управленческие отчёты?
  10. Исправлены ли рекомендации предыдущего периода?

2. Объём и частота

Может применяться:

  • проверка перед запуском;
  • проверка через 30–90 дней;
  • регулярный квартальный/годовой аудит;
  • внеплановая проверка после инцидента;
  • ревизия перед открытием крупного клиента;
  • проверка при изменении банка, формул или расчёта зарплаты.

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

3. Выборка на основе риска

Не только случайный выбор. Выборка должна включать:

  • транзакции с большой стоимостью/близкие к лимиту;
  • людей с множеством транзакций в день/период;
  • ожидающие, неудачные, затем успешные транзакции;
  • работу, изменённую после утверждения;
  • уволенных/переведённых сотрудников;
  • работников, работающих на нескольких клиентов;
  • изменения аккаунтов/устройств;
  • транзакции вне обычного времени;
  • клиентов с высоким уровнем ошибок;
  • невозвратные суммы;
  • случайные выборки для выявления непредсказуемых отклонений.

Размер выборки должен определяться аудитором в зависимости от общего объёма и рисков, а не использовать фиксированное число для всех периодов.

4. Шкала оценки выявлений

УровеньХарактеристикаПример
СерьёзныйРиск значительных финансовых/данных потерь или сбой ключевого контроляДублирование, ошибка в идентификации, утечка ключей
ВысокийВлияние на множество людей/периодов или невозможность сверкиОшибка в формуле, отклонение в расчёте зарплаты
СреднийКонтроль есть, но работает непоследовательноЗадержка утверждения, не проверенные права
НизкийНеобходимы улучшения в документации/эффективностиНедостаток доказательств обучения

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

5. Группа 1 — Управление и политика (Контрольные точки 1–5)

Контрольный список внутреннего аудита доступа к заработанной зарплате
  1. Есть ответственный за весь процесс Service Owner.
  2. Политика доступа к заработанной зарплате действительна, имеет полномочия на утверждение и историю версий.
  3. RACI соответствует фактическим правам в системе.
  4. KPI не поощряют принуждение работников к транзакциям.
  5. Риски, исключения и действия регулярно сообщаются.

Доказательства: назначение, политика, матрица прав, протоколы собраний, дашборд, журнал рисков.

Тестирование: выберите три роли и сопоставьте права в документах с фактическими правами; проверьте, есть ли ответственный за просроченные действия.

6. Группа 2 — Список сотрудников и идентификация (6–10)

  1. Список включает только работающих сотрудников/правильных клиентов.
  2. Идентификационный номер CCCD используется как уникальный идентификатор и не дублируется.
  3. Код учёта рабочего времени привязан к правильному клиенту/месту работы.
  4. Аккаунты VPBank проверяются на соответствие владельцу перед использованием.
  5. Изменения устройств/аккаунтов или исключения утверждаются и логируются.

Доказательства: исходный файл сотрудников, журнал синхронизации, результаты аутентификации, история изменений, формы утверждения исключений.

Тестирование: выберите образцы новых сотрудников, уволенных, переведённых и изменивших устройства; проследите от исходного файла до текущих прав.

7. Группа 3 — Учёт рабочего времени и утверждение (11–15)

  1. Источник работы/ключ соединения/частота синхронизации документированы.
  2. Будущая работа и не закрытые дни не создают доступные суммы.
  3. Только уполномоченные лица могут утверждать/отклонять/изменять работу.
  4. Изменения в утверждённой работе возвращают запись в ожидание и сохраняют до/после.
  5. Ночные смены, сверхурочные, отпуска и работа в нескольких местах обрабатываются по правилам утверждения.

Доказательства: конфигурация источника, журнал импорта, список прав, журнал аудита, справочник смен/символов.

Тестирование: воспроизведите обычную смену, смену через полночь и изменённую запись; проверьте результат в доступных суммах.

8. Группа 4 — Формулы, цены, лимиты и резервы (16–20)

  1. Формулы системы соответствуют утверждённой политике.
  2. Цена/день привязана к правильному клиенту и периоду действия.
  3. Минимальные лимиты, на транзакцию, на день настроены правильно.
  4. Резерв/количество рабочих дней рассчитывается и отображается правильно.
  5. Изменения чувствительных параметров требуют двойного контроля, логируются и проверяются после изменений.

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

Тестирование: пересчитайте образец по формуле утверждённая работа × цена − получено − резерв, проверьте округление до 1 000 VND и пределы лимитов.

Стандартные значения в коде включают 50 000 VND/раз, 3 миллиона VND/транзакцию и 5 миллионов VND/человека/день; аудит должен сравнивать с фактическими применяемыми значениями, а не считать эти числа политикой.

9. Группа 5 — Инициация и обработка транзакций (21–25)

  1. Сервер проверяет все условия, а не только доверяет данным из приложения.
  2. Работник подтверждает содержание перед каждым запросом.
  3. Каждый запрос имеет стабильный код транзакции для предотвращения повторов.
  4. Есть блокировка для предотвращения двух запросов на одну и ту же доступную сумму.
  5. Только действительные ответы изменяют статус на выплачено.

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

Тестирование: попробуйте два запроса почти одновременно, запросы, превышающие лимит, без CCCD, не утверждённую работу и недействительный ответ банка в разрешённой тестовой среде.

10. Группа 6 — Банки и сверка (26–30)

(Подробнее: Сверка транзакций доступа к заработанной зарплате с расчётом зарплаты и бухгалтерией.)

  1. Сервис, управляющий банковскими ключами, отделён и имеет ограниченный доступ.
  2. Управляются исходные счета, подписанты/уполномоченные лица и лимиты расходов.
  3. Неясные статусы удерживаются в ожидании, не создавая новых запросов.
  4. Подвешенные суммы проверяются по процедуре и имеют предупреждающий возраст.
  5. Сверка выписок T+1 выполняется, расхождения утверждаются.

Доказательства: схема потока денег, матрица прав, журнал проверки, выписки с скрытыми данными, отчёт о сверке и протокол утверждения.

Тестирование: выберите все подвешенные транзакции за период и образцы успешных/неудачных; сопоставьте в обе стороны от системы к выписке и от выписки к системе.

Текущая система имеет расписание проверки каждые 5 минут и чтение выписок в 08:00 T+1. Это технические характеристики; аудит должен проверить фактическое выполнение и официальное SLA.

11. Группа 7 — Расчёт зарплаты и окончательный расчёт (31–35)

Аудит транзакций доступа к заработанной зарплате и сверка расчёта зарплаты
  1. Только успешно подтверждённые транзакции входят в общий полученный объём.
  2. Транзакции привязаны к правильному человеку, клиенту и периоду зарплаты.
  3. Рабочие дни покрыты, не переносятся на следующий период.
  4. Общая сумма транзакций совпадает с суммой на расчётном листе/выписке.
  5. Увольнения, уменьшение работы, возвраты и невозвратные суммы имеют процедуру.

Доказательства: файл транзакций, отчёт о мосте, расчёт зарплаты, образец расчётного листа, advancecovereddays, журнал невозвратных сумм.

Тестирование: повторите сверку для образца пользователей; проверьте cut-off в начале/конце периода и случай увольнения.

Не делайте выводы о вычетах/возвратах только из логики программного обеспечения; сравните с утверждённой политикой и юридическим мнением.

12. Группа 8 — Персональные данные и конфиденциальность (36–40)

(Полный каркас: см. Защита данных и конфиденциальность при внедрении доступа к заработанной зарплате.)

  1. Роли обработки, цели и категории данных задокументированы.
  2. Уведомления/согласия и права субъектов данных выполняются при применении.
  3. Доступ к CCCD, фото, GPS, аккаунтам и зарплате ограничен.
  4. Сроки хранения, удаления/анонимизации и сторонние обработчики управляются.
  5. Нарушения данных имеют процедуру обнаружения, оценки и уведомления.

Доказательства: политика, документация обработки, оценка воздействия, список сторонних обработчиков, журнал прав, доказательства удаления, протокол инцидента.

Тестирование: выберите один тип данных от сбора до удаления; выберите три внутренних аккаунта и проверьте права; проверьте журнал экспорта данных.

Текущая законодательная база включает Закон о защите персональных данных 91/2025/QH15 и Декрет 356/2025/NĐ-CP, оба вступают в силу с 01/01/2026.

13. Группа 9 — Информационная безопасность и обработка инцидентов (41–45)

(Подробнее: Уровни защиты транзакции доступа к заработанной зарплате и Как обрабатываются инциденты с доступом к заработанной зарплате.)

  1. Управление уязвимостями, патчами и тестирование безопасности.
  2. Секреты/ключи хранятся, передаются и отзываются безопасно.
  3. Важные журналы защищены, синхронизированы по времени и имеют предупреждения.
  4. Инциденты P1–P4 имеют Incident Commander, эскалацию и RCA.
  5. Аварийный выключатель контролируется и тестируется.

Доказательства: отчёты сканирования/пентеста, журнал активов, политика ключей, предупреждения, тикеты инцидентов, RCA, протоколы тестирования.

Тестирование: выберите закрытый инцидент и проверьте временную шкалу; подтвердите завершение действий RCA; проверьте, что у уволенных сотрудников нет доступа к чувствительным данным.

Количество тестовых файлов не заменяет независимое тестирование безопасности или доказательства операционного контроля.

14. Группа 10 — Изменения, BCP/DR и завершение услуги (46–50)

  1. Все релизы/конфигурации имеют запрос, утверждение, тестирование и откат.
  2. Разделение обязанностей между разработчиком, утверждающим и внедряющим соответствует рискам.
  3. Резервное копирование, RTO/RPO и восстановление тестируются.
  4. Зависимости от банка/ERP/Sheet/VietQR имеют планы на случай перебоев.
  5. Завершение услуги включает экспорт/возврат/удаление данных и отзыв прав.

Доказательства: тикеты изменений, журнал развертывания, протоколы резервного копирования и восстановления, планы BCP/DR, результаты тестирования, контрольный список завершения работы с поставщиком.

Тестирование: выберите одно срочное изменение и одно обычное; проверьте наличие пост-аудита. Выберите резервную копию и проверьте доказательства восстановления, а не только статус "резервное копирование успешно".

15. Рекомендуемые аудиторские техники

Прохождение

Выберите транзакцию и следуйте вместе с владельцем процесса от работы до расчётного листа.

Повторное выполнение

Пересчитайте доступные суммы и общую сверку из исходных данных.

Инспекция

Проверьте конфигурации, журналы, утверждения и документацию.

Наблюдение

Наблюдайте за пользователем/мониторингом обработки исключения.

Подтверждение

Подтвердите баланс/статус с независимым источником, например, банковской выпиской.

Анализ данных

Сканируйте весь объём для поиска дублирующихся кодов, превышения лимитов, транзакций вне времени, изменений работы после выплаты или отклонений в расчёте зарплаты.

Интервью только показывает, как описан процесс; недостаточно для доказательства его работы.

16. Пример рабочей таблицы аудита

ПолеСодержание
Код контроляC01–C50
ЦельКакой риск контролируется
ВладелецОтветственное лицо
ДизайнПодходит ли контроль
ОперацияРаботает ли в периоде
Общий/образецРазмер и способ выбора
ДоказательстваСсылка или код документа
ИсключениеКоличество/значение/влияние
ЗаключениеЭффективно/неэффективно/частично
ДействиеОтветственный и срок

17. Рекомендуемые запросы данных

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

Запросы должны быть протестированы, чтобы избежать ложных срабатываний, и выполняться в пределах прав доступа к данным.

18. Как писать аудиторские выводы

Хороший вывод состоит из пяти частей:

  1. Критерий: что требует политика/контракт/контроль.
  2. Фактическое состояние: что показывают доказательства.
  3. Причина: почему контроль не работает.
  4. Влияние: деньги, люди, данные, юридические, операционные.
  5. Рекомендация: конкретные действия, ответственный и срок.

Пример, которого следует избегать: "Необходимо усилить контроль."
Пример лучше: "Из 25 выбранных изменений лимитов, 4 изменения не имели независимого утверждения. Добавьте обязательное утверждение двойным контролем в системе до..."

Не публикуйте реальные примеры, если они не анонимизированы и не разрешены.

19. Мониторинг исправлений

Каждое действие должно иметь:

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

Не закрывайте выявления только из-за наличия плана; необходимо проверить доказательства внедрения и эффективность после исправления.

20. Часто задаваемые вопросы

Означает ли наличие в коде, что контроль уже эффективен?

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

Сколько транзакций следует аудировать?

Зависит от общего объёма, рисков и целей. Используйте выборку на основе риска, случайную и анализ всех данных, когда это возможно.

Кто не должен сам аудировать свою операцию?

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

Является ли подвешенная транзакция ошибкой?

Не обязательно. Необходимо проверить, удерживает ли система безопасное ожидание, проверяет ли в срок и не дублирует ли расходы.

Нужно ли отдельно аудировать персональные данные?

Можно объединить или разделить, но необходимо иметь достаточную экспертизу и объём в соответствии с действующим законодательством/политиками.

21. Заключение

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

Официальные источники

---

Автор: Nguyen Minh Khang — Chuyên viên ban chiến lược, Nhan Kiet Manpower Supply Co., Ltd.

Консультации по решениям доступа к заработанной зарплате для бизнеса: Горячая линия 0937.022.655 · Email info@nhankiet.vn · Доступ к заработанной зарплате для бизнеса

Новости