Logging and Monitoring Policy Template: Log Sources, Retention and Review

Most incident investigations stall on the same problem: the log that would have answered the question was never collected, was overwritten, or cannot be trusted. This template sets out a logging and monitoring policy that defines which sources must be logged, what each record must contain, how long logs are kept, how they are protected and who reviews them. It treats service accounts, API keys, tokens and workload identities as first-class log subjects, because machine credentials now perform most of the activity in cloud and SaaS estates. It is written for security, IT operations and risk teams who need a policy they can adopt quickly and then implement through standards and procedures. Have it reviewed by legal, privacy and compliance before adoption.

How to use this template

• Replace text in square brackets, such as [Organisation], [Security operations] and [X days], with your own terms and values.
• "Must" indicates a mandatory requirement; "should" indicates a recommended practice where a documented exception may be justified.
• Keep the policy short and stable. Put product-specific settings (for example audit policy GPOs or cloud trail configuration) in a separate logging standard that the policy references.
• The retention values in section 4.4 are starting points drawn from published guidance, not legal requirements. Check sector rules, contracts and data protection law before you set them.

1. Purpose

This policy sets the requirements for generating, collecting, protecting, retaining, reviewing and disposing of security-relevant logs at [Organisation]. Its aims are to detect malicious or unauthorised activity quickly, to support investigation and recovery after an incident, to provide evidence of accountability for the actions of people and non-human identities, and to meet [Organisation]'s legal, regulatory and contractual obligations.

2. Scope

This policy applies to all systems that store or process [Organisation] data or support its services, whether hosted on premises, in public cloud or by third parties, including:

• Servers, endpoints, virtual machines, containers and Kubernetes clusters.
• Identity providers, directory services, privileged access and secrets management platforms.
• Cloud control planes (for example AWS, Azure and Google Cloud management APIs) and SaaS applications.
• Network and security devices: firewalls, VPNs, proxies, DNS, email gateways and load balancers.
• Business applications, databases and APIs, including CI/CD pipelines and AI agents.
• All identities that act on these systems: employees, contractors, administrators, service accounts, API keys, OAuth applications, workload identities and AI agents.

It applies to all staff, contractors and third parties who own, operate or administer in-scope systems.

3. Roles and responsibilities

• [Chief Information Security Officer]: owns this policy, approves the logging standard and retention schedule, and approves exceptions.
• [Security operations]: operates the central log platform (SIEM), maintains detection content, triages alerts and performs log reviews.
• System owners: ensure their systems generate and forward the required logs, fix collection failures and confirm coverage at onboarding.
• [IAM team]: ensures identity platforms log authentication and authorisation events for human and non-human identities, and maintains the inventory that maps each service account, API key and workload identity to an owner.
• [Platform and cloud engineering]: configures cloud audit logging at organisation or tenant level, time synchronisation and log transport.
• [Data protection officer]: advises on personal data in logs, retention limits and lawful basis for monitoring.
• [Internal audit]: independently tests compliance with this policy.

4. Policy statements

4.1 Log sources

• Every in-scope system must generate security logs before it enters production. Onboarding to the central log platform must be part of the system acceptance criteria.
• As a minimum, the following must be logged: successful and failed authentication; privilege use and changes to accounts, groups, roles and permissions; creation, change and deletion of credentials, keys and secrets; administrative and configuration changes; security tool status changes; access to data classified [Confidential] or above; and network connections crossing trust boundaries.
• Non-human identity activity must be logged with the same depth as human activity. This includes service principal and managed identity sign-ins, API key and access key usage (calling identity, key identifier, source address and API called), token issuance and refresh, OAuth consent grants, secrets manager read operations and CI/CD pipeline runs.
• Cloud audit logging must be enabled at organisation, management group or tenant level, so that new accounts, subscriptions and projects inherit it and cannot opt out.
• AI agents must log the agent identity, the principal on whose behalf they act, the tool or API called, the credential used and the outcome of each action.
• The logging standard [reference] must list the required events for each platform and must be reviewed when platforms change.

