--- title: "Access Audits and Security Logs in a Business Application" description: "The question \"who changed this and when\" always arrives — in a complaint, an inspection, an incident. If the search starts then, it is too late." canonical: "https://interfase.sk/en/news/access-audits-and-security-logs-in-a-business-application" lang: "en" last_updated: "2026-10-30" --- # Access Audits and Security Logs in a Business Application > The question "who changed this and when" always arrives — in a complaint, an inspection, an incident. If the search starts then, it is too late. Published: 2026-10-30 - An audit log should record who, what, when and from what value — without the previous value a change cannot be reconstructed. - Access rights go stale more quietly than anything else; without regular review, half the staff hold rights they no longer need. - A log that can be deleted from the application is not evidence — the record has to be immutable and kept separately. - Record reads of sensitive data too, not only changes; that is precisely what an inspection asks about. A customer insists the order had a different price. The system holds the current value and nobody can say whether it changed, by whom or why. The discussion moves to "it seemed to me" and the company loses it. That is the cheapest scenario. The others cost more: a regulatory inspection, an employee who left with access nobody revoked, or a suspected data leak with no way to establish its scope. ## What an audit log should contain The minimum worth having is four items, plus one that gets forgotten: - **Who** — a specific user, not "the system". If an automation acted on someone's instruction, both belong there. - **What** — which record and which field. - **When** — to the second, in UTC. - **From where** — IP address and device, where that makes sense. - **From what to what** — and this is the forgotten one. "Price was changed" is useless. "Price changed from €1,240 to €990" is usable evidence. ## Record reads as well Most applications log changes and ignore reads. For ordinary data that is fine. For **personal data, salaries, health records and contracts** it is the most important part — an inspection does not ask "who changed it" but "who saw it". There is no need to log every list view. Access to the detail of a sensitive record, and every export, is enough. ## An export is its own event Downloading a table of a thousand contacts is, in risk terms, something entirely different from opening one record. Exports therefore get their own entry with row count and scope — and for large exports, notifying an administrator is worth considering. ## The log must not be rewritable An audit log an administrator can edit or delete inside the application has no evidential value. The person with the highest rights is exactly the one whose actions need to be provable. The practical answer: **the record is append-only**, with no editing or deletion from the interface; a copy goes to separate storage; and the retention period is set in advance, not as needed. ## Access rights go stale quietly This is the most common gap in companies that otherwise take security seriously. People change roles, gain new rights and nobody takes the old ones away. After two years the accountant has warehouse access, a former temp has a live account, and an external supplier holds rights they needed for one project. What works: - **A review twice a year.** The list of people and their rights goes to managers with the question of whether it should stay that way. It takes an hour and always turns something up. - **Departure as a process.** Revoking access is an item on the exit checklist, not a verbal agreement. - **Rights by role, not by person.** Otherwise every change of position adds and never removes. - **Automatic alerts on dormant accounts.** An account with no login for 90 days deserves a question. ## Logs are useful only when they are searchable A file that gets written to and never opened is only a feeling of safety. For a log to have value, "show me everything this user did with this record" has to be answerable in seconds — without a developer. This connects to the rest of the operational view of an application we described in [where time is really lost in a business application](/blog/rychlost-firemnej-aplikacie-kde-sa-realne-straca-cas): you can only measure what you record. ## What does not belong in a log Passwords, tokens, card numbers and national ID numbers in the clear. Logs tend to be less protected than the database and are often copied into analysis tools. Sensitive values are therefore masked, or left out entirely. Equally, the audit log is itself processing of personal data — it has its own retention period and its own purpose. We described the related principles in the piece on [AI agents and GDPR](/blog/ai-agenti-a-gdpr-na-co-si-dat-pozor-pri-spracovani-osobnych-udajov). ## Where to start Add "from what to what" to the changes already being logged, and turn on export records. Those are two changes that can be made quickly and cover most situations in which an audit log actually gets opened. If you are working on the security of an existing application and want to know where the gaps are, [get in touch](/kontakt). We handle it under [cybersecurity](/riesenia/kyberbezpecnost) and [custom development](/riesenia/vyvoj) — examples in our [case studies](/referencie). --- Web version: https://interfase.sk/en/news/access-audits-and-security-logs-in-a-business-application llms.txt: https://interfase.sk/llms.txt