This is an Italian obligation: it comes from an order of the Garante, the Italian Data Protection Authority, and applies to organisations that process personal data under Italian law. The Garante requires the logical access of system administrators to computers and electronic archives to be recorded, meaning logins, logouts and login attempts, with logs that are complete, unalterable and whose integrity can be verified. The logs must be kept for an appropriate period, no shorter than six months, and the administrators' work must be checked at least once a year.
The requirement concerns almost every company, because almost every company has someone, in-house or external, who manages servers, the network, email and the management software with elevated privileges. This guide explains what the order requires, how the official answers to frequently asked questions interpret it and how to apply it today, with part of the infrastructure in the cloud.
The Garante's order on system administrators
The reference is the order issued by the Garante per la protezione dei dati personali on 27 November 2008, "Measures and arrangements prescribed for controllers of processing carried out with electronic means in relation to the assignment of system administrator functions", published in the Gazzetta Ufficiale (the Italian Official Journal) no. 300 of 24 December 2008. It was amended by the order of 25 June 2009 (Gazzetta Ufficiale no. 149 of 30 June 2009), which among other things clarified the role of external processors. In 2009 the Garante also published a set of answers to frequently asked questions, which remain the most useful key to reading it.
The order was issued under the old Italian Privacy Code, but it did not lapse with the GDPR. Legislative Decree 101/2018, which brought the Code into line with the European regulation, established that the Garante's earlier orders continue to apply in so far as they are compatible. Today the register of administrator logins is also one of the most concrete ways to demonstrate the appropriate security measures that the GDPR requires under Article 32.
The FAQ exclude processing carried out solely for ordinary administrative and accounting purposes, with examples such as managing the vehicle fleet, purchasing or building maintenance. In practice, almost every company also processes other data, starting with that of employees and customers.
Who is a system administrator
For the Garante, a system administrator is the professional dedicated to managing and maintaining processing systems, or their components, used to process personal data. The order includes roles that are comparable in terms of risk: administrators of databases, of networks and security devices, and of complex software systems.
It is the role that counts, not the contract. System administrators include the in-house technician with domain credentials, the IT supplier that manages the servers remotely, and the software house that goes into the management software's database to provide support. According to the FAQ, on the other hand, users who work in an application with their own authorisation profile, however broad, are not system administrators, and neither is anyone who works on systems only occasionally, for example to fix a fault.
External administrators do not let you off the hook. When system administration is outsourced, the order requires the controller or the external processor to keep directly and specifically, for any eventuality, the identification details of the individuals appointed as administrators. The 2009 amendments clarified that these measures can also be implemented by the processor, on the basis of the contract. The appointment of the supplier and the instructions to it are prepared with the GDPR forms, and its reliability is checked through supplier qualification.
The five measures required by the order
The operative part of the order lists five measures. The log register is the best known, but on its own it is not enough.
| Point | What it requires | What to produce |
|---|---|---|
| Assessment of characteristics | Assign the role after assessing the person's experience, ability and reliability | Documented selection criteria |
| Individual appointment | One appointment per person, with a detailed list of the areas in which they are allowed to operate | Signed appointment letters |
| List of administrators | Identification details and assigned functions, in an up-to-date internal list; if administrators process workers' data, their identity must be made known or available to the workers | Up-to-date list, privacy notice or internal communication |
| Check of activities | Check of the administrators' work at least once a year | Minutes of the check |
| Recording of logins | Systems capable of recording logical access, with complete, unalterable and verifiable logs, kept for no less than six months | Access log register and proof of retention |
What to record in access logs
The order requires the logical access, that is the computer authentications, of administrators to processing systems and electronic archives to be recorded. FAQ no. 9 specifies that access log means the recording of events generated by the authentication system at the moment of access or attempted access and at the moment of disconnection. So successful logins, failed logins and logouts.
Every record must include time references and a description of the event that generated it. According to the same FAQ, an event usually contains:
- The username used
- The date and time of the event
- The system or software accessed
- The type of event: login, logout or error condition
- The communication line or device from which the access took place
Three clarifications in the FAQ prevent unnecessary work or gaps:
- You do not need to record commands. The order does not require interactive activity, meaning the commands issued or the transactions carried out, to be tracked. If your system collects more, that is fine, and you can filter out just the data relevant to administrators.
- Workstations too. Administrator logins must be recorded on servers, but also on clients, meaning computerised workstations.
- Databases too. Authentications to database management systems are within scope.
Completeness, unalterability, integrity
The records must have the characteristics of completeness, unalterability and verifiability of their integrity, appropriate to the verification purpose for which they are required.
Completeness means, according to FAQ no. 11, that the logging system must include all interactive access events by administrators on all systems used to process personal data, even indirectly. If you record the domain controller but not the firewall, the NAS and the management software's database, the register is not complete.
Unalterability and integrity do not necessarily call for expensive products. FAQ no. 12 states that in the simplest cases the operating systems' own tools may be enough, with periodic export of the logs to non-rewritable media; in more complex cases you can use centralised, "certified" log servers. There is one principle: the people being checked must not be able to modify or delete the traces of their own logins. If the server administrator is also the only person who can touch the logs, the requirement is not met.
That is why many companies collect logins on a separate central system, such as a SIEM, managed with credentials different from those of the administrators being checked. If you want to understand how it works, read the guide what is a SIEM.
How long to keep the logs
The order requires the records to be kept for an appropriate period, no shorter than six months. Six months is the minimum, not a recommended value. The order sets no maximum: the duration must be decided by the controller, justified and written down, taking into account the verification purpose and the GDPR's storage limitation principle.
A useful line of reasoning: if the check of the administrators' work is annual, a register that keeps only six months leaves you without data for half the period to be checked. Many organisations therefore choose a longer period, documenting the reason. Whatever you choose, write it into the procedure and actually apply it, including deletion when the period ends.
Watch how you count. "No shorter than six months" applies to every record. If the system rotates log files when they reach a certain size, on a very busy server six months can turn into a few weeks without anyone noticing.
The annual check of the administrators' work
The administrators' work must be subject, at least once a year, to a check by the controller or the processors, to verify that it complies with the organisational, technical and security measures in place. The login register is the starting point: the FAQ give as its purpose the detection of anomalies in frequency, times, duration and systems used.
A check that stands up in an inspection is documented. The minutes state who carried it out and when, which period and which systems were examined, which anomalies were found and what was decided. For an inspector, a check with no written record did not happen.
Microsoft 365 and Google Workspace
The order dates from 2008, but its principles also apply to cloud services: the administrators of the Microsoft 365 tenant or the Google Workspace console have access to mailboxes, documents and master data. The delicate point is how long the platform keeps the logs on its own.
- Microsoft 365. According to Microsoft's documentation, Microsoft Entra ID sign-in logs are kept for seven days with the entry-level licence and for thirty days with P1 and P2 licences. Far less than six months: the logs must be exported and archived elsewhere. The Microsoft Purview unified audit log follows its own rules, which depend on the licence.
- Google Workspace. According to Google's documentation, admin log events and user login events remain available for six months, and administrators cannot change this period. Six months matches the minimum, with no margin: if your procedure sets a longer period, you need an export.
In both cases the solution is the same: collect logins in a register outside the tenant, separate from the administrators you want to check. It is also the way to have cloud logins and workstation logins in one place.
Common mistakes
- The list only covers in-house staff. The IT supplier and the software house are often the main system administrators, and the most overlooked.
- Shared accounts. An "admin" account used by three people makes the log useless: it records a login, but does not say who made it.
- Logs on the same server they monitor. If the administrator can delete them, they are not unalterable.
- Servers only. The FAQ include workstations and databases.
- Retention "by eye". Nobody has checked that the logs really go back six months.
- The cloud forgotten. The on-premises domain is recorded and the tenant ignored, where logs expire after a few days.
- An annual check never minuted. The logs are there, but nobody has ever looked at them.
How to prove it in an inspection
In an inspection or an audit, whether for the order or for standards such as ISO/IEC 27001 or NIS2, you will be asked to show evidence, not intentions. Prepare a file with:
- The up-to-date list of system administrators, in-house and external, with their assigned functions
- The signed individual appointments and, for outsourced services, the identification details of the supplier's administrators
- The communication to workers of the administrators' identity, when they process staff data
- An extract from the login register, with user, date and time, system and outcome
- Proof that the register covers at least six months, and the procedure that sets the retention period
- A description of how the logs are kept unalterable
- The minutes of the latest annual check, with the anomalies found and the actions decided
The same register is also useful after an incident: to reconstruct who got in and when, as the guide data breach: what to do in the 72 hours explains.
How Dottor Box helps
The Access logs check collects logins into a single register from three sources: from endpoints, with the Cyber Agent acting as a SIEM, and from tenants connected read-only through the Microsoft Entra ID and Google Workspace modules. For every endpoint login it records the user, workstation, IP address, domain, host, outcome, whether the account is administrative, and the date and time.
Alongside the register you will find the declared list of system administrators and the full CSV export to attach in an audit. Alerts on repeated failed attempts, logins from new countries and access with administrative accounts are the basis of the periodic check. The complete path, from appointments to the check, is described on the system administrators page.