MUNKANAPLÓ / WORKLOG
Not a case study. An engineering worklog.
Finished systems hide most of the engineering work behind them. This log keeps the problems, wrong turns, fixes, trade-offs and verification steps that do not fit on a portfolio card.
103 of 103 entries are currently available in English. The remaining entries stay in Hungarian while translations are reviewed in batches.
13 entries ezen az pageon · 103 total
Who owns the evidence? Not necessarily the person who currently has the file
Evidence ownership was often confused with whoever had last sent the document. That model was operationally wrong, so responsibility was separated by role and source system.
Open entry →A KPI is only useful if you can trace it back to its source
Management metrics needed a traceable data path. A number is not trustworthy merely because it looks good in a dashboard; we need to know which records and which calculation rules produced it.
Open entry →February direction: fewer manual steps, more traceability
The month was not about building one large new system. It was about reducing manual handling in many small places while making sources, responsibilities and rules more visible.
Open entry →NIS2 started working when we stopped treating it as a list of legal quotations
The first hard problem was not technical. Legal requirements had to be translated into operational tasks with real evidence, accountable roles and states that could actually be verified.
Open entry →A missing-evidence list is not a backlog yet
A long spreadsheet showed that something was missing, but not how to move from that gap to an auditable state. The list had to become a task system rather than a collection of unresolved labels.
Open entry →C-level reporting: remove the noise without removing the risk
Technical state had to be compressed for executive use without erasing uncertainty, dependencies or the issues that genuinely required a management decision.
Open entry →An evidence filename is not a source of truth
The same control could have several filenames, folders and human labels. The important question was not what the document was called, but how to prove which source was current and authoritative.
Open entry →Where does the technical answer end, and where does audit interpretation begin?
Technical teams could often prove how a system behaved, but that did not automatically settle whether the behaviour fully satisfied a specific audit or regulatory requirement.
Open entry →Audit readiness is not a document-collection contest
A large number of uploaded files can look like progress, but audit readiness depends on whether controls actually operate and whether the evidence genuinely demonstrates them.
Open entry →Evidence expires too: treating freshness as part of the evidence model
A screenshot or export from last year can be factually correct and still fail to demonstrate current operation. Evidence existence and evidence freshness had to become separate states.
Open entry →When 73% looks more precise than the data actually is
Percentage-based status was tempting, but in several cases the source data was not stable or comparable enough for a single number to represent genuine precision.
Open entry →We started treating evidence generation like a build
Instead of relying on a manually assembled audit package, the path to evidence increasingly had to be reproducible: the same source and the same rules should be able to generate it again.
Open entry →January principle: turn technical data into decision-ready information
By the end of the month, it was clear that most of the work was not inventing new controls but making existing technical state understandable, traceable and verifiable enough to support decisions.
Open entry →No matching entry in the complete worklog.