Digital Forensics Procedure

1. Purpose

The Digital Forensics Procedure defines how the organization identifies, preserves, collects, examines, analyzes, documents, and reports digital evidence during security investigations.

The objective is to ensure that forensic activities are:

Authorized
Evidence-based
Controlled
Repeatable
Traceable
Proportionate to the incident
Protective of evidence integrity
Respectful of privacy and legal requirements

The procedure supports investigations where ordinary incident-response activities are not sufficient to determine what happened, how it happened, what was affected, or whether evidence of unauthorized activity exists.

Digital forensics should be performed only to the level necessary for the investigation. Not every security incident requires a full forensic examination.

2. Scope

This procedure applies to digital evidence from:

Employee endpoints
Laptops and desktops
Servers
Virtual machines
Cloud environments
AWS accounts and resources
SaaS platforms
Identity providers
Email systems
Databases
Applications
Network infrastructure
Mobile devices where authorized
Storage systems
Source-code repositories
CI/CD platforms
Containers
Kubernetes environments
Security tools
Authentication systems
Logs and monitoring platforms
Removable media
Supplier systems where evidence is lawfully provided

3. When Digital Forensics Is Required

Digital forensic activities may be appropriate when:

Unauthorized access is suspected or confirmed.
An account or credential may have been compromised.
Malware is suspected.
Ransomware is detected.
A system may have been compromised.
Evidence of persistence is suspected.
Data exfiltration is suspected.
Privilege escalation occurred.
An attacker may have moved laterally.
A cloud account may have been compromised.
A production system may have been altered.
An insider investigation requires technical evidence.
Evidence may be required for legal, regulatory, insurance, or contractual purposes.
The organization cannot determine the incident scope using normal investigation methods.

A forensic investigation may not be necessary for a blocked phishing email, routine vulnerability scan, false positive, or other low-impact event where sufficient evidence already establishes the outcome.

4. Digital Forensics Principles

The organization should follow these principles.

4.1 Authorization First

Forensic collection must be authorized by an appropriate person or function.

4.2 Preserve Before Analysis

Where practical, preserve relevant evidence before performing actions that could alter it.

4.3 Minimize Changes

Investigators should avoid unnecessary changes to the original evidence.

4.4 Maintain Traceability

Record who collected, accessed, transferred, analyzed, and disposed of evidence.

4.5 Protect Evidence Integrity

Use appropriate integrity mechanisms such as hashing and controlled storage.

4.6 Least Privilege

Only authorized personnel should access forensic evidence.

4.7 Minimize Sensitive Data

Collect only information relevant to the investigation.

4.8 Separate Original Evidence and Working Copies

Where practical, preserve original evidence and perform analysis on authorized copies.

4.9 Record Limitations

Document missing logs, unavailable systems, retention limitations, or other evidence gaps.

4.10 Facts Before Conclusions

Distinguish:

Evidence → Observation → Hypothesis → Finding → Conclusion

5. Roles and Responsibilities

Role	Responsibility
Incident Commander	Authorizes and coordinates investigation
Forensic Investigator	Performs forensic collection and analysis
Security Lead	Provides technical/security oversight
IT/Cloud Lead	Supports infrastructure and cloud investigation
Application/DevOps Lead	Supports application and CI/CD analysis
Privacy Lead	Assesses personal-data considerations
Legal/Compliance	Advises on legal/regulatory requirements
HR	Supports authorized employee investigations
Business Owner	Assesses business impact
Management	Provides decisions and resources
External Forensic Specialist	Performs specialized investigation where required

For sensitive employee, legal, or regulatory investigations, appropriate legal/HR authorization should be obtained before collecting potentially private information.

6. Forensic Investigation Lifecycle

The standard lifecycle is:

Trigger → Authorize → Scope → Preserve → Acquire → Verify → Examine → Analyze → Correlate → Determine Findings → Report → Retain → Dispose

Each phase should be documented.

7. Forensic Investigation Trigger

A forensic investigation may begin from:

