ISO 27001 A.5.25: Assessment and Decision on Information Security Events

Quick Reference: A.5.25 in 60 Seconds

What the Standard Actually Requires

ISO 27001:2022 A.5.25 Control Text

ISO 27001:2022 Annex A 5.25 asks organizations to assess security events and decide whether they should be treated as security incidents.

This is a short, two-clause control, but it carries enormous operational weight. It sits at the centre of the incident management lifecycle: every alarm, alert, user report, vulnerability notification, anomaly, or automated detection must pass through a formal assessment gate before the organization decides whether it has become an incident.

ISO 27002:2022 Implementation Guidance (Section 5.25)

ISO 27002:2022 expands A.5.25 into the following practical guidance:

1. Establish assessment and classification criteria. The organization should define how events are evaluated and what factors turn an event into an incident. Criteria typically include business impact, technical severity, affected assets, data sensitivity, regulatory exposure, and exploitability.

2. Assess events as soon as practicable. Once an event is detected or reported, it should be evaluated promptly. Delays increase business impact and can turn a manageable event into a major incident.

3. Decide whether the event is an incident. A documented decision must be made and recorded. If the event is not an incident, it should be classified as a false positive, near miss, accepted risk, or minor event and closed with rationale.

4. Prioritize response. Genuine incidents must be prioritized based on severity, impact, and urgency so that response resources are allocated correctly.

5. Escalate when necessary. Events that exceed the authority or capability of the first-line assessor must be escalated to the incident response team, crisis management team, or top management.

6. Document everything. Assessment decisions, rationale, classification, owner, and timestamps must be recorded to support audit, forensics, legal defence, and post-incident learning.

The "Shall" vs "Should" Analysis

What Auditors Actually Check

Why This Control Matters

The Business Risk of Getting Triage Wrong

A.5.25 is the control that prevents two equally dangerous failures: under-reaction and over-reaction.

• Under-reaction: A suspicious login from an unusual location is dismissed as a false positive. Three weeks later, the organization discovers that attackers have been moving laterally through its network, exfiltrating customer data. The initial event was never formally assessed; no one documented why it was ignored.
• Over-reaction: Every alert is treated as a critical incident. The SOC team is overwhelmed, executives are woken at 3 a.m. for routine vulnerability scans, and the organization burns trust, budget, and people.

Effective event assessment creates a disciplined filter between the noisy world of security telemetry and the focused world of incident response.

The Indian Regulatory Context

Indian organizations operate under an increasingly strict regulatory environment where the quality of event assessment directly affects legal and regulatory outcomes.

Digital Personal Data Protection Act, 2023 (DPDP Act)

The DPDP Act requires Data Fiduciaries to implement reasonable security safeguards and to notify the Data Protection Board and affected Data Principals of personal data breaches. A.5.25 is directly relevant because:

• Detection-to-decision time determines whether the organization can meet breach notification timelines.
• Classification rationale demonstrates that the organization exercised reasonable judgment in identifying a breach.
• Documentation becomes legal evidence in the event of a Board inquiry or penalty proceeding.

Failure to assess events promptly can lead to penalties of up to for failure to take reasonable security safeguards and up to for failure to notify breaches.

CERT-In Directions, 2022

The Indian Computer Emergency Response Team (CERT-In) mandates that organizations report specified cyber incidents within six hours of noticing or being brought to notice. "Noticing" is the assessment trigger. If an organization detects an event but fails to assess it, the six-hour clock may not start, but neither does the response. When the incident is finally discovered, the organization may be past the reporting window and face regulatory action.

Key incident types requiring reporting include:

• Targeted scanning or probing of critical networks
• Compromise of critical information systems
• Unauthorized access to IT systems or data
• Defacement of websites or intrusion into systems
• Malware deployment
• Data breach or data leak
• Attacks on DNS, routers, or core infrastructure
• Identity theft, spoofing, or phishing attacks
• Denial-of-service attacks

Reserve Bank of India (RBI) Cyber Security Guidelines

Banks, NBFCs, payment system operators, and other regulated entities must maintain a Security Operations Centre (SOC) and Cyber Crisis Management Plan. RBI expects:

• Continuous monitoring
• Incident detection and response
• Root-cause analysis
• Reporting to the RBI within defined timelines

A.5.25 provides the formal triage mechanism that feeds these RBI requirements. Poor triage leads to missed reporting deadlines and regulatory censure.

