Incident Reporting Form

1. Purpose

The Incident Reporting Form provides a structured method for reporting suspected or confirmed information security incidents.

The form captures the information required to:

Record the initial report
Establish what happened
Identify affected systems and information
Determine whether an incident exists
Assign initial severity
Initiate escalation
Preserve relevant evidence
Start investigation and response

The person reporting the event is not expected to determine the final severity, root cause, or impact. Those decisions should be made by the designated incident response team.

2. When to Use This Form

Report an event when you suspect:

Unauthorized access
Account or credential compromise
Phishing
Malware
Ransomware
Data leakage or exposure
Loss or theft of an information asset
Unauthorized disclosure
Suspicious cloud activity
Unauthorized configuration changes
Security vulnerability exploitation
Production system compromise
Denial-of-service or availability attack
Source-code or CI/CD compromise
Supplier security incident
Privacy or personal-data incident
Physical security incident affecting information
Any unusual activity that could affect information security

When in doubt, report the event.

3. Reporter Information

Field	Information
Report ID
Date Reported
Time Reported
Reported By
Employee / Contractor / Customer / Supplier
Department / Organization
Email / Contact
Location / Time Zone
Preferred Contact Method
How Was the Event Detected?
Is the Reporter Still Observing the Activity?	Yes / No

4. Incident Information

4.1 What Happened?

Describe the event in your own words.

Do not attempt to determine the root cause unless you have verified evidence.

Description:

4.2 Date and Time

Field	Information
Date/Time First Observed
Date/Time Incident Started, if Known
Date/Time Reported
Time Zone
Is the Time Confirmed?	Yes / No / Estimated

If the exact time is unknown, record the best available estimate.

5. Incident Type

Select all applicable categories:

Phishing
Account Compromise
Credential Exposure
Malware
Ransomware
Data Breach
Unauthorized Access
Information Leakage
Lost/Stolen Device
Cloud Security Incident
Application Security Incident
Network Security Incident
Vulnerability Exploitation
Denial of Service
Insider/Suspected Misuse
Supplier/Third-Party Incident
Privacy Incident
Physical Security Incident
Availability Incident
Source Code/CI-CD Incident
Other

Other:

6. Affected Information

Identify what type of information may be involved.

Public Information
Internal Information
Confidential Information
Customer Information
Personal Data
Financial Information
Authentication Information
Passwords
API Keys / Access Keys
Secrets
Source Code
Intellectual Property
Security Configuration
Regulated Information
Other

Information Description

Is the Information Confirmed to Have Been Accessed?

Yes
No
Unknown

7. Affected Systems / Assets

Identify any affected or potentially affected assets.

Asset / System	Environment	Owner	Affected?	Evidence Available
	Production / Test / Development		Yes / No / Unknown

Examples:

Laptop
Server
AWS account
S3 bucket
RDS database
ECS workload
SaaS application
Email account
Git repository
CI/CD pipeline
VPN
Firewall
Database
API
Mobile device

8. Account / Identity Information

If an account may be involved:

Field	Information
Account/User
Username / User ID
Role
Privileged Account?	Yes / No / Unknown
MFA Enabled?	Yes / No / Unknown
API Key Involved?	Yes / No / Unknown
Access Key Involved?	Yes / No / Unknown
Suspicious Login Observed?	Yes / No / Unknown
Account Currently Active?	Yes / No / Unknown

Do not include passwords, private keys, authentication codes, or other secrets in this form.

9. Initial Impact Assessment

At the time of reporting, identify any known impact.

Confidentiality

No known impact
Possible unauthorized access
Confirmed unauthorized access
Data disclosure suspected
Unknown

Integrity

No known impact
Unauthorized change suspected
Confirmed unauthorized change
Data/system corruption suspected
Unknown

Availability

No known impact
Service degradation
Service unavailable
Production outage
Unknown

Business Impact

No known business impact
Limited impact
Significant impact
Critical impact
Unknown

10. Customer / Third-Party Impact