Confirmed security incident
Security event
Incident response team decision
Data breach investigation
Malware detection
Ransomware
Account compromise
Cloud compromise
Insider investigation
Legal request
Regulatory requirement
Customer investigation
Cyber-insurance requirement
Significant vulnerability exploitation

The trigger should be linked to the relevant Incident ID or Investigation ID.

8. Forensic Authorization

Before collection, document:

Incident ID
Investigation ID
Investigation objective
Scope
Systems/assets
Collection authority
Investigator
Approver
Date/time
Legal/privacy considerations
Expected evidence
Collection limitations

Authorization Record

Field	Details
Investigation ID
Incident ID
Objective
Scope
Authorized By
Investigator
Date/Time
Privacy Review Required	Yes/No
Legal Review Required	Yes/No
Restrictions

Do not begin intrusive forensic activity without appropriate authorization.

9. Investigation Scoping

Define exactly what is being investigated.

Scope may include:

Specific user
Specific endpoint
AWS account
Cloud resource
Application
Database
Email mailbox
Source repository
CI/CD environment
Network segment
Specific time period
Specific information

Example

Incident: AWS privileged account compromise

Scope:

AWS production account
IAM identities
CloudTrail
S3
RDS
EC2
Security groups
Secrets Manager
CI/CD
24-hour period surrounding initial detection

10. Evidence Identification

Potential forensic evidence includes:

Identity

Authentication logs
SSO logs
IAM activity
MFA events
Access-key activity
OAuth activity

Endpoint

System logs
Processes
Files
Browser artifacts
Security-tool alerts
Persistence mechanisms
Network connections

Network

Firewall logs
DNS
VPN
Proxy
WAF
Network flow logs

Cloud

Cloud audit logs
IAM
Security alerts
Storage activity
Network activity
Configuration history

Application

Application logs
API logs
Authentication logs
Administrative actions

Database

Query logs
Audit logs
Authentication
Data access

Development

Git activity
CI/CD logs
Deployment records
Secrets access
Build activity

Email

Original messages
Headers
Attachments
URLs
Mailbox activity

11. Evidence Preservation

Before acquisition, identify evidence that may be lost through:

System shutdown
Log rotation
Credential rotation
Cloud retention expiry
Automatic deletion
Malware cleanup
Configuration changes
Application restart
Endpoint reimaging

Where appropriate, preserve:

Relevant logs
System state
Cloud audit records
Authentication records
Network evidence
Memory or volatile information
Files
Configuration
Email
Application/database records

Containment remains the priority if delaying containment would increase the security risk.

12. Volatile Evidence

Some evidence may disappear rapidly.

Examples include:

RAM
Running processes
Active network connections
Logged-in users
Active sessions
Temporary files
Memory-resident malware
Cloud sessions
Temporary credentials
Authentication tokens

The investigator should determine whether volatile evidence should be collected before:

Shutdown
Reboot
Isolation
Credential revocation
Process termination

The decision should be documented.

13. Digital Evidence Acquisition

Evidence acquisition should be:

Authorized
Relevant
Controlled
Documented
Repeatable where practical
Proportionate

Record:

Source
Date/time
Investigator
Collection method
Tool
Tool version where relevant
Query/command
Filters
Time period
Original location
Output
Hash/integrity information

14. Forensic Imaging

Where a full forensic image is necessary, record:

Device/system
Storage media
Serial number
Asset ID
Imaging method
Tool
Tool version
Start/end time
Investigator
Image size
Hash
Storage location
Write-protection controls where applicable

The organization should avoid unnecessary imaging when targeted collection is sufficient.

15. Working Copies

Where practical:

Original Evidence → Preserved Master → Authorized Working Copy → Analysis

The original should remain protected from unnecessary modification.

Record:

Original Evidence ID
Working Copy ID
Copy date/time
Created by
Purpose
Hash/integrity information
Storage location

16. Hashing and Integrity

Where appropriate, calculate an integrity value for acquired evidence.

Example:

Field	Value
Evidence ID	EV-2026-0042
Evidence Type	CloudTrail export
Algorithm	SHA-256
Collection Hash	Recorded
Verification Hash	Recorded
Match	Yes
Verified By	Investigator
Verification Date

