Artykuł nr 31, Kategoria: Metody audytu i kontroli

Finding Register – jak prowadzić rejestr ustaleń audytowych i nie zgubić żadnej poprawki?

Audyt wykrył 27 problemów.

Dokument wrócił do autorów.

Rozpoczęły się poprawki.

Pierwszy finding został poprawiony bezpośrednio w Wordzie.

Drugi omówiono telefonicznie.

Przy trzecim ktoś napisał:

„zrobione”.

Czwarty przeniesiono do Excela.

Piąty miał poprawić inny dział.

Po tygodniu dokument wygląda lepiej.

Ale pojawia się podstawowe pytanie:

Które z 27 problemów zostały rzeczywiście usunięte, które tylko zmieniono, a które nadal istnieją?

Jeżeli odpowiedzi trzeba szukać:

w komentarzach Worda;
w kilku wiadomościach e-mail;
na czacie;
w pamięci członków zespołu;
w różnych wersjach pliku;

to audyt zaczyna tracić kontrolę nad własnym wynikiem.

Dlatego po wykryciu problemu potrzebny jest Finding Register – rejestr ustaleń audytowych.

Nie chodzi o dodatkową tabelę „dla porządku”.

Chodzi o stworzenie jednego miejsca, w którym można odtworzyć pełny cykl życia każdego ustalenia:

co znaleziono → na jakiej podstawie → kto odpowiada → co poprawiono → jak sprawdzono poprawkę → czy problem rzeczywiście został zamknięty.

Finding nie powinien żyć tylko w komentarzu Worda

Komentarz:

„wartość się nie zgadza”

jest przydatny podczas pracy.

Nie jest jednak kompletnym zapisem audytowym.

Po zmianie dokumentu komentarz może:

zniknąć;
zostać usunięty;
utracić kontekst;
odnosić się do strony, która już nie istnieje.

Finding Register pozwala oddzielić:

ustalenie

od:

miejsca, w którym zostało znalezione.

To ważne, ponieważ problem może później:

przemieścić się;
propagować do innych dokumentów;
zostać częściowo poprawiony;
ponownie pojawić się w kolejnej wersji.

Co mówią aktualne standardy audytu?

Global Internal Audit Standards 2024 The Institute of Internal Auditors wymagają, aby potencjalne findings były oceniane pod kątem znaczenia, skutków i ryzyka, a następnie odpowiednio priorytetyzowane. Standard 14.4 przewiduje również pracę nad rekomendacjami lub action plans prowadzącymi m.in. do usunięcia różnicy pomiędzy kryterium i stanem faktycznym, ograniczenia ryzyka oraz – tam gdzie to możliwe – zaadresowania przyczyny źródłowej. (theiia.org)

Jeszcze ważniejszy z punktu widzenia prowadzenia rejestru jest Standard 15.2. Wymaga on potwierdzania realizacji rekomendacji lub planów działań według ustalonej metodologii, obejmującej m.in. śledzenie postępu, risk-based follow-up oraz aktualizowanie statusu działań w systemie trackingowym. (theiia.org)

To bardzo ważna zasada:

finding nie kończy się w chwili wysłania raportu.

Kończy się dopiero wtedy, gdy organizacja potrafi wykazać, co się z nim stało.

„Poprawione” i „zamknięte” to dwa różne statusy

Załóżmy:

Finding:

w raporcie znajduje się koszt 14,2 mln zł zamiast 18,2 mln zł.

Autor zmienia liczbę.

Czy finding jest zamknięty?

Jeszcze nie wiadomo.

Trzeba sprawdzić:

executive summary;
tabelę kosztów;
wykres;
model finansowy;
rekomendację;
prezentację zarządczą.

Jeżeli wszystkie zależne miejsca nadal korzystają ze starej wartości:

poprawiono komórkę,

ale:

nie zamknięto problemu.

Dlatego bezpieczniejsza sekwencja to:

OPEN → ACTION TAKEN → RETEST → CLOSED

a nie:

OPEN → DONE

Finding Register 360 – autorski model Expert Design

Do zarządzania ustaleniami można zastosować:

SIGNAL → CANDIDATE → VERIFIED → FINDING → OWNER → ACTION → RETEST → CLOSED

To Finding Register 360.

Nie jest oficjalnym standardem IIA ani ISO.

Jest praktycznym modelem pozwalającym zachować pełny ślad od pierwszego sygnału aż do potwierdzonego zamknięcia problemu.

ETAP 1. SIGNAL – coś wygląda podejrzanie

Przykład:

W raporcie:

18 miesięcy.

W harmonogramie:

24 miesiące.

Na tym etapie nie powinniśmy jeszcze pisać:

„błąd krytyczny”.

Mamy:

SIGNAL

czyli anomalię wymagającą wyjaśnienia.

Możliwe, że:

dokumenty dotyczą innych okresów;
jedna wersja jest archiwalna;
jeden termin obejmuje dodatkowy etap.