SEBI Cybersecurity Guidelines

For stock brokers, depository participants, mutual funds, and other market infrastructure institutions, SEBI mandates:

• Periodic vulnerability assessments
• Incident reporting to SEBI
• Maintenance of cyber audit logs
• Business continuity planning

Event assessment determines whether a detected anomaly becomes a reportable cyber incident under SEBI's circulars.

IRDAI Guidelines on Information and Cyber Security

Insurance companies and intermediaries must protect policyholder data. IRDAI expects insurers to detect, assess, and respond to cyber incidents. The event assessment decision is the first documented step in demonstrating due diligence.

Information Technology Act, 2000

Sections 43, 43A, 66, and 70B of the IT Act create obligations around reasonable security practices, compensation for negligence, and reporting to CERT-In. Organizations that fail to assess security events may struggle to demonstrate "reasonable security practices" in litigation or regulatory proceedings.

Industry-Specific Consequences

impact of Non-Compliance: By the Numbers

• The average time to identify a data breach globally is 204 days (IBM impact of a Data Breach Report 2024). Effective event assessment can compress this to hours or days.
• The average impact of a data breach in India is **** (IBM 2024).
• Organizations with automated SOAR-based triage save an average of **** per breach compared to manual processes.
• DPDP Act penalties can reach **** for failure to implement reasonable security safeguards.
• CERT-In non-reporting can result in imprisonment up to 1 year or fines, or both, under the IT Act.

Scope and Applicability

What A.5.25 Covers

A.5.25 applies to every information security event that is detected or reported within the organization, including:

• Automated alerts from SIEM, EDR, IDS/IPS, DLP, firewall, WAF, CASB, IAM, and cloud security tools
• User-reported events such as suspicious emails, lost devices, password anomalies, or policy violations
• Threat intelligence indicating active exploitation of a vulnerability in the organization's technology stack
• Vulnerability scan results that show critical or exploitable weaknesses
• Supplier or third-party notifications of security events affecting shared systems or data
• Physical security events such as unauthorized entry, tailgating, or theft of equipment
• Audit findings or control failures that may indicate a security event
• Media or regulator inquiries that suggest a breach may have occurred
• Anomalous behaviour detected by UEBA, deception technology, or manual review

Who It Applies To

Size-Based Applicability

Key Definitions and Terminology

Relationship to Other Controls

A.5.25 does not operate in isolation. It is the central switching station of the incident management lifecycle.

Upstream Controls (Inputs to A.5.25)

Downstream Controls (Outputs from A.5.25)

Parallel Controls (Coordinate With)

Detailed Implementation Guidance

The Event Assessment Lifecycle

┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│   DETECT     │───▶│   RECEIVE    │───▶│   ENRICH     │───▶│   ASSESS     │
│  Event found │    │  Log ticket  │    │ Add context  │    │ Apply criteria│
└──────────────┘    └──────────────┘    └──────────────┘    └──────┬───────┘
                                                                    │
                                                                    ▼
┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│    CLOSE     │◀───│   DISPOSE    │◀───│  CLASSIFY    │◀───│   DECIDE     │
│ With rationale│    │  Route/close │    │ Set severity │    │ Incident?    │
└──────────────┘    └──────────────┘    └──────────────┘    └──────────────┘

Step 1: Define Event Sources and Collection Points

Before you can assess events, you must know where they come from. Consolidate detection into a single queue:

Action items:

• Inventory all detection sources.
• Ensure every source can create a ticket or alert in the central system.
• Standardize timestamp formats and time zones.
• Validate that A.8.17 clock synchronization is in place.

Step 2: Build the Event Assessment Criteria

The criteria are the rules that determine whether an event becomes an incident. Document them in the incident management policy or a standalone event assessment procedure.

Severity Matrix Example

Incident Declaration Criteria

An event shall be declared an information security incident when any of the following are true:

1. Unauthorized access to systems, networks, or data has been confirmed.
2. Malware has been detected on production systems.
3. Data has been lost, corrupted, or exfiltrated.
4. A critical control has been bypassed or disabled.
5. A privileged account has been compromised.
6. A ransomware or denial-of-service attack is in progress.
7. A supplier reports a breach affecting the organization's data.
8. Regulatory notification thresholds have been crossed.
9. The event affects critical business processes or customer services.
10. There is evidence of insider threat or malicious intent.

An event shall not be declared an incident when:

1. It is confirmed to be expected or authorized behaviour.
2. It is a known test or authorized security activity.
3. It is a false positive with documented evidence.
4. It is a near miss where controls prevented impact.

Step 3: Establish the Assessment Workflow

┌─────────────────────────────────────────────────────────────────────────────┐
│  EVENT RECEIVED (Ticket created within 15 minutes of detection)             │
└─────────────────────────────────────────────────────────────────────────────┘
                                      │
                                      ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│  L1 TRIAGE (SOC Analyst / Helpdesk)                                         │
│  • Verify alert validity                                                    │
│  • Perform initial enrichment (user, asset, time, location)                 │
│  • Apply classification criteria                                            │
│  • Decision within SLA:                                                     │
│    a) False positive → close with rationale                                 │
│    b) Near miss → record and close                                          │
│    c) Needs investigation → escalate to L2                                  │
│    d) Confirmed incident → escalate immediately to Incident Response Team   │
└─────────────────────────────────────────────────────────────────────────────┘
                                      │
                                      ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│  L2 ASSESSMENT (Senior Analyst / Incident Handler)                          │
│  • Deep-dive investigation                                                  │
│  • Correlate with threat intelligence                                       │
│  • Determine business impact                                                │
│  • Confirm or downgrade severity                                            │
│  • Decision: declare incident, continue monitoring, or close                │
└─────────────────────────────────────────────────────────────────────────────┘
                                      │
                                      ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│  ESCALATION (CISO / Incident Commander / Crisis Team)                       │
│  • Critical/High incidents escalated immediately                            │
│  • Regulatory/legal involvement if required                                 │
│  • Executive notification per communication plan                            │
└─────────────────────────────────────────────────────────────────────────────┘

Step 4: Define Roles and Authority Levels

Step 5: Create the Event Record / Ticket Template

Every event must be recorded with the following fields:

Step 6: Set SLAs and OLAs

Step 7: Implement Enrichment and Correlation

Enrichment turns raw alerts into assessable events. Key enrichment sources:

Step 8: Handle Special Event Types

User-Reported Events

• Provide a single reporting channel: email, Slack bot, phone hotline, or incident portal.
• Acknowledge receipt within the SLA.
• Do not dismiss user reports without investigation; many major breaches begin with a user noticing something odd.

Third-Party / Supplier Events

• Maintain a contact directory for supplier security teams.
• Require contractual notification timelines (e.g., within 24 hours of discovery).
• Assess impact on your data, systems, and customers even if the event occurred at the supplier.

Physical Security Events

• Coordinate with facilities/security team.
• Determine if devices, documents, or access credentials were compromised.
• Treat theft of laptops, phones, or access badges as potential information security incidents until proven otherwise.

Insider Threat Events

• Handle with confidentiality and HR/legal involvement.
• Avoid tipping off the subject until evidence is preserved.
• Follow labour law and disciplinary procedures.

Step 9: Automate Where Appropriate

Caution: Automation should assist, not replace, human judgment for declaring incidents. Always require human approval for incident declaration.

Step 10: Continuous Improvement

• Review all closed events weekly for missed incidents or misclassifications.
• Measure false-positive rate and tune detection rules.
• Update assessment criteria after major incidents or changes in threat landscape.
• Conduct tabletop exercises quarterly to test decision-making under pressure.
• Benchmark MTTA and MTTD against industry standards.

Tools, Technologies, and Solutions

Categories of Tools

Vendor Comparison Table

Indian Vendor and MSSP Options

Tool Selection Decision Matrix

Policy and Procedure Templates

Event Assessment and Decision Policy (Extract)

INFORMATION SECURITY EVENT ASSESSMENT AND DECISION POLICY
[Organization Name]
Version: 1.0
Approved by: [CISO Name]
Date: [Date]
Review Date: [Date + 12 months]
Classification: Internal

1. PURPOSE
This policy defines the process for assessing information security events 
and deciding whether they are to be classified as information security 
incidents, in accordance with ISO 27001:2022 Annex A 5.25.

2. SCOPE
This policy applies to all information security events detected or reported 
within [Organization Name], including automated alerts, user reports, 
supplier notifications, vulnerability findings, and physical security events.

3. POLICY STATEMENT
3.1 Every information security event shall be assessed in a timely manner.
3.2 A formal decision shall be made on whether each event is an incident, 
    false positive, near miss, or requires further investigation.