If an integrity mismatch occurs:

Preserve both versions where appropriate.
Do not overwrite the original.
Record the mismatch.
Investigate the cause.
Assess impact on the investigation.
Escalate if required.

17. Endpoint Forensics

For endpoint investigations, consider:

Identity

Logged-in users
Local accounts
Administrative accounts
Authentication activity

Processes

Running processes
Unusual processes
Parent-child relationships
Unsigned or unknown executables

Files

Recently created files
Modified files
Deleted files where recoverable
Executables
Scripts
Temporary files

Persistence

Startup items
Scheduled tasks
Services
Registry/configuration persistence
SSH keys
Browser extensions

Network

Active connections
DNS activity
Remote destinations
Listening ports

Security Tools

EDR alerts
Antivirus alerts
Firewall events

18. Cloud Forensics

Cloud investigations require analysis of both:

Control Plane Activity

and

Workload/Data Plane Activity

Review as appropriate:

Cloud audit logs
IAM
Authentication
Role assumptions
API calls
Resource creation
Resource deletion
Configuration changes
Network changes
Storage access
Database activity
Secrets access
Encryption-key activity
Security-control changes
CI/CD activity

19. AWS Forensic Investigation

For an AWS SaaS environment, relevant evidence may include:

AWS Area	Investigation Evidence
CloudTrail	API activity
IAM	Users, roles, policies, access keys
GuardDuty	Threat findings
Security Hub	Security findings
S3	Object access and configuration
EC2	Instance activity
VPC	Network activity
VPC Flow Logs	Network flows
WAF	Web requests
RDS	Database activity
KMS	Key usage
Secrets Manager	Secret access
CloudWatch	Logs and monitoring
Config	Configuration history
ECR	Container image activity
ECS/EKS	Container activity
Lambda	Function activity
CI/CD	Deployment and credential activity

The investigator should correlate these sources rather than relying on a single log.

20. AWS Investigation Example

Scenario

A privileged AWS identity is suspected of compromise.

Investigation

Identity

→ Identify affected IAM identity.

Authentication

→ Review login and MFA activity.

CloudTrail

→ Establish API timeline.

IAM

→ Identify role/policy changes.

→ Determine object access.

RDS

→ Review database activity.

VPC

→ Assess network activity.

Secrets Manager

→ Determine whether secrets were accessed.

KMS

→ Review encryption-key activity.

CI/CD

→ Determine whether credentials were used in development or deployment systems.

Persistence

→ Search for unauthorized roles, users, keys, policies, or resources.

Data Impact

→ Determine whether customer or sensitive information was accessed.

21. Application Forensics

Application investigation may include:

Authentication logs
API calls
Administrative actions
Session activity
Error logs
Database activity
File uploads
File downloads
Configuration changes
API keys
OAuth activity
Deployment history
Application security alerts

Determine:

Which account performed the action?
What action occurred?
Which resource was affected?
Was the action authorized?
What occurred immediately before and after the action?

22. Database Forensics

Where appropriate, review:

Database authentication
Privileged accounts
Queries
Administrative changes
Data exports
Bulk reads
Schema changes
Permission changes
Audit logs
Backup activity

Avoid unnecessarily extracting entire databases when targeted evidence is sufficient.

Use data minimization principles.

23. Email Forensics

Email investigations may examine:

Original message
Headers
Sender
Recipient
Timestamp
Message ID
URLs
Attachments
Authentication results
Mailbox access
Forwarding rules
OAuth applications
Suspicious login activity

For phishing investigations, preserve the original message rather than relying only on screenshots.

24. Malware Investigation

Where malware is suspected:

Preserve evidence.
Contain the affected system.
Identify suspected malware.
Determine execution time.
Identify persistence.
Identify network communications.
Determine affected files/systems.
Assess lateral movement.
Assess data access.
Remove or rebuild affected systems.
Verify recovery.
Identify root cause.

Do not execute unknown malware on production systems.

Specialized analysis should be performed in an appropriately isolated environment by qualified personnel.

25. Ransomware Forensics

