If you don't watch login attempts, a hacker could break into an employee's account and steal customer data, financial records, or confidential business information for weeks before you notice. For example, a manufacturing firm in Bangalore had a vendor email account compromised; the attacker accessed their supply chain documents and customer lists, and the breach only came to light during a customer audit 45 days later—by then the damage was done and they faced a ₹15 lakh penalty under customer contracts. Without login monitoring, you won't know when credentials are being misused, which means ransomware actors or competitors can operate inside your network undetected. Banks and insurance companies now ask MSMEs for login monitoring logs during due diligence—if you don't have them, you fail the security check and lose the contract.
Find where your organisation is today. Be honest — the self-assessment is only useful if it reflects reality.
Absent
You have no system in place to watch login attempts. When you ask staff if anyone noticed strange activity, they look confused because no one is checking for it.
Initial
Someone on the IT team occasionally looks at login attempts manually—maybe once a month when they remember, by checking the server or email logs in a spreadsheet or text file with no real organization.
Developing
You have login attempt logs being kept in one place (email server, network device, or basic IT tool), and someone reviews them roughly once a week looking for obviously weird patterns like the same account logged in from two countries in one hour.
Defined
You have documented login monitoring procedures in place; a designated person checks logs at least twice weekly, has a simple documented list of what counts as suspicious (5 failed attempts, login outside business hours, unusual location), and writes down findings in a log book or shared document.
Managed
You have automated alerts set up (email notification or dashboard) when suspicious login events occur; someone reviews these alerts daily, keeps a formal record of each investigation, documents what action was taken, and escalates serious incidents to management.
Optimised
You have a real-time monitoring system in place with automated detection rules tuned for your business; alerts are triaged and acted on within hours; all login anomalies are logged in a central system; monthly reports are generated for management review; and the whole process is tested and improved regularly.
| Step | What to Do | Who | Effort |
|---|---|---|---|
| 0 → 1 | Ask your email and IT system providers (Microsoft, Google, Zoho, or your server admin) to show you where login logs are stored. Document the location and access process. Schedule a monthly 30-minute review slot for one IT person to manually scan these logs. | IT Person or System Administrator | 1 day |
| 1 → 2 | Export login logs to a shared spreadsheet or simple tracking system (Google Sheets, Excel on shared drive). Create a basic template with columns: Date, User, Time, Location/IP, Status (Success/Failed), Notes. Set a weekly review schedule. | IT Person | 3-5 days |
| 2 → 3 | Write down clear rules for what counts as suspicious (5+ failed logins in 1 hour, login from outside India if team is India-based, login at 2 AM from new IP, same user logged in from 2 cities within 15 minutes). Create a one-page procedure document. Train the designated reviewer. Start keeping a simple investigation log (who noticed it, what was it, what was done). | IT Person + Manager | 2-3 weeks |
| 3 → 4 | Set up automated email alerts using built-in features in Microsoft 365, Google Workspace, or third-party tools (Okta, Zoho OneAuth). Configure alerts for your defined suspicious events. Assign someone to check alerts daily. Create a formal incident log with columns: Date Detected, Alert Type, User, Investigation Notes, Action Taken, Escalated (Y/N), Date Closed. | IT Person + IT Manager | 4-6 weeks |
| 4 → 5 | Implement a SIEM-like dashboard or advanced monitoring tool (Splunk, Microsoft Sentinel, or cloud-native logging). Set up automated rules and ML-based anomaly detection. Conduct quarterly reviews of alert tuning. Run tabletop exercises with management to practice incident response. Document and measure detection time and false positive rate. | IT Manager + Security Team (external consultant may be needed) | Ongoing monthly tuning and quarterly reviews |
Documents and records that prove your maturity level.
- Login logs exported or accessible from your email/IT systems (email server, Microsoft 365 Audit Logs, Google Workspace Activity Reports, Zoho logs) covering the last 30-90 days
- Weekly or twice-weekly review notes or checklists signed by the person who conducted the review, with date and any findings noted
- Documented list of rules defining what counts as suspicious activity (e.g. '5 failed attempts in 1 hour = escalate')
- Incident investigation log showing at least 2-3 past investigations: what was flagged, who reviewed it, what action was taken, and when it was closed
- If using automated alerts: screenshots of alert configuration, email alerts received, or dashboard showing recent alerts and investigation status
Prepare for these questions from customers or third-party reviewers.
- "Can you show me the login logs for the past 30 days and tell me who is responsible for reviewing them? How often are they reviewed?"
- "Walk me through a recent example where you noticed unusual login activity. What did you see and what did you do about it?"
- "What are your rules for flagging a login attempt as suspicious? Are these documented?"
- "Do you have automated alerts set up, or is this a manual process? If manual, how do you ensure nothing is missed?"
- "If I ask for all failed login attempts across your system in the last 60 days, what would you show me and how quickly could you provide it?"
| Purpose | Free Option | Paid Option |
|---|---|---|
| View and export login logs from your email and cloud systems | Microsoft 365 Audit Log Search (built-in), Google Workspace Activity Reports (built-in), Zoho Audit Log (built-in for paid plans) | Splunk (₹3-5 lakhs/year for small deployment), Microsoft Sentinel (₹15,000-30,000/month) |
| Set up automated alerts for suspicious login events | Okta free tier (basic alerts), Auth0 free tier (limited), built-in alerts in Microsoft 365/Google Workspace | Okta Standard (₹1.5-2 lakhs/year), Auth0 (₹50,000-1 lakh/year), Zoho OneAuth (₹20,000-40,000/year) |
| Track and log investigation findings in a centralized place | Google Sheets, Microsoft Excel on shared drive, Notion (free tier), OpenIncident tracker (open source) | Jira (₹30,000-60,000/year for small team), ServiceNow (₹2-5 lakhs/year), Splunk (as above) |
- Keeping login logs but never actually reviewing them. Many Indian MSMEs have logs enabled in their email or server but no one looks at them for months; this provides no protection.
- Setting alerts too sensitive or too loose. New admins often set alerts for every single login, creating alert fatigue and false positives, so real incidents get ignored. Or they set the threshold so high (e.g. 100 failed attempts) that actual break-in attempts are missed.
- Assuming that 'the software vendor handles this' and not checking yourself. Many cloud services log activity by default, but the vendor doesn't notify you of breaches—you have to look for them yourself.
- Not documenting investigations or actions taken. Even if you spot something suspicious, if you don't write down what you found and what you did about it, there's no proof during an audit and you can't learn from the incident.
- Checking logs only after a breach is suspected. Login monitoring is prevention and early warning, not post-breach forensics. By the time you suspect a problem, attackers have already stolen data.
| Standard | Relevant Section |
|---|---|
| DPDP Act 2023 | Section 8 (Principle of Security) and Schedule 1 (security safeguards for personal data); Article 32 of GDPR (similar requirement) |
| CERT-In 2022 | Direction 4 (Log and monitoring), Direction 6 (Incident response) |
| ISO 27001:2022 | Annex A.8.3 (Access control), A.8.5 (Authentication), A.8.8 (User access rights review) |
| NIST CSF 2.0 | Govern (GV.RO: Risk and Oversight), Detect (DE.AE: Anomalies and Events) |
Ready to assess your organisation?
Answer all 191 questions and get your NIRMATA maturity score across all 12 pillars.
Start Free Self-Assessment →