Are customers affected or potentially affected?

Yes
No
Unknown

Is a supplier or third party involved?

Yes
No
Unknown

Is customer data potentially involved?

Yes
No
Unknown

Is personal or regulated information potentially involved?

Yes
No
Unknown

If yes, provide details without including unnecessary personal information.

11. Evidence Available

Identify evidence that may help the investigation.

Email
Email Headers
Screenshot
Log File
Cloud Log
Application Log
Security Alert
Endpoint Alert
Network Log
File
URL
Message
Ticket
System Configuration
Audit Log
Other

Evidence Location / Reference

Important: Do not delete, modify, forward, rename, or otherwise alter potentially relevant evidence unless instructed by the incident response team.

12. Suspicious Indicators

Record known indicators where available.

Indicator Type	Value
IP Address
Domain
URL
Email Address
File Name
Hash
Username
Hostname
AWS Resource
Account ID / Resource ID
Other Indicator

Only record information necessary for investigation. Do not enter passwords, access tokens, private keys, or other secrets.

13. Actions Already Taken

Describe anything already done.

Examples:

Account disconnected
Password changed
Device disconnected from network
Suspicious email reported
Access revoked
System isolated
Supplier contacted
Security team notified

Actions Taken:

Who Performed the Action?

Date/Time of Action

14. Initial Severity

The reporter may provide an initial assessment, but the Incident Response Team is responsible for confirming severity.

SEV-1 – Critical
SEV-2 – High
SEV-3 – Medium
SEV-4 – Low
Unknown / Requires Assessment

Reason for Initial Classification

15. Immediate Escalation Indicators

Check any that apply:

Privileged account involved
Production environment affected
Customer information involved
Personal data involved
Financial information involved
Active attacker suspected
Data exfiltration suspected
Ransomware suspected
Cloud account compromise suspected
Critical vulnerability exploited
Major service disruption
Supplier compromise
Regulatory obligation may apply
Contractual notification may be required
Business continuity may be required
Unknown but potentially significant impact

If any critical condition is suspected, escalate according to the Incident Escalation Matrix without waiting for completion of this form.

16. Incident Response Team Assessment

For use by the Incident Response Team

Field	Assessment
Incident Confirmed?	Yes / No / Under Investigation
Incident ID
Final Incident Type
Severity	SEV-1 / SEV-2 / SEV-3 / SEV-4
Incident Commander
Security Lead
Technical Owner
Business Owner
Privacy/Legal Required?	Yes / No
Supplier Involved?	Yes / No
Customer Impact?	Yes / No / Unknown
Regulatory Assessment Required?	Yes / No
BCP/DR Activation Required?	Yes / No
External Support Required?	Yes / No

17. Initial Response Decision

Select the applicable action:

Monitor / No Incident
Open Security Incident
Escalate to Incident Commander
Activate Incident Response Team
Activate Specialized Playbook
Contain Immediately
Preserve Evidence
Initiate Privacy Assessment
Initiate Legal Assessment
Initiate Supplier Response
Initiate Business Continuity
Customer Impact Assessment
Regulatory Assessment
External Incident Response Support

18. Specialized Playbook

If applicable, activate:

Account Compromise Playbook
Phishing Playbook
Data Breach Playbook
Ransomware Playbook
Cloud Compromise Playbook
Malware Playbook
Supplier Incident Playbook
Other

Playbook Reference:

19. Incident Reporting Approval / Acceptance

Role	Name	Date/Time	Status
Incident Receiver
Security Lead
Incident Commander

20. Follow-Up Actions

Action	Owner	Priority	Target Date	Status

Follow-up actions should be transferred to the organization’s Corrective Action Tracker where appropriate.

21. Reporter Guidance

Employees and other users should:

Report Quickly

Do not wait until all facts are known.

Preserve Evidence

Keep suspicious emails, messages, screenshots, alerts, and other relevant information.

Do Not Investigate Beyond Your Authority

Do not attempt to access another user’s account, alter logs, delete files, or perform unauthorized forensic activity.