4.2 Log content and time

• Each record must contain at least: timestamp, event type, source system, identity (user, service account, key or workload ID), source and destination address where applicable, object acted on, and outcome (success or failure).
• All systems must synchronise to [Organisation]'s approved authenticated time sources. Unauthenticated public NTP pools must not be used in production.
• Timestamps must be recorded in UTC, or with an explicit offset, in ISO 8601 or RFC 3339 format with at least millisecond precision where the source supports it.
• Logs must not contain passwords, private keys, full API keys or tokens, session cookies or full payment card numbers. Where a credential must be identified, log a key ID, fingerprint or truncated value.

4.3 Collection and protection

• Logs must be forwarded to the central log platform within [5] minutes of generation for sources rated high criticality, and within [24] hours for others.
• Log transport must be encrypted. Sources must buffer locally to survive network interruptions of at least [X hours].
• Logs must be protected against unauthorised access, modification and deletion. Central storage must be write-once or append-only, or protected with cryptographic integrity checks (for example signed and chained digest files), and integrity must be verified [monthly] and whenever logs are used as evidence.
• Read access to logs must be limited to roles with a job need. No one, including administrators of a source system, may delete or alter its logs in central storage. Access to the log platform must itself be logged and reviewed [quarterly].
• Copies of critical logs should be stored in a separate account, subscription or tenant from the systems that generate them.
• Clearing a log, stopping a logging agent or disabling an audit trail must generate a high-priority alert.

4.4 Retention

Logs must be retained according to the following schedule unless a longer period is required by law, regulation, contract or a legal hold. Logs must be securely disposed of at the end of the period.

4.5 Monitoring and review

• [Security operations] must maintain detection rules for the threats in [Organisation]'s threat model, including use of credentials from new locations, service accounts signing in interactively, API keys used outside their normal pattern, mass secret reads, new OAuth consent grants, privilege escalation and log tampering.
• High-severity alerts must be triaged within [X minutes] and handled under the [Incident Response Plan].
• Privileged activity and changes to non-human identities with administrative rights must be reviewed at least [weekly].
• Missing log sources must be detected automatically: an alert must fire when an expected source stops sending for more than [X hours].
• Detection coverage must be tested at least [twice a year] through exercises or purple-team testing, and lessons from incidents must be fed back into the logging standard.

4.6 Privacy

• Monitoring of staff must be proportionate, documented and communicated in line with [Data protection policy] and [employee monitoring notice].
• Logs containing personal data must be handled according to their classification and must not be used for purposes other than those stated in this policy without approval from [Data protection officer].

5. Exceptions

Where a system cannot meet this policy (for example a legacy or OT device that cannot forward logs), the system owner must request an exception from [CISO]. The request must state the gap, the risk, compensating controls (such as network-level monitoring or a log collector in front of the device) and an expiry date of no more than [12 months]. Exceptions must be recorded in the [risk register] and reviewed before expiry.

6. Compliance and monitoring

[Security operations] will report log source coverage and collection health monthly to [CISO]. [Internal audit] will test compliance at least annually, including sampling systems for onboarding, checking retention and validating integrity controls. Non-compliant systems may be blocked from production. Breaches of this policy by staff may be handled under [disciplinary procedure].

7. Review and approval

This policy is owned by [policy owner], approved by [approving body] on [date], and will be reviewed at least annually, or sooner after a significant incident, change in regulation or change in [Organisation]'s technology estate.

Implementation guidance

Where the requirements come from