For ransomware investigations, determine:

Initial access
Compromised identity
Initial affected endpoint
Privilege escalation
Lateral movement
Backup access
Encryption activity
Data exfiltration
Persistence
Systems affected
Recovery sources
Attacker activity

Preserve relevant evidence before rebuilding systems where practical.

Protect backups from further compromise.

26. Account Compromise Forensics

Review:

Authentication
MFA
Password changes
Access keys
OAuth tokens
Sessions
Role assumptions
Privilege changes
Resource access
Email activity
Endpoint activity
Source IP
Geographic indicators
Device information

Determine:

How was the identity compromised?

What did the identity access?

What changed?

Did the attacker maintain access?

27. Timeline Reconstruction

Forensic investigations should reconstruct events chronologically.

Timeline model

Initial Access

↓

Authentication

↓

Privilege Escalation

↓

Persistence

↓

Lateral Movement

↓

Data Access

↓

Exfiltration

↓

Detection

↓

Containment

↓

Eradication

↓

Recovery

Use multiple evidence sources to validate important timeline events.

28. Evidence Correlation

A single log may provide only partial information.

Correlate:

Identity Logs + Cloud Logs + Application Logs + Network Logs + Endpoint Evidence + Database Evidence + Security Alerts

Example

CloudTrail shows:

IAM role assumed at 09:14 UTC.

Identity logs show:

User authenticated at 09:12 UTC.

S3 records show:

Customer objects accessed at 09:17 UTC.

VPC logs show:

Network connection to external destination.

Together, these records may establish a more complete activity sequence than any individual source.

29. Indicators of Compromise

Where applicable, record indicators such as:

IP addresses
Domains
URLs
File hashes
User agents
Email addresses
File names
Process names
IAM identities
Access keys
Malicious accounts
Cloud resources
Registry/configuration indicators

Sensitive credentials should never be recorded as IOC values in general reports.

Instead, record that a credential was compromised and reference the controlled evidence location.

30. Investigation Findings

Each forensic finding should be linked to supporting evidence.

Finding ID	Finding	Evidence	Confidence	Impact
F-001	Unauthorized IAM activity occurred	EV-0042	High	High
F-002	Privileged role was created	EV-0043	High	High
F-003	S3 objects were accessed	EV-0045	High	High
F-004	Data exfiltration could not be conclusively established	EV-0045/0046	Medium	Under assessment

Use confidence carefully.

Suggested values:

High
Medium
Low
Unable to determine

The organization should define what each confidence level means.

31. Root Cause Analysis

The forensic investigation should provide factual input to the RCA.

Consider:

Technology

Vulnerability
Misconfiguration
Weak authentication
Excessive permissions
Missing logging

People

Credential exposure
Phishing
Training gap
Human error

Process

Weak access review
Poor credential lifecycle
Missing change control
Incomplete incident detection

Governance

Inadequate risk treatment
Undefined ownership
Missing security requirements

Supplier

Compromised third party
Weak supplier control
Supplier credential exposure

Do not automatically classify the root cause as “human error” without determining the underlying control or process conditions.

32. Privacy and Personal Data

Forensic evidence may contain personal information.

Investigators should:

Define the lawful/authorized purpose.
Limit collection to what is relevant.
Restrict access.
Avoid unnecessary duplication.
Apply appropriate classification.
Protect evidence during transfer.
Follow applicable privacy requirements.
Coordinate with privacy/legal functions where required.

Where an employee investigation is involved, appropriate HR/legal processes should be followed.

33. Legal Hold

Where legal proceedings or a legal hold may apply:

Stop routine deletion of relevant evidence.
Identify affected evidence.
Record the legal hold.
Restrict disposal.
Coordinate with authorized legal personnel.
Document release of the hold.

Legal advice should come from the organization’s authorized legal function or counsel.

34. Third-Party Forensic Support

External forensic specialists may be engaged when:

Internal expertise is insufficient.
A major incident occurs.
Specialized forensic tooling is required.
Legal proceedings are anticipated.
Large-scale investigation is required.
Regulatory/customer requirements exist.
Independent investigation is required.

