1. Purpose

The Information Security Event Reporting Policy establishes requirements for identifying, reporting, recording, assessing, and escalating information security events.

The objective is to ensure that potential security issues are reported early enough for the organization to determine whether they require investigation or formal incident response.

This policy helps the organization:

• Detect security events early
• Encourage timely reporting
• Prevent small events from becoming significant incidents
• Establish clear reporting responsibilities
• Protect evidence
• Support incident assessment
• Support regulatory and contractual obligations
• Improve security monitoring
• Maintain an auditable event-to-incident process

Core Principle

Notice → Report → Record → Assess → Escalate → Investigate → Respond → Learn

---

2. Scope

This policy applies to:

☐ Employees
☐ Contractors
☐ Consultants
☐ Interns
☐ Temporary workers
☐ Supplier personnel
☐ Privileged users
☐ Remote workers
☐ IT and security personnel
☐ Application and cloud administrators
☐ Other authorized users

It applies to information security events involving:

• Information
• Applications
• Cloud environments
• Networks
• Endpoints
• Identity systems
• Accounts
• Source code
• Customer environments
• Physical security
• Suppliers
• Security controls

---

3. Policy Statement

All personnel must promptly report suspected or observed information security events through the organization’s approved reporting channels.

Personnel must not wait until they are certain that an event is a security incident.

The Security or designated responsible team will assess the event and determine whether it should be:

• Closed as a non-security event
• Recorded for monitoring
• Escalated for investigation
• Classified as a security incident
• Escalated as a major incident

Users are not expected to determine the final severity of an event themselves.

---

4. What Is an Information Security Event?

An information security event is an observed occurrence that may indicate a security issue, weakness, policy violation, unauthorized activity, or condition relevant to information security.

Examples include:

• Repeated failed login attempts
• Unexpected MFA prompts
• Suspicious email
• Lost company device
• Unexpected password reset
• Unusual cloud activity
• Malware detection
• Unauthorized access attempt
• Accidental information disclosure
• Security control failure
• Unexpected system configuration change
• Suspicious network activity
• Unusual data download
• Source-code repository access anomaly
• Security warning from a supplier
• Physical security concern

An event does not automatically mean that a security incident has occurred.

---

5. Event vs. Incident

The organization should distinguish between an event and an incident.

Event

An event is something observed that may require assessment.

Security Incident

An incident is an information security event or series of events that has been determined to compromise, or threaten to compromise:

• Confidentiality
• Integrity
• Availability
• Authenticity
• Information or systems
• Security controls
• Business operations

Example

A user receives an unexpected MFA notification.

This is initially an event.

If investigation confirms that an attacker attempted to access the user’s account, it may become a security incident.

---

6. Reporting Responsibilities

All personnel are responsible for reporting events they:

• Observe
• Experience
• Suspect
• Receive
• Discover
• Are informed about

Personnel should report even when:

• They are unsure whether it is a security issue
• The event appears accidental
• They believe someone else has already reported it
• The event occurred outside normal working hours
• They caused the event themselves

Honest reporting of mistakes is encouraged.

---

7. What Must Be Reported

Personnel should report events including, but not limited to:

Account and Identity

☐ Suspicious login
☐ Unexpected MFA request
☐ Password compromise
☐ Lost authentication device
☐ Unauthorized account activity
☐ Unexpected account creation
☐ Suspicious privilege change

Information

☐ Accidental disclosure
☐ Misaddressed email
☐ Unauthorized file sharing
☐ Lost information
☐ Suspected data theft
☐ Customer-data exposure
☐ Personal-data exposure
☐ Confidential information sent to an unauthorized recipient

Devices

☐ Lost laptop
☐ Stolen laptop
☐ Lost mobile device
☐ Malware detection
☐ Suspicious software
☐ Unauthorized USB/removable media
☐ Unexpected device behavior

Applications and Systems

☐ Unexpected system behavior
☐ Security warning
☐ Unauthorized configuration change
☐ Application vulnerability
☐ Suspicious administrator activity
☐ Unexpected deployment

Cloud

☐ Unexpected AWS/Azure/GCP activity
☐ Unknown cloud account/user
☐ Suspicious IAM activity
☐ Unexpected security-group change
☐ Unexpected storage exposure
☐ Unusual API activity
☐ Unexpected access-key activity

Network

☐ Suspicious traffic
☐ Unexpected connection
☐ Firewall alert
☐ Intrusion alert
☐ Network outage with security implications

Physical Security

