1. Purpose
The Security Investigation Checklist provides a structured method for investigating suspected information-security events, incidents, violations, unauthorized activity, control failures, and other security concerns.
It helps ensure that investigations are:
- Consistent
- Evidence-based
- Risk-based
- Appropriately authorized
- Confidential
- Properly documented
- Reproducible
- Defensible for audit and management review
Identify → Preserve → Contain → Plan → Investigate → Analyze → Validate → Assess → Report → Remediate → Verify → Close
2. When to Use
Use this checklist for investigations involving:
☐ Security incidents
☐ Suspected security violations
☐ Unauthorized access
☐ Credential compromise
☐ Privileged-access misuse
☐ Data exposure
☐ Personal-data incidents
☐ Customer-data incidents
☐ Malware
☐ Ransomware
☐ Phishing/BEC
☐ Cloud compromise
☐ Production-system compromise
☐ Security-control bypass
☐ Suspicious employee activity
☐ Security monitoring alerts
☐ Evidence or log manipulation
☐ Significant policy violations
☐ Repeated security non-compliance
☐ Other: __________________________
3. Investigation Information
| Field | Details |
|---|---|
| Investigation ID | |
| Related Incident ID | |
| Related Violation ID | |
| Date Opened | |
| Time Opened | |
| Investigator | |
| Investigation Lead | |
| Business Owner | |
| System Owner | |
| Security Reviewer | |
| Investigation Status | |
| Severity | |
| Classification | |
| Target Closure Date |
4. Investigation Status
☐ Reported
☐ Initial Assessment
☐ Evidence Preservation
☐ Containment
☐ Investigation Planned
☐ Investigation in Progress
☐ Analysis
☐ Findings Review
☐ Remediation
☐ Follow-Up
☐ Closed
5. Investigation Trigger
Identify how the investigation started.
☐ Employee report
☐ Security alert
☐ SIEM alert
☐ EDR alert
☐ Cloud alert
☐ IAM alert
☐ Access review
☐ Audit finding
☐ Vulnerability assessment
☐ Customer report
☐ Supplier report
☐ Incident response
☐ Security testing
☐ Management referral
☐ Other: __________________________
6. Initial Description
What was reported?
Who reported it?
When was it reported?
What is currently known?
What is currently unknown?
7. Initial Assessment
Determine:
☐ What happened?
☐ When did it happen?
☐ Who may be involved?
☐ What system is involved?
☐ What information is involved?
☐ Is the activity ongoing?
☐ Is unauthorized access possible?
☐ Is customer data involved?
☐ Is personal data involved?
☐ Is privileged access involved?
☐ Is production affected?
☐ Is there an immediate security risk?
8. Investigation Classification
Investigation Type
☐ Security Incident
☐ Security Violation
☐ Unauthorized Access
☐ Data Security Investigation
☐ Privacy Investigation
☐ Malware Investigation
☐ Phishing Investigation
☐ Cloud Security Investigation
☐ Insider Activity Investigation
☐ Security Control Failure
☐ Policy Non-Compliance
☐ Other: __________________________
Initial Severity
☐ Low
☐ Medium
☐ High
☐ Critical
9. Immediate Risk Assessment
Is the threat or activity ongoing?
☐ No
☐ Yes
☐ Unknown
Is unauthorized access still possible?
☐ No
☐ Yes
☐ Unknown
Is sensitive information exposed?
☐ No
☐ Yes
☐ Unknown
Is production affected?
☐ No
☐ Yes
☐ Unknown
Is customer impact possible?
☐ No
☐ Yes
☐ Unknown
10. Immediate Containment
Where required:
☐ Account disabled
☐ Session terminated
☐ Credential reset
☐ Token revoked
☐ MFA reset
☐ Device isolated
☐ Network access restricted
☐ Cloud access restricted
☐ Privileged access suspended
☐ Application access restricted
☐ Data access restricted
☐ Malicious activity blocked
☐ Vulnerable service isolated
☐ Other: __________________________
Containment Decision
Action: __________________________
Approved By: __________________________
Date/Time: __________________________
Reason: __________________________
11. Evidence Preservation
Before changing systems or collecting evidence:
☐ Evidence sources identified
☐ Relevant logs preserved
☐ Authentication records preserved
☐ Access records preserved
☐ Cloud activity preserved
☐ Application logs preserved
☐ Database logs preserved
☐ Endpoint evidence preserved
☐ Email evidence preserved where appropriate
☐ Relevant tickets preserved
☐ Security alerts preserved
☐ Evidence access restricted
☐ Chain of custody considered
☐ Evidence preservation documented
12. Evidence Register
| Evidence ID | Evidence | Source | Date/Time | Collector | Location | Integrity | Status |
|---|---|---|---|---|---|---|---|
Do not store passwords, API keys, private keys, MFA codes, or other authentication secrets as investigation evidence unless specifically required and securely handled under an authorized process.
13. Investigation Authorization
Confirm:
☐ Investigation authorized
☐ Investigation scope approved
☐ Investigator assigned
☐ Required technical access approved
☐ Privacy considerations reviewed
☐ Legal considerations reviewed where necessary
☐ HR considerations reviewed where necessary
☐ External investigator approved where applicable
14. Investigator Independence
☐ Investigator has appropriate competence
☐ No known conflict of interest
☐ Independence considered
☐ Responsibilities clearly defined
☐ External reviewer considered for sensitive matters
Independence Notes
15. Investigation Scope
Objective
Systems
Information
Personnel
Date/Time Period
Locations/Environments
Relevant Policies
Investigation Questions
- What happened?
- Who performed the activity?
- When did it occur?
- What systems were accessed?
- What information was involved?
- Was the activity authorized?
- What security controls were involved?
- What was the impact?
- Why did the event occur?
- What needs to be corrected?
16. Investigation Team
| Role | Person | Responsibility |
|---|---|---|
| Investigation Lead | ||
| Security | ||
| IT | ||
| System Owner | ||
| HR | ||
| Legal | ||
| Privacy | ||
| Compliance | ||
| Management |
Only assign functions that are necessary for the investigation.
17. Investigation Plan
☐ Objective defined
☐ Scope defined
☐ Evidence sources identified
☐ Systems identified
☐ Personnel identified
☐ Investigation team assigned
☐ Timeline established
☐ Interview plan established
☐ Analysis methodology defined
☐ Legal/privacy considerations addressed
☐ Reporting requirements defined
☐ Expected completion date established
18. Evidence Sources
Review relevant sources.
Identity and Access
☐ IAM logs
☐ Authentication logs
☐ MFA records
☐ Privileged-access records
☐ Access approvals
☐ Account changes
Cloud
☐ AWS CloudTrail
☐ Cloud configuration
☐ Cloud IAM
☐ Security alerts
☐ Network activity
☐ Storage activity
Endpoint
☐ EDR
☐ Antivirus
☐ Device logs
☐ File activity
☐ Malware alerts
Application
☐ Application logs
☐ API logs
☐ Administrative activity
☐ User activity
Network
☐ Firewall
☐ VPN
☐ DNS
☐ Network monitoring
Business Records
☐ Emails
☐ Tickets
☐ Change requests
☐ Access requests
☐ Approvals
☐ Relevant communications
19. Evidence Collection
For each evidence item:
☐ Source identified
☐ Collection authorized
☐ Collection date/time recorded
☐ Collector recorded
☐ Original protected where appropriate
☐ Working copy created where appropriate
☐ Integrity considered
☐ Evidence stored securely
☐ Evidence access restricted
☐ Evidence reference assigned
20. Timeline Reconstruction
Create a chronological record.
| Date/Time | Event | Source | Person/System | Significance |
|---|---|---|---|---|
Check for:
☐ Initial activity
☐ Initial authentication
☐ Privilege change
☐ System access
☐ Data access
☐ Data transfer
☐ Configuration change
☐ Detection
☐ Containment
☐ Subsequent activity
21. User and Account Analysis
☐ User identified
☐ Account identified
☐ Account ownership verified
☐ Access permissions reviewed
☐ Role reviewed
☐ MFA status reviewed
☐ Login locations reviewed
☐ Device information reviewed
☐ Session activity reviewed
☐ Privileged activity reviewed
☐ Account changes reviewed
☐ Shared-account possibility assessed
22. Access Authorization Analysis
Determine:
☐ Was the access authorized?
☐ Was the access within the person’s role?
☐ Was approval available?
☐ Was the access temporary?
☐ Had access expired?
☐ Was privileged access involved?
☐ Was another person’s account used?
☐ Were credentials shared?
☐ Were controls bypassed?
23. Information Analysis
Identify:
☐ Information accessed
☐ Information classification
☐ Information owner
☐ Number of records
☐ Customer information
☐ Personal data
☐ Confidential information
☐ Restricted information
☐ Source code
☐ Credentials/secrets
☐ Financial information
24. Data Activity Analysis
Determine whether information was:
☐ Viewed
☐ Accessed
☐ Copied
☐ Downloaded
☐ Exported
☐ Transferred
☐ Shared
☐ Modified
☐ Deleted
☐ Encrypted
☐ Published
☐ Disclosed
☐ Unknown
Details
25. Technical Analysis
Review where applicable:
☐ Authentication
☐ Authorization
☐ IAM
☐ Privileged access
☐ Endpoint
☐ Network
☐ Cloud
☐ Application
☐ Database
☐ Source code
☐ Configuration
☐ Vulnerability
☐ Malware
☐ Logging
☐ Monitoring
☐ Security controls
26. Interview Checklist
Preparation
☐ Interview objective defined
☐ Evidence reviewed
☐ Questions prepared
☐ Participants identified
☐ Confidentiality considered
☐ HR/legal requirements considered
Interview
☐ Date/time recorded
☐ Participants recorded
☐ Facts discussed
☐ Timeline discussed
☐ Authorization discussed
☐ Access discussed
☐ Information discussed
☐ Other personnel discussed
☐ Supporting evidence identified
☐ Additional evidence requested
Interview Record
| Person | Role | Date | Key Information | Follow-Up |
|---|---|---|---|---|
Statements should be distinguished from independently verified facts.
27. Intent Assessment
Where relevant:
☐ Accidental
☐ Human error
☐ Negligent
☐ Reckless
☐ Intentional
☐ Malicious
☐ Unknown
Evidence Supporting Assessment
Intent should not be assumed without appropriate evidence.
28. Training and Awareness Review
☐ Relevant policy existed
☐ Policy was accessible
☐ Employee received policy
☐ Training was assigned
☐ Training was completed
☐ Role-based training was provided
☐ Requirement was communicated
☐ Policy had recently changed
☐ Employee was informed of change
☐ Previous warnings existed
Assessment
29. Security Control Assessment
Determine which controls should have prevented or detected the activity.
| Control | Expected | Actual | Effective? | Gap |
|---|---|---|---|---|
Consider:
☐ Authentication
☐ MFA
☐ Least privilege
☐ Access approval
☐ Privileged access
☐ Logging
☐ Monitoring
☐ Network controls
☐ Endpoint controls
☐ Data protection
☐ Security awareness
☐ Change management
☐ Incident detection
30. Root Cause Analysis
Determine why the event occurred.
☐ Human error
☐ Lack of awareness
☐ Insufficient training
☐ Unclear policy
☐ Process weakness
☐ Excessive access
☐ Technical control weakness
☐ Monitoring weakness
☐ Configuration error
☐ System limitation
☐ Management issue
☐ Workload/process pressure
☐ Deliberate behavior
☐ Third-party issue
☐ Other
Root Cause
31. Contributing Factors
Identify additional factors.
☐ Excessive privileges
☐ Shared credentials
☐ Missing MFA
☐ Poor documentation
☐ Inadequate training
☐ Inadequate monitoring
☐ Lack of segregation of duties
☐ Inadequate approval
☐ Poor configuration
☐ Legacy system
☐ Supplier dependency
☐ Time pressure
☐ Human error
☐ Other
32. Impact Assessment
Confidentiality
☐ No impact
☐ Potential impact
☐ Confirmed impact
Integrity
☐ No impact
☐ Potential impact
☐ Confirmed impact
Availability
☐ No impact
☐ Potential impact
☐ Confirmed impact
Privacy
☐ No impact
☐ Potential impact
☐ Confirmed impact
33. Business Impact
☐ No known impact
☐ Service disruption
☐ Customer impact
☐ Financial impact
☐ Regulatory impact
☐ Contractual impact
☐ Reputational impact
☐ Operational impact
☐ Unknown
Details
34. Customer Impact
☐ No customer impact
☐ Potential customer impact
☐ Confirmed customer impact
☐ Customer data involved
☐ Customer service affected
☐ Customer notification assessment required
Details
35. Privacy Assessment
If personal data is involved:
☐ Data categories identified
☐ Data subjects identified
☐ Volume assessed
☐ Location assessed
☐ Access assessed
☐ Disclosure assessed
☐ Transfer assessed
☐ Retention assessed
☐ Privacy team notified
☐ Legal assessment completed
☐ Regulatory notification assessed
☐ Data-subject notification assessed where applicable
36. Regulatory and Contractual Assessment
☐ Regulatory requirement identified
☐ Customer contract reviewed
☐ Supplier contract reviewed
☐ Notification requirement assessed
☐ Security commitment assessed
☐ Audit requirement assessed
☐ Legal review completed where required
Requirements
37. Risk Assessment
Likelihood
☐ Low
☐ Medium
☐ High
Impact
☐ Low
☐ Medium
☐ High
Overall Risk
☐ Low
☐ Medium
☐ High
☐ Critical
Risk Rationale
38. Findings
Each finding should be evidence-based.
| Finding ID | Requirement | Evidence | Condition | Risk | Conclusion |
|---|---|---|---|---|---|
Use:
Requirement → Evidence → Condition → Risk → Conclusion
39. Evidence Validation
Before finalizing conclusions:
☐ Evidence source verified
☐ Evidence integrity considered
☐ Evidence corroborated where appropriate
☐ Alternative explanations considered
☐ Conflicting evidence assessed
☐ Interview statements compared with evidence
☐ Timeline validated
☐ Conclusions supported by evidence
☐ Investigation limitations documented
40. Investigation Conclusion
Select the appropriate conclusion.
☐ Incident confirmed
☐ Violation confirmed
☐ Policy non-compliance confirmed
☐ Human error
☐ Control failure
☐ Security concern only
☐ Violation not confirmed
☐ Incident not confirmed
☐ Insufficient evidence
☐ Further investigation required
☐ Other
Conclusion
41. Final Classification
Investigation Type: __________________________
Violation Category: __________________________
Information Classification: __________________________
System Criticality: __________________________
Access Level: __________________________
Intent: __________________________
Actual Impact: __________________________
Potential Impact: __________________________
Overall Severity: Low / Medium / High / Critical
Response Level: R1 / R2 / R3 / R4
Classification Rationale
42. Corrective Action
Identify actions required to address the immediate issue and root cause.
☐ Access correction
☐ Credential reset
☐ MFA improvement
☐ Privileged-access control
☐ Monitoring improvement
☐ Logging improvement
☐ Configuration change
☐ Vulnerability remediation
☐ Training
☐ Policy update
☐ Procedure update
☐ Technical control
☐ Process improvement
☐ Supplier action
☐ Risk treatment
☐ Other
43. Corrective Action Register
| Action ID | Finding | Root Cause | Action | Owner | Due Date | Evidence | Verification | Status |
|---|---|---|---|---|---|---|---|---|
44. HR Review
Where the investigation involves employee conduct:
☐ HR review not required
☐ HR informed
☐ HR investigation required
☐ Disciplinary review initiated
☐ Employment requirements considered
☐ Employee response documented
☐ HR action completed
Security findings should be kept separate from employment decisions where appropriate.
45. Legal/Privacy Review
☐ Not required
☐ Legal review
☐ Privacy review
☐ Regulatory assessment
☐ Customer notification assessment
☐ Contractual notification assessment
☐ Litigation/evidence preservation consideration
☐ Other
Reference: __________________________
46. Evidence and Record Protection
☐ Investigation records stored securely
☐ Access restricted
☐ Sensitive evidence protected
☐ Personal information minimized
☐ Investigation communications protected
☐ Evidence retention requirement determined
☐ Disposal requirements determined
☐ Chain-of-custody records retained where required
47. Management Review
For significant investigations:
☐ Investigation summary provided
☐ Risk discussed
☐ Customer impact discussed
☐ Privacy impact discussed
☐ Corrective actions reviewed
☐ Residual risk reviewed
☐ Risk acceptance considered
☐ Management decision recorded
Management Comments
48. Follow-Up
After corrective actions:
☐ Action implementation verified
☐ Evidence reviewed
☐ Control effectiveness assessed
☐ Residual risk assessed
☐ Recurrence checked
☐ Additional monitoring established
☐ Additional training completed
☐ Finding closed
☐ Risk register updated where required
49. Lessons Learned
What worked?
What failed?
Why did it happen?
Could it have been prevented?
What controls should change?
What training is required?
What process should change?
50. Investigation Closure Checklist
☐ Investigation objective achieved
☐ Scope completed
☐ Evidence collected
☐ Evidence validated
☐ Timeline completed
☐ Interviews completed where required
☐ Technical analysis completed
☐ Root cause determined
☐ Impact assessed
☐ Risk assessed
☐ Findings documented
☐ Classification finalized
☐ Customer assessment completed
☐ Privacy assessment completed where required
☐ Regulatory/contractual assessment completed
☐ HR review completed where required
☐ Legal review completed where required
☐ Corrective actions assigned
☐ Corrective actions verified
☐ Residual risk addressed
☐ Lessons learned documented
☐ Investigation report completed
☐ Records securely retained
☐ Management approval obtained where required
☐ Investigation formally closed
51. Investigation Closure Record
Investigation ID: __________________________
Final Status: __________________________
Final Severity: __________________________
Final Classification: __________________________
Root Cause: __________________________
Residual Risk: __________________________
Risk Treatment: __________________________
Corrective Action Reference: __________________________
Investigator: __________________________
Reviewer: __________________________
Approver: __________________________
Closure Date: __________________________
52. AWS SaaS Startup Example
Consider a SaaS startup operating:
- AWS production
- Customer database
- GitHub
- Microsoft 365
- Remote employees
- Centralized logging
Scenario
Security receives an alert indicating that an employee account accessed an AWS production database from an unusual location.
Investigation
Initial Assessment
☐ Production involved
☐ Customer data potentially involved
☐ User account identified
☐ Potential unauthorized access
Containment
☐ Active session terminated
☐ Account temporarily restricted
Evidence
☐ CloudTrail
☐ IAM activity
☐ Database logs
☐ MFA records
☐ Endpoint records
Timeline
Login → MFA → AWS access → Database access → Queries → Session termination
Analysis
Determine:
- Was the employee authorized?
- Was the device legitimate?
- Was MFA used?
- What records were accessed?
- Was data exported?
- Was another person’s account used?
- Was the activity malicious?
Outcome
Suppose the investigation determines that the employee was authorized to work remotely, MFA was valid, and the unusual location was caused by an approved corporate VPN.
The initial alert would therefore not be classified as a confirmed security violation.
Lesson
An alert is a trigger for investigation—not automatically proof of a security violation.
53. Startup-Friendly Investigation Model
For routine investigations:
Level 1 — Basic
- Security/IT review
- Basic evidence
- Simple conclusion
- Corrective action
Level 2 — Formal
- Investigation lead
- Evidence register
- Timeline
- Interviews
- Root-cause analysis
- Risk assessment
Level 3 — Enhanced
- Security + management
- HR/Legal/Privacy
- Detailed evidence preservation
- Technical analysis
- Formal investigation report
- Corrective-action verification
Level 4 — Critical
- Incident response
- Executive escalation
- Legal involvement
- Privacy/regulatory assessment
- Independent investigation where appropriate
- Formal evidence handling
- Detailed remediation and follow-up
54. Common Mistakes
Avoid:
- Investigating before preserving evidence.
- Changing systems without recording the change.
- Assuming the initial alert is proof.
- Assuming employee intent.
- Collecting unnecessary personal information.
- Allowing unauthorized investigators to access evidence.
- Ignoring privacy or employment requirements.
- Relying on one evidence source.
- Failing to reconstruct a timeline.
- Failing to distinguish facts from assumptions.
- Closing investigations without corrective-action verification.
- Failing to document limitations.
- Treating technical containment as final remediation.
- Ignoring root causes.
55. Relationship With Other ISMS Documents
| Document | Relationship |
|---|---|
| Security Violation Investigation Procedure | Defines investigation process |
| Security Violation Classification Matrix | Classifies violations |
| Employee Security Violation Report | Initiates violation reporting |
| Incident Response Procedure | Handles active security incidents |
| Incident Investigation Procedure | Supports incident investigations |
| Evidence Preservation Procedure | Protects evidence |
| Evidence Collection Procedure | Defines evidence collection |
| Chain-of-Custody Form | Records evidence handling |
| Security Findings Register | Records findings |
| Corrective Action Tracker | Tracks remediation |
| Information Security Disciplinary Policy | Defines personnel disciplinary principles |
| Access Management Procedure | Supports access investigation |
| Privileged Access Procedure | Supports privileged-access investigation |
| Security Awareness Policy | Supports training/awareness assessment |
56. ISO 27001 Connection
A Security Investigation Checklist supports a structured approach to investigating security events, incidents, violations, control failures, and other security concerns.
It can support areas relating to:
- Information-security incident management
- Access control
- Logging and monitoring
- Personnel security
- Information protection
- Evidence handling
- Risk management
- Corrective action
- Continual improvement
The Security Investigation Checklist is not itself a universally mandatory ISO 27001 document. The organization should determine its investigation methodology, evidence requirements, escalation criteria, roles, and records based on its ISMS scope, risks, applicable controls, contractual commitments, and legal/regulatory requirements.
57. Final Audit Checklist
☐ Investigation ID assigned
☐ Trigger documented
☐ Initial assessment completed
☐ Severity assessed
☐ Immediate risk assessed
☐ Containment considered
☐ Evidence identified
☐ Evidence preserved
☐ Investigation authorized
☐ Investigator assigned
☐ Independence considered
☐ Scope defined
☐ Investigation plan established
☐ Evidence collected
☐ Timeline reconstructed
☐ User/account activity reviewed
☐ Authorization reviewed
☐ Information affected identified
☐ Technical analysis completed
☐ Interviews completed where appropriate
☐ Intent assessed
☐ Training reviewed
☐ Security controls assessed
☐ Root cause assessed
☐ Impact assessed
☐ Customer impact assessed
☐ Privacy impact assessed
☐ Regulatory/contractual impact assessed
☐ Risk assessed
☐ Findings documented
☐ Evidence validated
☐ Final classification recorded
☐ Corrective actions assigned
☐ HR review completed where required
☐ Legal/Privacy review completed where required
☐ Management review completed where required
☐ Corrective actions verified
☐ Residual risk addressed
☐ Lessons learned recorded
☐ Investigation report completed
☐ Evidence securely retained
☐ Investigation formally closed
58. Final Audit Trail
For every significant security investigation, the organization should be able to demonstrate:
What triggered the investigation?
Who authorized it?
What was initially known?
What immediate risk existed?
What evidence was preserved?
Who conducted the investigation?
Was sufficient independence maintained?
What systems and information were examined?
What happened and when?
Was the activity authorized?
What evidence supports the conclusion?
What was the root cause?
What was the security, business, customer, and privacy impact?
What risk remained?
What corrective actions were assigned?
Were the actions verified?
What lessons were learned?
Who approved closure?
Final Principle
A security investigation is successful when it establishes what happened, supports the conclusion with reliable evidence, identifies the root cause and risk, and ensures that corrective actions actually reduce the likelihood or impact of recurrence.
Investigation Lifecycle:
Identify → Preserve → Contain → Plan → Investigate → Analyze → Validate → Assess → Report → Remediate → Verify → Close → Improve