3.3 Assessment decisions shall be documented with rationale.
3.4 Events shall be prioritized based on severity and business impact.
3.5 Events exceeding the assessor's authority shall be escalated immediately.
3.6 Event assessment criteria shall be reviewed at least annually.

4. ROLES AND RESPONSIBILITIES
4.1 CISO: Owns this policy and the event assessment process.
4.2 SOC Manager: Manages the event queue and ensures SLAs are met.
4.3 SOC Analysts: Perform L1 and L2 assessment of events.
4.4 Incident Response Team: Responds to declared incidents.
4.5 All Employees: Report events promptly and cooperate with assessment.

5. CLASSIFICATION CRITERIA
[Reference the severity matrix and incident declaration criteria defined 
in Section 7 of the guide.]

6. ESCALATION
Critical and High events shall be escalated to the Incident Response Team 
within 15 minutes and 1 hour respectively.

7. DOCUMENTATION
All event records shall be maintained in the central ticketing system for 
a minimum of [3/7] years, depending on regulatory requirements.

8. REVIEW
This policy is reviewed annually and after any major incident or significant 
organizational change.

Event Assessment Procedure (Extract)

PROCEDURE: ASSESSMENT AND DECISION ON INFORMATION SECURITY EVENTS
Document ID: SEC-PROC-525
Version: 1.0
Owner: SOC Manager

PURPOSE
To provide step-by-step instructions for assessing information security 
events and deciding whether they are incidents.

TRIGGER
Receipt of a security event in the SOC queue, helpdesk queue, or incident 
hotline.

STEP-BY-STEP PROCESS

Step 1: Receive and Log
- Create a ticket within 15 minutes of detection.
- Record detection timestamp, source, description, and affected assets.

Step 2: Perform Initial Enrichment
- Identify the user, device, IP address, and location.
- Check asset criticality and data classification.
- Query threat intelligence for IOCs.
- Review recent change records and maintenance windows.

Step 3: Apply Classification Criteria
- Determine if the event meets incident declaration criteria.
- Assign preliminary severity (Critical/High/Medium/Low).
- Assign priority (P1/P2/P3/P4).

Step 4: Make Decision
- If confirmed incident: escalate to Incident Response Team.
- If false positive: close with documented rationale.
- If near miss: record and close with lessons learned.
- If uncertain: escalate to L2 for deeper investigation.

Step 5: Document Rationale
- Record the decision, criteria applied, assessor name, and timestamp.
- Attach evidence (logs, screenshots, intel reports).

Step 6: Escalate if Needed
- Critical/High: immediate escalation.
- Regulatory/legal exposure: notify Legal/Compliance.
- Customer impact: notify Customer Success/Account Management.

Step 7: Close or Hand Over
- False positives and near misses closed by L1/L2.
- Incidents handed over to Incident Response Team with full context.

QUALITY CHECKS
- All tickets have a recorded decision.
- No ticket is closed without rationale.
- SLA compliance is monitored daily.

Event Classification Quick Reference Card (Extract)

┌─────────────────────────────────────────────────────────────────────────────┐
│  EVENT CLASSIFICATION QUICK REFERENCE                                       │
├─────────────────────────────────────────────────────────────────────────────┤
│  CRITICAL (P1) — Escalate immediately                                       │
│  • Confirmed compromise of production system                                │
│  • Active data exfiltration or ransomware                                   │
│  • Critical infrastructure / customer service down                          │
│  • Response: Incident Response Team within 15 min; CISO within 30 min       │
├─────────────────────────────────────────────────────────────────────────────┤
│  HIGH (P2) — Escalate within 1 hour                                         │
│  • Confirmed unauthorized access                                            │
│  • Privileged account compromise                                            │
│  • Sensitive data potentially exposed                                       │
│  • Response: L2 investigation + IR team activation                          │
├─────────────────────────────────────────────────────────────────────────────┤
│  MEDIUM (P3) — Investigate within 4 hours                                   │
│  • Suspicious activity requiring deeper analysis                            │
│  • Isolated malware or policy violation                                     │
│  • Response: L2 investigation; escalate if impact confirmed                 │
├─────────────────────────────────────────────────────────────────────────────┤
│  LOW (P4) — Handle within 24 hours                                          │
│  • Minor policy violation                                                   │
│  • Informational alert                                                      │
│  • Response: Routine handling or closure with rationale                     │
└─────────────────────────────────────────────────────────────────────────────┘

Risk Assessment and Treatment

