Logging is the control that most reliably produces two opposite findings in the same organisation. From the security side, too little is logged and almost nothing is reviewed. From the data protection side, too much is logged, held too long and used without a clear purpose. Both are usually true at once, and the reason is that the two decisions are taken by different people who never compare notes.
What should be logged
The selection follows the protection needs of what is being protected, not the technical possibilities of the platform. The events normally treated as security-relevant are: logons, logoffs and failed authentication attempts; changes to entitlements and group memberships; all activity by privileged accounts; changes to security configuration; access to data holdings with particular protection needs; the starting and stopping of logging itself; and changes to log data.
That last item is often overlooked and is the most important. Logs that can be altered by the people whose actions they document serve neither as a security control nor as evidence. Log data therefore belongs in a store to which the administrators being logged have no write access.
Evaluation rather than accumulation
Logging without evaluation is data retention, not control. It becomes effective through three determinations: which events trigger an automatic alert, who works those alerts and within what time, and at what interval a review takes place that is not triggered by an event. These belong in a logging concept rather than in the configuration of a tool: the configuration implements them, it does not justify them.
The data protection conflict
Log data is almost always personal: it links an identifier to a point in time and an action. It is therefore subject to the general requirements for processing, including purpose limitation and data minimisation. Because it depicts employee behaviour, its introduction and design can be subject to co-determination. Works council, data protection officer and legal advice should therefore be involved before the introduction, not after the first analysis.
For an organisation consolidating logs centrally across countries, this is the point at which a technically finished project stops moving. The platform is built, the connectors work, and the German entity cannot switch on because the works agreement is not in place. Building the three determinations below into the design from the start is considerably faster than retrofitting them into a negotiation.
- Purpose limitation. The purpose of the logging is set down in writing, and use for other purposes, in particular monitoring performance and conduct, is either expressly excluded or expressly governed.
- Access restriction. Only a named, small group may view log data, and that viewing is itself logged. For event-driven analyses, dual control involving the data protection officer is advisable.
- Deletion. A retention period is defined for each type of log and enforced technically. There are no generally applicable periods; the duration follows from the purpose, from the applicable retention obligations and from the risk. What matters is that a determination exists and is adhered to.
Where the requirement comes from
Art. 32(1)(b) GDPR frames the requirement around the ability to ensure the confidentiality, integrity, availability and resilience of systems and services on an ongoing basis; traceability of access serves all four objectives. Point (d) of the same paragraph additionally requires a process for regularly testing and evaluating the effectiveness of the measures; for logging that means the evaluation itself has to be reviewable, not only the capture. For entities in scope of the German BSI Act, the catalogue of measures in § 30(2) sentence 2 BSIG names, in no. 2, the handling of security incidents; access control and the administration of ICT systems, products and processes sit in no. 9. Both presuppose a traceability that cannot be produced without logging. At the same time the logging is itself a processing activity, and belongs in the records of processing activities.
What reviewers ask
Typically: which events are captured, and who determined the extent? How is it ensured that logs cannot be altered after the fact? Who may view them, and is the viewing documented? How long are they retained, and what enforces the deletion? When did the last review that was not triggered by an event take place, and what did it find? Is there an agreement with the employee representatives, and does it cover what actually happens?
What has to be on file
Useful evidence is the logging concept covering purpose, extent, roles and retention; the entry in the records of processing activities; the access list for log data; evidence of immutability or of separated storage; records of analyses performed, with date and outcome; deletion records; and, where applicable, the works agreement.
One more item belongs on that list: evidence of time synchronisation. Without a common time base, events from several systems can be neither correlated nor used as evidence, a point that becomes acute the moment systems in different time zones have to be read together.
The question before the tool: what has to log
The question before the tool is the more expensive one: which systems have to log at all, and in what depth.
That answer is a derivation from the inventory. A system inherits the protection needs of the primary assets it carries, particularly the confidentiality and integrity requirement, including across several steps. Where that requirement is high, the logging requirement is justified accordingly, and it appears as a requirement on that object, with an owner and evidence. Conversely it stands out when a system with a high inherited requirement appears in no logging at all, because the requirement stays open there.