ISO 27001 A.5.28: Collection of Evidence

Quick Reference: A.5.28 in 60 Seconds

What the Control Asks For

The Control in Brief

ISO 27001:2022 Annex A 5.28 asks organizations to define and apply procedures to identify, collect, acquire, and preserve evidence related to security events.

Do you need this control?

A.5.28 is not mandatory in itself: under clause 6.1.3 you include it if your risk assessment calls for it, and record the decision in your Statement of Applicability. Include it if you may need evidence for legal, disciplinary or regulatory action, which is most organisations. A small company may rely on an external forensic partner and a simple preservation procedure.

ISO 27002:2022 Implementation Guidance (Section 5.28)

ISO 27002 5.28 asks for internal procedures to identify, collect, acquire and preserve evidence, by type of storage media, device and device state (for example powered on or off). Evidence should be able to show that records are complete and have not been tampered with, that copies are probably identical to the originals, and that the information system was operating correctly when the evidence was recorded. Where available, use certified or qualified personnel and tools to strengthen the evidential value, and consider jurisdictional differences when evidence may be used across borders. The points below turn this into practice:

1. Procedural foundation: Documented procedures should define how evidence is identified, collected, acquired, and preserved. These procedures must cover the complete lifecycle from event detection through potential litigation or disciplinary action.
2. Behavioural rules: Personnel with access to evidence must understand and follow behavioural rules that prevent contamination, tampering, or unauthorised disclosure. This includes limiting access, using write blockers, avoiding privileged commands on live systems, and maintaining confidentiality.
3. Identification of evidence: The organisation must be able to identify what constitutes evidence for different event types: system logs, network captures, endpoint artefacts, database transaction records, physical access logs, CCTV footage, mobile device backups, cloud audit trails, and witness statements.
4. Collection and acquisition: Evidence must be collected in a forensically sound manner that preserves integrity. This includes creating bit-for-bit forensic images, capturing volatile memory, generating cryptographic hashes, and using validated tools.
5. Preservation: Evidence must be stored securely with controls against alteration, deletion, or degradation. Storage must maintain integrity (hash verification), confidentiality (encryption and access control), and availability (redundancy and retention scheduling).
6. Legal admissibility: Evidence must be collected and handled so it can be admitted in legal, regulatory, or disciplinary proceedings. This typically requires demonstrating continuity of possession (chain of custody), integrity (hashes), reliability of tools, and competence of collectors.
7. Roles and responsibilities: Clear roles must be defined for incident responders, forensic investigators, legal counsel, HR, line managers, system owners, and external law enforcement or regulators.
8. External coordination: Procedures should address when and how to engage external forensic experts, law enforcement (including Indian Cyber Crime Cells and CERT-In), legal advisors, and insurance providers.

Shall / Should / May Analysis

What Auditors Actually Check

Why This Control Matters

The Business Risk Narrative

Evidence collection is the bridge between an information security event and organisational justice. Whether the event is a ransomware attack, an insider data theft, a fraudulent wire transfer, a phishing compromise, or a regulatory breach notification, the quality of evidence collected determines whether the organisation can:

• Prosecute or recover losses from attackers,
• Discipline or dismiss employees without wrongful termination claims,
• Defend itself in customer litigation or arbitration,
• Satisfy regulators that due diligence was exercised,
• File cyber-insurance claims with defensible proof of loss,
• Learn accurately from incidents and improve controls.

Poor evidence handling turns a containable incident into an existential legal and reputational crisis. A single chain-of-custody gap can render months of investigation worthless in court. An unverified log file can be challenged as tampered. A responder's well-intentioned login to a compromised server can overwrite timestamps and destroy the very evidence needed to prove the case.

In the Indian market, where cybercrime investigations are accelerating and regulators are increasingly demanding forensic-grade documentation, A.5.28 is no longer a "nice-to-have" appendix control. It is a core capability for legal defensibility.

Indian Regulatory Context

Industry-Specific Consequences