Do Not Destroy Evidence

Do not delete suspicious emails, files, logs, or messages unless instructed.

Do Not Communicate Externally

Do not contact customers, regulators, suppliers, media, or attackers unless authorized by the incident response process.

Do Not Include Secrets

Never enter:

Passwords
MFA codes
Private keys
API secrets
Access tokens
Recovery codes

in the incident report.

22. AWS SaaS Startup Example

Report

A developer receives an AWS security alert showing an unusual login to an administrative identity.

The developer submits:

Incident Type: Cloud Security Incident / Account Compromise

Affected Asset: AWS Production Account

Account: Administrator IAM identity

Observed Activity: Unusual login followed by creation of an IAM role

Customer Impact: Unknown

Data Access: Unknown

Evidence: CloudTrail alert and security notification

Initial Severity: SEV-1/SEV-2 pending investigation

Incident Response Team Action

The security team:

Creates an incident record.
Assigns an Incident Commander.
Preserves CloudTrail evidence.
Restricts the suspicious identity.
Revokes active sessions where appropriate.
Reviews IAM activity.
Investigates S3, RDS, ECS and other production resources.
Checks for unauthorized data access.
Determines customer/privacy impact.
Reassesses severity based on evidence.

The reporter does not need to determine whether the attacker actually accessed customer data. That determination belongs to the investigation team.

23. Incident Reporting Workflow

Security Event Observed

↓

Employee / System Reports Event

↓

Incident Reporting Form Created

↓

Initial Validation

↓

Incident Confirmed?

No → Record / Close / Monitor
Yes → Create Incident Record

↓

Initial Severity Assigned

↓

Incident Escalation Matrix Applied

↓

Incident Response Team Activated

↓

Evidence Preserved

↓

Containment / Investigation

↓

Impact and Root Cause Assessment

↓

Recovery

↓

Corrective Actions

↓

Incident Closure

24. Relationship With Other Incident Records

The Incident Reporting Form is the starting point of the incident record.

It feeds into:

Incident Register
Incident Severity Matrix
Incident Escalation Matrix
Incident Response Team RACI
Incident Investigation Template
Incident Timeline
Evidence Log
Incident Communication Records
Corrective Action Tracker
Incident Closure Report
Lessons Learned
Management Review

The reporting form should capture initial facts, while subsequent investigation records should contain validated findings.

25. ISO 27001 Connection

The reporting mechanism supports the organization’s information security incident management process by providing a defined method for personnel to report suspected information security events.

The organization should determine:

What events must be reported
Who can report them
Reporting channels
Response time expectations
Escalation requirements
Evidence handling requirements
Roles and responsibilities
Communication requirements
Regulatory and contractual considerations

The form itself is an implementation tool; the organization should tailor it to its risk environment and ISMS.

26. Audit Evidence

Evidence generated from this process may include:

Completed Incident Reporting Forms
Incident Tickets
Email or alert records
Security monitoring alerts
Incident Register entries
Severity assessments
Escalation records
Investigation records
Evidence logs
Corrective action records
Incident Closure Reports
Lessons Learned
Management Review records
Incident Response Testing records

27. Incident Reporting Audit Trail

A practical audit trail is:

Security Event Observed
→ Event Reported
→ Reporter Information Recorded
→ Initial Facts Captured
→ Potential Information/System Impact Identified
→ Evidence Identified
→ Incident Validated
→ Incident ID Assigned
→ Severity Assessed
→ Escalation Performed
→ Incident Response Team Activated
→ Investigation Initiated
→ Containment/Recovery Performed
→ Corrective Actions Assigned
→ Incident Closed

28. Final Principle

If Something Looks Wrong, Report It Early — Capture the Facts, Preserve the Evidence, and Let the Incident Response Team Determine the Impact.

A good incident reporting process should make reporting easy, fast, and safe. The objective is not to require employees to diagnose security incidents; it is to ensure that potentially important events reach the right people before they become larger incidents.

ISO/IEC 27001