Signal jest więc:

punktem startowym.

Nie finalnym findingiem.

ETAP 2. CANDIDATE – problem wygląda wiarygodnie

Po wstępnej kontroli ustalamy:

oba dokumenty dotyczą tego samego etapu;
oba są częścią finalnego corpus;
różnica nie wynika z jednostki ani definicji.

Teraz problem staje się:

FINDING CANDIDATE

To nadal ważne rozróżnienie.

Dopóki nie sprawdzimy:

źródła prawdy;
hierarchii dokumentów;
możliwego wyjątku;

nie powinniśmy nadawać mu finalnej oceny.

ETAP 3. VERIFIED – dowód potwierdzony

Załóżmy, że projekt umowy wskazuje:

24 miesiące

i jest dokumentem nadrzędnym.

Raport:

18 miesięcy.

Mamy już:

kryterium;
condition;
różnicę;
dowód.

Status:

VERIFIED

Teraz można utworzyć formalny finding.

ETAP 4. FINDING – ustalenie musi być opisane tak, aby dało się je później odtworzyć

Dobry finding powinien odpowiedzieć przynajmniej na kilka pytań:

co znaleziono?
gdzie?
względem jakiego kryterium?
jaki jest dowód?
jaki może być skutek?
jakie jest znaczenie?

Nie:

„termin jest błędny”.

Lepiej:

W raporcie głównym wskazano okres realizacji 18 miesięcy, podczas gdy §7 aktualnego projektu umowy przewiduje 24 miesiące. Rozbieżność dotyczy tego samego zakresu realizacji i może prowadzić do różnej interpretacji harmonogramu przez odbiorców.

Teraz finding:

jest audytowalny.

Anatomy of a Finding

Można zastosować strukturę:

CRITERION → CONDITION → GAP → IMPACT → EVIDENCE

Criterion

Jak powinno być?

Condition

Jak jest?

Gap

Na czym polega różnica?

Impact

Dlaczego ma znaczenie?

Evidence

Na czym opieramy ustalenie?

Przykład

Criterion

Projekt umowy §7: 24 miesiące.

Condition

Raport, str. 18: 18 miesięcy.

Gap

Różnica 6 miesięcy.

Impact

Możliwa niespójność w planowaniu i komunikacji zakresu.

Evidence

Finalne wersje obu dokumentów.

Taki finding nie wymaga pamięci osoby, która go znalazła.

Może zostać zweryfikowany przez inną osobę.

ETAP 5. OWNER – finding bez właściciela prawdopodobnie zostanie niczyj

To jeden z najczęstszych problemów.

Rekomendacja:

„poprawić”.

Kto?

autor raportu?
finanse?
dział prawny?
project manager?
klient?

Jeżeli nie ma jednoznacznego właściciela:

odpowiedzialność rozmywa się.

Dlatego każdy finding wymagający działania powinien mieć:

OWNER

czyli konkretną osobę albo funkcję odpowiedzialną za doprowadzenie działania do końca.

Owner nie musi sam wykonywać poprawki

To istotne.

Owner:

odpowiada za zamknięcie.

Może delegować wykonanie.

Przykład:

Project Manager – owner.

Poprawkę Excela wykonuje:

analityk finansowy.

Ale to PM ma dopilnować:

wykonania;
zgodności;
przekazania materiału do retestu.

„Zespół” jest słabym ownerem

Pole:

Owner: zespół projektowy

często oznacza:

nikt konkretny.

Lepiej:

Owner: Dyrektor projektu

albo:

Owner: właściciel procesu finansowego.

Jedna funkcja.

Jedna odpowiedzialność.

ETAP 6. ACTION – trzeba zapisać, co zostanie zrobione

Finding:

różne terminy.

Action:

„poprawić dokument”.

Za mało.

Lepszy action plan:

Ustalić obowiązujący termin na podstawie zatwierdzonego harmonogramu i projektu umowy, a następnie zaktualizować wszystkie wystąpienia w raporcie i materiałach zależnych.

To jest:

konkretne;
mierzalne;
możliwe do retestu.

Recommendation ≠ Action Plan

Warto je rozróżniać.

Recommendation

Audytor może wskazać:

ujednolicić termin we wszystkich dokumentach zgodnie z dokumentem nadrzędnym.

Action Plan

Owner może zdecydować:

do 5 października PM potwierdzi termin z właścicielem umowy, następnie redaktor zaktualizuje raport i prezentację.

IIA w Standardzie 14.4 rozróżnia rekomendacje audytora i działania podejmowane przez management, podkreślając również potrzebę oceny, czy planowane działania rzeczywiście odpowiadają na zidentyfikowane ryzyko i przyczynę problemu. (theiia.org)

Poprawka powinna adresować przyczynę, nie tylko objaw

Załóżmy, że znaleziono:

pięć różnych terminów.