Cost of Non-Compliance: Statistics and Research

• Average cost of a data breach in India (IBM Cost of a Data Breach Report 2024): ₹19.5 crore (INR 195 million, about USD 2.35 million). Investigations without forensic-grade evidence take longer, and IBM consistently finds that longer breach lifecycles cost more.
• Cyber insurance claims: insurers typically require prompt notice and documented evidence; poor evidence preservation weakens a claim.
• Employee disputes: dismissals that rest on digital evidence are open to challenge if the evidence cannot be shown to be complete and untampered.
• Prosecutions: electronic records need the BSA s.63 certificate and a clear chain of custody; defects in either are a common reason evidence is challenged.
• Regulatory fines: RBI, SEBI, and IRDAI have imposed penalties on entities that failed to maintain adequate logs or report incidents accurately.

These figures make the business case unmistakable: a small investment in A.5.28 capability pays for itself many times over when the first serious incident occurs.

Scope and Applicability

What This Control Covers

A.5.28 applies to all forms of evidence that may be relevant to information security events, including but not limited to:

Who It Applies To

Size-Based Applicability

Key Definitions and Terminology

Relationship to Other Controls

Upstream Controls (They Feed Evidence Into A.5.28)

Downstream Controls (They Consume or Build on A.5.28)

Parallel Controls (They Overlap in Practice)

Detailed Implementation Guidance

Establish Governance and Ownership

Before writing procedures, define who owns evidence collection and how decisions are made:

Develop the Evidence-Handling Policy

The policy must set the strategic direction. See Section 9 for an inline template. At minimum, the policy should cover:

• Purpose and scope
• Legal and regulatory drivers
• Roles and responsibilities
• Evidence categories and sources
• Behavioural rules for all personnel
• Identification, collection, acquisition, and preservation principles
• Chain-of-custody requirements
• Integrity verification (hashing)
• Storage and access control
• Retention and disposal
• External expert and law enforcement engagement
• Training and awareness
• Non-compliance consequences

Develop the Evidence-Handling Procedure

The procedure is the operational heart of A.5.28. It should be a step-by-step workflow covering:

Phase 1: Detection and Triage

1. Event detected through SIEM alert, user report, anomaly detection, or external notification.
2. SOC analyst or first responder records initial details in the incident ticket: date/time, reporter, system, suspected nature, business impact.
3. Incident Response Lead assesses whether the event meets evidence-collection triggers.
4. If yes, activate the evidence-management track in parallel with containment.
5. Notify Legal Counsel if legal hold, criminal matter, or regulatory exposure is possible.
6. Notify HR if employee misconduct is suspected.

Phase 2: Identification

1. Identify potentially relevant evidence sources based on event type:
   • Compromised endpoint: disk, memory, logs, browser data, USB history
   • Phishing: email headers, mailbox logs, proxy logs, endpoint telemetry
   • Insider threat: file access logs, DLP alerts, chat logs, print logs, CCTV
   • Ransomware: initial access logs, lateral movement logs, backup states, ransom note
   • Fraud: database transaction logs, application audit trails, access logs
2. Determine custodians of each evidence source.
3. Issue preservation notices or legal holds to custodians and system owners.
4. Document the identification decision in the evidence inventory.

Phase 3: Collection and Acquisition

1. Prioritise volatile evidence (RAM, network connections, running processes) before it is lost.
2. Use write blockers for disk imaging where possible.
3. Create forensic images using validated tools (dd, FTK Imager, Guymager, EnCase, Cellebrite, etc.).
4. Capture system logs, network captures, and cloud audit trails in native format.
5. Generate SHA-256 hashes for all acquired evidence and record in the chain-of-custody form.
6. Label physical evidence with tamper-evident seals and unique evidence IDs.
7. Photograph or video-record physical seizures and screen states where appropriate.

Phase 4: Preservation and Storage

