1. Purpose

The purpose of this procedure is to define how the organization identifies, validates, assesses, classifies, and responds to information security events.

The procedure helps the organization determine whether a reported event is:

• A routine security event
• A false positive
• A security weakness requiring action
• A suspected security incident
• A confirmed information security incident
• A major incident requiring immediate escalation

The objective is to make decisions based on available evidence rather than assumptions.

---

2. Scope

This procedure applies to information security events involving:

• Employees
• Contractors
• Customers
• Suppliers
• Cloud services
• SaaS applications
• Production systems
• Endpoints
• Networks
• Applications
• Databases
• Source code
• CI/CD systems
• Identity and access systems
• Physical assets
• Personal or regulated information

Examples include:

• Suspicious login
• Malware alert
• Phishing email
• Unauthorized access attempt
• Privilege escalation
• Vulnerability exploitation
• Data exposure
• Cloud configuration change
• Lost device
• Suspicious administrator activity
• Security control failure
• Supplier security notification
• Unexpected data transfer
• Availability disruption

---

3. Key Definitions

Information Security Event

An identified occurrence that may affect information security or the operation of information security controls.

An event does not automatically mean that an incident has occurred.

Security Incident

A single or series of unwanted or unexpected information security events that have a significant probability of compromising information security or business operations.

Security Alert

A notification generated by a security tool, monitoring system, user, supplier, or other source indicating potentially suspicious activity.

False Positive

An alert or reported activity initially appearing suspicious but subsequently determined not to represent a security incident.

Security Weakness

A condition that does not necessarily constitute an incident but requires corrective action to reduce risk.

---

4. Assessment Principles

Event assessment should follow these principles:

4.1 Validate Before Escalating

Do not automatically treat every alert as a confirmed incident.

4.2 Act Quickly Where Risk Is High

Assessment should not create unnecessary delay when there is evidence of active compromise or significant impact.

4.3 Use Available Evidence

Assessment should be based on logs, alerts, reports, system information, user information, and other available evidence.

4.4 Protect Evidence

Relevant evidence should be preserved before it is lost or overwritten where practical.

4.5 Assess Impact

Consider confidentiality, integrity, availability, customers, personal data, business operations, and regulatory or contractual obligations.

4.6 Reassess as Facts Change

The initial assessment may change as additional information becomes available.

---

5. Information Security Event Lifecycle

The standard process is:

Detect → Report → Record → Validate → Assess → Classify → Escalate → Respond → Monitor → Close

Where an event is confirmed as an incident, the appropriate Incident Response Procedure or specialized incident playbook should be activated.

---

6. Event Sources

Security events may originate from:

• Employees
• Customers
• Suppliers
• Security monitoring
• SIEM
• EDR
• Cloud security services
• Vulnerability scanners
• Application monitoring
• Network monitoring
• Identity systems
• Email security
• Penetration testing
• Internal audits
• External audits
• Security researchers
• Regulatory notifications
• Threat intelligence
• Automated alerts

---

7. Step 1 — Detect or Receive the Event

An event may be detected automatically or reported manually.

The person or system identifying the event should capture the available facts.

Minimum information should include:

• Date and time
• Source
• Description
• Affected system
• User/account, if known
• Initial indicators
• Evidence available
• Reporter
• Initial impact, if known

The reporter should not attempt unauthorized investigation or modify systems unnecessarily.

---

8. Step 2 — Create an Event Record

Each event should receive a unique identifier.

Example:

SEC-EVT-2026-001

The record should contain:

Field	Description
Event ID	Unique identifier
Date/Time	Detection time
Source	Monitoring/user/supplier/etc.
Event Type	Phishing/login/malware/etc.
Description	What was observed
Affected Asset	System/account/service
Reporter	Person/system reporting
Evidence	Available supporting information
Initial Impact	Known impact
Status	Current state
Assessor	Person assessing

---

9. Step 3 — Validate the Event

The assessor should determine whether the event is genuine.

Validation may include:

• Checking system logs
• Reviewing security alerts
• Confirming user activity
• Checking authentication records
• Reviewing cloud activity
• Reviewing application logs
• Checking configuration changes
• Comparing against approved activity
• Contacting the relevant system owner
• Reviewing related events

Example

An alert shows a user logging in from an unusual location.

The assessor checks:

• Was the user actually travelling?
• Was a corporate VPN used?
• Was the device recognized?
• Was MFA completed?
• Were other suspicious activities observed?