Można poprawić pięć pól.

Ale dlaczego powstały?

Możliwe przyczyny:

brak source of truth;
brak kontroli wersji;
ręczne przepisywanie;
nieaktualne załączniki.

Jeżeli poprawimy tylko wartości:

obecny dokument będzie lepszy.

Jeżeli poprawimy przyczynę:

zmniejszymy ryzyko powtórzenia problemu.

Root Cause nie należy jednak wymyślać

Nie każda niezgodność daje od razu podstawę do stwierdzenia:

„przyczyną był brak procedury”.

Możliwe, że:

procedura istnieje;
nie została zastosowana;
błąd był jednostkowy.

Dlatego warto rozróżniać:

OBSERVED CAUSE

od:

HYPOTHESIZED CAUSE

ETAP 7. RETEST – najważniejsza kontrola po poprawce

Owner pisze:

„poprawione”.

Audytor nie powinien odpowiadać automatycznie:

CLOSED.

Najpierw:

RETEST

czyli ponowne wykonanie adekwatnego testu.

Retest powinien sprawdzać nie tylko miejsce pierwotnego błędu

Jeżeli problem był lokalny:

retest może być lokalny.

Jeżeli problem propagował:

retest musi objąć zależności.

Przykład:

zmieniono:

CAPEX 14 mln → 18 mln.

Retest:

model;
raport;
tabela;
executive summary;
NPV;
rekomendacja.

Nie tylko:

czy komórka zawiera teraz 18.

Fix Test i Impact Test

Warto rozdzielić:

Fix Test

Czy wskazany problem został poprawiony?

Impact Test

Czy poprawka prawidłowo przeszła przez elementy zależne?

Dopiero:

PASS + PASS

pozwala rozważyć zamknięcie.

ETAP 8. CLOSED – finding ma dowód zamknięcia

Status CLOSED powinien oznaczać:

poprawka została wykonana i zweryfikowana.

Nie:

ktoś napisał, że została wykonana.

Dlatego przy zamknięciu warto zapisać:

wersję pliku;
datę retestu;
osobę retestującą;
evidence closure;
wynik.

Closed Evidence

Przykład:

Raport v12, str. 18 = 24 miesiące; harmonogram v5 = 24 miesiące; umowa v9 = 24 miesiące; cross-document test PASS, 06.10.2026.

To jest:

dowód zamknięcia.

Finding Register 360 – minimalny zestaw pól

Pole	Po co?
Finding ID	jednoznaczna identyfikacja
Tytuł	szybkie rozpoznanie
Status	etap cyklu życia
Lokalizacja	gdzie wykryto
Criterion	jak powinno być
Condition	jak jest
Evidence	dowód
Materiality	znaczenie
Owner	odpowiedzialność
Action Plan	sposób naprawy
Due Date	termin
Retest	wynik ponownej kontroli
Closure Evidence	dowód zamknięcia

To wystarcza do większości audytów dokumentowych.

Finding ID powinien pozostać niezmienny

Przykład:

F-001

Nie zmieniamy go po poprawce na:

F-001A
F-001-FIX
NEW-F001

Ten sam problem powinien zachować:

swoją tożsamość.

Może natomiast mieć historię statusów.

Finding History

Przykład:

Data	Status
01.10	CANDIDATE
02.10	VERIFIED
03.10	OPEN
06.10	ACTION TAKEN
07.10	RETEST FAIL
09.10	ACTION TAKEN
10.10	CLOSED

To pokazuje prawdziwy przebieg.

Nie tylko:

końcowy wynik.

Dlaczego historia jest ważna?

Bo po miesiącu można zapytać:

dlaczego finding zamykano dwa razy?

Historia pokaże:

pierwsza poprawka była nieskuteczna.

To cenna informacja o:

procesie;
jakości remediation;
możliwej przyczynie systemowej.

Nigdy nie kasuj findingu tylko dlatego, że okazał się false positive

To bardzo ważna zasada metodologiczna.

Załóżmy:

Signal:

90 vs 120 dni.

Po weryfikacji:

90 dni = realizacja;
120 dni = realizacja + odbiór.

Nie ma sprzeczności.

Czy rekord należy usunąć?

Nie musi.

Lepszy status:

FALSE POSITIVE – CLOSED

Dlaczego?

Bo później można wykazać:

problem został zauważony;
sprawdzony;
świadomie odrzucony.

To chroni przed ponownym badaniem tej samej anomalii.

False Positive Register może być niezwykle wartościowy

Bez niego kolejny reviewer może ponownie zgłosić:

dokładnie ten sam problem.

A zespół zaczyna całą analizę od początku.

Status:

REJECTED / FALSE POSITIVE

z dowodem:

pozwala oszczędzić czas.

Nie każdy finding musi mieć rekomendację

Przykład:

Finding:

nie można zweryfikować źródła danych historycznych.

Audytor może nie wiedzieć:

jak organizacja ma je odzyskać.

Wtedy zamiast wymyślać sztuczną rekomendację można wskazać:

EVIDENCE GAP wymagający decyzji ownera.

To uczciwsze.

Finding Register powinien rozróżniać problem i decyzję biznesową

Przykład:

Finding:

wymaganie bezpieczeństwa podniesie koszt o 400 tys. zł.

To niekoniecznie błąd.

Może wymagać:

management decision

czy organizacja akceptuje koszt.

Status może być:

DECISION REQUIRED

a nie:

FAIL.

Przydatne statusy Finding Register

Możliwy zestaw:

SIGNAL
CANDIDATE
VERIFIED
OPEN
ACTION AGREED
IN PROGRESS
ACTION TAKEN
RETEST REQUIRED
RETEST FAIL
CLOSED
FALSE POSITIVE
ACCEPTED RISK
DECISION REQUIRED
ON HOLD

Nie zawsze potrzebujemy wszystkich.

Ale warto unikać systemu:

OPEN / CLOSED

dla całej rzeczywistości.

Co oznacza ACCEPTED RISK?

Czasami organizacja świadomie nie usuwa problemu.

Przykład:

Finding:

część procesu pozostaje manualna.

Remediation kosztowałaby:

500 tys. zł.

Management może zdecydować:

ryzyko akceptujemy.

Wtedy finding nie powinien zniknąć.

Status:

ACCEPTED RISK

z informacją:

kto zaakceptował;
kiedy;
na jaki okres;
jakie warunki obowiązują.

Global Internal Audit Standards przewidują również mechanizmy komunikowania sytuacji, w których management akceptuje ryzyko mogące przekraczać ustalone tolerancje organizacji. (theiia.org)

Accepted Risk ≠ Closed as Fixed

To dwie zupełnie różne rzeczy.

CLOSED – FIXED

problem usunięto.

CLOSED – ACCEPTED RISK

problem pozostaje, ale został świadomie zaakceptowany.

Jeżeli oba statusy sprowadzimy do:

CLOSED

po kilku miesiącach nie będzie wiadomo:

co naprawdę naprawiono.

Due Date – termin powinien wynikać z ryzyka

W guidance IIA dotyczącym komunikowania wyników i action plans wskazuje się m.in. na znaczenie odpowiedzialnej osoby oraz terminu realizacji, przy czym adekwatność terminu powinna uwzględniać poziom ryzyka. (theiia.org)

To bardzo logiczne.

Finding HIGH przed publikacją jutro:

termin poprawki = dzisiaj.

Finding LOW dotyczący wewnętrznej procedury:

może mieć dłuższy deadline.

Nie wszystkie findingi potrzebują:

„natychmiast”.

Overdue nie oznacza automatycznie, że finding jest gorszy

Ale oznacza:

plan działania nie został wykonany zgodnie z założeniem.

Dlatego Finding Register powinien umożliwiać filtrowanie:

po due date;
po ownerze;
po materiality;
po statusie.

Aging – jak długo finding pozostaje otwarty?

Przy większej liczbie ustaleń warto monitorować:

Finding Age

czyli czas od otwarcia.

Przykład:

Finding	Wiek
F-01	3 dni
F-02	28 dni
F-03	141 dni

Stary finding HIGH powinien zwrócić uwagę.

Ale nie dlatego, że:

liczba dni automatycznie zwiększa severity.

Tylko dlatego, że:

organizacja długo pozostaje wystawiona na zidentyfikowane ryzyko.

Rejestr może ujawnić problemy systemowe, których nie widać w pojedynczym findingu

Załóżmy:

20 findingów.

Z tego:

11 dotyczy wersjonowania;
5 źródeł;
4 liczb.

Każdy finding osobno wygląda inaczej.

Ale analiza rejestru pokazuje:

55% problemów powstaje wokół kontroli wersji.

Możliwe, że największym problemem nie jest więc:

11 różnych błędów.

Tylko:

jeden słaby proces zarządzania wersjami.

Finding Clustering

Można grupować ustalenia według:

root cause;
procesu;
typu dokumentu;
właściciela;
klasy błędu.

Przykład:

Klaster	Findings
Version Control	11
Source Traceability	5
Calculations	4
Requirements	3

To pomaga przejść od:

korekty pojedynczych objawów

do:

usprawnienia procesu.

ISO 9001:2026 – aktualny kontekst jakościowy

16 września 2026 r. ISO opublikowało ISO 9001:2026, które zastąpiło ISO 9001:2015 jako aktualne wydanie standardu dotyczącego systemów zarządzania jakością. Nowa edycja zachowuje nacisk m.in. na podejście procesowe, risk-based thinking, ocenę wyników oraz ciągłe doskonalenie. ISO opisuje również znaczenie monitorowania i analizowania skuteczności systemu oraz wykorzystywania wyników do poprawy. (iso.org)