☐ Unauthorized person in restricted area
☐ Lost access card
☐ Tampering
☐ Suspicious physical activity
☐ Lost removable media

Supplier

☐ Supplier security warning
☐ Supplier breach notification
☐ Supplier system compromise
☐ Unexpected supplier access
☐ Security-control failure

---

8. Reporting Channels

The organization shall maintain approved reporting channels.

Examples include:

• Security email
• Incident-management system
• Service desk
• Security hotline
• Security portal
• Manager escalation
• Emergency communication channel

Approved Channels

Channel	Purpose	Contact	Availability
Security Email	Security events
Service Desk	General reporting
Emergency Contact	Critical events
Incident Platform	Event registration

Personnel should use the fastest available approved channel for urgent events.

---

9. Emergency Reporting

Critical events should be reported immediately.

Examples include:

• Active ransomware
• Suspected major data breach
• Compromised privileged account
• Active production compromise
• Major cloud compromise
• Large-scale malware outbreak
• Significant customer-data exposure
• Destructive attack
• Active unauthorized administrative access

Personnel should not delay reporting while attempting to collect complete information.

---

10. Reporting Time Requirements

The organization should define reporting expectations based on event severity.

Example:

Event Type	Reporting Expectation
Critical/Suspected Active Attack	Immediately
High-Risk Security Event	As soon as possible
Suspected Data Exposure	Immediately
Lost/Stolen Device	Immediately
Suspicious Account Activity	Promptly
Security Weakness	Promptly
Low-Risk Security Observation	Within defined reporting period

Specific regulatory, contractual, or customer requirements may impose shorter notification periods.

---

11. Information to Include in a Report

Personnel should provide, where known:

• Date and time
• What happened
• How it was discovered
• Affected person
• Affected system
• Affected account
• Affected information
• Location
• Screenshots where appropriate
• Relevant messages
• Error messages
• Device information
• Customer/supplier involved
• Actions already taken

Users should not delay reporting because some information is unavailable.

---

12. Event Reporting Form

A standard reporting form may include:

Field	Information
Event ID
Date/Time Reported
Reporter
Contact
Event Date/Time
Event Type
Description
Affected System
Affected Information
Initial Impact
Immediate Actions
Evidence Available
Customer/Supplier Involved
Assigned To
Assessment Status

---

13. Anonymous Reporting

Where appropriate, the organization may provide an anonymous or confidential reporting mechanism.

This may be useful for:

• Security policy violations
• Insider concerns
• Suspected misuse
• Fraud-related security concerns
• Retaliation concerns
• Sensitive security observations

Anonymous reporting should not prevent the organization from investigating the event.

---

14. No-Blame Reporting

The organization should encourage personnel to report security events without fear of inappropriate retaliation.

Accidental mistakes should be reported promptly.

Examples:

“I accidentally emailed a confidential file to the wrong recipient.”

“I clicked a suspicious link.”

“I entered my password into a suspicious website.”

“I accidentally exposed an AWS storage resource.”

Early reporting can significantly reduce potential impact.

Intentional misconduct remains subject to the organization’s disciplinary and legal processes.

---

15. Initial Event Assessment

Security or designated personnel should assess reported events.

Consider:

What happened?

• What was observed?
• Is the event genuine?
• Is it ongoing?

What is affected?

• User
• Device
• Application
• Cloud
• Network
• Information
• Customer
• Supplier

What is the potential impact?

• Confidentiality
• Integrity
• Availability
• Privacy
• Financial
• Regulatory
• Contractual
• Reputation

---

16. Event Classification

Events may be classified according to the organization’s approved classification model.

Example:

Classification	Description
Informational	No apparent security impact
Low	Limited security concern
Medium	Potential security impact requiring investigation
High	Significant potential security impact
Critical	Active or potentially severe security threat

The classification may be changed as additional information becomes available.

---

17. Event-to-Incident Decision

The organization should determine whether the event becomes a security incident.

Consider:

☐ Unauthorized access
☐ Unauthorized disclosure
☐ Malware
☐ Account compromise
☐ Data compromise
☐ Security-control failure
☐ Significant availability impact
☐ Integrity compromise
☐ Regulatory impact
☐ Customer impact
☐ Supplier impact
☐ Repeated suspicious activity

Decision

☐ Close as event
☐ Monitor
☐ Investigate further
☐ Escalate to incident
☐ Escalate to major incident

---

18. Evidence Preservation

Where an event may become an incident:

☐ Preserve relevant evidence
☐ Do not unnecessarily delete logs
☐ Preserve suspicious emails/messages
☐ Record timestamps
☐ Preserve relevant screenshots
☐ Preserve system information
☐ Protect evidence from alteration
☐ Follow evidence-handling requirements

Personnel should avoid modifying or deleting potentially relevant evidence unless authorized.

---

19. Immediate Actions

Depending on the event, authorized personnel may:

• Disable a compromised account
• Revoke a session
• Reset credentials
• Isolate an endpoint
• Block malicious traffic
• Remove malicious email
• Disable exposed credentials
• Restrict cloud access
• Protect affected information

Immediate containment should be coordinated with the incident-response process for significant events.

---

20. Escalation

Events should be escalated according to the organization’s severity and escalation matrix.

Possible escalation recipients:

☐ Security Team
☐ IT Team
☐ Incident Response Team
☐ CISO/Security Lead
☐ IT Management
☐ Privacy Officer
☐ Legal
☐ Compliance
☐ Business Owner
☐ Executive Management
☐ Customer
☐ Supplier
☐ Regulator where required

---

21. Customer and Supplier Events

Where an event involves a customer or supplier:

☐ Relationship identified
☐ Contractual requirements reviewed
☐ Security contact identified
☐ Notification requirements assessed
☐ Evidence preserved
☐ Communication coordinated
☐ Incident process initiated where required

Personnel must not independently notify customers or regulators unless authorized.

---

22. Personal Data Events

If an event may involve personal data:

☐ Personal data involvement identified
☐ Data categories identified
☐ Data subjects considered
☐ Processing location identified
☐ Privacy team notified where applicable
☐ Breach assessment initiated
☐ Regulatory requirements assessed
☐ Customer contractual requirements assessed

---

23. Information Classification

The event report should identify the classification of affected information where known.

☐ Public
☐ Internal
☐ Confidential
☐ Restricted
☐ Unknown — assessment required

Do not include unnecessary sensitive information in the event report.

---

24. Cloud and AWS Events

For AWS environments, report events such as:

☐ Unexpected IAM activity
☐ Unknown IAM user/role
☐ Unexpected access-key usage
☐ Suspicious console login
☐ Unexpected MFA change
☐ Unexpected security-group modification
☐ Unexpected S3 exposure
☐ Unusual API activity
☐ Unexpected EC2 activity
☐ Unexpected Lambda deployment
☐ CloudTrail alert
☐ GuardDuty alert
☐ Unexpected privilege escalation

Potentially relevant evidence may include:

• CloudTrail
• GuardDuty
• AWS Config
• IAM records
• VPC Flow Logs
• Application logs
• Security monitoring alerts

---

25. Security Monitoring Integration

Automated security alerts should be assessed through the same event-management process where applicable.

Possible sources:

• SIEM
• EDR
• IDS/IPS
• Cloud security tools
• IAM monitoring
• Vulnerability tools
• Email security
• Firewall
• Application monitoring
• Supplier notifications
• User reports

Automated alerts should not automatically be treated as confirmed incidents without appropriate assessment.

---

26. False Positives

The organization should record significant false positives where useful.

Examples:

• Legitimate administrator activity
• Authorized deployment
• Approved configuration change
• Scheduled security scan
• Expected vulnerability scanner traffic
• Authorized cloud activity

False positives may be used to improve:

• Detection rules
• Alert thresholds
• Monitoring
• User training
• Event classification

---

27. Event Register

Significant events should be recorded in an Information Security Event Register.

Event ID	Date	Type	Source	System	Severity	Incident?	Status

Recommended fields include:

• Event ID
• Date/time
• Reporter
• Event source
• Description
• Classification
• Affected asset
• Affected information
• Initial severity
• Assessment
• Incident decision
• Actions
• Owner
• Closure date

---

28. Event Closure

An event may be closed when:

☐ Assessment completed
☐ Impact understood
☐ Incident decision recorded
☐ Required actions completed
☐ Evidence retained
☐ Follow-up assigned where required
☐ Monitoring established where appropriate
☐ Closure approved where required

Events escalated to incidents should follow the organization’s incident-management process.

---

29. Event Trends and Analysis

The organization should periodically analyze event information.

Consider:

• Number of events
• Event categories
• Repeat events
• False positives
• User-reported events
• Automated alerts
• Events converted to incidents
• High-risk events
• Events by business unit
• Events by system
• Events by supplier

Trend analysis can identify weaknesses before they become major incidents.

---

