Record protection requirements for audit logs require an organization to keep audit evidence available, accurate, secure, and accessible only to authorized people for as long as it is needed. Under ISO 27001 control 5.33, this means protecting logs and related records from loss, destruction, falsification, unauthorized access, and unauthorized release through defined retention rules, technical safeguards, and documented handling procedures.
For an IT manager preparing for certification, the practical test is straightforward: can you show an assessor which audit records matter, where they are stored, who can access or change them, how they are backed up, and how you prevent premature deletion or unauthorized disclosure?
What do record protection requirements for audit logs mean under ISO 27001?
ISO 27001:2022 Annex A control 5.33, Protection of Records, states:
“Records shall be protected from loss, destruction, falsification, unauthorized access and unauthorized release.” [1]
The control applies to records broadly, not just technology logs. However, audit logs are often important evidence because they show who accessed systems, changed settings, approved transactions, exported data, or performed privileged actions. If the organization relies on a log to investigate an incident, demonstrate compliance, resolve a dispute, or support management decisions, it should be treated as a protected record.
| ISO 27001 requirement | Plain-English meaning for audit logs | Evidence an assessor may expect |
|---|---|---|
| Loss | Logs must not disappear because a server fails, a retention job runs incorrectly, or a cloud account is deleted. | Backup configuration, centralized log collection, restoration test results, retention settings. |
| Destruction | Logs must not be deleted before the approved retention period, whether accidentally or deliberately. | Retention schedule, deletion approval process, immutable storage or deletion restrictions. |
| Falsification | Users, administrators, and attackers must not be able to alter evidence without detection. | Write-once storage, restricted permissions, integrity monitoring, SIEM audit trails. |
| Unauthorized access | Only approved roles may view logs, especially where logs contain usernames, IP addresses, customer data, or sensitive activity. | Role-based access control, access reviews, MFA settings, SIEM role assignments. |
| Unauthorized release | Logs must not be exported, emailed, shared with customers, or provided to third parties without authorization. | Information classification rules, export controls, incident procedures, vendor agreements. |
The control does not prescribe one retention period, one product, or one storage architecture. Your organization must decide what is appropriate based on legal obligations, contracts, incident-response needs, privacy requirements, business risk, and other applicable controls. The key is to make the decision deliberately, document it, and operate it consistently.
Who must protect audit-log records, and when does the requirement apply?
Control 5.33 applies to the organization’s information security management system (ISMS) scope. It affects more than the security team. System owners create records, IT operations teams retain and protect them, security teams monitor them, legal or compliance teams may define retention obligations, and business managers may authorize access or disclosure.
For audit logs, responsibility commonly includes:
- IT operations: protects operating system, network, endpoint, backup, and cloud-platform logs.
- Security operations: manages SIEM data, alert history, investigation records, and privileged-access monitoring.
- Application owners: retains application activity, administrative changes, authentication events, and transaction records.
- Human resources, finance, and business teams: owns records that may be generated by business applications and require restricted access.
- Third-party providers: must protect records they host or process under contractual and supplier-security arrangements.
The requirement is triggered when information becomes a record that the organization needs to preserve as evidence. A record may be created automatically, such as an Entra ID sign-in event, an AWS CloudTrail entry, or a ServiceNow approval history. It may also be created manually, such as an incident timeline, a change approval, or an auditor’s evidence request.
Protection is needed throughout the record lifecycle: creation, collection, transmission, storage, access, use, archival, and approved disposal. A secure SIEM alone is not enough if logs can be lost before collection, exported to unsecured spreadsheets, or deleted without authorization at the end of a contract.
What does compliant audit-log protection look like in practice?
An assessor does not usually expect perfection or unlimited log retention. They expect controls that match the risk and evidence that those controls operate. The following examples demonstrate what audit-log record protection can look like in a functioning ISMS.
1. Centralized collection with protected retention
A 420-person staffing and BPO provider uses Microsoft Entra ID, Microsoft 365, CrowdStrike Falcon, Fortinet firewalls, ServiceNow, and AWS-hosted customer portals. The IT team forwards identity, endpoint, firewall, administrative, and application audit events to Microsoft Sentinel. Microsoft 365 audit logs are retained under the organization’s licensing and retention configuration, while high-value security records are exported to an Azure Storage account with immutable blob storage enabled.
The organization’s retention schedule defines 90 days of immediately searchable Sentinel data and 12 months of archived security logs. The storage account permits retention-policy deletion only after the approved period, and only the cloud platform team can modify retention settings through privileged access. This demonstrates protection against loss and destruction while keeping evidence available for investigations.
2. Controls that prevent or expose log tampering
A Linux application server writes local authentication and administrative events to /var/log/auth.log, but the server is not treated as the authoritative log repository. Fluent Bit forwards events to a managed SIEM within minutes. Local log rotation is limited to seven days, while the SIEM stores the centrally collected copy under restricted permissions.
source: linux-production-servers events: ssh authentication, sudo commands, user creation, service changes forwarding: Fluent Bit to Microsoft Sentinel over TLS local retention: 7 days central retention: 365 days SIEM access: Security Analyst (read), Security Manager (export approval), Platform Admin (no log deletion) integrity review: weekly alert for forwarding failures and unexpected retention-policy changes
This arrangement recognizes a common audit issue: a privileged server administrator may be able to alter local logs. Centralized forwarding, restricted SIEM administration, and alerts for collection failures make falsification more difficult and more detectable.
3. Access restrictions appropriate to sensitive log content
Audit logs often include personal data, such as usernames, email addresses, IP addresses, device identifiers, candidate records, customer account references, or timestamps. The organization therefore classifies security logs as confidential and grants read access only to security analysts, the IT manager, and selected incident responders. Administrators who operate infrastructure do not automatically receive access to all investigation records.
A quarterly access review compares Sentinel roles against current job responsibilities. Departed employees are removed through the joiner-mover-leaver process, and privileged access uses MFA and time-limited elevation. This supports both unauthorized-access prevention and accountability for those who view the records.
4. Controlled exports and releases to customers or suppliers
During a customer dispute, the BPO provider needs to show that a supervisor approved a workflow change in ServiceNow. Rather than emailing a broad SIEM export containing unrelated employee activity, the security manager creates a narrow, date-bounded report and has the account owner approve release. The report is stored in the case record, and the release decision is logged.
This is an important part of audit-log retention and protection: confidentiality applies to evidence sharing as well as storage. A technically protected log can still be improperly released if employees export excessive data or send records to an unapproved recipient.
5. Tested recovery and controlled disposal
The organization performs an annual recovery test by restoring a selected archived CloudTrail dataset from Azure Blob Storage and confirming that event timestamps, user identifiers, and actions can be searched. The test record identifies the dataset, recovery date, person performing the test, result, and any corrective actions.
At the end of the 12-month retention period, deletion is performed by the automated lifecycle rule defined in the retention schedule. If a legal hold, customer dispute, or active incident exists, the compliance manager places a hold before scheduled deletion. This demonstrates that destruction is authorized, traceable, and suspended when records remain necessary.
What evidence should an IT manager show an ISO 27001 assessor?
For control 5.33, an assessor will normally look for a coherent connection between policy, configuration, and operating evidence. You should be able to show that the documented rule is actually implemented in the systems that produce important records.
- A records retention and disposal policy that includes security and audit records.
- A log inventory or data-flow diagram identifying critical sources, repositories, owners, and retention periods.
- SIEM, cloud-storage, backup, and application configuration screenshots or exports.
- Role assignments and recent access-review evidence for log repositories.
- Evidence of immutable storage, restricted deletion permissions, or equivalent integrity safeguards.
- Recent alerts, tickets, or test results showing that failed log collection and recovery issues are investigated.
- Supplier contracts or security schedules covering records processed by managed service providers.
Do not present every system log as equally important. A risk-based approach is acceptable and usually more credible. Focus on records that support security monitoring, privileged-access accountability, financial or contractual evidence, incident investigations, regulatory obligations, and material business processes.
Frequently asked questions about protecting audit logs
How long must audit logs be retained for ISO 27001?
ISO 27001 does not set a universal number of days or years. Retention should be defined according to risk, contractual commitments, legal requirements, privacy obligations, incident-investigation needs, and the value of the record as evidence.
Does ISO 27001 require immutable audit logs?
ISO 27001 control 5.33 does not explicitly require a specific immutable-storage technology. However, you must protect records from falsification and unauthorized destruction, so immutable storage, write-once retention, restricted deletion rights, and centralized collection are common ways to demonstrate adequate protection.
Who should have access to audit logs?
Access should be limited to roles with a legitimate business or security need, such as security analysts, incident responders, selected IT managers, and authorized auditors. Access should be role-based, reviewed regularly, and protected with strong authentication.
Are cloud provider logs covered by ISO 27001 record protection controls?
Yes, if cloud logs are within the ISMS scope or support security, operational, legal, or contractual evidence. The organization remains responsible for defining retention, access, protection, and supplier oversight even when the cloud provider hosts the logs.
Next step: Before your certification audit, map your critical audit-log sources to their owners, retention periods, access roles, and recovery evidence, then resolve any gaps between the documented rule and actual system configuration.