Risk Scenarios Related to A.5.25

Risk Treatment Plan

Residual Risk Acceptance

Any residual risk rated High after treatment must be accepted by the CISO or top management with documented justification. Accepted risks are reviewed quarterly.

Audit and Compliance Checklist

Use this checklist to prepare for internal and external audits of A.5.25.

Metrics and KPIs

KPI Dashboard Layout

┌─────────────────────────────────────────────────────────────────────────────┐
│  EVENT ASSESSMENT KPI DASHBOARD — June 2026                                │
├─────────────────────────────────────────────────────────────────────────────┤
│  THIS WEEK                                                                  │
│  Total Events: 1,247   Assessed on Time: 96.3%   Backlog: 3                │
│  MTTA: 8 min   MTTA2: 42 min   False Positive Rate: 24%                    │
├─────────────────────────────────────────────────────────────────────────────┤
│  SEVERITY BREAKDOWN                                                         │
│  Critical: 2   High: 18   Medium: 142   Low: 1,085                          │
├─────────────────────────────────────────────────────────────────────────────┤
│  TRENDS (Last 4 Weeks)                                                      │
│  Event volume: ▁▂▄▆ (increasing — review detection tuning)                 │
│  SLA compliance: ████████░░ (96% — stable)                                 │
│  False positives: ▃▄▃▂ (improving)                                          │
├─────────────────────────────────────────────────────────────────────────────┤
│  ACTION ITEMS                                                               │
│  • 1 false negative from last week — update EDR rule                        │
│  • 2 assessors due for refresher training                                   │
│  • Phishing campaign increased user reports by 35%                          │
└─────────────────────────────────────────────────────────────────────────────┘

Common Pitfalls / Audit Failures & How to Avoid Them

Illustrative Scenarios

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative Scenario 1: Indian Fintech Company, Missed Initial Compromise Due to Weak Triage

Organization: A Bengaluru-based payments fintech with 400 employees and RBI authorization.

Challenge: The fintech's SOC was receiving over 3,000 alerts per day from its SIEM. The L1 team was two analysts working business hours only. Alerts were routinely marked "reviewed" without documented rationale. One alert showed a successful login from an unusual location for a senior finance executive at 2 a.m. The analyst assumed it was VPN-related travel and closed it as a false positive without enrichment.

Three weeks later, the company discovered that the executive's credentials had been harvested via a phishing email. The attacker had accessed the financial reporting system, attempted to modify settlement records, and exfiltrated data on 85,000 customers. The RBI was notified late, and the company's PCI DSS and RBI cyber audit were both flagged.

Root Cause:

• No documented criteria for when an anomalous login should be escalated.
• False positives closed without rationale or enrichment.
• No 24x7 coverage for critical alerts.
• User context (executive, sensitive role, off-hours) not factored into assessment.

Solution Implemented with Singahi:

1. Rewrote the event assessment procedure with a clear severity matrix.
2. Implemented automated enrichment: user role, asset criticality, geo-location, and login history.
3. Created an escalation rule: any off-hours privileged access anomaly automatically escalates to L2.
4. Engaged an Indian MSSP for 24x7 L1 coverage.
5. Required documented rationale for every closure.
6. Started weekly QA review of 10% of closed tickets.

Results (12 Months Later):

• Event assessment SLA compliance increased from 62% to 97%.
• False positives without rationale dropped to zero.
• MTTD for credential compromise scenarios fell from 21 days to under 4 hours.
• The fintech passed its RBI cyber audit with no major findings.
• Customer trust was rebuilt; churn related to security concerns dropped by 40%.

Key Lesson: A single poorly assessed event can become a breach. Documented criteria, enrichment, and 24x7 coverage are non-negotiable for regulated organizations.

Illustrative Scenario 2: Indian IT Services Company, Over-Reaction damaging Deals and Reputation

Organization: A Hyderabad-based mid-sized IT services and SaaS provider with 1,200 employees serving global enterprise clients.

Challenge: The company had recently obtained ISO 27001 certification but had not operationalized A.5.25. Every alert from its EDR and DLP tools was escalated as a "potential incident." The incident response team was waking up 2-3 times per week for events that turned out to be authorized patching, legitimate data exports by operations teams, or misconfigured detection rules.

This "cry wolf" culture had several consequences:

• Client-facing incident reports were issued for non-incidents, causing unnecessary panic.
• Two major enterprise prospects requested additional security due diligence and delayed deals.
• Analyst burnout led to 35% attrition in the SOC in one year.
• External auditors noted that the incident register contained events that did not meet incident criteria.

Root Cause:

• No classification criteria; everything was treated as an incident.
• Detection rules not tuned to the environment.
• Lack of asset and business context in event assessment.
• No L1 triage layer to filter noise before escalation.

Solution Implemented with Singahi:

1. Defined a four-tier severity matrix and incident declaration criteria.
2. Introduced an L1 triage step with authority to close false positives and near misses.
3. Implemented SOAR-based auto-enrichment and auto-closure for known benign patterns.
4. Tuned detection rules based on baseline activity.
5. Trained the SOC on the new criteria and held tabletop exercises.
6. Created a communication protocol: only confirmed incidents trigger client notifications.

Results (12 Months Later):

• Incidents escalated to the IR team dropped by 70%.
• Mean time to respond to genuine incidents improved by 55%.
• SOC attrition fell to 12%.
• Both delayed enterprise deals closed.
• The next surveillance audit found no findings related to incident management.

Key Lesson: Over-classification is as damaging as under-classification. A disciplined triage layer with clear criteria protects both operational efficiency and customer trust.

Illustrative Scenario 3: Indian Healthcare Provider, Third-Party Event Assessment Failure

Organization: A chain of diagnostic laboratories based in Mumbai with 75 centres across Maharashtra and Gujarat.

Challenge: The provider used a third-party cloud laboratory information system (LIS). The vendor sent a security advisory about unauthorized access to a shared API key used by multiple customers. The IT team filed the email in a general inbox but did not assess whether the provider's patient data was affected. Two months later, a journalist contacted the provider about a data leak. The provider had no record of assessing the vendor advisory and could not demonstrate when it had "noticed" the breach.

Regulatory Exposure:

• Potential breach notification failure under the DPDP Act 2023.
• Loss of patient trust and negative media coverage.
• Investigation by the Maharashtra Medical Council.

Solution Implemented:

1. Created a supplier security event register.
2. Mandated that all vendor security advisories be logged and assessed within 24 hours.
3. Added contractual clauses requiring vendors to report events within 4 hours.
4. Mapped vendor events to affected assets and data types.
5. Trained procurement and IT on the new process.

Results:

• Vendor events now assessed within SLA.
• DPDP Act breach response playbook created.
• No further missed third-party events in the next audit cycle.

Key Lesson: Third-party events must be assessed with the same rigour as internal events. "It happened at the vendor" is not a defence.

Multi-Framework Mapping

How to Use This Mapping

• SOC 2 Type II auditors will look at A.5.25 evidence to satisfy CC7.2, CC7.3, CC7.4, and CC7.5.
• PCI DSS QSA will verify incident response procedures and event monitoring.
• NIST 800-53 assessors will map your process to IR-4, IR-5, IR-6, and SI-4.
• CIS Controls reviewers will check log management (Control 08) and incident response (Control 17).
• DPDP Act compliance requires that event assessment records support breach notification decisions.

Implementation Roadmap

Phase 1: Foundation (Weeks 1-2)

Phase 2: Build (Weeks 3-5)

Phase 3: Operate (Weeks 6-8)

Phase 4: Optimize (Weeks 9-12)

Post-Implementation Sustainment

FAQ

Q1: What is the difference between an information security event and an incident?

An event is any observable occurrence in a system, network, or service that may have security significance. An incident is an event (or series of events) that has actually compromised or has a significant probability of compromising information security. A.5.25 is the control that determines which events become incidents.

Q2: Does every event need to be investigated in depth?

No. Every event must be assessed, but the depth of investigation depends on severity and likelihood. Low-risk informational events can be closed with minimal rationale, while high-risk events require deeper analysis. The key is that the assessment decision is documented and defensible.

Q3: Who has the authority to declare an incident?

Authority levels should be defined in your policy. Typically, L1 analysts can close false positives and near misses; L2 analysts can declare Medium/Low incidents; the CISO or Incident Commander declares Critical/High incidents and authorizes external communications.

Q4: How quickly must events be assessed?

ISO 27001 does not specify a universal timeframe. Your organization must define SLAs based on risk. A common baseline is: Critical events within 15 minutes, High within 1 hour, Medium within 4 hours, and Low within 24 hours.

Q5: What should be documented when closing an event as a false positive?