1. Transfer evidence to the secure evidence repository immediately.
2. Store originals/immutable copies separately from working copies.
3. Verify hash values upon transfer and at scheduled intervals.
4. Restrict access to authorised forensic investigators, Legal, and designated custodians.
5. Maintain audit logs of all access to the evidence repository.
6. Apply encryption at rest and in transit.
7. Ensure environmental protection for physical media (fireproof safe, climate control).

Phase 5: Analysis and Review

1. Conduct analysis on working copies or forensic duplicates, never on originals.
2. Document every analytical step, tool version, and command used.
3. Maintain analysis notes that are contemporaneous and attributable.
4. Escalate findings to Incident Response Lead, Legal, and HR as appropriate.

Phase 6: Disclosure and Handover

1. Prepare evidence packages for internal disciplinary process, regulatory filing, insurance claim, or law enforcement.
2. Use agreed formats and redaction where necessary to protect unrelated personal data.
3. Complete handover forms recording recipient, date, contents, and intended use.
4. Obtain acknowledgement signature from recipient.

Phase 7: Retention and Disposal

1. Apply retention periods based on legal hold, regulatory requirement, and organisational policy.
2. Review retention status periodically; extend legal holds as needed.
3. Dispose of evidence securely when retention expires, with documented approval and certificate of destruction.

Evidence Collection Triggers Matrix

Not every information security event requires full forensic evidence collection. The following matrix helps responders decide when to activate the formal evidence-management track.

Forensic Acquisition Techniques by Evidence Type

Chain of Custody Best Practices

A defensible chain of custody answers four questions at every stage:

1. Who had custody?
2. What was in their custody?
3. When did they have it?
4. Why did they have it (purpose of transfer)?

Best practices include:

• Use sequentially numbered evidence IDs (e.g., EVID-2026-00123).
• Use tamper-evident bags or seals for physical media.
• Record every transfer with signature, date, time, and purpose.
• Record hash values at acquisition, transfer, and storage verification.
• Limit the number of custodians; prefer two-person integrity for high-stakes evidence.
• Store chain-of-custody forms with the evidence, not separately.
• Never leave evidence unattended in unsecured areas.
• Use GPS or access logs to track movement where appropriate.

Behavioural Rules for All Personnel

Integration with Incident Response

Evidence collection must not slow incident response. The two functions should be integrated:

• Include an "Evidence Preservation" workstream in every incident runbook.
• Assign an Evidence Custodian role in the Incident Response Team.
• Use predefined evidence-preservation playbooks for common incident types (ransomware, phishing, insider threat, data breach).
• Capture volatile evidence before containment actions that may alter system state.
• Where containment requires shutdown, document the rationale and capture memory first if feasible.
• After recovery, verify that log sources used as evidence remain intact and retained.

Integration with Legal and HR

Size-Tiered Implementation

Forensic Analysis Methodologies

Once evidence is preserved, analysis must be structured, repeatable, and well-documented. The following methodologies are commonly used:

Timeline Analysis

Timeline analysis reconstructs the sequence of events by correlating timestamps from logs, file system metadata, registry entries, and network activity. It helps answer "when did the attacker first access the system?" and "what did they do next?" Use tools such as Plaso, Autopsy, or manual correlation of SIEM data.

File System Analysis

Examine file system artefacts including Master File Table (MFT) entries on Windows, inodes on Linux, and file system journals. Look for deleted files, alternate data streams, permission changes, and recently accessed files. This is essential for malware placement, data staging, and exfiltration investigations.

Memory Analysis

Analyse RAM dumps to identify running processes, network connections, loaded drivers, open files, and encryption keys. Tools such as Volatility and Rekall enable extraction of artefacts that may not exist on disk. Memory analysis is critical for detecting fileless malware and live attacker sessions.

Log Correlation and Aggregation

Centralise logs from endpoints, network devices, cloud services, and applications. Correlate events using common fields such as user identity, IP address, timestamp, and process hash. SIEM platforms automate much of this, but manual correlation is often needed for deep investigations.

Network Traffic Analysis

