Logging and Monitoring Procedure

1. Purpose

This procedure sets out how the Organisation records events on its systems, protects those records, reviews them and acts on what they show. Its aims are to detect misuse and attacks early, to prove who did what and when, to support investigations and legal requests, and to demonstrate that controls operate. It implements the Logging and Monitoring Policy.

2. Scope

• In scope: all servers, endpoints, network and security devices, databases, applications, identity systems, cloud services and customer-facing platforms that store, process or transmit Organisation or customer information.
• In scope: administrative and privileged activity, remote access, physical access systems, backup and recovery tools, and the logging and monitoring tools themselves.
• Out of scope: the content of personal communications beyond what the Acceptable Usage Policy allows, and logs held entirely by customers on systems the Organisation does not operate. Where the Organisation relies on a supplier's logs, the Supplier Relationship Management Procedure governs access to them.

3. Terms and Definitions

4. Roles and Responsibilities

5. System Classes

Systems are placed in one of three classes by the sensitivity of what they hold and their role in the business. The class sets how much is logged, how long it is kept and how often it is reviewed. The owner records the class in the log source register (Annexure A).

6. What Is Logged

The following minimum events are recorded. System owners may log more but may not log less without a recorded exception. Each record must carry at least the date and time (with time zone), the source system, the user or service identity, the action, the object affected, the outcome and the source address where one exists.

7. Time Synchronisation

All systems synchronise to the Organisation's approved time sources, which in turn use at least [two] independent reference sources. Clock drift beyond [one second] on Class 1 systems raises a ticket; the time zone and format are the same everywhere that logs are collected.

8. Collection, Protection and Retention

8.1 Collection and integrity

• Class 1 and Class 2 sources forward logs in near real time to the central logging platform; local copies are kept only for the buffer period of [24 hours].
• Logs are transmitted over encrypted channels where the platform supports them and are time-stamped on receipt.
• Write access to logs is limited to the collection service. Administrators of source systems must not be able to edit or delete their own logs on the platform.
• The central platform records every access to its contents, including searches and exports of raw data.
• Integrity checks (hashing or write-once storage) are applied to Class 1 logs and verified [monthly].
• Loss of log flow from a Class 1 source for more than [15 minutes] raises an alert; for Class 2, [4 hours].

8.2 Retention

Retention is the longer of the periods below, any contractual obligation to a customer, and any legal hold. Logs of systems operated in India are stored within Indian jurisdiction. The CERT-In Directions of 28 April 2022 require ICT logs to be kept for 180 days within Indian jurisdiction [confirm the current requirement].

8.3 Access and disposal

• Access to raw logs is by role and approved in the ticketing tool; analysts use read-only roles.
• Logs that identify individuals are used only for security, operations, audit and legal purposes; use for staff performance review requires HR and the data protection officer to approve.
• Expired logs are deleted automatically by the platform and the deletion jobs are checked [quarterly].
• Logs needed as evidence are exported with a hash and handled as described in the Incident Management Procedure.

9. Monitoring and Alerting

9.1 Alert priorities and response

9.2 Minimum alert rules

• Multiple failed logins followed by a success for the same account within [10 minutes].
• Use of a privileged account outside approved hours or from a new location or device.
• Creation of accounts, role changes or group membership changes outside a recorded request.
• Disabling or clearing of logs, audit policies, endpoint protection or monitoring agents.
• Access to Restricted data by an account that has not used it in the last [90 days].
• Unusually large data transfers out of the network, or uploads to unapproved storage.
• Communication with addresses or domains on threat intelligence lists, as supplied under the Threat Intelligence Policy.
• Vulnerable or end-of-life software detected on Class 1 systems.
• Physical access to a secure area outside the person's usual hours without a matching approval.

9.3 Tuning

The security operations team reviews rules [monthly] for false positives and gaps, using incident outcomes, penetration test findings and new threat intelligence. Every rule change is recorded with the reason, tested before use and approved by the Head of IT Security for Critical and High rules.

10. Log Review Procedure

1. PrepareThe analyst lists the sources due for review from the schedule below and confirms that collection was complete for the period. Output: review checklist.
2. ReviewLook for the minimum alert patterns, accounts with unusual activity, new administrators, changes to audit settings, failed backup or patch jobs, and gaps in the logs. Time: per schedule.
3. InvestigateRaise a ticket for every unexplained finding, assign it to the system owner, and set a due date by priority. Escalate suspected incidents under the Incident Management Procedure.
4. ReportSummarise findings, trend and outstanding items in the log review report and send to the Head of IT Security within [3 working days] of the review.
5. CloseVerify that every ticket has an outcome. Unresolved items older than [30 days] go to the ISMS steering group.

11. Responding to Logging Failures

1. DetectAn alert or review shows a source has stopped sending logs, the platform has run out of space, or time sync has failed.
2. AssessThe security operations team decides whether the failure could hide an attack; if so, treat as an incident.
3. RestoreIT operations restores collection and, where possible, recovers buffered logs. Target: Class 1 within [4 hours].
4. RecordLog the gap in the log source register with start and end times and the cause.
5. PreventAdd capacity, redundancy or monitoring so the same failure raises an earlier alert.

12. Measures

13. Records and Evidence

Annexure A: Log source register

Annexure B: Log review record

Annexure C: Log access request

14. Exception

Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.

15. Enforcement

Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.

16. Review

This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.

ISO/IEC 27001:2022 references

Related documents

• Logging and Monitoring Policy
• Incident Management Procedure
• Network Security Procedure
• Information Security Monitoring and Compliance Policy
• Patch Management Procedure
• Backup Management and Retention Procedure