30. Security Awareness Feedback

Event reports may be used to improve security awareness.

Examples:

• Repeated phishing reports → improve phishing training
• Repeated password incidents → improve authentication awareness
• Repeated data-sharing errors → improve information-classification training
• Repeated cloud misconfigurations → improve cloud security training

Individual reports should not be used inappropriately to discourage future reporting.

---

31. Confidentiality of Event Reports

Security event reports may contain sensitive information.

Access should be restricted to authorized personnel.

Protect:

• Reporter identity where appropriate
• Customer information
• Personal information
• Security weaknesses
• Vulnerability details
• Credentials or secrets
• Investigation information
• Legal information

Event reports should not be broadly circulated.

---

32. Security Event Communication

Communication should be:

• Accurate
• Timely
• Need-to-know
• Authorized
• Consistent
• Documented

Personnel should not post security-event details on:

• Public social media
• Public forums
• Unapproved messaging channels
• Personal websites
• Public repositories

unless explicitly authorized.

---

33. Relationship With Incident Management

The event-reporting process feeds the incident-management process.

Process

Security Event → Report → Record → Assess → Incident Decision → Escalate → Investigate → Respond → Close → Learn

The event-reporting process should not replace the organization’s incident-response procedure.

---

34. Roles and Responsibilities

All Personnel

• Report suspected events promptly
• Provide accurate information
• Preserve relevant evidence
• Cooperate with assessment
• Follow security instructions

Managers

• Support reporting
• Escalate significant concerns
• Ensure personnel cooperate

Security Team

• Receive and assess events
• Classify events
• Determine incident status
• Escalate where required
• Preserve evidence
• Maintain records

IT/Engineering

• Support technical investigation
• Provide system/log information
• Implement authorized containment

Privacy/Legal/Compliance

• Assess applicable legal, regulatory, privacy, and contractual requirements

Management

• Support significant-event response
• Make risk decisions where required
• Approve major communications where applicable

---

35. Training and Awareness

Personnel should be informed about:

☐ What constitutes a security event
☐ Examples of reportable events
☐ Reporting channels
☐ Emergency reporting
☐ Reporting expectations
☐ Evidence preservation
☐ Confidentiality
☐ No-blame reporting
☐ Incident escalation

Reporting instructions should be easily accessible.

---

36. Testing

The organization should periodically test whether personnel know how to report security events.

Methods may include:

• Security awareness exercises
• Phishing simulations
• Tabletop exercises
• Incident-response exercises
• Help-desk testing
• Emergency contact testing

Test Record

Test	Date	Participants	Result	Finding	Action

---

37. Metrics

The organization may monitor:

Metric	Target	Actual
Events Reported
Average Reporting Time
Events Converted to Incidents
High-Risk Events
Critical Events
User-Reported Events
Automated Events
False Positives
Events Closed Within SLA

Metrics should be used to improve security rather than discourage reporting.

---

38. Exceptions

Exceptions to this policy must:

☐ Be documented
☐ Have business justification
☐ Have risk assessed
☐ Have compensating controls where appropriate
☐ Have an owner
☐ Have an expiry/review date
☐ Be approved by the appropriate authority

---

39. Policy Violations

Failure to report a known or suspected security event may result in:

• Additional security training
• Corrective action
• Investigation
• Disciplinary action where appropriate

However, accidental mistakes should primarily be handled through learning and risk reduction rather than discouraging future reporting.

---

40. Records and Retention

The organization should retain appropriate records including:

• Event reports
• Event register
• Assessment records
• Incident decisions
• Evidence references
• Escalation records
• Communications
• Closure records
• Trend reports
• Testing records

Retention should follow the organization’s legal, regulatory, contractual, and information-retention requirements.

---

41. AWS SaaS Startup Example

Scenario

An AWS SaaS employee receives an unexpected MFA notification for the company’s identity provider.

The employee did not initiate a login.

Required Action

The employee should:

1. Report the event immediately.
2. Avoid approving the MFA request.
3. Provide the approximate time.
4. Identify the affected account.
5. Preserve relevant notification/email evidence.
6. Follow security-team instructions.

Security Team

The security team:

Receive → Record → Assess → Investigate

may review:

• Identity-provider logs
• AWS IAM activity
• CloudTrail
• Recent password changes
• MFA changes
• Source IP information
• Other authentication events

Possible Outcome

If no unauthorized access occurred:

Event → Investigated → No Incident → Closed/Monitored

If unauthorized access is confirmed:

Event → Security Incident → Incident Response

Audit Trail

User Report → Event Record → Assessment → Evidence → Incident Decision → Response → Closure

---

42. Startup-Friendly Reporting Model

A startup does not need a complicated reporting platform to begin.

A practical model can use:

Reporting

security@company.com

Emergency

Security/Incident Response contact

Tracking

Security Event Register

Assessment

Security Event Assessment Procedure

Escalation

Incident Severity Matrix

Response

Incident Response Procedure

The process should become more automated as the organization grows.

---

43. Common Mistakes

Avoid:

• Expecting users to prove an incident before reporting.
• Making the reporting process difficult.
• Having no emergency reporting mechanism.
• Treating every event as an incident.
• Treating every alert as a confirmed security incident.
• Failing to record user-reported events.
• Discouraging users from reporting mistakes.
• Waiting for complete information before reporting.
• Failing to preserve evidence.
• Allowing unauthorized personnel to investigate sensitive events.
• Sharing security-event details through public channels.
• Failing to connect events with incident management.
• Not analyzing recurring events.
• Not testing whether personnel know how to report.

---

44. Relationship With Other ISMS Documents

Document	Relationship
Information Security Incident Management Policy	Defines overall incident-management requirements
Information Security Event Assessment Procedure	Determines whether events become incidents
Security Event Classification Matrix	Defines event classification
Security Event Reporting Form	Records reported events
Security Event Register	Tracks events
Event-to-Incident Decision Checklist	Supports incident decisions
Incident Reporting Form	Records confirmed incidents
Incident Response Procedure	Defines incident response
Incident Severity Matrix	Defines severity
Incident Escalation Matrix	Defines escalation
Incident Investigation Procedure	Supports investigation
Evidence Preservation Procedure	Protects evidence
Security Incident Communication Procedure	Controls communications
Security Awareness Policy	Supports personnel awareness
Security Monitoring Procedure	Generates automated security events
Supplier Security Incident Procedure	Handles supplier events
Business Continuity Plan	Addresses significant disruption

---

45. ISO 27001 / SOC 2 Connection

Information security event reporting supports the organization’s ability to detect, assess, and respond to information security events.

It supports areas such as:

• Information security event reporting
• Information security incident management
• Security awareness
• Access control
• Monitoring
• Evidence preservation
• Supplier security
• Privacy and breach assessment
• Continual improvement

For SOC 2, event-reporting evidence may support controls related to:

• Security monitoring
• Incident detection
• Incident response
• Logical access
• Confidentiality
• Availability
• Protection of customer information

The exact control mapping should be determined based on the organization’s scope, risk assessment, applicable criteria, and control environment.

---

46. Quick Audit Checklist

☐ Policy approved
☐ Scope defined
☐ Reportable events defined
☐ Event vs incident distinction documented
☐ Reporting channels available
☐ Emergency reporting defined
☐ Reporting expectations defined
☐ Personnel responsibilities defined
☐ Security team responsibilities defined
☐ Event reporting form available
☐ Event register maintained
☐ Event classification defined
☐ Event-to-incident assessment defined
☐ Escalation process defined
☐ Evidence preservation defined
☐ Customer/supplier reporting considered
☐ Personal-data events considered
☐ Cloud/AWS events considered
☐ Security monitoring integrated
☐ Event closure defined
☐ Event trends reviewed
☐ Personnel awareness provided
☐ Reporting process tested
☐ Metrics monitored
☐ Exceptions controlled
☐ Records retained
☐ Policy periodically reviewed

---

47. Document Control

Field	Details
Document Name	Information Security Event Reporting Policy
Document Owner
Security Owner
Version
Effective Date
Classification	Internal
Approved By
Review Frequency	At least annually or upon significant change
Next Review Date

---

48. Final Audit Trail

For the information security event-reporting process, the organization should be able to demonstrate:

How can personnel report a security event?
What types of events must be reported?
How quickly must significant events be reported?
Who receives the report?
How is the event recorded?
Who assesses the event?
How is an event distinguished from an incident?
How are critical events escalated?
How is evidence protected?
How are customer, privacy, regulatory, and supplier requirements considered?
How are events tracked through closure?
How are recurring events identified and addressed?

Final Principle

The goal of event reporting is not to make every employee an incident investigator. It is to make sure that potentially important security signals reach the right people early enough to be assessed and acted upon.

The complete lifecycle is:

Notice → Report → Record → Assess → Classify → Escalate → Investigate → Respond → Close → Learn