• Retention: the NCSC recommends keeping the most important logs for at least 6 months. US OMB memorandum M-21-31 sets 12 months in active storage and 18 months in cold storage for most log categories, and 72 hours for full packet capture. The schedule above uses these as defaults.
• Time: M-21-31 asks for ISO 8601 / RFC 3339 timestamps with millisecond precision and treats public, unauthenticated NTP pools as a last resort. The NCSC recommends recording time in UTC.
• Integrity: M-21-31 requires cryptographic protection and periodic hash checks. AWS CloudTrail log file integrity validation is one example: it hashes each log file with SHA-256, delivers an hourly digest signed with SHA-256 with RSA, and chains each digest to the previous one. Enabling it only delivers digests; you still have to run validation.
• Non-human identity logs: Microsoft Entra separates interactive, non-interactive, service principal and managed identity sign-in logs. Collect all four; many tenants forward only interactive sign-ins and miss most machine activity.

Phased rollout

1. Inventory log sources against the asset and identity inventory, and rate each source by criticality. Start with identity providers, cloud control planes, secrets managers and privileged access.
2. Write the logging standard: per-platform events, for example Windows audit policy settings and Event ID 1102 (audit log cleared), cloud trail settings and SaaS audit APIs.
3. Fix time synchronisation and the timestamp format before onboarding at scale; correlation fails without it.
4. Onboard sources in waves, with a pilot group first. Confirm parsing, field mapping (identity, key ID, outcome) and volume before moving on. Roll back a source by disabling its forwarder, not by turning off logging on the source.
5. Apply retention tiers and immutability, then test restore from archive.
6. Build detections and the missing-source alert, then run a tabletop or purple-team test against them.

Decision guidance

Small organisations can meet most of this policy with native cloud and SaaS audit logs, a managed SIEM or log service and a short list of detections focused on identity. Larger organisations usually need tiered storage, because hot retention of endpoint and network telemetry for 12 months is costly; keep identity, cloud control plane and secrets logs hot for longest, as they answer "who did what with which credential".

Framework mapping

Attackers target logs directly: MITRE ATT&CK T1685 Disable or Modify Tools and T1685.005 Clear Windows Event Logs describe the behaviour section 4.3 is designed to catch. CIS Controls v8.1 Control 8 (Audit Log Management) covers the same ground.

Metrics

• Source coverage: percentage of in-scope systems and identity platforms sending logs centrally (target [98%] for high criticality).
• Non-human identity coverage: percentage of service accounts, API keys and workload identities whose usage appears in central logs.
• Collection gaps: number and duration of missing-source alerts per month.
• Integrity checks: percentage of scheduled integrity validations completed and passed.
• Time to triage: median time from high-severity alert to triage.

Common failure patterns

• Logs kept only on the device: attackers who gain administrative access clear them. In the Salt Typhoon telecom intrusions, the group cleared logs while capturing traffic and, in one case, kept access for over three years using stolen credentials.
• Human sign-ins only: service principal and API key usage is not collected, so a stolen machine credential is invisible.
• Retention shorter than dwell time: the evidence has rolled over by the time the intrusion is found.
• Secrets in logs: debug logging writes tokens and keys, turning the log platform into a credential store.
• Silent collection failure: an agent stops after an upgrade and no one notices for weeks.

References and related guides

• NCSC: 10 Steps to Cyber Security, Logging and monitoring
• NCSC: Introduction to logging for security purposes
• OMB: M-21-31 Improving the Federal Government's Investigative and Remediation Capabilities
• NIST: SP 800-92 Rev. 1 Cybersecurity Log Management Planning Guide (initial public draft)
• NIST: SP 800-53 Rev. 5
• AWS: CloudTrail log file integrity validation
• Microsoft Learn: Sign-in logs in Microsoft Entra ID
• Platform and detection detail: see the SIEM Guide, the Detection Engineering Guide, the Log Management and Retention Guide and the Cloud Logging and Audit Trail Guide.
• Machine credentials as log subjects: see the Service Account Security Guide and the API Key Management Guide.

This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: Incident Response Plan Template · Change Management Policy Template · Privileged Session Management Guide · NIST SP 800-92 Log Management Guide