Audit trails: which information actually explains a change?

Event records and case documents answer different questions

An event record shows who performed an action, when and on which object. The case documents explain why it happened and which material supported the decision. An invoice approval entry without the invoice, contract and evidence of completed work is insufficient to assess the expenditure. Conversely, an invoice file does not show who approved payment or how a changed bank account was checked.

The Polish Act on Ownership of Premises includes requirements concerning the community's specified non-accounting records, maintenance of the owners and shares register and owners' right to inspect the board's activity. [1] It does not prescribe a particular software brand or a single universal log format. An audit trail is a proposed way to organise evidence needed when handling those responsibilities.

List the processes you need to reconstruct: a charge, correction, vote, work order, complaint or permission change. For each, identify the source evidence, responsible role, result and storage location. This defines the scope of your controls. Collecting every possible event without a purpose makes retrieval harder and may unnecessarily increase the personal data being processed. Define which question each record needs to answer. A contact change needs its source and verification outcome; a payment also needs its approval basis. Do not automatically copy complete messages into technical logs. A reference to an appropriately restricted document can be more useful than another copy visible to a wider group.

Start with a persistent identifier and a clear timeline

Assign an identifier that remains stable when a case moves between employees. Link it to the community, premise or document where needed. Do not use an email subject as the sole identifier. Two messages titled “leak” may concern different staircases, contractors and dates. Staff need a reliable reference that distinguishes the two matters without reading an entire mailbox.

A practical event record identifies the timestamp, user or automated process, action, object, outcome and supporting evidence. For imports, retain the file name, source, date and error report. For automated calculations, identify the rule and configuration version. An entry saying “the system recalculated” cannot explain which data produced the revised charge or which setting applied at that time.

Define what each date means. If software stores UTC timestamps and users read local Polish time, an export should clearly identify the time zone. Keep the document date, receipt date and entry date separate. An invoice issued on Monday, received on Wednesday and recorded on Friday has three different dates. Replacing them with one unexplained field makes later checks of response and payment timelines unreliable.

Corrections need a previous state and an explanation

An owner reports that a water-meter reading was entered incorrectly. The company changes the value and recalculates the settlement. A reconstructable case should show the original reading, complaint, confirming material, approved correction and its financial effect. The latest number alone cannot explain the difference or establish when the corrected document was communicated to the owner.

Not every alteration needs extensive approval. Set categories and thresholds for independent checks, such as a correction affecting a charge, a contractor's bank-account change or an ownership-share change. This is an organisational recommendation. Too many checks on trivial edits burden staff; too few on payments leave substantial risks uncontrolled. Choose the control according to the consequence of an error.

The explanation should be short and factual. “Corrected” provides little information. A better note identifies the reversed digits in an import, a photograph confirming the correct reading and the resulting balance adjustment. Do not add unrelated details about a resident's health, family or disputes. The record should explain the action rather than become an uncontrolled collection of personal observations.

Separate operational access from control over the history

An employee's account should match their tasks. Someone receiving maintenance reports does not automatically need permission to change settlements or delete history. Supplier support access also needs defined rules. The GDPR requires appropriate technical and organisational measures in relation to risk; it does not prescribe one identical security configuration for every company. [2]

Ask whether history entries can be altered or deleted, who can do so and whether those operations are themselves recorded. Check ordinary-user, application-administrator and database-administrator access separately. A claim that a history is immutable needs technical evidence. The absence of an edit button on a user's screen does not establish resistance to manipulation at other levels.

Practical protection may include restricted permissions, separately stored event records, access controls and backups. Each mechanism has limits. A checksum can help detect a file change against a known reference but does not prove that the original contents were true. An ordinary application log is not automatically a qualified timestamp or electronic signature. Describe what a control actually establishes instead of assigning it a stronger legal or technical meaning.

Make evidence accessible to the appropriate recipient

Owners have the right to inspect the board's activity under the Polish Act. [1] Access arrangements need to support that right while considering personal-data protection. Do not interpret inspection rights as an automatic reason to email every owner the entire database, private correspondence and all individual balances. Establish the scope of the specific request and the appropriate form of access.

Prepare an export relating to the matter rather than an indiscriminate download of everything. Include the chronology, source documents, decision and a clear indication of gaps. Check file readability and identifier consistency. If a report references a document identifier, the recipient should be able to locate the matching file without relying on a vendor's application or asking the original employee to explain it.

GDPR accountability means that the controller must be able to demonstrate compliance with the processing principles. [2] Access and change records may supply some evidence, but they do not replace a lawful basis, a processing agreement or the handling of individuals' rights. A log proving that a document was sent cannot justify sending it to the wrong person. Evidence of an action and justification of an action remain separate questions.

Decide how long to retain records and how to recover them

Do not use one retention period for every category. Technical building documents, settlements, dispute evidence and login records have different purposes. Determine the applicable duties, justified period, responsible role and end-of-retention action for each. The GDPR storage-limitation principle does not require deleting records contrary to another applicable legal obligation. [2] A blanket promise to keep everything indefinitely is equally unhelpful.

Where a dispute is ongoing, establish which material needs protection from routine deletion. Record the reason and scope of that decision. Do not freeze the entire database without an end date simply because one case remains open. Return to the retention assessment when the matter ends. The schedule should distinguish the principal document, working exports and access records. A duty to retain the principal document does not automatically justify keeping every copy. Establish how deletion or restriction works in backups and during recovery. Retention control should not become manual folder clearing without evidence of which files and relationships were removed. Staff should know how to identify relevant records and who can approve an exception.

Backups should preserve links between documents and their history. A restoration test checks that files open, identifiers still match and the chronology remains interpretable. Define acceptable data loss and expected recovery time as organisational requirements. Showing an actual recovery is more useful than a general assurance that backups exist. Record the test date, scope, missing items and any corrective work assigned afterwards.

Test a handover to someone unfamiliar with the case

Take a completed settlement complaint and give its file to an employee who was not involved. Ask them to establish the source of the amount, reason for correction, approving person and document delivered to the owner. Measure retrieval time and record gaps. The exercise tests the evidence left by the process, not the memory or personal commitment of the original case handler.

Then examine handover of an entire community to another administration company. The export should contain the agreed documents and explain how the data is interpreted. Withdraw former staff access and determine any further retention of copies according to the roles, contract and legal duties. Private mailboxes should not become the organisation's only archive for matters for which it remains responsible. Prepare a file inventory, field descriptions and open exceptions. The recipient should confirm readability before the previous tool is closed. If an attachment is missing or history begins only on migration day, state that limitation in the handover record. Separately verify that transferred identifiers do not connect different communities' documents. Such an error may remain invisible until someone opens the referenced file.

When evaluating software, request a demonstration involving a correction, a permission change and a complete case export. Ask about limitations of the history and evidence supporting its protection mechanisms. View the scope of WM Administrator and test your process. The useful outcome is that another person can reconstruct the matter reliably. The number of screens labelled “audit” does not establish that result.

Record the community context, role, resource, operation identifier and execution channel in an event. A log can retain safe identifiers, the scope of a change and an evidence hash; passwords, tokens, complete documents and excessive personal data do not belong in it. An audit export should state its time range and filters and allow completeness to be checked without access to environment secrets.