The event may be legitimate or may require escalation.

---

10. Step 4 — Determine Event Type

Classify the event based on the available facts.

Event Type	Examples
Authentication	Unusual login, failed login
Access	Unauthorized access attempt
Malware	Malware detection
Phishing	Suspicious email
Vulnerability	Exploitation attempt
Data	Unexpected data access
Cloud	Unauthorized cloud activity
Configuration	Security-control change
Availability	Service disruption
Physical	Lost device
Supplier	Supplier security alert
Privacy	Potential personal-data exposure
Policy	Security policy violation
Other	Other security-related event

---

11. Step 5 — Assess Security Impact

The assessor should consider the three primary information-security properties.

Confidentiality

Could information have been viewed, accessed, copied, disclosed, or exposed by an unauthorized party?

Integrity

Could information, configuration, software, or systems have been modified without authorization?

Availability

Could systems or information have become unavailable or degraded?

Use:

C — Confidentiality

I — Integrity

A — Availability

An event may affect one, two, or all three.

---

12. Step 6 — Assess Business Impact

Consider:

• Critical business processes
• Customer services
• Production systems
• Revenue-generating systems
• Employee operations
• Financial systems
• Legal obligations
• Regulatory obligations
• Contractual commitments
• Reputation
• Safety
• Business continuity

The assessment should distinguish between:

Potential impact

and

Confirmed impact.

---

13. Step 7 — Assess Information Impact

Determine whether sensitive information may be involved.

Consider:

• Customer information
• Personal data
• Employee information
• Financial information
• Authentication information
• Credentials
• Source code
• Intellectual property
• Confidential business information
• Security configurations
• Regulated information

The assessor should determine whether the information was:

• Not involved
• Potentially accessed
• Confirmed accessed
• Modified
• Disclosed
• Lost
• Deleted
• Exfiltrated

Avoid assuming data exfiltration merely because unauthorized access occurred.

---

14. Step 8 — Assess Scope

Determine the potential scope of the event.

Consider:

• One user
• Multiple users
• One endpoint
• Multiple endpoints
• One application
• Production environment
• Multiple systems
• One customer
• Multiple customers
• One supplier
• Multiple suppliers
• One cloud account
• Multiple environments

Also determine whether the event appears:

Isolated → Limited → Widespread → Unknown

When scope is unknown, treat the uncertainty itself as a risk factor.

---

15. Step 9 — Assess Attacker Activity

Where malicious activity is suspected, determine whether there is evidence of:

• Unauthorized authentication
• Credential compromise
• Privilege escalation
• Persistence
• Lateral movement
• Malware execution
• Data access
• Data exfiltration
• Security-control modification
• Command execution
• Unauthorized configuration changes

The presence of active attacker activity should normally result in immediate escalation.

---

16. Step 10 — Determine Incident Status

Based on the assessment, classify the event as one of the following.

Category A — False Positive

Evidence indicates that the activity is legitimate or the alert was incorrectly triggered.

Action: Document the assessment and close.

Category B — Routine Security Event

The activity is genuine but does not meet the organization’s incident criteria.

Action: Record, monitor, and close or manage through normal security processes.

Category C — Security Weakness

The event reveals a control weakness requiring corrective action.

Action: Create a corrective action or risk record.

Category D — Suspected Incident

There is insufficient evidence to confirm an incident, but the possibility cannot reasonably be excluded.

Action: Escalate and investigate.

Category E — Confirmed Incident

Evidence indicates that an information security incident has occurred.

Action: Activate the Incident Response Procedure or appropriate playbook.

Category F — Major/Critical Incident

The event involves significant customer, business, security, regulatory, or operational impact.

Action: Immediately escalate according to the Incident Escalation Matrix.

---

17. Event Classification Decision Tree

Use the following decision logic:

Security Event Detected

↓

Is the event genuine?

No → False Positive → Document → Close

Yes ↓

Does it represent a security concern?

No → Routine Event → Record → Close

Yes ↓

Is there a control weakness?

Yes → Corrective Action/Risk Record

Does evidence indicate unauthorized activity or significant security impact?

No → Monitor / Corrective Action

Yes → Suspected or Confirmed Incident

↓

Assess Severity

↓

Escalate

↓

Activate Incident Response

---

18. Severity Assessment

Where the event is considered an incident, use the organization’s Incident Severity Matrix.

Consider:

Dimension	Assessment
Confidentiality	None / Low / Medium / High
Integrity	None / Low / Medium / High
Availability	None / Low / Medium / High
Customer Impact	None / Low / Medium / High
Personal Data	None / Potential / Confirmed
Business Impact	None / Low / Medium / High
Regulatory Impact	None / Potential / Confirmed
Scope	Isolated / Limited / Widespread / Unknown
Attacker Access	None / Attempted / Confirmed
Persistence	None / Possible / Confirmed
System Criticality	Low / Medium / High / Critical

The highest credible severity should initially be considered where significant uncertainty exists, and the classification should be reassessed as evidence improves.

---

19. Immediate Escalation Triggers

An event should be escalated immediately when there is evidence or credible suspicion of:

• Privileged account compromise
• Cloud administrator compromise
• Active attacker activity
• Ransomware
• Significant data exposure
• Customer information exposure
• Personal or regulated data exposure
• Large-scale malware
• Data exfiltration
• Critical vulnerability exploitation
• Production compromise
• Major service outage caused by security activity
• Security logging being disabled or manipulated
• Significant supplier compromise
• Financial fraud or BEC
• Major contractual or regulatory implications

---

20. Evidence Preservation

During assessment, preserve relevant evidence.

Examples:

• Authentication logs
• Cloud audit logs
• Application logs
• Endpoint alerts
• Network logs
• Email messages
• Security alerts
• Configuration history
• Database audit records
• Source-code activity
• CI/CD records

Follow the Evidence Preservation Procedure where formal preservation is required.

---

21. AWS SaaS Example

Consider an AWS SaaS company.

Event

AWS monitoring detects an unusual login for a privileged identity.

Initial Assessment

The security team checks:

• CloudTrail
• IAM
• MFA
• Source IP
• Login time
• Role assumptions
• Recent policy changes

New Finding

The identity created a new IAM role.

The event is no longer treated as merely an unusual login.

The team assesses:

• Who created the role?
• What permissions does it have?
• Was it used?
• Which resources were accessed?
• Was customer information accessed?
• Were security controls changed?

Response

Event → Validation → Evidence Preservation → Severity Assessment → Escalation → Incident Response

The organization should not wait for complete forensic certainty before containing an actively compromised privileged identity.

---

22. Event Assessment Record

Use the following structure for each assessed event.

Event Information

Event ID:
Date/Time:
Reported By:
Source:
Event Type:
Affected Asset:

Description

What was observed?

Validation

What evidence was reviewed?

Findings

What does the evidence demonstrate?

Information Impact

What information may be involved?

C/I/A Assessment

• Confidentiality:
• Integrity:
• Availability:

Business Impact

• Customer:
• Operational:
• Financial:
• Regulatory:
• Contractual:

Scope

• Systems:
• Users:
• Customers:
• Data:
• Geographic scope:

Attacker Activity

• Unauthorized access:
• Privilege escalation:
• Persistence:
• Lateral movement:
• Data access:
• Exfiltration:

Classification

• False Positive
• Routine Security Event
• Security Weakness
• Suspected Incident
• Confirmed Incident
• Major/Critical Incident

Severity

SEV-1 / SEV-2 / SEV-3 / SEV-4 / Not Applicable

Immediate Actions

List actions taken.

Escalation

Who was notified and when?

Evidence

List preserved evidence.

Decision

Why was the event classified this way?

Follow-up

Corrective action, risk treatment, monitoring, or incident response.

Assessor

Name / Role / Date

---

23. Relationship With Other Security Processes

This procedure should connect with:

Security Monitoring

→ detects potential event

Incident Reporting Form

→ reports event

Information Security Event Assessment

→ validates and assesses event

Incident Severity Matrix

→ determines severity

Incident Escalation Matrix

→ determines escalation

Evidence Preservation Procedure

→ protects evidence

Incident Response Procedure

→ manages confirmed incidents

Specialized Playbooks

→ manages ransomware, phishing, cloud compromise, data breach, etc.

Corrective Action Tracker

→ manages improvement actions

Incident Closure Report

→ documents final outcome

---

24. Roles and Responsibilities

Role	Responsibility
Reporter	Provide accurate initial information
Security/IT Team	Validate and assess event
Security Lead	Determine escalation and response
Incident Commander	Coordinate confirmed major incidents
Cloud/IT Team	Investigate technical environment
Application/DevOps	Assess applications and CI/CD
Privacy	Assess personal-data implications
Legal/Compliance	Assess legal/regulatory/contractual obligations
Business Owner	Assess business impact
Supplier Owner	Coordinate supplier-related events
Executive Management	Make major business/risk decisions

