Англійська мова для IT аудиторських аналітиків: написання висновків, доказів і планів відновлення
Вивчіть англійську лексику і структуру для написання результатів аудиту IT, документування доказів і створення чітких планів усунення для відповідності SOX і ISO 27001.
Всі інші значення: точність — точність
Звіти про аудит IT мають прямі наслідки — вони впливають на регуляторні рішення, виконавчі дії, а іноді й судові процеси. Написати їх чітко і точно англійською не є обов’язковим. У цьому довіднику описано структуру результатів аудиту, словник доказів, мову плану усунення порушень, а також ключові терміни, з якими ви зіткнетеся під час аудиту SOX і ISO 27001.
4-й розділ — про структуру
Кожен добре написаний аудиторський висновок має стандартну структуру з чотирьох частин. Знаючи цю структуру — і словниковий запас, пов’ язаний з кожною частиною — ви зможете писати висновки, які будуть ясними, захисними і дійсними.
Перша умова
Умова це те, що ви знайшли - фактичне спостереження. Напиши його простою, конкретною мовою. Не роби висновків і не звинувачуй на цьому етапі.
Журнали доступу до системи фінансової звітності показали, що 14 облікових записів користувачів зберігали підвищені привілеї протягом більш ніж 90 днів після зміни ролі користувачів
Критерії
** Критерій ** є стандартом, політикою або контрольною метою, з якою порівнюється умова. Це твердження “що повинно бути”.
«За політикою управління доступом організації (v2.3), підвищені привілеї повинні бути скасовані протягом п’яти робочих днів після зміни ролі»
Причина
** Причина ** пояснює, чому існує умова. Причини, як правило, пов’язані з прогалинами процесу, відсутністю автоматизації, неясним правом власності або відсутніми засобами контролю.
«Процес перегляду доступу покладається на вручну повідомлення з системи HR, яка не генерує автоматизовані попередження, коли записуються зміни ролей»
4. Ефект
Ефект описує ризик або вплив, що виникає в результаті стану — що могло піти не так, або що пішло не так, як результат.
«Збережений підвищений доступ збільшує ризик несанкціонованого зміни фінансових даних, що може вплинути на цілісність регуляторних звітів»
Довідковий словник
** Доказами ** в аудиті є інформація, зібрана для підтримки висновків і висновків. Різні види доказів мають різну вагу.
** Документальні докази ** — письмові записи, такі як правила, контракти, знімок вікна налаштування або листування електронною поштою. « Ми отримали документальні докази у вигляді журналу запитів на забезпечення доступу, який було експортовано з системи ITSM. »
** Свідчення** — свідчення, отримані під час інтерв’ ю з працівниками. « Свідчення системного адміністратора підтверджують, що процес вручну перегляду в останній раз було виконано у 3- ю кварталі попереднього року. »
** Спостереження ** — докази, зібрані шляхом спостереження за процесом або безпосереднього вивчення системи. « Через безпосереднє спостереження за процесом управління змінами, аудитор помітив, що кроки рецензування були обійняті під тиском часу. »
** Населення** — повний набір елементів, з яких буде складено вибірку для аудиту. « Населенням для цього контрольного тесту було всі 342 облікових записів користувачів з доступом до виробничої бази даних. »
** Вибірка ** — підмножина населення, обраного для тестування. « Випадкову вибірку з 25 облікових записів було обрано для детального перегляду прав доступу. »
Редагування мов програмування
План ліквідації описує, як управління буде розглядати виявлення. Як аналітик аудиту, ви можете писати ці документи від імені керівництва або планів перегляду, надісланих власником контролю.
** Ключові фрази: **
- Менеджмент погоджується з висновками і впровадить наступні виправлення дій
- «Коренева причина була визначена як [причина]; усунення буде спрямовано на це [дією]»
- “Цільова дата відновлення - [дата], залежно від наявності ресурсів.”
- «Компенсаційні заходи контролю будуть введені до [дати] для зменшення ризику в проміжний період»
- Процес буде відстежуватися в реєстрі ризиків і переглянутий на наступному квартальному засіданні аудиторського комітету
Система управління якістю ISO 27001
SOX (Закон Сарбейнса-Окслі) — законодавство США, що вимагає сильного внутрішнього контролю над фінансовою звітністю. IT-системи, що обробляють фінансові дані, підпадають під сферу застосування SOX. Ключові терміни: ITGC (IT General Controls), розділення обов’язків, контроль управління змінами, логічний контроль доступу.
ISO 27001 — міжнародний стандарт для систем управління інформаційною безпекою. Ключові терміни: Заява про застосовність (SoA), план управління ризиками, контроль за додатком A, невідповідність, виправні дії.
** Об’ єкт контролю ** — мета або завдання, для досягнення якого розроблено об’ єкт контролю. « Об’ єктом контролю є забезпечення того, щоб лише уповноважені особи могли схвалювати зміни до систем виробництва »
** Невідповідність ** — у ISO 27001, нездатність виконати вимогу стандарту. « Відсутність формального інвентарного переліку активів є невідповідністю до пункту 8. 1 ISO 27001. »
П’ять прикладів речення
- «Умови, визначені під час польової роботи, полягають у тому, що перегляди привілеїв доступу для системи ERP не були виконані протягом періоду аудиту»
- «За ISO 27001 Додаток A Контроль 9.2.5, привілейовані права доступу повинні переглядатись через регулярні проміжки часу, які політика організації визначає як квартальні»
- «Причиною недоліку була відсутність автоматизованого потоку роботи для планування і доказових переглядів доступу в платформі ITSM»
- «Менеджмент погодився реалізувати автоматизовану кампанію сертифікації доступу до кінця Q2, з CISO як призначеним власником контролю»
- «Документальні докази у вигляді підписаних записів схвалення були отримані для всіх 25 вибіркових запитів на зміни, що підтверджує ефективність контролю»
Останній звук в тоні
Звіти про аудит повинні бути ** фактичними, об’єктивними і професійними **. Уникайте мови, яка звучить обвинувачуючим чи спекулятивним. Написати « журнал не містив доказів затвердження » замість « ніхто не затвердив цю зміну ». Нехай факти говорять, а керівництво інтерпретує причини і намір. Цей підхід робить ваші висновки важче спростувати і будує довгострокове довір’я з аудиторами.
Навигація нюансів: спільні пастки і оновлені фрази
Для нерідних носіїв, переклад технічних концепцій на поліровану професійну англійську мову може бути значною перешкодою в контексті аудиту ІТ. Це не просто про точне описання того, що ви знайшли; це про те, щоб зробити це з ясністю, точністю і тоном, який демонструє як експертизу, так і відповідальність. Поширеною помилкою є надмірно буквальні переклади - прийняття прямого перекладу технічного терміну без урахування очікуваного розуміння вашої аудиторії. Наприклад, просто сказати «Система виявляла витоки пам’яті» може бути цілком прийнятним в деяких контекстах, але в звіті аудиту, що вимагає відповідності SOX, це потребує більшого контексту. Аналогічно, сильна залежність від пасивного голосу може затемнити відповідальність і ускладнити відстеження елементів дії.
Розглянемо реалістичний сценарій: ви пишете коментар для запитів на витягнення, пов’ язаних з вразливістю, виявленою під час оцінки безпеки. Замість написання «Вразливість була виявлена командою», що є пасивним і неясним, більш ефективним підходом буде «Команда виявила потенційну вразливість введення SQL в модулі автентифікації користувача. Під час подальшого розслідування виявлено недостатній контроль перевірки введення, що призвело до ризику несанкціонованого доступу до даних. “Зауважте, як це переглянуте речення чітко говорить * хто * знайшов це (команда), вказує * що * було знайдено (вразливість введення SQL і відсутність перевірки введення), і відразу підкреслює пов’ язаний з цим ризик. Іншою частою проблемою є надмірне використання складного словникового запасу; простіша, пряма мова часто передає значення ефективніше. Замість того, щоб сказати « Налаштування системи відхилялися від встановлених стандартів », спробуйте сказати « Налаштування системи не відповідали нашим правилам безпеки »
Крім того, структурування ваших результатів для максимального впливу передбачає використання послідовної структури. Хорошою початковою точкою є формат «Проблема», «Вплив» і «Рекомендація» — часто скорочується як IIR. Це забезпечує чітку розповідь: “Проблема: Недостатня практика ведення журналу була спостерігана в конфігурації сервера бази даних… Вплив: Ця відсутність детальних журналів ускладнює відстеження діяльності користувача і дослідження потенційних порушень безпеки… Рекомендація: Впровадити всебічне ведення журналу, включаючи записи з часом всіх операцій з базою даних, щоб полегшити судовий аналіз. » Використання цієї структури послідовно у звітах і повідомленнях забезпечує ясність і полегшує ефективне усунення порушень. Нарешті, завжди ретельно перечитуйте – невелика граматична помилка може підірвати довіра до ваших висновків, особливо при спілкуванні з старшими зацікавленими сторонами або регуляторними органами.