Inspect packet captures and flow records for command-and-control communications, data exfiltration, lateral movement, and scanning activity. Use Wireshark for deep packet inspection, Zeek for connection metadata, and Suricata for intrusion detection signatures.

Malware Analysis

When malware is discovered, preserve the sample and perform static or dynamic analysis in a sandbox. Document Indicators of Compromise (IOCs) including file hashes, domains, IP addresses, and behavioural patterns. Share IOCs with detection teams to improve defences.

User Behaviour Analysis

Profile normal user activity and identify anomalies such as unusual login times, access to sensitive data, large downloads, or privilege escalations. UEBA tools and manual review of DLP alerts support insider threat investigations.

Documentation and Reproducibility

Every analysis step must be documented so that another qualified investigator can reproduce the findings. Record the tool, version, command, input, output, interpretation, and analyst identity. Contemporaneous notes are stronger in legal proceedings than reconstructed summaries.

Tools, Technologies, and Solutions

Tool Categories

Tool Evaluation Criteria

When selecting evidence-collection tools, evaluate vendors against the following criteria:

Vendor Comparison Matrix

Tool Selection Guidance

Policy and Procedure Templates

Evidence Collection and Handling Policy (Inline Extract)

EVIDENCE COLLECTION AND HANDLING POLICY
[Organisation Name]
Version: 1.0
Approved by: [CISO / Legal Counsel]
Date: [Date]
Review Date: [Date + 12 months]
Classification: Internal / Restricted

---

1. PURPOSE AND SCOPE

1.1 Purpose
This policy establishes the principles, responsibilities, and minimum requirements
for the identification, collection, acquisition, and preservation of evidence
relating to information security events. It ensures that evidence is handled in
a forensically sound, legally admissible, and ethically responsible manner.

1.2 Scope
This policy applies to all information assets, personnel, contractors, suppliers,
and third parties that may possess or control evidence relevant to information
security events. It covers digital, physical, and documentary evidence.

2. LEGAL AND REGULATORY CONTEXT

This policy supports compliance with:
- ISO 27001:2022 Annex A 5.28
- Information Technology Act, 2000 (India)
- Bharatiya Sakshya Adhiniyam, 2023, Section 63 (replaced Indian Evidence Act ss.65A and 65B from 1 July 2024)
- Digital Personal Data Protection Act, 2023
- CERT-In Directions, 2022
- Applicable RBI / SEBI / IRDAI regulations
- Contractual and customer obligations

3. ROLES AND RESPONSIBILITIES

- CISO: Owns this policy and the evidence-management programme.
- Incident Response Lead: Activates evidence collection and assigns Evidence Custodian.
- Evidence Custodian: Maintains chain of custody, storage, and integrity verification.
- Legal Counsel: Advises on legal hold, admissibility, privilege, and disclosure.
- HR Lead: Handles employee-related evidence and disciplinary process.
- System Owners: Preserve and provide access to logs and systems under their control.
- All Personnel: Comply with behavioural rules and report events promptly.

4. EVIDENCE PRINCIPLES

4.1 Integrity
Evidence must be protected from unauthorised alteration, deletion, or degradation
from the moment of identification through disposal.

4.2 Authenticity
Evidence must be attributable to a source, time, and custodian. Cryptographic
hashes and chain-of-custody records demonstrate authenticity.

4.3 Completeness
Relevant evidence must be collected comprehensively. Gaps must be documented
with reason.

4.4 Reliability
Collection methods and tools must be reliable, repeatable, and defensible.

4.5 Timeliness
Evidence must be collected as soon as practicable after an event to prevent loss
or degradation.

4.6 Confidentiality
Evidence must be accessed only on a need-to-know basis and stored securely.

5. EVIDENCE LIFECYCLE

5.1 Identification
- Determine event type and likely evidence sources.
- Issue preservation notices and legal holds.
- Record sources in the Evidence Inventory.

5.2 Collection and Acquisition
- Follow the Evidence Handling Procedure.
- Use write blockers, validated tools, and documented methods.
- Capture volatile evidence before stable evidence where appropriate.

