1. Purpose
The Security Log Retention Standard defines how security and operational logs are retained, protected, reviewed, and disposed of so that the organization can:
- Detect and investigate security events and incidents.
- Support incident response and digital investigations.
- Maintain evidence required for audits and assessments.
- Monitor unauthorized access and security-control activity.
- Support business, contractual, legal, regulatory, and customer requirements.
- Maintain sufficient historical information for trend analysis and forensic investigation.
- Prevent unnecessary retention of sensitive information.
The objective is not to retain every log indefinitely. Logs should be retained for a defined period based on security value, risk, investigation requirements, contractual obligations, and applicable legal or regulatory requirements.
2. Scope
This standard applies to security-relevant logs generated by:
- Cloud infrastructure
- AWS accounts and services
- Identity and access management systems
- SSO and MFA systems
- Firewalls and network security devices
- VPN and remote-access systems
- Endpoint security tools
- Servers and operating systems
- Applications and APIs
- Databases
- SaaS applications
- Email and collaboration platforms
- Web applications and WAF
- Security monitoring and SIEM platforms
- Vulnerability and security tools
- CI/CD and source-code platforms
- Backup and recovery systems
- Administrative activity
- Security incidents and investigations
- Third-party and supplier systems where logs are contractually or operationally available
The standard applies to production, corporate, development, testing, and other environments where security-relevant logging is enabled.
3. Log Retention Principles
The organization should follow these principles:
3.1 Retain Logs Based on Risk
Retention periods should reflect the importance of the system, information, business process, and potential security impact.
3.2 Protect Logs From Unauthorized Modification
Security logs should be protected against unauthorized deletion, alteration, or tampering.
3.3 Separate Operational and Security Retention
Some logs may be retained for operational troubleshooting for a shorter period, while security logs may require longer retention.
3.4 Preserve Investigation Evidence
When an incident, investigation, audit, legal matter, or other defined requirement requires preservation, relevant logs must not be deleted according to the normal retention schedule.
3.5 Minimize Sensitive Information
Logs should not unnecessarily contain passwords, authentication secrets, API keys, private keys, session tokens, or other sensitive information.
3.6 Maintain Time Synchronization
Systems generating security logs should use reliable time synchronization so that events can be correlated accurately.
3.7 Review Retention Periods
Retention periods should be reviewed periodically and when business, technology, threat, contractual, legal, or regulatory requirements change.
4. Security Log Categories
The organization should identify logs according to their security value.
| Log Category | Examples | Security Purpose |
|---|---|---|
| Authentication | Login, logout, MFA, failed login | Detect unauthorized access |
| Authorization | Permission changes, access denied | Detect privilege misuse |
| Privileged Activity | Admin actions, role changes | Monitor high-risk activity |
| Cloud Activity | AWS CloudTrail, cloud configuration changes | Investigate cloud activity |
| Network | Firewall, VPN, DNS, VPC Flow Logs | Investigate network activity |
| Endpoint | EDR, malware, process activity | Detect endpoint compromise |
| Application | Login, API, security events | Investigate application activity |
| Database | Authentication, administrative actions, queries where appropriate | Investigate database access |
| WAF | Blocked/allowed requests, attack signatures | Investigate web attacks |
| Security Tools | SIEM, IDS/IPS, GuardDuty, vulnerability alerts | Detect threats |
| CI/CD | Deployment, repository, pipeline, secret-related events | Investigate development compromise |
| Data Access | Sensitive-data access events | Investigate unauthorized access |
| Backup | Backup creation, deletion, restore | Detect backup manipulation |
| Configuration | Security configuration changes | Detect control weakening |
| Incident | Incident actions and response events | Support investigation and audit |
5. Log Retention Requirements
The following baseline may be adopted by the organization and adjusted based on risk and applicable requirements.
| Log Type | Recommended Minimum Retention | Priority |
|---|---|---|
| Privileged/Admin Activity | 12 months | High |
| Authentication & MFA | 12 months | High |
| Cloud Control-Plane Logs | 12 months | High |
| Security Alerts | 12 months | High |
| Firewall/WAF/Security Logs | 6–12 months | High |
| Endpoint Security Logs | 6–12 months | High |
| Application Security Logs | 6–12 months | High |
| Database Security Logs | 6–12 months | High |
| VPN/Remote Access Logs | 6–12 months | High |
| CI/CD Security Logs | 6–12 months | High |
| Vulnerability Scanner Results | 12 months | Medium/High |
| Configuration Change Logs | 12 months | High |
| Backup Activity Logs | 12 months | High |
| General Application Logs | 30–180 days | Medium |
| Debug/Performance Logs | 7–90 days | Low/Medium |
| Security Incident Logs | Per incident/evidence retention requirement | Critical |
| Forensic Evidence | Per investigation/legal requirement | Critical |
These are organizational baseline recommendations, not universal ISO 27001 retention periods. Actual retention should be determined using the organization’s risk assessment and applicable requirements.
6. Critical Security Logs
The organization should identify a minimum set of logs that must receive enhanced protection and retention.
For a SaaS startup, these normally include:
- Identity-provider authentication logs
- MFA activity
- Privileged account activity
- AWS CloudTrail
- AWS IAM changes
- Security-group and network configuration changes
- S3 access and security-relevant activity
- RDS administrative activity
- ECS/EKS/compute administrative activity where applicable
- Secrets-management activity
- KMS/key-management activity
- WAF security events
- GuardDuty findings
- Security Hub findings
- Endpoint security alerts
- CI/CD administrative activity
- Production deployment activity
- Source-code repository administrative activity
- Security incident records
7. AWS SaaS Example
Consider a SaaS company running its production platform on AWS.
A minimum security logging architecture could include:
AWS Activity → CloudTrail → Central Log Storage → Access Control → Monitoring → Investigation → Retention/Deletion
Example
An administrator unexpectedly creates a new IAM role.
CloudTrail records:
- Identity that performed the action
- Timestamp
- Source IP
- API operation
- AWS account
- Resource
- Result
- Related request information
The organization retains the CloudTrail record according to the security-log retention schedule.
If the event later becomes part of an investigation, the relevant log is linked to:
Event → Incident → Evidence → Investigation → Root Cause → Corrective Action
The relevant evidence may then be placed under investigation-specific preservation rather than being deleted according to the normal retention schedule.
8. Log Protection
Security logs should be protected using appropriate technical and administrative controls.
Controls may include:
- Least-privilege access
- MFA for administrative access
- Encryption at rest
- Encryption in transit
- Restricted deletion permissions
- Centralized log storage
- Immutable or tamper-resistant storage where appropriate
- Access logging
- Backup where justified
- Integrity monitoring
- Separation of log administration from ordinary system administration where practical
- Alerting on unauthorized changes or deletion
- Regular access review
For critical security logs, the organization should consider storage mechanisms that make unauthorized modification or deletion difficult.
9. Log Access Control
Access to security logs should be limited according to business and security requirements.
Typical access roles include:
| Role | Access |
|---|---|
| Security Team | Investigation and monitoring |
| Incident Response Team | Incident-related investigation |
| Cloud/IT Team | Operational/security troubleshooting |
| System Owner | Relevant system logs |
| Internal Auditor | Read-only evidence access where authorized |
| Compliance Team | Audit/compliance review |
| Management | Reporting and approved investigations |
| Developers | Limited application logs required for their role |
Users should not receive unrestricted access merely because they are administrators of the underlying system.
10. Log Integrity
The organization should implement reasonable measures to demonstrate that security logs have not been improperly altered.
Depending on risk, this may include:
- Centralized collection
- Write-protected storage
- Immutable storage
- Object-lock mechanisms
- Access-control restrictions
- Hashing for investigation-specific evidence
- Integrity monitoring
- Separate administrative roles
- Monitoring of log deletion
- Monitoring of logging configuration changes
For incident evidence, stronger evidence-preservation controls should be applied according to the Evidence Collection Procedure and Chain-of-Custody requirements.
11. Log Availability
Security logs should remain available for the required retention period.
The organization should consider:
- Storage availability
- Backup requirements
- Cloud-region considerations
- Disaster recovery
- Log ingestion failures
- Storage capacity
- Searchability
- Restoration capability
- Security-tool dependencies
Critical security logs should not depend on a single storage location where such dependency creates unacceptable investigation risk.
12. Logging Failure
The organization should define how failures of critical logging are handled.
Examples include:
- CloudTrail stops generating events.
- SIEM ingestion fails.
- WAF logs are no longer received.
- Authentication logs are unavailable.
- Endpoint security logs stop reporting.
- Central log storage becomes inaccessible.
For critical systems, logging failures should generate an alert or ticket where practical.
The responsible team should:
- Identify the failure.
- Assess security impact.
- Determine the affected period.
- Restore logging.
- Investigate whether relevant activity occurred during the gap.
- Document the event.
- Assess whether additional monitoring is required.
- Record corrective action where appropriate.
13. Log Review
Retention alone does not provide effective monitoring.
Security-relevant logs should be reviewed or monitored based on risk.
Examples:
- Repeated failed privileged logins
- MFA changes
- New privileged accounts
- Permission changes
- Security-control disabling
- Unexpected geographic access
- Unusual API activity
- Large data downloads
- Public storage changes
- Security-group changes
- Creation of unexpected cloud resources
- Log deletion attempts
- Unexpected production deployments
Automated detection may be used where appropriate.
14. Incident-Related Log Preservation
When an event becomes a formal incident or investigation, normal log deletion schedules may no longer apply to relevant evidence.
The Incident Response Team should identify:
- Relevant systems
- Relevant accounts
- Relevant time period
- Relevant log sources
- Relevant cloud resources
- Relevant application activity
- Relevant security alerts
- Relevant communications
Relevant logs should then be preserved according to the organization’s evidence-preservation requirements.
Example
Normal retention:
AWS CloudTrail → 12 months
Incident preservation:
Security incident identified → relevant CloudTrail records preserved → evidence ID assigned → integrity verified where appropriate → linked to investigation → retained according to investigation requirements.
15. Log Retention Exceptions
An exception may be required when:
- A customer contract requires longer retention.
- A legal or regulatory requirement applies.
- An active investigation requires preservation.
- An insurance requirement applies.
- An audit requires additional historical evidence.
- A critical security investigation requires extended retention.
- A business requirement justifies a longer period.
Exceptions should document:
- Reason
- Log source
- Required retention period
- Risk
- Owner
- Approval
- Review date
- Disposal date where applicable
16. Legal Hold / Investigation Hold
Where an authorized legal, regulatory, investigative, or incident-preservation requirement exists, relevant logs must be protected from routine deletion.
The responsible owner should document:
- Hold reason
- Scope
- Relevant systems
- Date range
- Log sources
- Responsible person
- Approval
- Release/closure condition
The normal retention schedule should resume only after the hold is formally released, where applicable.
17. Log Disposal
At the end of the approved retention period, logs should be securely deleted or otherwise disposed of according to the organization’s information-disposal requirements.
Before disposal, the owner should verify:
- Retention period has expired.
- No investigation hold exists.
- No legal/regulatory requirement requires continued retention.
- No active incident depends on the logs.
- No contractual requirement requires continued retention.
- Disposal is authorized.
Where technically and operationally appropriate, automated lifecycle rules may be used.
18. Log Retention Register
The organization should maintain a central register for important log sources.
| Field | Description |
|---|---|
| Log ID | Unique identifier |
| Log Source | System/service generating logs |
| Log Type | Authentication, cloud, application, etc. |
| System Owner | Responsible owner |
| Environment | Production/Corporate/Development |
| Information Sensitivity | Classification |
| Security Criticality | Low/Medium/High/Critical |
| Collection Method | SIEM/API/agent/cloud service |
| Storage Location | Approved repository |
| Retention Period | Approved duration |
| Protection | Encryption/immutability/access controls |
| Monitoring | Monitoring method |
| Backup | Required/not required |
| Investigation Hold | Yes/No |
| Disposal Method | Deletion/lifecycle rule |
| Last Review | Review date |
| Next Review | Planned date |
| Approval | Authorized owner |
19. Log Retention Review
The Security or ISMS function should periodically review:
- Whether required logs are being generated.
- Whether critical logs are being collected.
- Whether retention periods remain appropriate.
- Whether logs can be retrieved.
- Whether access is appropriately restricted.
- Whether log integrity controls remain effective.
- Whether logging gaps occurred.
- Whether incidents required extended retention.
- Whether legal, regulatory, customer, or contractual requirements changed.
- Whether storage costs remain reasonable.
- Whether unnecessary logs can be removed.
20. Minimum Security Log Review Checklist
Before closing a review, confirm:
- Critical systems have identified security logs.
- Log sources are documented.
- Retention periods are defined.
- Retention periods are risk-based.
- Critical logs are protected against unauthorized deletion.
- Access is restricted.
- Logs are encrypted where required.
- Time synchronization is configured.
- Critical logging failures are detected.
- Security alerts are monitored.
- Incident-related logs can be preserved.
- Investigation holds can override normal deletion.
- Disposal is controlled.
- Retention register is current.
- Log access is periodically reviewed.
- Retention requirements are periodically reassessed.
21. Startup Implementation
A startup does not need a complicated SIEM architecture on day one.
A practical implementation could be:
Identity Provider
→ Authentication/MFA Logs
AWS
→ CloudTrail + Security Findings + Relevant Service Logs
Production Application
→ Application/API Security Logs
Endpoint
→ EDR/Security Logs
Central Repository
→ Protected Log Storage
Monitoring
→ Security Alerts
Incident Response
→ Investigation + Evidence Preservation
Retention
→ Automated Lifecycle Rules
The important objective is not the number of security tools. It is the ability to answer:
Who did what, when, from where, against which system, and what happened afterward?
22. Relationship With Other ISMS Documents
This standard should operate as part of the wider ISMS.
| Document | Relationship |
|---|---|
| Logging & Monitoring Standard | Defines what should be logged and monitored |
| Access Control Policy | Defines access to systems and logs |
| Incident Response Procedure | Uses logs during incident response |
| Security Event Assessment Procedure | Uses logs to validate events |
| Evidence Collection Procedure | Defines collection of investigation evidence |
| Evidence Register | Tracks preserved evidence |
| Digital Forensics Procedure | Supports forensic examination |
| Incident Investigation Report | Uses logs as investigation evidence |
| Incident Timeline | Uses timestamps and log records |
| Root Cause Analysis | Uses logs to establish cause |
| Corrective Action Tracker | Tracks improvements resulting from findings |
| Risk Register | Records material security risks |
| ISMS Improvement Log | Tracks systemic improvements |
| Business Continuity/DR | Uses logs for recovery and investigation |
23. ISO 27001 Alignment
This standard supports the organization’s implementation of ISO/IEC 27001:2022 controls related to areas such as:
- Event logging
- Monitoring activities
- Information security event assessment
- Incident management
- Access control
- Privileged access
- Configuration management
- Protection of information
- Backup and recovery
- Evidence preservation
- Security monitoring
The exact controls and implementation should be determined through the organization’s risk assessment and Statement of Applicability (SoA).
The retention periods in this document are organizational standards; ISO 27001 does not prescribe one universal retention period for every type of security log.
24. Audit Evidence
Typical evidence demonstrating implementation includes:
- Security Log Retention Standard
- Log Retention Register
- AWS CloudTrail configuration
- Identity-provider logs
- MFA logs
- WAF/security logs
- SIEM/log-management configuration
- Log retention configuration
- Storage access-control configuration
- Immutable-storage configuration where applicable
- Log monitoring alerts
- Logging failure alerts
- Log access review records
- Incident-related preserved logs
- Evidence Collection Forms
- Evidence Register
- Chain-of-Custody records where applicable
- Retention review records
- Log disposal records
- Exceptions and approvals
- Internal audit observations
- Corrective actions
25. Example Audit Trail
Log Source Identified
→ Security Value Assessed
→ Retention Requirement Defined
→ Retention Period Approved
→ Log Collection Enabled
→ Central Storage Configured
→ Access Restricted
→ Integrity Protection Implemented
→ Monitoring Enabled
→ Retention Period Monitored
→ Investigation Hold Applied When Required
→ Relevant Incident Logs Preserved
→ Retention Reviewed
→ Disposal Authorized
→ Logs Securely Disposed
→ Record Updated
26. Final Principle
A security log is useful only if the organization can generate it, protect it, retain it long enough, retrieve it when needed, understand its context, and preserve it when it becomes evidence.
Log → Protect → Retain → Monitor → Retrieve → Preserve → Investigate → Dispose Securely
The objective is not “keep everything forever.”
The objective is:
Keep the right logs + for the right period + with the right protection + with the ability to use them when security matters.