1. Purpose
The Security Event Reporting Form provides a structured method for employees, contractors, customers, suppliers, and automated security systems to report suspected or observed information security events.
The form helps the organization:
- Capture security events consistently
- Ensure potentially significant events are reported quickly
- Preserve initial facts and available evidence
- Identify affected systems, information, and users
- Support security event assessment and classification
- Determine whether an event should become a formal security incident
- Initiate appropriate escalation where required
- Maintain an auditable record of the initial report
Important: The person reporting an event is not expected to determine whether it is a confirmed security incident. The Security/IT team should validate and classify the event.
2. When to Use This Form
Use this form when something appears unusual, suspicious, unauthorized, or potentially harmful.
Examples include:
- Suspicious email or phishing message
- Unexpected login or MFA notification
- Lost or stolen company device
- Suspected malware
- Unauthorized access
- Unexpected password reset
- Suspicious cloud activity
- Unexpected AWS/IAM activity
- Data sent to the wrong recipient
- Possible customer or personal data exposure
- Unapproved software or SaaS usage
- Security vulnerability discovered
- Unexpected production change
- Suspicious API activity
- Source-code or repository access that appears unusual
- Supplier security event
- Physical security event affecting information
- Security control failure
- Repeated failed authentication attempts
- Unexpected administrative activity
When in doubt, report the event rather than deciding that it is unimportant.
3. Reporting Information
| Field | Details |
|---|---|
| Report ID | |
| Date Reported | |
| Time Reported | |
| Time Zone | |
| Reported By | |
| Department / Team | |
| Email / Contact | |
| Reporting Method | Email / Portal / Phone / Monitoring / Other |
| Location | |
| Manager / Team Lead | |
| Is the Reporter Directly Affected? | Yes / No |
4. Event Information
| Field | Details |
|---|---|
| Date of Event | |
| Approximate Time | |
| Time Zone | |
| Event Type | |
| Event Title | |
| Affected System / Asset | |
| Affected Application | |
| Affected Account / Identity | |
| Affected Location | |
| Event Description | |
| How Was the Event Detected? | |
| Is the Activity Still Occurring? | Yes / No / Unknown |
Suggested Event Types
- Authentication / Login
- Access Control
- Phishing
- Malware
- Ransomware
- Data Exposure
- Unauthorized Access
- Cloud Security
- Vulnerability
- Configuration
- Availability
- Privacy
- Supplier / Third Party
- Physical Security
- Application Security
- Network Security
- Endpoint Security
- Source Code / CI/CD
- Policy Violation
- Other
5. What Happened?
Describe the event using factual information.
Reporter Description
What did you observe?
What were you doing when the event occurred?
What made the activity appear unusual or suspicious?
Was the activity expected or approved?
- Yes
- No
- Unknown
If known, provide the related change request, ticket, approval, or activity reference:
6. Affected Information
Identify the type of information potentially involved.
| Information Type | Yes / No / Unknown | Details |
|---|---|---|
| Public Information | ||
| Internal Information | ||
| Confidential Information | ||
| Restricted Information | ||
| Customer Information | ||
| Personal Data | ||
| Financial Information | ||
| Authentication Information | ||
| Source Code | ||
| Intellectual Property | ||
| Security Information | ||
| Regulated Information | ||
| Other |
If you do not know what information was involved, select Unknown rather than assuming that no information was affected.
7. Affected Systems and Assets
Identify anything potentially involved.
| Asset / System | Asset Type | Environment | Details |
|---|---|---|---|
| Laptop / Server / Cloud / SaaS / Application / Database | Production / Test / Development | ||
Cloud Resources
Where applicable:
- Cloud provider:
- Account / subscription:
- Region:
- IAM user/role:
- Resource:
- Service:
- API:
- Security group/network:
- Storage:
- Database:
- CI/CD environment:
8. Initial Security Impact
The reporter should provide an initial indication only. Final impact assessment should be performed by the Security/IT team.
Confidentiality
Could information have been viewed, accessed, disclosed, or downloaded without authorization?
- No
- Possibly
- Yes
- Unknown
Integrity
Could information, configuration, code, or systems have been modified without authorization?
- No
- Possibly
- Yes
- Unknown
Availability
Could a system or service have been disrupted or made unavailable?
- No
- Possibly
- Yes
- Unknown
Customer Impact
Could customers or customer services be affected?
- No
- Possibly
- Yes
- Unknown
Personal / Regulated Data
Could personal or regulated information be involved?
- No
- Possibly
- Yes
- Unknown
9. Suspicious Indicators
Select anything observed.
- Unknown login
- Unexpected MFA notification
- Password reset not initiated by user
- Suspicious email
- Suspicious link
- Suspicious attachment
- Unknown application
- Unexpected administrator activity
- Unexpected cloud resource
- Unexpected IAM role/user
- Unexpected privilege change
- Unexpected firewall/security-group change
- Unexpected data download
- Unusual network activity
- Malware alert
- Antivirus/EDR alert
- Data sent to wrong recipient
- Lost/stolen device
- Source-code access anomaly
- CI/CD anomaly
- Customer report
- Supplier notification
- Security monitoring alert
- Other
10. Evidence Available
Identify evidence that may help the investigation.
| Evidence | Available? | Location / Reference |
|---|---|---|
| Email / Message | Yes / No | |
| Screenshot | Yes / No | |
| Log | Yes / No | |
| Security Alert | Yes / No | |
| URL | Yes / No | |
| File / Attachment | Yes / No | |
| Ticket | Yes / No | |
| Cloud Log | Yes / No | |
| Application Log | Yes / No | |
| Endpoint Alert | Yes / No | |
| Other |
Evidence Handling
Do not delete suspicious emails, logs, files, messages, or other potential evidence unless instructed by the Security/IT team.
Do not forward sensitive evidence to personal email or upload it to unauthorized services.
11. Actions Already Taken
Record anything already done.
| Action | Date/Time | Person | Result |
|---|---|---|---|
Examples:
- Disconnected device
- Reported phishing email
- Changed password
- Contacted IT
- Disabled account
- Stopped suspicious process
- Blocked sender
- Removed device from network
- Contacted supplier
- No action taken
Do not take actions that could destroy evidence or interfere with an investigation unless immediate containment is necessary or instructed by an authorized person.
12. Immediate Escalation Indicators
Immediately notify the Security/IT team if any of the following may have occurred:
- Privileged account compromise
- Cloud administrator compromise
- Active attacker activity
- Ransomware
- Confirmed unauthorized access
- Customer information exposure
- Personal or regulated data exposure
- Large-scale malware
- Data exfiltration
- Production system compromise
- Major production outage
- Security logging disabled or manipulated
- Critical supplier compromise
- Financial fraud or business email compromise
- Significant contractual or regulatory impact
The reporter does not need to confirm the impact before escalating.
13. Initial Severity — Reporter Input
Does the event appear to be:
| Initial Assessment | Selection |
|---|---|
| Routine / Expected Activity | |
| Suspicious Activity | |
| Security Weakness | |
| Possible Security Incident | |
| Confirmed Security Incident | |
| Major / Critical Security Event | |
| Unknown |
Note: This is an initial reporter assessment. The Security/IT team determines the formal event classification and incident severity.
14. Security Team Assessment
| Assessment Field | Result |
|---|---|
| Event ID | |
| Assessed By | |
| Assessment Date/Time | |
| Event Validated? | Yes / No / Pending |
| Evidence Reviewed | |
| Information Affected | |
| Asset Affected | |
| Confidentiality Impact | |
| Integrity Impact | |
| Availability Impact | |
| Customer Impact | |
| Personal/Regulated Data Impact | |
| Business Impact | |
| Scope | |
| Attacker Activity | |
| Persistence | |
| Formal Classification | |
| Incident Severity | |
| Escalation Required? | Yes / No |
| Specialized Playbook Required? | Yes / No |
| Incident ID, if created |
15. Event Classification
After assessment, the Security/IT team may classify the event as:
| Classification | Meaning | Typical Action |
|---|---|---|
| CE-0 | False Positive | Document and close |
| CE-1 | Routine Security Event | Monitor and close |
| CE-2 | Security Weakness | Corrective action / risk treatment |
| CE-3 | Suspected Incident | Investigate and escalate as appropriate |
| CE-4 | Confirmed Incident | Activate incident response |
| CE-5 | Major/Critical Incident | Immediate escalation and major incident response |
Classification should be based on available evidence and should be reassessed if new information becomes available.
16. Response Decision
Security/IT Decision
- No security issue identified
- False positive
- Routine security event
- Security weakness identified
- Corrective action required
- Further investigation required
- Incident response activated
- Specialized incident playbook activated
- Management escalation required
- Privacy/legal assessment required
- Supplier escalation required
- Customer impact assessment required
- Regulatory assessment required
Decision Rationale
17. Corrective Actions
| Action ID | Finding / Weakness | Corrective Action | Owner | Target Date | Status |
|---|---|---|---|---|---|
Corrective actions may include:
- MFA implementation
- Access restriction
- Credential rotation
- Patch deployment
- Configuration correction
- Logging improvement
- Monitoring enhancement
- Security awareness
- Supplier action
- Policy/process improvement
- Technical control improvement
18. Reassessment
Security events should be reassessed when new evidence changes the understanding of the event.
Reassessment Questions
- Has new evidence been discovered?
- Has the scope increased?
- Has unauthorized access been confirmed?
- Has attacker activity been confirmed?
- Has persistence been identified?
- Has customer information been affected?
- Has personal or regulated data been affected?
- Has business impact increased?
- Has the event become a confirmed incident?
- Does the severity need to be increased or decreased?
Reclassification Record
| Date | Previous Classification | New Classification | Reason | Approved By |
|---|---|---|---|---|
19. Closure
The event may be closed when:
- Event has been assessed
- Evidence has been reviewed/preserved as appropriate
- Classification has been determined
- Required escalation has been completed
- Required response has been completed
- Corrective actions have been assigned
- Residual risk has been considered
- Related incident record has been linked, if applicable
- Required notifications/assessments have been completed
- Closure decision has been documented
Closure Summary
Closed By
Name: __________________________
Role: __________________________
Date: __________________________
20. AWS SaaS Example
Scenario
A developer receives an unexpected AWS MFA notification and notices an unfamiliar login to the company’s cloud account.
The developer reports the event using the Security Event Reporting Form.
Initial Report
Event Type: Cloud / Authentication
Affected System: AWS
Affected Identity: Developer IAM/federated identity
Observation: Unexpected authentication activity.
Initial Impact: Unknown
Information Potentially Affected: Production systems and customer data — unknown at initial reporting.
Security Team Assessment
The Security team reviews:
- AWS CloudTrail
- IAM activity
- Authentication logs
- Role assumptions
- Permission changes
- S3 access
- RDS activity
- ECS/container activity
- Security-group changes
- Secrets access
- Network activity
- CI/CD activity
The event may initially be classified as CE-3 Suspected Incident.
If unauthorized access is confirmed, it may be reclassified as CE-4 Confirmed Incident. If significant production or customer impact is established, the severity may be increased according to the organization’s Incident Severity Matrix.
The reporting form therefore becomes the starting point for the investigation rather than the final incident record.
21. Relationship With Other Security Records
The Security Event Reporting Form should connect to the broader security-event and incident-management process:
Security Event Reporting Form
↓
Information Security Event Assessment Procedure
↓
Security Event Classification Matrix
↓
Incident Severity Matrix
↓
Incident Escalation Matrix
↓
Incident Register
↓
Incident Investigation
↓
Incident Response / Specialized Playbook
↓
Corrective Action Tracker
↓
Incident Closure Report
↓
Lessons Learned / Management Review
Not every reported event becomes a security incident.
22. Startup Implementation
A startup does not need a complicated reporting platform to implement this process.
A practical model is:
Security Email / Form / Slack or Teams Reporting → Event ID → Security Assessment → Classification → Escalation → Response → Corrective Action → Closure
For a small SaaS company, the form can initially be implemented using:
- Microsoft Forms
- Google Forms
- Jira Service Management
- ServiceNow
- Freshservice
- Security ticketing system
- Internal compliance/GRC platform
The important requirement is not the software itself. The organization should be able to demonstrate that security events are reported, assessed, classified, escalated where necessary, acted upon, and documented.
23. Audit Evidence
The organization should be able to demonstrate:
- Security Event Reporting Form
- Event ID
- Date/time of report
- Reporter
- Event description
- Affected systems/information
- Evidence references
- Security assessment
- Classification decision
- Severity decision
- Escalation records
- Investigation records where applicable
- Corrective actions
- Reclassification decisions
- Closure approval
- Related incident records
For audits, the strongest evidence is not simply having the form. It is demonstrating that actual security events were reported, assessed, acted upon, and closed with evidence.
24. ISO 27001 Alignment
This form supports the organization’s information security event and incident-management processes.
It can provide evidence supporting processes related to:
- Reporting information security events
- Assessing information security events
- Information security incident management
- Access control
- Logging and monitoring
- Incident response
- Evidence preservation
- Corrective action
- Continual improvement
The exact form fields and workflow should be adapted to the organization’s ISMS, risk assessment, Statement of Applicability, contractual obligations, and applicable legal/regulatory requirements.
25. Final Audit Trail
Security Event Observed
→ Event Reported
→ Event ID Assigned
→ Initial Facts Recorded
→ Evidence Identified
→ Event Validated
→ C/I/A Impact Assessed
→ Information Impact Assessed
→ Business/Customer Impact Assessed
→ Scope Determined
→ Classification Assigned
→ Severity Assessed
→ Escalation Decision
→ Response / Investigation
→ Corrective Action
→ Reassessment
→ Residual Risk Considered
→ Closure Decision
→ Evidence Retained
Final Principle
Report Early + Capture Facts + Preserve Evidence + Assess Impact + Classify Based on Evidence + Escalate When Required + Reassess When Facts Change + Document the Decision.
A good Security Event Reporting Form should make it easy for people to report something suspicious before they know exactly what happened. The security team then turns that initial report into a structured, evidence-based assessment.