At minimum: event ID, description, why it was determined to be benign, evidence reviewed, assessor name, and timestamp. Without this, auditors cannot verify that the event was properly assessed.

Q6: How does A.5.25 relate to CERT-In's six-hour reporting requirement?

CERT-In requires reporting of specified cyber incidents within six hours of "noticing." A.5.25 determines when an organization has "noticed" an incident. A weak assessment process can delay this determination and cause non-compliance.

Q7: Can event assessment be fully automated?

Automation can help with enrichment, correlation, and closing known benign patterns. However, the final decision to declare an incident should involve human judgment, especially for events with regulatory, legal, or customer impact.

Q8: What are the most common audit findings for A.5.25?

Common findings include: events not assessed, no classification criteria, false positives closed without rationale, missing event-to-incident linkage, untrained assessors, and no metrics.

Q9: How do we handle events reported by employees?

Provide a simple reporting channel, acknowledge receipt within SLA, and assess every report. Do not dismiss user reports without investigation, many serious breaches are first noticed by employees.

Q10: How often should we review the event assessment criteria?

At least annually, and also after major incidents, significant organizational changes, new regulatory requirements, or changes in the threat landscape. Post-incident reviews often reveal needed updates to criteria.

Q11: What if we outsource our SOC, who owns A.5.25?

The organization retains accountability. Your contract must define the MSSP's responsibilities for event assessment, SLA, escalation, documentation, and evidence provision. The CISO still owns A.5.25 from an ISO 27001 perspective.

Q12: Do physical security events fall under A.5.25?

Yes, if they have information security implications. Examples include theft of laptops, unauthorized access to server rooms, or lost access badges. These should be routed to the information security team for assessment.

References and Further Reading

Standards and Frameworks

• ISO/IEC 27001:2022, Annex A, Control 5.25, Assessment and Decision on Information Security Events
• ISO/IEC 27002:2022, Section 5.25, Assessment and Decision on Information Security Events
• ISO/IEC 27035:2016, Information Security Incident Management
• NIST SP 800-61 Rev. 2, Computer Security Incident Handling Guide
• NIST SP 800-53 Rev. 5, Security and Privacy Controls (IR-4, IR-5, IR-6, SI-4)
• CIS Controls v8, Controls 08, 13, and 17

Indian Regulations and Guidance

• Digital Personal Data Protection Act, 2023 (India)
• CERT-In Directions, 2022, Cyber Security Incident Reporting
• Reserve Bank of India, Master Direction on Information Technology Framework for the NBFC Sector
• Reserve Bank of India, Guidelines on Information Security, Electronic Banking, Technology Risk Management, and Cyber Frauds
• SEBI Cyber Security and Cyber Resilience Framework for Stock Brokers/Depository Participants
• IRDAI Guidelines on Information and Cyber Security for Insurers
• Information Technology Act, 2000 (India), Sections 43, 43A, 66, and 70B

Industry Reports

• IBM Security, impact of a Data Breach Report 2024
• Ponemon Institute, State of Cybersecurity in India
• Verizon, Data Breach Investigations Report (DBIR) 2024

Useful Resources

• SANS Incident Handler's Handbook
• FIRST.org, Standards for Incident Response (CSIRT Services Framework)
• MITRE ATT&CK Framework, for understanding adversary tactics and enrichment context
• OWASP Logging Cheat Sheet

End of Guide

Sample Event Assessment Playbooks

The following playbooks provide concrete decision trees for common event types. Customize them for your environment.

Playbook A: Suspicious Email Reported by User

TRIGGER: User reports suspicious email via security@company.com or phishing button

L1 TRIAGE (15 minutes):
1. Acknowledge receipt to the reporter.
2. Extract email headers, sender, URLs, and attachments.
3. Check sender reputation via threat intelligence.
4. Scan attachments in sandbox.
5. Check if any other users received the same email.

DECISION:
├─ Confirmed malicious + user clicked link/opened attachment
│  → Declare INCIDENT (High or Critical)
│  → Escalate to IR Team
│  → Isolate affected endpoint
│  → Reset user credentials
│  → Hunt for lateral movement
├─ Confirmed malicious + no user interaction
│  → Record as NEAR MISS
│  → Update email security rules
│  → Notify affected users
├─ Suspicious but not confirmed malicious
│  → Escalate to L2 for deeper analysis
│  → Hold for 2 hours max
└─ Benign / legitimate email
│  → Close as FALSE POSITIVE
│  → Provide feedback to reporter
│  → Document rationale

