.svg){kind=logo}
You’re three weeks from your SOC 2 audit and the auditor asks for evidence that someone is actually reviewing your security logs. You have logs. You have CloudWatch configured. But you don’t have a written policy, and you don’t have records showing anyone reviewed anything on a schedule. That’s when most teams realise that having logging infrastructure and having a logging and monitoring programme are two very different things.
A logging and monitoring policy is the document that bridges that gap. It defines what events your systems must record, how long those logs are kept, who reviews them, at what frequency, and what happens when something unusual shows up. It’s not a technical runbook. It’s the formal commitment, in writing, that your organisation treats its audit trail as a real security control.
It’s required or strongly recommended across the major compliance frameworks:
- SOC 2: CC7.2 (System Monitoring) requires that system components are monitored for anomalies and deviations from baseline
- ISO 27001: Annex A 8.15 (Logging) and 8.16 (Monitoring) are mandatory controls in the 2022 standard
- HIPAA: §164.312(b) is a required implementation specification for audit controls, with no flexibility
- GDPR: Article 32 requires technical measures to ensure ongoing confidentiality and integrity, and logging supports that directly
By the end of this, you’ll know exactly what to put in a logging and monitoring policy, how to write one that holds up in an audit, and you’ll have a free template you can use today.
Here’s what I’ll cover:
- The difference between logging, monitoring, and log management
- Why log monitoring gaps get companies into trouble
- Which companies need this policy
- What a logging and monitoring policy must include
- A free, pre-populated template
- How to roll it out step by step
- SOC 2, ISO 27001, HIPAA, and GDPR requirements mapped
- What evidence auditors actually want to see
- Common mistakes that fail audits
Free Template
Download the Free PDF Template
Pre-built and compliance-ready. Customise and use immediately.
Logging, Monitoring, and Log Management: Sorting Out the Terminology
Before writing anything, it helps to know that “logging and monitoring policy,” “monitoring and logging policy,” and “log management policy” all refer to the same type of document. The order of the words varies; the substance doesn’t. If you’re searching for templates or examples and finding slightly different terminology, you’re looking at the same control.
Key insight
Logging and monitoring are different controls that need to be addressed together. Logging captures what happened. Monitoring detects when something is wrong. A logging and monitoring policy that only covers log retention without defining alerting thresholds will fail a SOC 2 or ISO 27001 audit.
Where it gets slightly more nuanced is between a logging policy and a logging and monitoring policy. A logging-only policy covers what to capture and how long to keep it. A logging and monitoring policy covers the full cycle: capture, retain, review, alert, and escalate. For any compliance framework you’re likely to care about, you need the full cycle.
You’ll also see it called a security logging and monitoring policy in some frameworks and vendor documentation. That’s the same document with a narrower name, emphasising that the scope is security-relevant events rather than all operational logs.
What is the difference between logging and monitoring?
Logging is the act of recording events: a user logs in, a configuration changes, an API call fails, a privileged action is taken. The log is the record.
Monitoring is the act of reviewing those records, either in real time through automated alerts or on a schedule through manual review. Monitoring is what turns a log file into a security control.
One without the other is an incomplete control. Logging without monitoring is a filing cabinet nobody opens. Monitoring without defined log sources is guesswork. Your policy needs to cover both halves.
Who owns this policy?
The policy owner is the person accountable for keeping it current, getting it approved, and making sure it’s followed. At most startups, that’s the CTO or Head of Engineering. At larger companies, it’s the Security Lead or CISO.
The policy must name a specific person, not just “the engineering team.” Auditors will ask who owns this control, and “everyone” is not an acceptable answer.
Why Log Monitoring Gaps Get Companies in Trouble
Here’s a scenario I’ve seen play out more than once. A company gets breached. The attackers had access for weeks. Nobody noticed because nobody was reviewing logs. The logs existed. The events were captured. But there was no process for looking at them, no alerts configured for the access patterns that should have raised a flag, and no policy requiring anyone to check.
Free Demo
SOC 2 CC7.2 requires continuous monitoring — not just log storage
ComplyJet generates a logging and monitoring policy mapped to SOC 2 CC7.2, ISO 27001 A.8.15, and HIPAA, with a pre-built log retention matrix and alerting requirements framework.
The breach is the obvious problem. The breach going undetected for weeks is a separate, auditable failure, and the second one is the one that shows up in your audit report.
From a security perspective, your logs are the primary mechanism for detecting unauthorized access, privilege abuse, data exfiltration, and configuration tampering. Without active monitoring, you find out about incidents when they’re already serious, not when they start.
From a compliance perspective, auditors don’t just want a policy document. They want evidence that logs exist, are retained for the required period, and are actively reviewed. A policy alone fails a SOC 2 Type II audit because auditors test the entire audit period, not just a point in time. If your log reviews are improvised rather than documented, the evidence won’t hold.
From an operational perspective, incident response without a reliable log trail is guesswork. You can’t reconstruct what happened, determine scope, or prove containment without logs that were captured and retained before the incident. Mean time to detect goes up dramatically without monitoring in place.
Is a Logging and Monitoring Policy Required for Your Business?
The short answer: if your business stores customer data and you’re pursuing or maintaining any compliance certification, yes.
Why it matters
Without a logging and monitoring policy, you have no documented evidence that your SIEM or log aggregator is configured correctly or that alerts are being reviewed. Auditors don't just want to see that logs exist — they want a policy that defines what must be logged, how long it must be retained, and who reviews alerts.
More specifically, you need a formal logging and monitoring policy if:
- You’re pursuing SOC 2 Type I or II: CC7.2 is one of the most commonly tested controls in a Type II audit. Auditors will ask for log review records spanning the entire audit period.
- You’re pursuing or maintaining ISO 27001 certification: Annex A 8.15 and 8.16 are mandatory controls in the 2022 version of the standard. They’re not optional.
- You’re a HIPAA-covered entity or business associate: §164.312(b) requires audit controls on systems containing ePHI. It’s a required implementation specification, not addressable, meaning you can’t make a risk-based decision to skip it.
- You handle EU personal data under GDPR: Article 32 requires appropriate technical measures for confidentiality and integrity. An audit trail is a core part of that.
- You’re a B2B SaaS company selling into enterprise: enterprise procurement teams now routinely ask for security documentation. A logging and monitoring policy is often on that list.
If you’re an early-stage startup that doesn’t yet have a compliance programme, a lightweight one-page policy still satisfies the control. Complexity should scale with your environment, not become an excuse to skip the requirement entirely.
What a Logging and Monitoring Policy Must Cover
The policy defines the what, where, how long, and who. Implementation details, specific tool configurations, SIEM rule logic, and alert thresholds belong in runbooks. The policy sets the requirements; the runbooks document how you meet them.
| Policy Section | What to Include |
|---|---|
| Purpose | Why this policy exists; the security and compliance risks it addresses; the link to your broader information security programme |
| Scope | Every system, environment, and person this policy applies to: production, staging, CI/CD pipelines, SaaS tools with admin access, cloud infrastructure, third-party integrations, and all staff with system access |
| What Must Be Logged | A specific list of event types, not vague language like “security-relevant events.” Name the categories: authentication events, privileged access, data access, API calls, configuration changes, errors and exceptions |
| Security Event Types | A security event logging and monitoring policy goes one level deeper: it names the specific events most likely to indicate a breach or misuse: failed login attempts, permission escalations, data exports above a threshold, firewall rule changes, new user creation, out-of-hours admin actions |
| Log Retention | Minimum retention periods by log type. Common baseline: access logs 90 days, security events 12 months. HIPAA-covered systems require 6 years. Define this explicitly. |
| Monitoring and Alerting | Who reviews logs, on what schedule, using which categories of tools. Alert response SLAs: how long from detection to initial triage. |
| Roles and Responsibilities | Who configures logging infrastructure. Who reviews logs and responds to alerts. Who owns the policy and is accountable for its maintenance. |
| Access Controls | Who can access raw log data. Least-privilege enforcement. Protection against log tampering or deletion. |
| Incident Escalation | How a detected anomaly triggers the incident response process. What the escalation path looks like and what the response SLA is. |
| Exceptions | How exceptions are requested, who approves them, how they’re documented, and when they expire. |
| Review Cadence | How often the policy itself is reviewed (minimum annually), and what infrastructure or compliance changes trigger an out-of-cycle review. |
| Enforcement | Consequences for non-compliance, and who is responsible for enforcement. |
A note on the “What Must Be Logged” section: this is the most commonly incomplete part of logging policies. Vague language like “all security-relevant events” is not acceptable to an auditor. Name the specific event types. An auditor who asks “what must be logged?” should be able to read your policy and get a concrete answer.
Logging and Monitoring Policy Template (Free Download)
Use this template as-is or adapt it for your stack, team size, and frameworks. Every section is pre-filled with best-practice text. Update the bracketed values and adjust the specifics to match your environment. It’s designed to work as an ISO 27001 logging and monitoring policy template (covering Annex A 8.15 and 8.16) as well as for SOC 2, HIPAA, and GDPR programmes.
Free Template
Download the Free PDF Template
Pre-built and compliance-ready. Customise and use immediately.
Logging and Monitoring Policy
Version: 1.0 Owner: [Name, Title] Approved by: [Name, Title] Effective date: [Date] Next review: [Date, typically 12 months from effective date]
1. Purpose
This policy establishes requirements for logging system events, retaining log data, monitoring for anomalous activity, and escalating potential security incidents at [Company Name]. Its purpose is to ensure that a reliable audit trail exists across all covered systems, that the organisation can detect and respond to security events promptly, and that it can demonstrate compliance with applicable regulatory and contractual requirements including SOC 2, ISO 27001, HIPAA, and GDPR.
2. Scope
This policy applies to all systems, infrastructure, and personnel listed below.
| Category | In Scope |
|---|---|
| Production infrastructure | Yes |
| Staging and test environments | Yes, for authentication and admin events |
| CI/CD pipelines | Yes, for admin actions and configuration changes |
| SaaS tools with admin access | Yes (identity provider, cloud console, source control, and similar) |
| Cloud infrastructure | Yes |
| Third-party integrations with system access | Yes |
| All employees and contractors with system access | Yes |
3. Roles and Responsibilities
| Role | Responsibility |
|---|---|
| Policy Owner ([Name/Title]) | Maintain and update this policy. Ensure it is reviewed annually and after significant infrastructure changes. |
| Engineering Lead ([Name/Title]) | Configure and maintain logging infrastructure across all covered systems. Ensure log coverage matches this policy. |
| Security Reviewer ([Name/Title]) | Conduct scheduled log reviews. Respond to and escalate alerts per the Incident Response Policy. |
| All engineering and operations staff | Follow logging configuration requirements. Report suspected log integrity issues immediately. |
4. What Must Be Logged
The following event types must be captured on all in-scope systems.
| Event Category | Required Events |
|---|---|
| Authentication | All successful and failed login attempts, including MFA challenges and outcomes |
| Privileged access | All actions taken by administrative or privileged accounts; any use of elevated permissions |
| User management | Account creation, deletion, role changes, and permission modifications |
| Data access | Access to sensitive or customer data, including reads of large data sets or data exports |
| API activity | Inbound and outbound API calls on production systems, including authentication and authorisation outcomes |
| Configuration changes | Changes to firewall rules, IAM policies, security group settings, and system configuration |
| Errors and exceptions | Application errors and unhandled exceptions that may indicate attack or misconfiguration |
| Third-party access | Events generated by external services or integrations accessing company systems |
5. Log Retention
Log data must be retained for the minimum periods below. Logs must not be deleted or modified during the retention period.
| Log Type | Minimum Retention |
|---|---|
| Authentication and access logs | 90 days |
| Security event logs | 12 months |
| Admin and privileged access logs | 12 months |
| Application error logs | 90 days |
| API activity logs | 90 days |
| Audit logs for HIPAA-covered systems | 6 years |
6. Monitoring and Alerting
Automated alerting must be configured for the following event types at minimum:
- Failed login attempts exceeding [X] attempts within [Y] minutes from a single source
- Privileged actions taken outside standard business hours
- Data exports exceeding [defined volume threshold]
- Any change to IAM policies or firewall rules
- New administrative account creation
Log review schedule: Security event logs must be reviewed on a [weekly/daily] basis by the designated Security Reviewer. A written record of each review must be maintained.
Alert response SLA: Alerts must be triaged within [4 hours] of detection during business hours and within [24 hours] outside business hours.
7. Access Controls
Access to raw log data is restricted to personnel listed in Section 3. Access must follow the principle of least privilege. Log data must be stored in a system that prevents modification or deletion by any user, including administrators. Any attempt to tamper with or delete log data must be treated as a security incident and escalated per the Incident Response Policy.
8. Incident Escalation
Any anomaly identified during log review or triggered by automated alerting must be escalated to the Security Reviewer immediately. If the anomaly meets the criteria defined in the Incident Response Policy, the incident response process must be initiated without delay. All escalations, including those confirmed to be benign, must be documented.
9. Exceptions
Exceptions to this policy require written approval from the Policy Owner. Each exception must document: the system or requirement being excepted, the reason for the exception, the alternative control in place, the risk owner, and the expiry date. Exceptions must be reviewed at least annually.
10. Enforcement
Failure to comply with this policy, including intentional modification or deletion of log data, failure to report suspected log integrity issues, or failure to maintain the logging configuration required by this policy, constitutes a significant policy violation and is subject to disciplinary action up to and including termination.
11. Review Cadence
This policy will be reviewed at least annually. An out-of-cycle review is required following: any significant change to production infrastructure, the addition of new SaaS tools with admin-level access, a change in applicable compliance frameworks, or any security incident that reveals a gap in logging or monitoring coverage.
12. Version History
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | [Date] | [Name] | Initial version |
How to Write and Roll Out a Logging and Monitoring Policy
Having the template is the easy part. Getting it approved, implemented, and producing evidence is where most teams stall. Here’s the full sequence:
Free Demo
Logging policy + retention matrix + alerting framework — all in one
ComplyJet ships a logging and monitoring policy with a pre-built log source matrix, retention requirements by data type, and alert review requirements — mapped to every framework control.
- Assign a policy owner. Name a specific individual, not a team. The CTO, Head of Engineering, or Security Lead is the right level for most companies.
- Audit your current logging coverage. Before you commit to what the policy requires, check what your systems actually capture today. Identify the gaps between current state and what the policy will mandate.
- Define log sources explicitly. Name every system this policy covers. “All production systems” is a start; an actual list is what an auditor wants to see.
- Set retention periods. Align to your most demanding framework requirement. If you’re HIPAA-covered, 6 years for audit logs is the floor. For SOC 2 without HIPAA, 90 days to 12 months is standard practice.
- Configure monitoring and alerting. Define what triggers an alert, who receives it, and what the response SLA is. Logging without alerting is not a monitoring programme.
- Get the policy formally approved. This means sign-off from the appropriate level: exec, board, or equivalent. The approval must be documented and dated.
- Communicate it to your team. Engineering, DevOps, and any staff with system access need to know the policy exists, where to find it, and what it requires of them.
- Collect acknowledgements. For HIPAA and ISO 27001 programmes especially, documented acknowledgements from relevant staff are expected by auditors.
- Map to your compliance controls. If you’re using a GRC tool, map this policy to the relevant controls: SOC 2 CC7.2, ISO 27001 Annex A 8.15 and 8.16, HIPAA §164.312(b).
- Collect initial evidence. Before your first audit, gather: a log coverage inventory, retention configuration screenshots, monitoring tool setup, and at least one documented log review.
Trigger an out-of-cycle review any time you add a new production system, a new SaaS tool with admin access, or change your cloud infrastructure significantly. A policy that doesn’t reflect your current environment is worse than no policy, because it creates a documented gap. You’ll also want your log retention periods to align with your data retention policy — the two documents need to be consistent.
Audit Logging and Monitoring Policy Requirements: SOC 2, ISO 27001, HIPAA, and GDPR
The frameworks all require logging and monitoring, but they approach it differently. Here’s what each one actually asks for.
| Framework | Control / Clause | What It Requires |
|---|---|---|
| SOC 2 | CC7.2 | Monitor system components for anomalies and deviations from baseline behaviour. Establish baselines, configure alerts, and document the monitoring programme. |
| ISO 27001 | Annex A 8.15 (Logging) | Produce and retain logs of user activities, exceptions, and security events. Protect logs against tampering and unauthorised access. |
| ISO 27001 | Annex A 8.16 (Monitoring) | Monitor networks and systems for anomalous behaviour. Detect and respond to potential information security incidents. |
| HIPAA | §164.312(b) | Implement hardware, software, and procedural mechanisms to examine activity in systems that contain ePHI. This is a required specification, not addressable. |
| GDPR | Article 32 | Implement appropriate technical and organisational measures to ensure ongoing confidentiality, integrity, and availability. Logging is a core supporting control. |
A few things worth calling out specifically.
ISO 27001 Logging and Monitoring Policy: Annex A 8.15 and 8.16 in Detail
On SOC 2 CC7.2: this is one of the most commonly tested controls in a Type II audit. The auditor tests the entire audit period, typically 6 to 12 months. They’ll ask for log review evidence across that window, not just from the weeks before your audit. If your reviews are documented, this is straightforward. If they’re not, it becomes a finding. The AICPA’s Trust Services Criteria provides the full specification.
On ISO 27001 Annex A 8.15: the 2022 revision of the standard added an explicit requirement that log data be protected against modification and unauthorised access. Log integrity is now as important as log retention under ISO 27001. Your policy needs to address both, not just retention. NIST SP 800-92 is a useful reference for building a log management programme that satisfies these requirements.
On HIPAA §164.312(b): this is a required implementation specification. Unlike addressable specifications, there’s no flexibility to make a risk-based decision not to implement it. If you’re a covered entity or business associate, audit controls on ePHI systems are mandatory. The HHS Security Rule guidance covers the full set of required and addressable specifications.
What Evidence Do Auditors Expect for Logging and Monitoring?
A signed policy document is the starting point, not the finish line. Here’s what auditors typically request when they test this control.
| Evidence Type | What to Provide |
|---|---|
| Policy document | Approved, signed logging and monitoring policy with effective date and next review date |
| Log coverage inventory | A list of systems with logging enabled and which event types are captured per system |
| Retention configuration | Screenshots or configuration exports showing log retention settings for each in-scope system |
| Monitoring tool configuration | SIEM rules, alert configurations, CloudWatch alarms, or equivalent showing what triggers alerts and who receives them |
| Log review records | Documented evidence that logs were reviewed on the schedule the policy requires: tickets, review notes, or SIEM reports |
| Escalation examples | At least one documented example of an alert triggering review or escalation. A false alarm that was investigated and documented counts. |
| Access control configuration | Evidence of who has access to raw log data, showing least-privilege enforcement |
| Acknowledgement records | Evidence that relevant staff have read and acknowledged the policy |
The evidence type missing most often in first-time audits is log review records. Logs exist; reviews happen informally but aren’t documented on a schedule. That gap is easy to close before an audit and very hard to explain during one.
Logging and Monitoring Policy Mistakes That Fail Audits
These are the mistakes I see most often when reviewing logging programmes ahead of audits.
Watch out
The most common logging audit failure is log retention that doesn't meet the framework requirement. SOC 2 typically requires 90 days minimum, ISO 27001 requires a defined retention period in your policy, and HIPAA requires 6 years for security-related records. If your CloudWatch retention is set to 30 days, your logs are being deleted before auditors can inspect them.
1. Vague log source definitions. “All production systems must generate logs” sounds complete. It isn’t. An auditor will ask: which systems? which events? If your policy doesn’t name the systems and the event types, you have no way to demonstrate coverage and no way to identify gaps.
2. No retention periods in the policy. “Logs are retained as required” is not a policy statement. You need specific periods by log type, aligned to your most demanding framework requirement. Without defined periods, you can’t demonstrate you’ve met the requirement.
3. Policy exists, monitoring doesn’t. This is the most common gap. The logging infrastructure is configured. The policy is signed. But nobody reviews logs on a schedule, and there are no documented alerts. A policy that describes monitoring you’re not doing doesn’t help you: it documents a gap.
4. Policy not updated after infrastructure changes. You add a new cloud account, a new SaaS tool with admin access, or a new production environment. The policy still describes the old systems. Your coverage has a gap, and the policy says there shouldn’t be one.
5. No access controls on the logs themselves. If any engineer can delete or modify log files, your audit trail is not reliable. Auditors will ask about log integrity. The answer needs to be a technical control, not a trust statement.
6. Conflating logging and monitoring with incident response. These are related but separate controls. Your logging policy defines the audit trail and the review process. Your incident response policy defines what you do when the audit trail reveals something concerning. Both need to exist, and they need to reference each other.
Scaling Your Logging and Monitoring Policy as You Grow
The right policy for a 10-person startup is not the right policy for a 300-person company. Here’s how to right-size it at each stage.
Quick tip
At under 20 people on AWS: CloudTrail + CloudWatch with 90-day retention, a documented list of what triggers an alert, and a weekly log review process is enough for SOC 2 CC7.2. You don't need a full SIEM until you're above 50 people or have multiple infrastructure environments.
Early-stage startups (1 to 20 engineers)
Cloud-native logging covers most of what you need out of the box: AWS CloudTrail, GCP Audit Logs, and Azure Monitor capture the essential events. Add a log aggregation tool and configure basic alerting for authentication failures, admin actions, and configuration changes.
Your policy can be one page. The key is specificity, not length. Name your systems, define your retention periods, name the person doing log reviews and how often. A concise policy that matches your actual environment is more useful than a complex one that doesn’t. One person reviewing logs weekly and documenting it is a complete monitoring programme at this stage.
Growing companies (20 to 100 engineers)
At this stage you’re likely adding dedicated DevOps or security functions, and your audit complexity is growing. You need automated alerting on specific event types, not just manual review. You need defined SLAs for alert response, a documented review cadence followed consistently, and review records covering a 12-month window if you’re in a SOC 2 Type II programme.
The policy should be reviewed after any major infrastructure change, not just annually.
Larger enterprises
Full SIEM implementation, 24/7 monitoring or a contracted SOC, and compliance-mapped controls per region or business unit are appropriate at this scale. The logging and monitoring policy becomes one document in a larger programme, referencing sub-policies and runbooks for specific system types (database audit logs, network access logs, endpoint logs). The core requirements don’t change; the operational complexity does.
Keeping Your Logging and Monitoring Policy Audit-Ready
Managing a logging and monitoring policy in a Google Doc or Confluence page works until it doesn’t. Version drift, missed annual reviews, no acknowledgement trail, and no link between the policy and your compliance controls are the failure modes I see most often.
ComplyJet automates the full policy lifecycle: create from a compliance-mapped template, route for approval, collect team acknowledgements, send annual review reminders, and map directly to SOC 2 CC7.2, ISO 27001 Annex A 8.15 and 8.16, and HIPAA §164.312(b). Your evidence is linked to your controls from day one, not assembled in a rush before the audit.
FAQs: Common Logging and Monitoring Policy Questions
What is a logging and monitoring policy?
A logging and monitoring policy is a document that defines what events your systems must capture, how long logs are retained, who reviews them, and how anomalies are escalated. It covers the full cycle from log capture to review to response. It’s a foundational security control required or expected by SOC 2, ISO 27001, HIPAA, and GDPR.
Logging vs. Monitoring: What’s the Difference?
Logging is the act of recording events: a user logs in, a configuration changes, an API call fails. Monitoring is the act of reviewing those records, either in real time through alerts or on a scheduled basis through manual review. Logging without monitoring is a filing cabinet nobody opens. A complete policy covers both.
Does SOC 2 require a logging and monitoring policy?
Yes. CC7.2 of the SOC 2 Trust Services Criteria requires that system components are monitored for anomalies and deviations from established baselines. For a Type II audit, you need not just a policy document but documented evidence of log reviews spanning the entire audit period. This is one of the most commonly tested controls in SOC 2 Type II.
How long should security logs be retained?
It depends on which frameworks apply to you. HIPAA requires 6 years for audit logs on ePHI systems. ISO 27001 defers to your documented retention schedule. SOC 2 has no prescribed minimum, but 90 days for access logs and 12 months for security event logs is the common baseline. Define your retention periods explicitly in the policy; don’t leave them to discretion.
Who is responsible for log monitoring?
Your policy must name a specific person or role, not just “the engineering team.” At most startups, this is the CTO or Head of Engineering. At companies with a dedicated security function, it’s the Security Lead or a designated security engineer. Auditors will ask who owns this control, and “everyone” is not an answer they’ll accept.
What should a logging and monitoring policy include?
At minimum: which systems and event types must generate logs, minimum retention periods by log type, who reviews logs and how often, alerting requirements and response SLAs, access controls on log data, and the escalation path when an anomaly is detected. See the full table in “What a Logging and Monitoring Policy Must Cover” for a complete breakdown.
Related Policies
A logging and monitoring policy doesn’t exist in isolation. These four policies are directly connected.
- Data Retention Policy: Your log retention periods must align with your overall data retention policy. If the two documents conflict, auditors will notice.
- Information Security Policy: The parent policy that your logging and monitoring controls sit within. Your logging policy should reference it.
