Without logs, you cannot prove what happened during a security incident, making it impossible to recover quickly or identify who caused the damage. If a customer's data is leaked from your company, regulators and customers will ask 'show us your logs'—and if you have none, you face regulatory fines under DPDP Act, loss of customer trust, and potential business shutdown. For example, a Bangalore IT services firm discovered unauthorized access to client data but had no logs; they could not prove when the breach started, lost three major contracts worth ₹2 crores, and faced a CERT-In investigation. Without logs, you also cannot meet audit requirements for ISO 27001 or customer due diligence, which can disqualify you from government contracts and enterprise clients.
Find where your organisation is today. Be honest — the self-assessment is only useful if it reflects reality.
Absent
You have no system logs or security records at all. Your IT person runs servers and computers, but nothing is written down or stored anywhere, so if something breaks or someone accesses data improperly, there is no trace.
Initial
You keep some basic logs, such as Windows Event Viewer records on one or two critical servers, or manually note down login attempts in a notebook or spreadsheet. But logs are not centralized, often get deleted after a few days, and there is no routine review of them.
Developing
You have logs enabled on most servers and critical systems (Active Directory, file servers, email). Logs are stored locally on each machine and kept for 30 days; a team member occasionally reviews them for obvious errors, but there is no automated search or alerting for suspicious activity.
Defined
You have centralized log collection using a basic tool (like Windows Event Forwarding or open-source Graylog); logs from servers, firewalls, and key applications flow to one place and are kept for 90 days. Your IT person or security lead reviews them monthly, and you have basic alerts set up for failed logins and critical errors.
Managed
You use a dedicated log management platform (like Splunk, ELK Stack, or Wazuh) that collects logs from all servers, network devices, and applications in real time. Logs are kept for 1 year, automatically analyzed for anomalies, and your team responds to alerts within 24 hours; you also conduct quarterly log reviews and investigations.
Optimised
Your log management system is fully integrated with your security operations; logs from all infrastructure, applications, and endpoints feed into a centralized SIEM or log analytics platform. Logs are retained for 2+ years, analyzed with AI/ML to detect threats, your team responds to alerts within 4 hours, and you conduct regular forensic investigations; audit trails are tamper-proof and regularly tested for integrity.
| Step | What to Do | Who | Effort |
|---|---|---|---|
| 0 → 1 | Enable Windows Event Viewer logging on your main server or domain controller; save login and security events to a text file. Ask your IT vendor to provide a one-page list of critical events to track (e.g., failed logins, system restarts). | IT person or outsourced IT vendor | 1 day |
| 1 → 2 | Enable audit logging on your file server, email server (if on-premises), and Active Directory. Configure logs to be kept for at least 30 days; create a simple spreadsheet checklist of events to review weekly and print it for your records. | IT person | 3-5 days |
| 2 → 3 | Set up Windows Event Forwarding or install Graylog (free) to collect logs from all servers into one place. Create a monthly log review schedule where your IT lead exports and reviews logs for unusual activity; document findings in a log review report. | IT person or IT manager | 2-3 weeks |
| 3 → 4 | Purchase and deploy a commercial log management tool (Splunk, ELK Stack, Wazuh, or cloud-based Datadog); configure it to ingest logs from servers, firewalls, and applications. Define 5-10 critical alerts (e.g., 5+ failed logins in 10 minutes) and assign on-call responsibilities for alert response. | IT manager or security consultant | 4-8 weeks (including vendor setup and training) |
| 4 → 5 | Integrate your log management platform with ticketing and incident response systems; implement automated threat detection rules and conduct quarterly log integrity tests. Train your security team on forensic investigation using logs and maintain a 2-year log archive for compliance. | Security lead or Chief Information Security Officer (CISO) | Ongoing (monthly tuning, quarterly reviews, annual audits) |
Documents and records that prove your maturity level.
- Log collection policy document that lists which systems generate logs and where they are stored (e.g., 'Active Directory logs stored on DC server for 90 days')
- Sample of actual logs from at least one critical system (e.g., a week of Active Directory security events showing login attempts and account lockouts)
- Monthly or quarterly log review report signed by IT manager, listing any anomalies found and actions taken (e.g., 'Reviewed logs on 2024-01-15; found 12 failed logins from IP 192.168.x.x; password reset issued')
- Log retention schedule or configuration screenshot showing how many days/months logs are kept and proof they are not being deleted prematurely
- Alert or escalation process document showing what critical events trigger a response and who is notified (e.g., 'Multiple failed logins = alert sent to IT manager within 1 hour')
Prepare for these questions from customers or third-party reviewers.
- "Can you show me where your system logs are stored and for how long you keep them? Show me an example of a log file from your most critical system (file server, email, or Active Directory)."
- "Walk me through a recent incident—can you pull up logs from that date and time to show me exactly what happened and who accessed what?"
- "If an employee was suspected of stealing data, could you produce logs showing which files they accessed, when they accessed them, and from which computer or IP address?"
- "How often do you review your logs, and who is responsible for that? Show me documentation of your last three log reviews."
- "If a hacker broke into your network, what would you check first to find out when they got in and what they accessed?"
| Purpose | Free Option | Paid Option |
|---|---|---|
| Collect and store logs from all servers and devices in one central location | Graylog Community Edition (self-hosted, no cost but requires Linux server); ELK Stack (Elasticsearch, Logstash, Kibana—fully free, open-source) | Splunk Enterprise (₹3-5 lakhs/year for small business); Datadog (₹50,000-2 lakhs/year depending on volume); Microsoft Sentinel (₹2,000-5,000/month on Azure) |
| Monitor Windows servers and Active Directory for security events | Windows Event Forwarding (built into Windows Server, no cost); Wazuh (free, open-source agent-based monitoring) | Splunk Universal Forwarder + Splunk Enterprise; Datadog Log Management |
| Alert you in real time when suspicious activity is detected (e.g., multiple failed logins, unusual file access) | Graylog and ELK Stack have built-in alerting; OSSEC (open-source intrusion detection) with email alerts | Splunk (included); Wazuh Manager (free core, paid support); commercial SIEM platforms |
- Storing logs locally on each server and letting them rotate (auto-delete) after 7-14 days—this is too short for investigation and means old logs are lost. Many Indian MSMEs do this because they do not understand the need for centralized, long-term storage.
- Enabling logs but never reviewing them—logs pile up unread, and when an incident happens, the team wastes time searching through gigabytes of unorganized data. Without a routine review process (monthly or quarterly), logs are essentially useless.
- Disabling verbose logging to save disk space—some businesses turn off detailed logging to reduce server load, but this means critical evidence is missing when you need it most. A better approach is to use centralized log storage on a separate device with cheap storage (NAS or cloud).
- Not logging third-party or SaaS applications (e.g., Google Workspace, Zoho, Salesforce)—many Indian SMEs use cloud apps but do not export or log activity from them, so they have no record of who accessed customer data in the cloud.
- Keeping logs but not securing them—if logs themselves can be deleted or tampered with by an attacker, they become useless as evidence. Logs should be read-only and stored on a separate device or cloud service that the application server cannot directly modify.
| Standard | Relevant Section |
|---|---|
| DPDP Act 2023 | Section 8(3) (integrity and confidentiality safeguards); Section 6 (consent and lawful purpose); Schedule 2 requires organizations to maintain audit trails and records of data processing |
| CERT-In 2022 | Direction 4 (Audit Logging): 'Organizations must maintain system audit logs for all critical systems for a minimum of one year and make them available to CERT-In during incident investigations' |
| ISO 27001:2022 | Annex A.8.4 (Logging), Annex A.12.4 (Logging of user, administrator and system activities), Annex A.8.3 (Access control) |
| NIST CSF 2.0 | Govern function (GV.3.1 - Logging); Detect function (DE.AE - Anomalies and Events); Protect function (PR.AU - Audit Logging) |
Ready to assess your organisation?
Answer all 191 questions and get your NIRMATA maturity score across all 12 pillars.
Start Free Self-Assessment →