Logs only help if someone reads them and the clocks agree

The useful test is simple. Imagine an incident: an account taken over, data exported, a setting changed. Which records would let you say who did what, from where, and when? Those are the events to log. Logging everything at full detail is expensive and buries the signal; logging only what a tool switches on by default leaves gaps.

• Send logs away from the source. Ship them to central storage so a compromised host cannot erase its own trail.
• Restrict who can delete. Administrators of a system should not be able to wipe its logs.
• Detect gaps. Alert when a source stops sending, which is often the first sign of trouble.
• Mind personal data. Logs often hold names, emails and addresses; treat them as personal data and avoid logging secrets.

Retention is a policy decision. Set it from your investigation needs, contracts and law, and record it per log type. For organisations in India, the CERT-In directions of April 2022 set their own expectations on log retention and on synchronising clocks; check the current text and fold it into the policy.

CERT-In's directions are commonly read as requiring a rolling log retention period kept within India and clock synchronisation to national time servers. Confirm the current wording with counsel.

Monitoring turns logs into decisions. Define a short list of things that should raise an alert, such as sign-ins from new countries for administrators, logging being switched off, large exports or repeated failed access. Then name who receives each alert, how quickly they respond, and how an alert becomes an incident under your incident process.

Control 8.17 is short and easy to overlook. If the firewall, the application and the identity provider each keep their own time, a sequence of events across them cannot be trusted, and evidence handed to a regulator or a court is weaker. Point every system at an approved time source, record which one, and store timestamps with a time zone or in UTC.

• Cloud services usually sync for you; record that fact and the provider's time service.
• On-premises servers and network devices need explicit configuration, checked as part of the baseline.
• Log pipelines should keep the original event time, not just the time the log arrived.

• A logging standard. Sources, events, retention and access, per system type.
• Coverage. In-scope systems in the inventory, matched against sources in the log platform.
• Alert handling. A sample of alerts, each traced to a response or a reasoned close.
• Review records. Evidence that someone looked, on the schedule you set.
• Time configuration. Settings on a few sampled systems pointing to the approved source.

• Logs nobody reads. Collection without review fails control 8.16 however much is stored.
• Alert floods. Hundreds of noisy alerts a day hide the one that counts and wear out the reviewer.
• Application blind spots. Infrastructure is logged, but nobody can say which user exported a customer list.
• Secrets in logs. Tokens and passwords captured in debug logs create a new exposure.

Sources: ISO/IEC 27001:2022 Annex A controls 8.15, 8.16 and 8.17 (cited by number and name only); NIST SP 800-92 on computer security log management; NIST SP 800-53 Rev. 5, Audit and Accountability (AU) family and SI-4 system monitoring; CERT-In directions of April 2022 under section 70B of the Information Technology Act, 2000, named only. The log-source table is our own.