Before providing evidence externally:

Verify authorization.
Define scope.
Confirm confidentiality requirements.
Use secure transfer.
Record chain of custody.
Define access.
Record provider and personnel.
Establish evidence return/retention requirements.

35. Forensic Tool Management

Where forensic tools are used, record:

Tool name
Version
Purpose
Investigator
Date/time
Configuration
Relevant commands/queries
Output
Limitations

The organization should use appropriately approved and maintained tools.

Tool output should be treated as evidence that requires interpretation, not automatically as a final conclusion.

36. Analysis Record

Investigators should maintain analysis notes containing:

Category	Record
Fact	What evidence directly establishes
Observation	What was observed
Hypothesis	Possible explanation
Analysis	How evidence was interpreted
Finding	Evidence-supported determination
Unknown	What could not be established
Conclusion	Overall determination

This structure helps prevent unsupported conclusions.

37. Forensic Investigation Report

The final report should normally include:

Executive Summary
Incident Information
Investigation Authorization
Objectives
Scope
Investigators
Methodology
Evidence Sources
Evidence Preservation
Collection Activities
Timeline
Identity Investigation
System Investigation
Cloud Investigation
Malware/Attack Analysis where applicable
Data Access Assessment
Exfiltration Assessment
Lateral Movement
Persistence
Findings
Root Cause
Impact
Limitations
Containment
Eradication
Recovery
Corrective Actions
Residual Risk
Conclusion
Evidence References
Approval

38. Forensic Investigation Quality Checklist

Before closing the investigation:

☐ Authorization documented
☐ Scope documented
☐ Investigation objectives defined
☐ Evidence sources identified
☐ Relevant evidence preserved
☐ Evidence IDs assigned
☐ Chain of custody maintained where required
☐ Original evidence protected
☐ Working copies identified
☐ Integrity verified where appropriate
☐ Timeline reconstructed
☐ Identity activity investigated
☐ Privilege escalation assessed
☐ Persistence assessed
☐ Lateral movement assessed
☐ Data access assessed
☐ Exfiltration assessed
☐ Malware assessed where applicable
☐ Root cause investigated
☐ Evidence limitations documented
☐ Findings linked to evidence
☐ Impact assessed
☐ Corrective actions assigned
☐ Residual risk assessed
☐ Final report reviewed
☐ Evidence retention determined

39. Relationship With Incident Response

Digital forensics is part of the wider incident-management process.

Security Event

→ Incident

→ Containment

→ Evidence Preservation

→ Forensic Investigation

→ Findings

→ Root Cause

→ Eradication

→ Recovery

→ Corrective Action

→ Lessons Learned

→ ISMS Improvement

Forensics should support incident response rather than unnecessarily delay containment.

40. Relationship With Evidence Management

Document	Purpose
Evidence Collection Procedure	Defines evidence collection
Evidence Collection Form	Records individual collection
Evidence Register	Tracks evidence
Chain-of-Custody Form	Tracks formal evidence handling/transfers
Digital Forensics Procedure	Defines forensic investigation methodology
Incident Investigation Report	Records investigation findings
Root Cause Analysis	Determines underlying cause
Corrective Action Tracker	Tracks remediation
Incident Closure Report	Records final outcome

41. Startup-Friendly Digital Forensics Model

A startup does not necessarily need an in-house forensic laboratory.

A practical model can be:

Tier 1 — Internal Investigation

Use:

Cloud logs
Identity logs
EDR
Application logs
SIEM/security tools
AWS security services
Existing incident-response capabilities

Tier 2 — Specialist Support

Engage an external forensic specialist when:

Evidence is complex.
A major incident occurs.
Advanced endpoint analysis is required.
Legal proceedings are possible.
Internal expertise is insufficient.

Tier 3 — Legal/Regulatory Investigation

Coordinate with:

Legal counsel
Privacy specialists
Regulators
Cyber insurer
Law enforcement where appropriate

The escalation level should depend on the incident’s severity and requirements.

42. AWS SaaS Startup Minimum Evidence Set

For a cloud-native SaaS startup, maintain sufficient logging and retention to support investigation of:

IAM authentication
Privilege changes
Cloud API activity
S3 access
Database activity
Network activity
WAF activity
Application activity
CI/CD activity
Secrets access
Security findings
Configuration changes

A practical evidence flow is:

Identity Provider

→ AWS IAM

→ CloudTrail

→ GuardDuty/Security Hub

→ VPC/WAF

→ Application

→ Database

→ S3

→ CI/CD

→ Central Evidence Repository

43. Forensic Readiness

The best forensic investigation starts before an incident.

Organizations should establish:

Appropriate logging
Log retention
Time synchronization
Centralized security monitoring
Cloud audit logging
Endpoint visibility
Identity monitoring
Evidence storage
Access controls
Incident procedures
Contact lists
Trained investigators
External forensic contacts
Tabletop exercises

Forensic Readiness Principle

If you cannot observe the activity, you may not be able to investigate it later.

44. Metrics

Organizations may track:

Metric	Purpose
Time to Preserve Evidence	Measures preservation speed
Time to Acquire Evidence	Measures collection efficiency
Evidence Coverage	Measures availability of relevant telemetry
Evidence Gaps	Identifies visibility weaknesses
Investigation Duration	Measures investigation effort
Findings Supported by Evidence	Measures investigation quality
Repeat Investigation Causes	Identifies recurring weaknesses
Forensic Readiness Gaps	Identifies preparedness issues

Metrics should be used to improve capability rather than create unnecessary administrative burden.

45. ISO 27001 Alignment

The Digital Forensics Procedure can support the organization’s ISMS processes relating to:

Information security incident management
Event assessment
Evidence preservation
Logging and monitoring
Access control
Information classification
Vulnerability management
Secure configuration
Cloud security
Backup and recovery
Supplier security
Corrective action
Risk treatment
Continual improvement

The procedure should be linked to the organization’s risk assessment and Statement of Applicability where relevant.

Digital forensics itself is not a universal requirement for every ISO/IEC 27001 incident. The organization should determine the appropriate level of forensic capability based on risk, business requirements, legal obligations, customer commitments, and incident scenarios.

46. Audit Evidence

An auditor should be able to verify that the organization can:

Authorize forensic activity.
Define investigation scope.
Preserve relevant evidence.
Maintain evidence integrity.
Control access.
Maintain chain of custody where required.
Conduct evidence-based investigation.
Document limitations.
Establish timelines.
Identify root causes.
Track corrective actions.
Learn from significant incidents.
Improve the ISMS.

Forensic readiness should also be tested periodically through incident-response exercises or appropriate technical testing.

47. Final Audit Trail

Security Event Detected

→ Incident Confirmed

→ Forensic Investigation Requirement Identified

→ Investigation Authorized

→ Scope Defined

→ Evidence Sources Identified

→ Volatile Evidence Assessed

→ Evidence Preserved

→ Evidence Acquired

→ Evidence ID Assigned

→ Integrity Verified

→ Evidence Secured

→ Working Copy Created Where Required

→ Evidence Examined

→ Timeline Reconstructed

→ Identity Investigated

→ Privilege Escalation Investigated

→ Persistence Investigated

→ Lateral Movement Investigated

→ Data Access Investigated

→ Exfiltration Assessed

→ Evidence Correlated

→ Findings Established

→ Root Cause Assessed

→ Impact Assessed

→ Limitations Documented

→ Corrective Actions Assigned

→ Residual Risk Assessed

→ Forensic Report Completed

→ Management/Authorized Review

→ Evidence Retained or Disposed

→ Investigation Closed

48. Final Principle

Digital forensics is not simply collecting technical data. It is the disciplined process of preserving evidence, establishing what happened, correlating technical facts, determining impact, documenting uncertainty, and producing defensible findings.

Digital Forensics Principle

Authorize → Preserve → Acquire → Verify → Examine → Correlate → Analyze → Establish Facts → Determine Impact → Report → Improve

Good forensic readiness means that when something goes wrong, the organization has enough trustworthy evidence to determine what happened—not merely enough logs to say that something happened.