5.3 Preservation
- Transfer to the secure evidence repository.
- Verify hash values and maintain chain of custody.
- Apply encryption, access control, and audit logging.

5.4 Analysis
- Analyse working copies only.
- Document tools, commands, and findings.

5.5 Disclosure and Handover
- Prepare packages under Legal direction.
- Complete handover documentation.

5.6 Retention and Disposal
- Apply retention schedules and legal holds.
- Dispose securely with documented approval.

6. BEHAVIOURAL RULES

All personnel must:
- Not delete, modify, or conceal potential evidence.
- Not interfere with systems under investigation without authorisation.
- Report events through official channels.
- Maintain confidentiality of investigations.
- Cooperate with authorised investigators.

7. TRAINING AND AWARENESS

All employees receive awareness on evidence preservation. Incident responders,
IT administrators, Legal, and HR receive role-specific training annually.

8. NON-COMPLIANCE

Violation of this policy may result in disciplinary action, legal consequences,
and termination of employment or contracts.

9. POLICY REVIEW

This policy is reviewed annually and after any significant incident, legal change,
or organisational change.

Evidence Handling Procedure (Inline Extract)

EVIDENCE HANDLING PROCEDURE
[Organisation Name]
Version: 1.0
Owner: Incident Response Lead / CISO

1. TRIGGER
   An information security event is detected and classified for evidence
collection per the Evidence Collection Triggers Matrix.

2. ACTIVATION
   a. Incident Response Lead activates the Evidence Custodian role.
   b. Legal Counsel is notified if legal, regulatory, or disciplinary exposure
      exists.
   c. HR is notified if employee misconduct is suspected.
   d. Evidence Custodian opens an Evidence Case File with unique case ID.

3. IDENTIFICATION
   a. Identify evidence sources based on incident type.
   b. Document source, custodian, location, format, and volatility in the
      Evidence Inventory.
   c. Issue preservation notices.

4. PREPARATION
   a. Gather forensic toolkit: write blocker, imaging software, evidence labels,
      tamper-evident bags, camera, chain-of-custody forms.
   b. Verify tool licences and updates.
   c. Prepare secure evidence repository destination.

5. ACQUISITION
   a. For live systems: capture volatile memory first, then disk image.
   b. For dead systems: remove storage and image with write blocker.
   c. For logs: export native format with timestamps and integrity hash.
   d. For cloud: export audit logs and snapshots to immutable storage.
   e. For mobile: follow mobile forensic protocol under Legal direction.
   f. Generate SHA-256 hash for every acquired item.
   g. Record acquisition details on chain-of-custody form.

6. TRANSFER AND STORAGE
   a. Transfer evidence to repository immediately.
   b. Verify hash match on transfer.
   c. Store original/master copy as read-only / immutable.
   d. Maintain access log.

7. ANALYSIS
   a. Create working copy from master.
   b. Document analysis environment and tools.
   c. Record all findings and maintain analysis notes.

8. REPORTING
   a. Prepare forensic summary report.
   b. Legal/HR review for privilege and disclosure.

9. HANDOVER
   a. Package evidence per recipient requirements.
   b. Complete handover form.
   c. Obtain recipient signature.

10. RETENTION AND DISPOSAL
   a. Apply retention schedule.
   b. Extend legal holds as advised by Legal.
   c. Dispose securely with approval and certificate of destruction.

Risk Assessment and Treatment

Audit and Compliance Checklist

Metrics and KPIs

Figure · Measures

The measures that show A.5.28 is working

Common Pitfalls / Audit Failures & How to Avoid Them

Illustrative Scenarios

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative Scenario 1: Indian NBFC Fights Insider Loan Fraud with Admissible Evidence

Organisation: A mid-sized Non-Banking Financial Company (NBFC) based in Mumbai with 400 employees and a digital lending platform.