Playbook B: Anomalous Login Alert

TRIGGER: SIEM alert for login from unusual location or device

ENRICHMENT:
- User role and privilege level
- Recent travel or remote work status
- Historical login locations
- MFA status (success/failure)
- Time of login (business hours or off-hours)
- Device compliance status

DECISION:
├─ Privileged user + impossible travel + successful MFA bypass
│  → Declare INCIDENT (Critical)
│  → Disable account immediately
│  → Escalate to IR Team
│  → Preserve logs
├─ Standard user + new location + successful MFA from managed device
│  → Contact user to confirm
│  → If confirmed legitimate → close as FALSE POSITIVE
│  → If unconfirmed → escalate to L2
├─ Multiple failed logins from unusual location
│  → Escalate to L2
│  → Consider blocking source IP
│  → Notify user
└─ Login from known VPN exit node or partner office
│  → Verify against travel/remote work register
│  → Close with rationale if legitimate

Playbook C: Malware Detection Alert

TRIGGER: EDR alerts that malware was detected on an endpoint

L1 TRIAGE:
1. Identify affected endpoint and user.
2. Determine malware family and reputation from threat intel.
3. Check if malware was executed or quarantined.
4. Identify how it arrived (email, web download, USB, supply chain).

DECISION:
├─ Malware executed + data access detected
│  → Declare INCIDENT (High or Critical)
│  → Isolate endpoint
│  → Begin forensics
│  → Reset credentials
│  → Hunt across environment
├─ Malware quarantined before execution
│  → Record as NEAR MISS
│  → Verify EDR protection across all endpoints
│  → Update signatures if needed
├─ Potentially unwanted application (PUA) but not malware
│  → Assess against software policy
│  → Remove if unauthorized
│  → Close as LOW event or near miss
└─ Known false positive from trusted software
│  → Close as FALSE POSITIVE
│  → Add exception with approval
│  → Document rationale

Playbook D: Data Exfiltration Alert (DLP)

TRIGGER: DLP alert for large file upload to personal cloud storage

L1 TRIAGE:
1. Identify user, data classification, and destination.
2. Check data volume and file types.
3. Review user's recent activity and job role.
4. Determine if upload was authorized (e.g., customer delivery).

DECISION:
├─ Sensitive/Restricted data + unauthorized destination
│  → Declare INCIDENT (High or Critical)
│  → Block further transfers
│  → Preserve evidence
│  → Notify Legal/Compliance
│  → Assess DPDP Act/GDPR breach notification
├─ Internal data + destination unclear
│  → Escalate to L2
│  → Interview user
│  → Review access logs
├─ Public data + authorized business purpose
│  → Close as FALSE POSITIVE
│  → Update DLP policy if needed
└─ Personal data of small volume, no malicious intent
│  → Handle as policy violation
│  → HR/manager notification
│  → Retraining

Integrating Event Assessment with Change Management

Many false positives arise from authorized changes. Reduce noise by:

1. Requiring change records to include expected security alerts.
2. Tagging change windows in the SIEM so alerts during those windows are auto-enriched.
3. Training SOC analysts to check the change calendar before escalating.
4. Creating a "known good" library of approved activities and their alert signatures.

Measuring and Improving Assessment Quality

Quality assurance is what separates a compliant process from an effective one.

FAQ Addendum

Q13: Should red-team or penetration-test events be treated differently?

Yes. Authorized tests should be pre-registered with the SOC, including expected indicators and time windows. This prevents false incident declarations and allows the test to validate real detection and assessment capabilities. However, the SOC should not know exactly when or how the test will occur, otherwise the test loses value.

Q14: How do we balance speed and accuracy in event assessment?

Use automation for enrichment and initial filtering so analysts can focus on judgment. Define clear escalation triggers so uncertain events are quickly raised rather than silently closed. Measure both speed (SLA compliance) and accuracy (false-negative/false-positive rates).

Q15: What is the role of threat intelligence in A.5.25?

Threat intelligence provides context that helps distinguish benign anomalies from targeted attacks. For example, an IP address associated with a known APT group changes a routine failed login into a High-priority event. Integrate threat feeds into your enrichment workflow.

Q16: How should we handle events during a major outage or crisis?

Activate your incident management plan. Event assessment may be temporarily centralized under an Incident Commander. Document any deviations from normal SLAs and justify them in the post-incident review.