Finding Register nie jest wymaganym przez ISO „formularzem”.

Ale logika:

problem → działanie → weryfikacja → poprawa procesu

dobrze wpisuje się w systemowe podejście do jakości.

Rejestr nie powinien być listą kar

Jeżeli Finding Register zaczyna służyć przede wszystkim do:

wskazywania winnych,

zespół może zacząć:

ukrywać problemy;
negocjować wording;
unikać zgłaszania nowych sygnałów.

Lepsza funkcja rejestru brzmi:

kontrola ryzyka i procesu naprawczego.

Owner odpowiada za działanie.

Nie musi być:

osobą, która spowodowała problem.

Root Cause bez blame culture

Przykład:

Problem:

nieaktualny załącznik.

Słaby root cause:

„Jan nie dopilnował”.

Lepsza analiza:

brak jednoznacznego źródła wersji finalnej i brak bramki publikacyjnej.

Osoba może popełnić błąd.

Ale proces powinien być zaprojektowany tak, aby:

pojedynczy błąd człowieka nie przechodził bez kontroli.

Jak wygląda Finding Register w praktyce?

Minimalna wersja może być bardzo prosta:

ID	Finding	Materiality	Owner	Action	Due	Status
F01	CAPEX niespójny	HIGH	Finanse	przeliczenie	05.10	RETEST
F02	termin 90/120	HIGH	PM	ujednolicić	06.10	OPEN
F03	brak źródła	MODERATE	Analityk	dodać źródło	10.10	IN PROGRESS
F04	literówka	LOW	Redakcja	poprawić	10.10	CLOSED

Przy większym audycie dokładamy:

evidence;
root cause;
history;
retest;
closure.

Jedna tabela nie zawsze wystarczy

Przy złożonym audycie można mieć:

Finding Register

jeden rekord na finding.

Evidence Register

dowody.

Action Register

działania.

Change Log

zmiany dokumentu.

Retest Log

wyniki ponownych testów.

Ale klucz musi pozostać wspólny:

Finding ID

Np.:

F-017

pojawia się we wszystkich rejestrach.

To zachowuje traceability.

Finding ID powinien towarzyszyć poprawce w dokumencie

Jeżeli poprawka jest wykonywana w Wordzie:

komentarz: F-017.

W Excelu:

notatka: F-017.

W changelogu:

F-017.

W retest log:

F-017.

Wtedy można przejść:

finding → poprawka → wersja → retest

bez zgadywania.

Wersja dokumentu jest częścią dowodu zamknięcia

Nie wystarczy:

„sprawdziłem i jest dobrze”.

Pytanie:

w której wersji?

Jeżeli retest przeprowadzono na:

v8,

a klient opublikował:

v9,

wynik nie musi automatycznie dotyczyć v9.

Dlatego closure evidence powinno wskazywać:

nazwę pliku;
wersję;
datę;
ewentualnie hash przy materiałach wysokiego ryzyka.

Finding może zostać ponownie otwarty

Przykład:

F-014:

CLOSED.

Po kolejnej zmianie dokumentu problem wraca.

Nie trzeba tworzyć:

F-099.

Można zastosować:

REOPENED

i zachować historię.

To pokazuje:

regresję.

Reopened finding jest bardzo cennym sygnałem

Jeżeli ten sam problem wraca kilka razy:

remediation może być wyłącznie objawowa.

Przykład:

termin wielokrotnie wraca do starej wartości.

Możliwa przyczyna:

aktualizowane są różne kopie dokumentu.

Wtedy potrzebne jest:

rozwiązanie systemowe.

„Resolved” może znaczyć coś innego niż „Closed”

Przydatne rozróżnienie:

RESOLVED

ustalono rozwiązanie / działanie wykonano.

CLOSED

audyt potwierdził skuteczność.

To eliminuje częsty problem:

wykonawca zamyka własny finding.

Separation of Duties przy high-risk findings

Przy problemach wysokiego ryzyka warto rozważyć:

osoba wykonująca poprawkę ≠ osoba wykonująca retest.

Nie zawsze jest to konieczne.

Ale zwiększa niezależność kontroli tam, gdzie:

koszt błędu jest wysoki;
finding wpływa na decyzję;
wcześniejsze poprawki były nieskuteczne.

Risk-Based Follow-Up

Nie każdy finding wymaga identycznego retestu.

IIA w Standardzie 15.2 wskazuje na risk-based approach do follow-upu. (theiia.org)

W praktyce:

HIGH

pełny retest + dependencies.

MODERATE

retest obszaru.

LOW

potwierdzenie poprawki może być prostsze.

To pozwala wykorzystać zasoby proporcjonalnie do ryzyka.

Nie zamykaj findingu na podstawie screenshota, jeśli potrzebny jest test

Przykład:

Owner przesyła zrzut:

„teraz jest 24”.

Ale finding dotyczył:

niespójności w pięciu dokumentach.

Screenshot jednej strony nie potwierdza:

pełnego zamknięcia.

Dowód powinien odpowiadać:

zakresowi findingu.

Closure Evidence Quality Gate

Przed zamknięciem warto zapytać:

Czy wykonano uzgodnione działanie?
Czy dotyczy właściwej wersji?
Czy pierwotna niezgodność zniknęła?
Czy zależności również zostały poprawione?
Czy poprawka nie stworzyła nowego problemu?
Czy istnieje dowód retestu?
Czy ryzyko spadło do akceptowalnego poziomu?

Dopiero wtedy:

CLOSED.

Punkt 5 jest często pomijany: poprawka może stworzyć nowy błąd

Przykład:

zmieniono:

termin 12 → 18 miesięcy.

Ale automatyczna aktualizacja harmonogramu przesunęła:

płatność poza okres obowiązywania umowy.

Pierwotny finding został naprawiony.

Powstał nowy.

Dlatego przy materialnych poprawkach potrzebny jest:

Regression Check.

Finding Register i audyt wersji powinny działać razem

W artykule Audyt zmian i wersji dokumentów opisałem ryzyko związane z kolejnymi poprawkami.

Finding Register odpowiada:

co miało zostać poprawione?

Version Audit:

czy poprawka prawidłowo przeszła do nowej wersji?

Razem tworzą:

controlled remediation.

Finding Register i Materiality Matrix

Nie wszystkie ustalenia powinny być traktowane tak samo.

Dlatego finding warto powiązać z Materiality Matrix.

Przykład:

Finding	Materiality
literówka	LOW
brak źródła pomocniczego	MODERATE
błędny termin umowy	HIGH
rekomendacja oparta na błędnym modelu	VERY HIGH

Materiality pomaga ustalić:

priorytet;
due date;
poziom retestu;
potrzebę eskalacji.

Finding Register i checklista audytowa

Adaptive Audit Checklist mówi:

co testujemy.

Finding Register:

co stało się, gdy test nie przeszedł.

Sekwencja:

RISK → CHECK → SIGNAL → FINDING → ACTION → RETEST

To kompletny łańcuch kontroli.

Finding Register może również mierzyć jakość procesu

Nie chodzi o ranking pracowników.

Chodzi o pytania takie jak:

ile findingów wraca po poprawce?
ile jest overdue?
ile nie ma ownera?
ile nie ma closure evidence?
które typy błędów się powtarzają?
które procesy generują najwięcej problemów HIGH?

To daje informacje potrzebne do:

ciągłego doskonalenia.

IIA wskazuje również na możliwość mierzenia skuteczności wdrażania działań

W narzędziu IIA dotyczącym pomiaru wyników jednym z przykładów miar jest udział rekomendacji lub action plans wykonanych w terminie oraz udział działań, które po wdrożeniu przyniosły pożądane rezultaty. Dokument wiąże te miary ze Standardem 15.2 dotyczącym potwierdzania implementacji rekomendacji lub action plans. (theiia.org)

To prowadzi do ważnego rozróżnienia:

action completed ≠ outcome achieved.

Activity Metric vs Outcome Metric

Activity

90% działań wykonano.

Outcome

czy problem rzeczywiście przestał występować?

Można wykonać:

100% action plans

i nadal mieć:

ten sam problem.

Dlatego najlepszy Finding Register powinien umożliwiać również ocenę:

remediation effectiveness.

Finding Closure Rate może być mylący

Jeżeli zespół jest oceniany tylko za:

procent zamkniętych findingów,

może pojawić się presja:

zamykaj szybciej.

Lepsze pytania:

ile findingów przeszło retest?
ile zostało reopened?
ile działań usunęło root cause?
ile problemów powróciło?

Jakość closure jest ważniejsza niż szybkość samego statusu.

Dziesięć najczęstszych błędów w Finding Register

1. Brak unikalnego ID

Nie wiadomo, którego problemu dotyczy rozmowa.

2. Finding opisany jednym słowem

„termin”.

Bez kontekstu.

3. Brak evidence

Nie da się ponownie zweryfikować ustalenia.

4. Brak ownera

Problem jest wspólny, czyli niczyj.

5. „Poprawić” jako cały Action Plan

Nie wiadomo jak.

6. Brak due date

Nie wiadomo kiedy.

7. CLOSED na podstawie deklaracji autora

Bez retestu.

8. Kasowanie false positives

Tracimy historię procesu.

9. Zmienianie ID po każdej poprawce

Tracimy traceability.

10. Jeden status „DONE”

Nie wiadomo, czy poprawiono, sprawdzono czy zaakceptowano ryzyko.

Finding Register może być prostym Excelem

Nie zawsze potrzebny jest specjalny system.

Dla mniejszego audytu wystarczy:

Excel;
arkusz online;
tabela w narzędziu projektowym.

Warunek:

jedno źródło prawdy.

Najgorszy model:

część findingów w Excelu, część w Wordzie, część na Slacku, część w e-mailu.

Przy dużym audycie warto rozważyć workflow

Dla dziesiątek lub setek findingów przydają się funkcje:

role;
statusy;
załączniki;
historia zmian;
deadline;
przypomnienia;
filtrowanie;
dashboard;
audyt trail.

Ale narzędzie nie naprawi słabej metodologii.

Można mieć doskonały system i nadal wpisywać:

„problem – poprawić”.

Minimalny Finding Register można zbudować w 10 minut

Kolumny:

ID
Finding
Materiality
Evidence
Owner
Action
Due Date
Status
Retest
Closure Evidence

To już daje znacznie większą kontrolę niż:

komentarze rozproszone po dokumentach.

Finding Register powinien zostać utworzony przed pierwszym findingiem

Nie dopiero na końcu audytu.

Dlaczego?

Bo od początku ustala:

nazewnictwo;
statusy;
sposób zbierania evidence;
odpowiedzialność.

To ogranicza późniejsze ręczne porządkowanie.

Finding Lifecycle – pełna ścieżka

Model można sprowadzić do:

SIGNAL
↓
CANDIDATE
↓
VERIFIED
↓
FINDING
↓
OWNER
↓
ACTION
↓
RETEST
↓
CLOSED

Dodatkowe ścieżki:

CANDIDATE → FALSE POSITIVE

FINDING → ACCEPTED RISK

RETEST → FAIL → ACTION

CLOSED → REOPENED

To daje rzeczywisty model cyklu życia.

Kiedy finding powinien zostać eskalowany?

Na przykład gdy:

owner nie jest wyznaczony;
termin mija;
action plan nie ogranicza ryzyka;
retest drugi raz kończy się FAIL;
management nie zgadza się z findingiem;
organizacja akceptuje wysokie ryzyko;
problem blokuje publikację lub decyzję.

Eskalacja powinna wynikać:

z reguły.

Nie z emocji.

Finding Escalation Gate

Przykład:

E1

Owner + zwykła poprawka.

E2

Właściciel procesu.

E3

Kierownictwo projektu.

E4

Zarząd / osoba uprawniona do akceptacji ryzyka.

Nie każdy finding trafia na najwyższy poziom.

Ale każdy powinien mieć:

ścieżkę.

Co powinien zobaczyć zarząd?

Nie całą tabelę 150 findingów.

Warstwowanie jest lepsze.

Executive View

HIGH / VERY HIGH;
overdue;
accepted risk;
repeated failures;
decyzje wymagane.

Operational View

pełny Finding Register.

Evidence View

szczegóły i dowody.

To ogranicza:

information overload.

Przykład dashboardu

Status	Liczba
Open HIGH	3
Open MODERATE	8
In Progress	9
Retest Required	4
Overdue	2
Closed	31
Reopened	1

Ale pamiętaj:

liczby są wskaźnikiem zarządczym.

Nie zastępują:

treści najważniejszych findingów.

Co zrobić z findingiem przed publikacją?

Jeżeli dokument ma być opublikowany, a finding pozostaje:

HIGH + OPEN,

potrzebna jest decyzja:

publikujemy mimo ryzyka?

poprawiamy?

HOLD?

Finding Register pozwala uniknąć sytuacji:

„myślałem, że ktoś to już poprawił”.

Pre-Publication Finding Gate

Przed finalnym release:

Czy istnieją OPEN HIGH?
Czy istnieją RETEST FAIL?
Czy wszystkie accepted risks mają akceptację?
Czy finalny plik przeszedł retest?
Czy rejestr odnosi się do właściwej wersji?

Jeżeli pierwszy lub drugi punkt brzmi:

TAK

publikacja może wymagać HOLD.

Najczęstsze pytania

Czy każdy drobny błąd trzeba wpisywać do Finding Register?

Nie zawsze. Zakres rejestru powinien odpowiadać celowi audytu. Drobne korekty językowe można prowadzić osobno, jeżeli nie wymagają śledzenia.

Czy finding może zostać zamknięty przez osobę, która go poprawiła?

Przy prostych problemach proces może być uproszczony. Przy findingach wysokiego ryzyka warto rozdzielić remediation i retest.

Czy „poprawione” oznacza „closed”?

Nie. Najpierw trzeba potwierdzić skuteczność poprawki.

Czy false positive należy usuwać?

Lepiej zachować status odrzuconego podejrzenia wraz z krótkim uzasadnieniem, szczególnie przy ważnych audytach.

Czy każdy finding potrzebuje root cause?

Nie zawsze. Przy problemach materialnych lub powtarzalnych root cause ma szczególnie dużą wartość.

Czy Finding Register jest wymagany przez IIA w dokładnie takiej postaci?