Challenge: The NBFC suspected that a group of employees in the loan disbursement team were colluding with external agents to approve fraudulent loans. Initial internal audit findings were inconclusive because:

• System logs had been overwritten after 30 days.
• Employees had deleted WhatsApp messages and emails.
• CCTV footage from the relevant period had been recorded over.
• There was no formal evidence-handling procedure.

The Legal team advised that without admissible evidence, disciplinary action could lead to wrongful termination claims, and a police complaint would likely fail.

Solution: The NBFC engaged an external security consultant to implement an A.5.28 evidence management programme over eight weeks:

1. Policy and procedure: Approved an Evidence Collection and Handling Policy and a step-by-step procedure.
2. Forensic readiness: Deployed a SIEM with 12-month log retention and immutable S3-backed storage.
3. Endpoint visibility: Implemented EDR on all employee laptops and DLP on file shares.
4. Legal hold process: Established a rapid legal hold workflow with HR and Legal.
5. Mobile forensics: Contracted a DSCI-empanelled forensic lab for smartphone acquisition.
6. Training: Trained SOC, IT, HR, and Legal on evidence preservation and chain of custody.

When a second fraud pattern emerged three months later, the team:

• Issued legal holds within two hours.
• Captured EDR telemetry, mailbox data, and database transaction logs.
• Acquired smartphones under Legal direction before devices could be wiped.
• Maintained a complete chain of custody and SHA-256 hashes.
• Prepared a forensic report accepted by the Mumbai Cyber Crime Cell.

Results:

• Five employees were terminated based on admissible evidence; no successful legal challenge.
• Police complaint led to charges under the IT Act and the Bharatiya Nyaya Sanhita (BNS).
• The NBFC recovered part of the fraudulent disbursements.
• RBI examination found the evidence-handling control operating effectively.
• Cyber insurance claim was approved with the forensic report as primary evidence.

Illustrative Scenario 2: Indian SaaS Company Preserves Evidence During a Ransomware Attack

Organisation: A Bengaluru-based B2B SaaS company with 250 employees serving enterprise customers in India, Southeast Asia, and the Middle East.

Challenge: The company suffered a ransomware attack at 2:00 AM. The on-call engineer, trying to stop the spread, powered off several servers and rebuilt them from backup before the Security team could respond. Critical evidence was lost:

• Memory dumps containing decryption keys and attacker command-and-control indicators.
• Disk images showing initial access vector and lateral movement.
• Windows event logs on rebuilt servers.

Customers demanded root-cause analysis, regulators asked for incident details, and the cyber insurer questioned whether the claim was valid. The company faced potential contract penalties and reputational damage.

Solution: After the incident, the company partnered with an external security consultant to build an A.5.28 capability:

1. Incident runbook update: Added an "evidence preservation" workstream to every incident runbook.
2. Behavioural rules: Trained all engineers on "do not power off" rules and rapid escalation.
3. Automated evidence collection: Configured EDR to auto-isolate endpoints and export memory dumps and disk artefacts to a secure evidence repository.
4. Cloud log immutability: Enabled AWS S3 Object Lock and CloudTrail organisation trails with multi-year retention.
5. Forensic retainer: Signed a retainer with an Indian digital forensic firm for 24/7 incident response.
6. Tabletop exercises: Ran quarterly ransomware simulations including evidence preservation.

Six months later, a phishing-based compromise attempt occurred. The team:

• Isolated the endpoint via EDR without powering it off.
• Captured memory and disk image within 45 minutes.
• Preserved mail logs, proxy logs, and SaaS audit trails.
• Maintained chain of custody and hashes.
• Shared a defensible incident report with affected customers and regulators.

Results:

• No regulatory penalties; customers retained contracts after receiving the forensic report.
• Cyber insurer approved the claim rapidly due to documented evidence.
• The company used IOCs from preserved evidence to enhance detection rules.
• The surveillance audit sampled the evidence log and chain-of-custody forms and raised no findings on A.5.28.

Illustrative Scenario 3: Indian E-commerce Platform Responds to a Customer Data Breach Notification

