amm_sistema audit logging requirements and how to satisfy them
Italy's Garante per la Protezione dei Dati Personali requires tamper-evident logging of every privileged operation performed by system administrators. This page covers exactly what that means, what a Garante inspection asks for as evidence, and how AuditRails' hash-chained logs satisfy it.
The control
amm_sistema: Logging of Privileged Operations
Garante per la Protezione dei Dati Personali, 27 November 2008 (updated 2009)
“All privileged operations performed by system administrators must be logged, including data access, configuration changes, user management, and system modifications.”
The Garante's own text sets a 6-month minimum retention floor for this specific provision. AuditRails retains longer than that minimum by default (see below), so you're covered even if you're also weighing a longer internal policy.
What an auditor asks for
A Garante inspection wants a tamper-evident record of every privileged operation a system administrator performed, not a policy stating that admin actions are reviewed. They'll ask for the specific log entry for a given change, and whether it can be proven unaltered.
Retention requirement
AuditRails retains amm_sistema audit logs for a minimum of 1 year by default: beyond the regulation's own 6-month floor. Retention extends automatically if you're also subscribed to a framework with a longer requirement.
What AuditRails captures
Administrative-operation events capture the operation type, affected system, and previous value directly, so a specific privileged action can be reconstructed from the log alone.
import { AuditRails } from '@auditrails/node';
const audit = new AuditRails({ apiKey: 'at_live_...' });
await audit.log({
action: 'admin.operation',
actor_id: '...', // required
resource: '...', // required
metadata: {
operation_type: '...', // required
before: '...', // required
after: '...', // required
details: '...', // optional
system: '...', // optional
previous_value: '...', // optional
privilege_scope: '...', // optional
}
});What you hand your auditor
Generate an evidence bundle for your audit window and you get a zip containing a PDF summary report, the full event log as NDJSON, and a manifest with SHA-256 checksums of both files plus a hash-chain proof: evidence you can hand directly to a Garante inspection, not a policy claim they have to take on faith.
Common ways teams fail this control
- Logging that an administrator made a change, but not what the previous value was: a Garante inspection asking "what did this actually change" gets no answer from a bare change-occurred entry.
- Retention shorter than the regulation's own 6-month floor, missing the minimum the provision itself sets.
- No distinction between different privilege scopes (data access vs. configuration vs. user management), when the regulation explicitly lists these as separate categories worth distinguishing.
- Logs editable by the same system administrators the provision is meant to hold accountable, the entire point of tamper-evident logging is that this shouldn't be possible.
- No consistent actor_id identifying which specific administrator performed a given operation, when individual accountability is the provision's core purpose.
Frequently asked questions
Does AuditRails make us compliant with the amm_sistema requirement?
No single tool does on its own, but this is a narrower, more mechanical requirement than most frameworks on this list. AuditRails gives you the tamper-evident privileged-operation logging evidence the provision specifically asks for.
Where is my data actually hosted?
AWS eu-central-1 (Frankfurt, Germany) for the durable audit-log store, an explicit EU-first choice.
How long do I need to keep amm_sistema audit logs?
A minimum of 1 year is what AuditRails retains by default for this framework, beyond the regulation's own 6-month floor.
Can I verify the logs haven't been tampered with, independent of AuditRails?
Yes: we publish an open-source CLI that independently recomputes the hash chain from an export. It doesn't call our API or trust our infrastructure.
This page describes regulatory obligations for information purposes and does not constitute legal advice. Whether they apply to your organisation should be confirmed with your own advisers.