Nie. Global Internal Audit Standards wymagają oceny findings, pracy nad recommendations/action plans oraz potwierdzania ich implementacji przy użyciu ustalonej metodologii i systemu śledzenia. Opisana tutaj struktura Finding Register 360 jest autorskim sposobem realizacji podobnej logiki w audytach dokumentów. (theiia.org)

Czy ISO 9001:2026 wymaga Finding Register 360?

Nie. ISO 9001:2026 jest standardem systemu zarządzania jakością i nie narzuca tego autorskiego formularza. Jego aktualna edycja wspiera jednak podejście procesowe, ocenę wyników, risk-based thinking i ciągłe doskonalenie. (iso.org)

Finding nie jest zamknięty wtedy, gdy poprawiono dokument. Jest zamknięty wtedy, gdy potwierdzono, że problem przestał istnieć

To najważniejsza zasada.

Najbardziej niebezpieczny model wygląda tak:

FIND → FIX → FORGET

Lepszy:

SIGNAL → VERIFY → FINDING → OWNER → ACTION → RETEST → CLOSE

A najlepszy przy problemach powtarzalnych:

SIGNAL → VERIFY → FINDING → ROOT CAUSE → ACTION → RETEST → PROCESS IMPROVEMENT → CLOSE

To jest Finding Register 360 Expert Design.

Dzięki niemu można po miesiącu, pół roku albo podczas kolejnego audytu odpowiedzieć:

co znaleziono;
na jakiej podstawie;
kto odpowiadał;
co poprawiono;
kiedy;
w której wersji;
czy poprawka została sprawdzona;
czy problem nie powrócił.

Bez tego audyt może bardzo dobrze wykrywać problemy, ale słabo kontrolować:

co stało się z nimi później.

A wartość audytu nie kończy się na znalezieniu błędu.

Kończy się dopiero wtedy, gdy organizacja wie:

czy ryzyko rzeczywiście zostało usunięte, ograniczone albo świadomie zaakceptowane.

Jeżeli masz już raport z audytu lub listę komentarzy, można przekształcić je w jeden kontrolowany Finding Register i ustalić status:

OPEN → ACTION → RETEST → CLOSED

dla każdego ustalenia.

Kolejnym krokiem po wdrożeniu poprawek powinien być audyt dokumentu po zmianach i retest.

Przekaż raport lub listę ustaleń do uporządkowania i kontroli zamknięcia

Źródła i podstawa merytoryczna

The Institute of Internal Auditors, Global Internal Audit Standards, 2024 – Standard 14.3 Evaluation of Findings – standard wymaga oceny potencjalnych findings pod kątem znaczenia, skutków, prawdopodobieństwa i wpływu ryzyka oraz ich priorytetyzacji. (theiia.org)

The Institute of Internal Auditors, Global Internal Audit Standards, 2024 – Standard 14.4 Recommendations and Action Plans – aktualne standardy przewidują tworzenie rekomendacji, uzyskanie action plans lub wspólne uzgodnienie działań służących usunięciu różnicy między kryterium i stanem faktycznym, ograniczeniu ryzyka, zaadresowaniu root cause oraz poprawie badanego obszaru. (theiia.org)

The Institute of Internal Auditors, Global Internal Audit Standards, 2024 – Standard 15.2 Confirming the Implementation of Recommendations or Action Plans – standard wymaga potwierdzania wdrożenia zaleceń lub action plans, w tym monitorowania postępu, risk-based follow-up oraz aktualizowania statusu działań w systemie trackingowym. (theiia.org)

The Institute of Internal Auditors, Performance Measurement Tool, 2025 – IIA wskazuje wśród możliwych miar m.in. terminowość wdrażania rekomendacji i action plans oraz odsetek działań prowadzących do oczekiwanych rezultatów, wiążąc te wskaźniki ze Standardem 15.2. (theiia.org)

ISO 9001:2026, Quality management systems — Requirements – aktualna, szósta edycja standardu została opublikowana 16 września 2026 r. i zastąpiła ISO 9001:2015. Standard utrzymuje nacisk na podejście procesowe, risk-based thinking, ocenę wyników i ciągłe doskonalenie systemu jakości. Finding Register 360 nie jest wymaganym formularzem ISO, lecz wykorzystuje podobną logikę kontrolowanego przechodzenia od problemu do poprawy. (iso.org)

Dane SEO

1. Meta title: Finding Register – jak śledzić ustalenia audytowe?

2. Meta opis: Jak prowadzić rejestr findingów, kontrolować poprawki i retest? Poznaj Finding Register 360 od wykrycia problemu do zamknięcia.

3. Tagi: Finding Register, rejestr ustaleń audytowych, findingi audytowe, retest, action plan, rekomendacje audytowe, kontrola poprawek, audyt dokumentu, remediation, follow-up audit

4. Fraza kluczowa: rejestr ustaleń audytowych

5. Uproszczona nazwa: rejestr-ustalen-audytowych