Organisation: A Delhi-NCR based e-commerce platform with 800 employees and approximately 5 million registered users.

Challenge: A security researcher reported that a misconfigured cloud database exposed customer names, phone numbers, addresses, and partial order history. The platform had 72 hours to determine whether a breach had occurred, what data was affected, and whether it needed to notify regulators and customers. Compounding the problem:

• Access logs were stored in a non-immutable bucket with 30-day retention.
• Multiple engineers had accessed the database during remediation, potentially altering evidence.
• There was no documented procedure for preserving evidence during a suspected breach.
• Legal was unsure whether the incident was a personal data breach requiring intimation (the DPDP Act has no harm threshold: any breach must be intimated).

Solution: The platform engaged an external security consultant under an emergency response engagement:

1. Immediate preservation: Exported remaining logs and database snapshots to a new immutable storage bucket with object lock enabled.
2. Forensic timeline: Reconstructed access history from cloud audit trails, database query logs, and application logs before they expired.
3. Evidence integrity: Generated SHA-256 hashes for all exported data and maintained a chain-of-custody log.
4. Impact assessment: Used preserved evidence to determine the exact records exposed, access duration, and whether unauthorised parties downloaded data.
5. Notification decision: Legal used the evidence package to decide on regulator and customer notification.
6. Post-incident programme: Implemented a full A.5.28 capability including policy, procedure, legal hold workflow, and immutable log retention.

Results:

• The platform notified the relevant authority within the required timeframe with a defensible factual basis.
• Customer communication was accurate and specific, reducing panic and churn.
• No regulatory penalty was imposed; the evidence demonstrated prompt detection and remediation.
• The subsequent DPDP Act readiness assessment found the breach evidence and intimation records complete.
• Cloud log retention was extended to 24 months, and SIEM integration was completed within 12 weeks.

Multi-Framework Mapping

Implementation Roadmap

Phase 1: Foundation (Weeks 1–2)

Phase 2: Procedure and Tools (Weeks 3–5)

Phase 3: Integration and Training (Weeks 6–8)

Phase 4: Operation and Improvement (Ongoing)

FAQ

Q1: Does every security incident require forensic evidence collection? A: No. Evidence collection should be triggered based on severity, legal/regulatory exposure, potential disciplinary action, or insurance/contractual needs. Low-severity malware detections with no business impact may only require log preservation.

Q2: Who should be the Evidence Custodian? A: Typically a senior member of the Incident Response or Security Operations team who is trained in evidence handling, integrity verification, and chain-of-custody practices. Independence from the incident subject is important.

Q3: Can we collect evidence from employee personal devices? A: Only under clear legal authority, such as a company policy permitting access, a legal hold, or a court order. Consult Legal and HR before seizing personal devices.

Q4: How long must we retain evidence? A: Retention depends on legal hold requirements, regulatory rules, and the statute of limitations. In India, this may range from 3 years for general records to 7+ years for financial fraud or contractual disputes. Always seek Legal guidance.

Q5: Is a screenshot enough evidence? A: A screenshot is evidence but may be challenged. It is stronger when accompanied by system logs, metadata, witness statements, and hash-verified source files. Use screenshots as supplementary evidence, not primary proof in high-stakes cases.

Q6: Do we need a dedicated forensic lab? A: Not necessarily. Many organisations use cloud-based evidence repositories and external forensic retainer services. Larger organisations may benefit from an in-house lab.

Q7: How do we handle evidence in the cloud? A: Export cloud audit logs and snapshots promptly to immutable storage. Use cloud-native object lock features and maintain export logs with hashes.

Q8: What if evidence collection conflicts with incident containment? A: Capture volatile evidence first if feasible, then contain. Document any trade-off decisions. The priority is to prevent evidence loss while protecting business operations.

Q9: Can we use open-source forensic tools in court? A: Yes, if they are widely accepted, properly used, and their reliability can be explained. Maintain records of tool versions and validation.