---

25. Communication During Assessment

Assessment communications should:

• Use authorized channels.
• Contain verified facts.
• Clearly identify unknown information.
• Avoid speculation.
• Follow need-to-know principles.
• Protect sensitive investigation information.

For significant events, the Incident Commander or designated Security Lead should control incident communications.

---

26. Closure Criteria

An event may be closed when:

• The event has been validated.
• The classification has been documented.
• Required investigation is complete.
• Required escalation has occurred.
• Relevant evidence has been preserved.
• Required corrective action has been assigned.
• No continuing security threat is identified.
• Residual risk has been considered.
• Required notifications have been assessed.
• Closure has been approved where required.

If the event is confirmed as an incident, closure should occur through the applicable incident-management process rather than simply closing the event record.

---

27. Metrics

The organization may monitor:

• Number of security events
• Number of false positives
• Number of confirmed incidents
• Number of suspected incidents
• Events by source
• Events by category
• Events by severity
• Time to validate
• Time to classify
• Time to escalate
• Number of recurring events
• Events resulting in corrective actions
• Overdue corrective actions

Metrics should be used to improve monitoring and response rather than simply to increase or decrease the number of reported events.

---

28. Common Mistakes

Avoid:

• Treating every alert as an incident.
• Ignoring low-severity events that reveal control weaknesses.
• Closing an event without recording the reasoning.
• Investigating without preserving important evidence.
• Assuming unauthorized access automatically means data exfiltration.
• Waiting for complete certainty before containing active threats.
• Failing to reassess severity as facts change.
• Allowing the person who caused the event to independently close the investigation where independence matters.
• Failing to involve Privacy/Legal when personal or regulated information may be affected.
• Treating a supplier’s notification as merely an administrative issue.
• Failing to link events to corrective actions.

---

29. Startup Implementation Model

A startup can implement this procedure without creating a complicated SOC workflow.

A simple process is:

Alert / Report

↓

Create Event ID

↓

Validate

↓

Assess C/I/A + Business Impact + Information Impact

↓

Classify

↓

False Positive / Routine Event / Weakness / Incident

↓

Escalate if Required

↓

Preserve Evidence

↓

Respond or Create Corrective Action

↓

Close With Documented Decision

A lightweight spreadsheet or ticketing system can be sufficient initially, provided that access control, auditability, evidence retention, and ownership are appropriately managed.

---

30. ISO 27001 Connection

This procedure supports the organization’s process for assessing information security events and determining whether they require incident response.

It can support activities relating to:

• Information security event reporting
• Assessment of security events
• Information security incident management
• Incident response
• Evidence preservation
• Logging and monitoring
• Access control
• Communication
• Corrective action
• Continual improvement

The exact assessment criteria should be aligned with the organization’s risk assessment, security objectives, incident criteria, applicable legal/contractual requirements, and Statement of Applicability.

Not every security event needs to become a formal incident.

The important objective is to have a consistent, risk-based, evidence-supported method for making and documenting that decision.

---

31. Audit Evidence

An auditor may review:

• Information Security Event Assessment Procedure
• Security Event Register
• Incident Reporting Forms
• Event Assessment Records
• Security Alerts
• Monitoring Records
• Authentication Logs
• Cloud Audit Logs
• Incident Severity Assessments
• Escalation Records
• Evidence Preservation Records
• Incident Reports
• Corrective Action Records
• Incident Closure Reports
• Management Review Records

A useful audit trail is:

Security Alert → Event Record → Validation → Impact Assessment → Classification → Escalation/Response → Evidence → Corrective Action → Closure

---

32. Final Audit Trail

Security Event Detected
↓
Event Reported/Recorded
↓
Event Validated
↓
Evidence Preserved
↓
Security Impact Assessed
↓
Business Impact Assessed
↓
Information Impact Assessed
↓
Scope Determined
↓
Attacker Activity Assessed
↓
Event Classified
↓
Severity Determined Where Applicable
↓
Escalation Performed
↓
Incident Response / Corrective Action / Monitoring Initiated
↓
Facts Reassessed
↓
Risk and Residual Impact Considered
↓
Decision Documented
↓
Event Closed

---

Final Principle

Validate the Event + Assess the Impact + Preserve Evidence + Classify Based on Facts + Escalate Early When Risk Is High + Reassess as Evidence Changes + Document the Decision.