Q10: How does A.5.28 relate to the DPDP Act 2023? A: A.5.28 helps demonstrate that your organisation has reasonable security safeguards and can investigate personal data breaches accurately. Evidence supports breach notification and accountability to the Data Protection Board.

Q11: What is the difference between evidence collection and incident response? A: Incident response focuses on containing, eradicating, and recovering from an incident. Evidence collection is a specialised workstream within incident response that ensures information is preserved in a forensically sound and legally admissible manner. Both must run in parallel without interfering with each other.

Q12: Should we notify law enforcement for every incident? A: No. Law enforcement notification should be based on the nature of the incident, potential criminality, legal advice, and business impact. Minor policy violations or contained malware incidents may not require police involvement, while fraud, ransomware, or significant data breaches often do.

Q13: How do we protect attorney-client privilege when collecting evidence? A: Involve Legal Counsel early, label investigation materials as privileged where appropriate, and control distribution. In some jurisdictions, work product prepared at the direction of counsel may be protected from disclosure. Always follow local legal advice.

Q14: What should we do if an employee refuses to hand over a company-issued device? A: Follow the employment contract and acceptable use policy. Escalate to HR and Legal. Do not use force or coercion. Document the refusal, as it may itself become evidence in a disciplinary or legal proceeding.

Q15: How do we evidence the competence of our forensic investigators? A: Maintain records of training, certifications (such as GCFE, GCFA, EnCE, ACE, or certified), case experience, and continuing education. Auditors and courts may ask whether the person who collected or analysed evidence was qualified.

References and Further Reading

Standards and Frameworks

• ISO/IEC 27001:2022, Information Security, Cybersecurity and Privacy Protection, Information Security Management Systems, Requirements, Annex A 5.28.
• ISO/IEC 27002:2022, Information Security, Cybersecurity and Privacy Protection, Information Security Controls, Section 5.28.
• ISO/IEC 27037:2012, Guidelines for Identification, Collection, Acquisition, and Preservation of Digital Evidence.
• ISO/IEC 27041:2015, Guidance on Assuring Suitability and Adequacy of Incident Investigative Methods.
• ISO/IEC 27042:2015, Guidelines for the Analysis and Interpretation of Digital Evidence.
• ISO/IEC 27043:2015, Incident Investigation Principles and Processes.
• ISO/IEC 27050-1:2019, Electronic Discovery, Part 1: Overview and Concepts.
• NIST SP 800-61 Rev 2, Computer Security Incident Handling Guide.
• NIST SP 800-86, Guide to Integrating Forensic Techniques into Incident Response.
• NIST SP 800-53 Rev 5, Security and Privacy Controls for Information Systems and Organizations.
• CIS Controls v8, Controls 8 and 17.

Indian Laws and Regulations

• Information Technology Act, 2000 (as amended in 2008).
• Bharatiya Sakshya Adhiniyam, 2023, Section 63 (replaced Indian Evidence Act ss.65A and 65B from 1 July 2024).
• Digital Personal Data Protection Act, 2023.
• CERT-In Directions, 2022 (Information Security Practices, Procedure, Prevention, Response and Reporting of Cyber Incidents for Safe and Trusted Internet).
• Reserve Bank of India, Cyber Security Framework in Banks, Guidelines on Information Security, Electronic Banking, Technology Risk Management, and Cyber Frauds.
• SEBI Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities, circular of 20 August 2024.
• IRDAI Guidelines on Information and Cyber Security for Insurers.

Useful Resources

• DSCI (Data Security Council of India), Best Practices and Empanelled Forensic Vendors.
• Indian Cyber Crime Coordination Centre (I4C), cybercrime.gov.in.
• CERT-In, cert-in.org.in.
• MeitY, meity.gov.in.
• IBM Cost of a Data Breach Report 2024.
• Verizon Data Breach Investigations Report (DBIR) 2024.

End of guide: ISO 27001:2022 Annex A 5.28, Collection of Evidence.