On this page
- Quick Reference: A.5.28 in 60 Seconds
- What the Standard Actually Requires
- Why This Control Matters
- Scope and Applicability
- Key Definitions and Terminology
- Relationship to Other Controls
- Detailed Implementation Guidance
- Tools, Technologies, and Solutions
- Policy and Procedure Templates
- Risk Assessment and Treatment
- Audit and Compliance Checklist
- Metrics and KPIs
- Common Pitfalls / Audit Failures & How to Avoid Them
- Illustrative Scenarios
- Multi-Framework Mapping
- Implementation Roadmap
- FAQ
- References and Further Reading
Quick Reference: A.5.28 in 60 Seconds
| Attribute | Details |
|---|---|
| Control ID | A.5.28 |
| Title | Collection of Evidence |
| Objective | Ensure evidence related to information security events is collected, preserved, documented, and admissible for legal, disciplinary, regulatory, or forensic purposes. |
| Domain | Organisational Controls, Information Security Incident Management |
| What You Must Do | Define an evidence-handling policy and procedure; identify trigger events; use forensically sound acquisition methods; maintain chain of custody; preserve integrity; store securely; restrict access; document every action; ensure timeliness; and align with legal/regulatory requirements. |
| Owner | CISO / Information Security Manager, supported by Legal Counsel, HR, IT Operations, and Incident Response Lead |
| Maturity Level 1 | Ad-hoc: evidence is collected inconsistently when incidents occur, with no formal process or chain of custody. |
| Maturity Level 2 | Defined: basic incident logs and screenshots are kept; informal procedures exist but lack legal admissibility rigour. |
| Maturity Level 3 | Managed: formal policy and procedure exist; chain-of-custody forms are used; evidence is stored securely and access-controlled. |
| Maturity Level 4 | Measured: metrics track evidence collection quality; regular tabletop exercises validate the process; integration with legal and HR is smooth. |
| Maturity Level 5 | Optimised: automated evidence preservation from SIEM, EDR, and cloud platforms; forensic readiness program; proactive legal hold integration; continuous improvement based on case outcomes. |
| Audit Red Flag | No documented evidence-handling procedure; missing chain-of-custody records; evidence stored on writable shared drives without integrity verification; no legal review before collection; collected evidence ruled inadmissible. |
| Quick Win | Create a one-page evidence-collection checklist and a shared secure evidence repository with read-only access and hash verification within one week. |
| Time to Implement | 4–8 weeks for a baseline program; 8–16 weeks for full forensic readiness. |
| Related Controls | A.5.24 (Information Security Incident Management Planning and Preparation), A.5.25 (Assessment and Decision on Information Security Events), A.5.26 (Response to Information Security Incidents), A.5.27 (Learning from Information Security Incidents), A.6.7 (Remote Working), A.8.1 (User Endpoint Devices), A.8.15 (Logging), A.8.16 (Monitoring Activities), A.8.30 (ICT Readiness for Business Continuity), A.8.32 (Change Management) |
What the Standard Actually Requires
ISO 27001:2022 A.5.28 Text
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.
ISO 27002:2022 Implementation Guidance (Section 5.28)
ISO 27002:2022 expands the one-line control text into practical guidance for building a defensible evidence-collection capability:
- Procedural foundation, Documented procedures shall 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.
- 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.
- 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.
- 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.
- 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).
- 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.
- 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.
- 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
| Requirement Type | Source | Implication |
|---|---|---|
| Shall | ISO 27001:2022 A.5.28 | Mandatory. The organisation must establish and implement evidence-collection procedures and behavioural rules. Non-conformance is a major nonconformity. |
| Should | ISO 27002:2022 guidance | Strongly recommended. Includes use of cryptographic hashes, chain-of-custody forms, and legal admissibility practices. |
| May | Organisational discretion | Optional enhancements such as automated forensic readiness platforms, threat-hunt-driven evidence collection, or integration with e-discovery tools. |
What Auditors Actually Check
| Auditor Action | What They Want to See |
|---|---|
| Review evidence-handling policy | Document approved by CISO and Legal; aligned with incident response policy; references applicable laws |
| Review evidence-handling procedure | Step-by-step identification, collection, acquisition, preservation, and disposal workflows |
| Check chain-of-custody records | Completed forms with signatures, dates, times, evidence IDs, storage locations, transfer history |
| Verify integrity verification | SHA-256 or MD5 hashes recorded at acquisition and on verification; mismatch escalation process |
| Inspect evidence storage | Encrypted, access-controlled, write-protected or WORM storage; segregation from production systems |
| Interview incident responders | Can explain the process; know where forms are; know when to call Legal/HR |
| Review incident case files | Evidence inventory, logs, screenshots, disk images, memory captures linked to incident records |
| Check training records | Forensic awareness training for responders; legal hold training for Legal and HR |
| Examine tool validation | Evidence that forensic tools are licensed, updated, and validated where required |
| Review external engagement process | Contracts with forensic vendors; law enforcement liaison protocol |
| Verify retention and disposal | Retention schedule aligned with legal hold requirements; secure disposal with audit trail |
| Test a sample case | Randomly select a past incident and verify evidence was handled according to procedure |
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
| Regulation / Authority | Relevance to Evidence Collection |
|---|---|
| Digital Personal Data Protection (DPDP) Act, 2023 | Data fiduciaries must implement reasonable security safeguards. In case of a personal data breach, evidence of the breach, its impact, and remedial measures may be required by the Board. Section 8(7) and breach-intimation rules demand documented incident handling. |
| CERT-In Directions, 2022 | Reporting of cyber incidents within 6 hours for certain categories. Organisations must maintain logs and evidence to support timely and accurate reporting. Failure to report or inadequate evidence can lead to penalties. |
| Information Technology Act, 2000 (as amended) | Sections 65, 66, 66C, 66D, 67, 70B cover cyber offences and evidence. Electronic evidence admissibility is governed by Sections 65A and 65B, which require certificate-based authentication of electronic records. |
| Indian Evidence Act, 1872 (Sections 65A/65B) | Electronic evidence must be authenticated by a certificate describing the system, process, and integrity. Chain of custody and hash verification strengthen admissibility. |
| Reserve Bank of India (RBI) | Banks, NBFCs, and payment system operators must maintain incident logs, forensic reports, and evidence for cyber incidents, frauds, and technology outages. RBI circulars on cyber security frameworks require documented evidence for root-cause analysis. |
| Securities and Exchange Board of India (SEBI) | Market infrastructure institutions must maintain logs and evidence for cyber incidents, trading anomalies, and insider threats. SEBI's cyber security and cyber resilience circulars mandate forensic readiness. |
| Insurance Regulatory and Development Authority of India (IRDAI) | Insurers must protect policyholder data and maintain evidence of security incidents. IRDAI cyber security guidelines expect documented incident handling and evidence preservation. |
| Ministry of Corporate Affairs (MCA) / Companies Act, 2013 | Directors' duties include cyber risk oversight. Evidence of incident response diligence can protect officers from allegations of negligence. |
| State Cyber Crime Cells and Police | FIRs and prosecutions require admissible digital evidence. Poorly collected evidence may be rejected during trial. |
Industry-Specific Consequences
| Industry | Consequence of Weak Evidence Collection |
|---|---|
| BFSI (Banking, Financial Services, Insurance) | Inability to prove fraud origin, regulatory penalties from RBI/SEBI/IRDAI, customer litigation, loss of license for payment operators, rejected insurance claims. |
| IT/ITES and SaaS | Customer contract disputes, inability to prove SLA compliance, loss of enterprise customers, breach of confidentiality obligations, failed due diligence in funding rounds. |
| Healthcare | Inability to prove medical record integrity, patient privacy litigation, action by National Medical Commission, reputational damage. |
| E-commerce and Retail | Payment card fraud disputes, chargebacks, PCI DSS non-compliance, consumer forum complaints, brand damage. |
| Manufacturing and Critical Infrastructure | Sabotage investigations stall, insurance disputes, regulatory action under critical infrastructure rules, production losses. |
| Government and Public Sector | Accountability failures, audit objections, compromised national security investigations, RTI-related disputes. |
impact of Non-Compliance: Statistics and Research
- Average impact of a data breach in India (IBM impact of a Data Breach Report 2024): (approximately USD 2.18 million). Investigations that lack forensic-grade evidence often extend breach lifecycle by 50–80 days, increasing overhead by 15–20%.
- Cyber insurance claim denial rates: Industry estimates suggest 20–30% of cyber claims face partial or full denial due to inadequate incident documentation or evidence preservation failures.
- Employee termination litigation: Wrongful termination cases where digital evidence was mishandled have reversal rates exceeding 40% in Indian labour courts, according to employment-law practitioner surveys.
- Prosecution success rates: Studies by Indian cyber law experts indicate that 60–70% of cybercrime prosecutions fail due to weak or inadmissible electronic evidence.
- Regulatory fines: RBI, SEBI, and IRDAI have imposed penalties ranging from to several crores 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:
| Evidence Category | Examples |
|---|---|
| System logs | Operating system event logs, application logs, authentication logs, audit trails, SIEM alerts |
| Network evidence | Packet captures (PCAP), NetFlow records, firewall logs, proxy logs, DNS logs, VPN logs |
| Endpoint evidence | Disk images, memory dumps, file system metadata, registry hives, browser history, USB device logs |
| Cloud evidence | CloudTrail, Azure Activity Logs, GCP Cloud Audit Logs, SaaS audit logs, container logs |
| Database evidence | Transaction logs, query logs, backup snapshots, schema change logs |
| Physical evidence | CCTV footage, access control logs, visitor registers, biometric logs, hardware seized for investigation |
| Communications evidence | Emails, chat messages, call recordings, video conference recordings, calendar entries |
| Mobile evidence | SMS, app data, geolocation logs, device backups, MDM logs |
| Documentary evidence | Incident reports, risk assessments, change requests, policy versions, contracts |
| Witness evidence | Statements from users, administrators, security staff, third parties |
Who It Applies To
| Role Category | Applicability |
|---|---|
| All employees | Must know how to report events without contaminating evidence; must not delete logs, clear caches, or factory-reset devices after an incident. |
| IT and system administrators | Often first responders; must follow preservation rules before remediation. |
| Information Security / SOC analysts | Execute evidence identification, collection, and preservation procedures. |
| Incident Response Team | Lead technical evidence acquisition and manage chain of custody. |
| Legal Counsel | Advise on legal holds, privilege, admissibility, and law enforcement coordination. |
| Human Resources | Handle employee-related evidence for disciplinary proceedings; ensure labour-law compliance. |
| Line managers | Preserve evidence related to team members and escalate appropriately. |
| External forensic experts | Must operate under contract and procedure aligned with organisational evidence standards. |
| Law enforcement / regulators | Receive evidence under formal handover protocols. |
Size-Based Applicability
| Organisation Size | Approach |
|---|---|
| Micro (1–10 employees) | Simple checklist; use cloud-native audit logs; engage external forensic support on retainer. |
| Small (10–50 employees) | Documented procedure; secure shared evidence folder with read-only access; basic chain-of-custody form. |
| Medium (50–500 employees) | Formal policy and procedure; SIEM/EDR integration; defined roles; annual tabletop exercise. |
| Large (500–5000 employees) | Forensic readiness program; dedicated CSIRT; e-discovery integration; legal hold automation; tool validation. |
| Enterprise (5000+ employees) | Global forensic operations centre; automated evidence preservation; dedicated legal hold team; continuous monitoring and metrics. |
Key Definitions and Terminology
| Term | Definition |
|---|---|
| Evidence | Information that supports or refutes a belief, assertion, or allegation about an information security event and may be used in legal, disciplinary, regulatory, or investigative proceedings. |
| Chain of Custody | A documented, chronological record of the seizure, control, transfer, analysis, and disposition of evidence, demonstrating that it was not altered or tampered with. |
| Forensic Image | A bit-for-bit copy of a digital storage medium, typically created using a write blocker and validated by cryptographic hash. |
| Hash Value | A fixed-length alphanumeric string generated by a cryptographic hash function (e.g., SHA-256) that uniquely represents a file or data set. Any change to the data changes the hash. |
| Write Blocker | A hardware or software device that prevents writes to a storage medium during acquisition, preserving the original evidence. |
| Volatile Memory | RAM and other short-term storage that is lost when power is removed; often contains critical evidence such as running processes, network connections, and encryption keys. |
| Live Acquisition | Collection of evidence from a running system, typically used when volatile data is essential and cannot be obtained after shutdown. |
| Dead Acquisition | Collection of evidence from a powered-off system or storage medium after it has been removed from the device. |
| Legal Hold | A process to suspend normal destruction of records that may be relevant to actual or anticipated litigation, investigation, or regulatory action. |
| Spoliation | The intentional or negligent destruction, alteration, or withholding of evidence that is relevant to a legal proceeding. |
| Admissibility | The quality of evidence that allows it to be accepted by a court, tribunal, regulator, or disciplinary panel. |
| Best Evidence Rule | A legal principle that prefers the original evidence over copies, unless the original is unavailable. |
| Electronic Record | Any data, record, or information generated, received, or stored electronically, as defined under Indian IT Act and Evidence Act provisions. |
| Forensic Readiness | The capability to collect, preserve, protect, and analyse digital evidence to maximise its use in legal and business proceedings while minimising investigation overhead. |
| Custodian | The person or role responsible for the safekeeping and integrity of evidence. |
| Evidence Repository | A secure, access-controlled storage location for evidence with integrity monitoring and audit logging. |
| Acquisition | The process of creating a forensic copy or capturing data in a manner that preserves its original state. |
| Preservation | The process of maintaining evidence in a secure, unchanged condition for as long as required by legal, regulatory, or operational needs. |
| Tamper Evidence | A property of storage or packaging that makes unauthorised modification detectable. |
Relationship to Other Controls
Upstream Controls (They Feed Evidence Into A.5.28)
| Control | Relationship |
|---|---|
| A.5.1 Policies for Information Security | Provides the policy framework under which evidence-handling policy is approved and maintained. |
| A.5.24 Information Security Incident Management Planning and Preparation | Defines the incident management programme, escalation criteria, and response structures that trigger evidence collection. |
| A.5.25 Assessment and Decision on Information Security Events | Decides whether an event is an incident and whether evidence collection is warranted. |
| A.8.15 Logging | Generates the logs that frequently constitute the primary evidence source. |
| A.8.16 Monitoring Activities | Produces alerts and telemetry that guide evidence identification. |
| A.8.17 Clock Synchronisation | Ensures timestamps across evidence sources are consistent and admissible. |
| A.8.32 Change Management | Maintains records of system changes that may be needed to reconstruct event context. |
Downstream Controls (They Consume or Build on A.5.28)
| Control | Relationship |
|---|---|
| A.5.26 Response to Information Security Incidents | Uses collected evidence to contain, eradicate, and recover from incidents while preserving admissibility. |
| A.5.27 Learning from Information Security Incidents | Relies on accurate evidence to perform credible root-cause analysis and corrective action. |
| A.5.35 Independent Review of Information Security | Internal audit reviews evidence-handling compliance and case files. |
| A.5.36 Compliance with Policies, Rules and Standards for Information Security | Tracks conformance with evidence-handling behavioural rules. |
| A.5.37 Documented Operating Procedures | Operational procedures may require evidence preservation as part of standard workflow. |
Parallel Controls (They Overlap in Practice)
| Control | Relationship |
|---|---|
| A.5.19 Information Security in Supplier Relationships | Supplier contracts must address evidence collection and handover obligations. |
| A.5.20 Addressing Information Security within Supplier Agreements | Agreements should specify forensic cooperation, log retention, and evidence access. |
| A.6.7 Remote Working | Remote endpoints require specific evidence-collection procedures. |
| A.8.1 User Endpoint Devices | Endpoint devices are frequent evidence sources. |
| A.8.10 Information Deletion | Disposal procedures must not destroy evidence subject to legal hold. |
| A.8.11 Data Masking | Evidence containing personal or sensitive data may require masking for analysis while preserving original integrity. |
| A.8.12 Data Leakage Prevention | DLP logs and quarantined files may become evidence. |
| A.8.30 ICT Readiness for Business Continuity | Business continuity tests should include evidence-preservation scenarios. |
Detailed Implementation Guidance
Establish Governance and Ownership
Before writing procedures, define who owns evidence collection and how decisions are made:
| Step | Action | Owner | Output |
|---|---|---|---|
| 1 | Designate A.5.28 control owner (typically CISO) and deputy | CEO / Board | Appointment record |
| 2 | Establish Evidence Management Committee with Legal, HR, IT, Security, Compliance | CISO | Committee charter |
| 3 | Define escalation triggers: legal hold, criminal matter, regulatory inquiry, employee misconduct, major cyber incident | Committee | Trigger matrix |
| 4 | Approve evidence-handling policy and procedure | Committee | Signed policy |
| 5 | Allocate budget for tools, training, and external forensic retainer | CFO / CISO | Budget approval |
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
- Event detected through SIEM alert, user report, anomaly detection, or external notification.
- SOC analyst or first responder records initial details in the incident ticket: date/time, reporter, system, suspected nature, business impact.
- Incident Response Lead assesses whether the event meets evidence-collection triggers.
- If yes, activate the evidence-management track in parallel with containment.
- Notify Legal Counsel if legal hold, criminal matter, or regulatory exposure is possible.
- Notify HR if employee misconduct is suspected.
Phase 2: Identification
- 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
- Determine custodians of each evidence source.
- Issue preservation notices or legal holds to custodians and system owners.
- Document the identification decision in the evidence inventory.
Phase 3: Collection and Acquisition
- Prioritise volatile evidence (RAM, network connections, running processes) before it is lost.
- Use write blockers for disk imaging where possible.
- Create forensic images using validated tools (dd, FTK Imager, Guymager, EnCase, Cellebrite, etc.).
- Capture system logs, network captures, and cloud audit trails in native format.
- Generate SHA-256 hashes for all acquired evidence and record in the chain-of-custody form.
- Label physical evidence with tamper-evident seals and unique evidence IDs.
- Photograph or video-record physical seizures and screen states where appropriate.
Phase 4: Preservation and Storage
- Transfer evidence to the secure evidence repository immediately.
- Store originals/immutable copies separately from working copies.
- Verify hash values upon transfer and at scheduled intervals.
- Restrict access to authorised forensic investigators, Legal, and designated custodians.
- Maintain audit logs of all access to the evidence repository.
- Apply encryption at rest and in transit.
- Ensure environmental protection for physical media (fireproof safe, climate control).
Phase 5: Analysis and Review
- Conduct analysis on working copies or forensic duplicates, never on originals.
- Document every analytical step, tool version, and command used.
- Maintain analysis notes that are contemporaneous and attributable.
- Escalate findings to Incident Response Lead, Legal, and HR as appropriate.
Phase 6: Disclosure and Handover
- Prepare evidence packages for internal disciplinary process, regulatory filing, insurance claim, or law enforcement.
- Use agreed formats and redaction where necessary to protect unrelated personal data.
- Complete handover forms recording recipient, date, contents, and intended use.
- Obtain acknowledgement signature from recipient.
Phase 7: Retention and Disposal
- Apply retention periods based on legal hold, regulatory requirement, and organisational policy.
- Review retention status periodically; extend legal holds as needed.
- 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.
| Event Category | Examples | Evidence Collection Trigger | Activation Level |
|---|---|---|---|
| Critical cyber incident | Ransomware, advanced persistent threat, data breach, unauthorised access to crown-jewel systems | Always activate | Full forensic collection, Legal/HR notified, external forensics on standby |
| Confirmed fraud or financial crime | Wire fraud, invoice fraud, loan fraud, payment card fraud | Always activate | Full collection, preserve database logs, Legal/HR engaged |
| Insider threat | Unauthorised data exfiltration, sabotage, policy violation with intent | Activate when misconduct is suspected | Targeted collection, HR/Legal hold, mobile forensics |
| Phishing / business email compromise | Successful credential theft, fraudulent wire transfer | Activate if business impact or regulatory notification required | Email and mailbox preservation, endpoint telemetry, proxy logs |
| Malware infection (contained) | Endpoint malware blocked by EDR | Preserve logs only | Log export and screenshot; no full disk image unless escalation |
| Misconfiguration or operational error | Exposed S3 bucket, accidental data disclosure | Activate if personal data exposed or contractual breach likely | Cloud audit logs, access logs, impact assessment evidence |
| Third-party security incident | Supplier breach affecting organisational data | Activate per contract and impact | Supplier evidence request, internal impact evidence |
| Physical security event | Tailgating, device theft, unauthorised access | Activate if information assets involved | CCTV, access logs, device inventory, witness statements |
Forensic Acquisition Techniques by Evidence Type
| Evidence Type | Recommended Acquisition Technique | Key Considerations |
|---|---|---|
| Windows endpoint disk | FTK Imager / Guymager / EnCase with hardware write blocker | Bit-for-bit image; capture before remediation; hash image and source |
| Volatile memory (RAM) | Magnet RAM Capture / WinPmem / LiME on live system | Capture before shutdown; document running processes and network state |
| Linux/Unix server disk | dd / dc3dd / Guymager; mount read-only | Preserve extended attributes and timestamps |
| Mobile device | Cellebrite / Oxygen / MSAB XRY; logical then physical if supported | Require legal basis for device seizure; note device state |
| Network traffic | tcpdump / Wireshark / Zeek on a span/mirror port | Capture sufficient duration; ensure storage capacity; legal interception considerations |
| Cloud audit logs | AWS CloudTrail / Azure Monitor / GCP Cloud Logging export to immutable storage | Enable log integrity and object lock; preserve original JSON/CSV |
| Email / Microsoft 365 | eDiscovery export / PowerShell / third-party tool | Preserve mailbox, calendar, Teams chats; legal hold first |
| Database | Native transaction log backup / database forensic tool | Avoid live queries that modify state; capture at point-in-time |
| CCTV footage | Export from NVR/DVR with timestamps and watermark | Export before overwrite cycle; verify continuity |
| Physical documents / devices | Photograph, seal, store in tamper-evident bag | Maintain physical custody log; environmental protection |
Chain of Custody Best Practices
A defensible chain of custody answers four questions at every stage:
- Who had custody?
- What was in their custody?
- When did they have it?
- 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
| Rule | Rationale |
|---|---|
| Do not power off, reboot, or log off a suspected compromised system without Security approval. | Volatile evidence may be lost. |
| Do not delete emails, files, chat messages, or logs related to a security event. | Spoliation risk and legal exposure. |
| Do not forward suspicious emails to colleagues or click links after reporting. | Preserves phishing evidence and prevents spread. |
| Do not factory-reset or wipe mobile devices involved in an investigation. | Destroys critical evidence. |
| Do not discuss investigation details outside the need-to-know group. | Protects integrity, confidentiality, and privilege. |
| Do not install unauthorised tools on evidence systems. | Tools may alter evidence or be challenged in court. |
| Report suspected events immediately through the official channel. | Timeliness improves evidence quality. |
| Cooperate with Security, Legal, and HR during evidence collection. | Non-cooperation may be a policy violation. |
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
| Scenario | Legal / HR Action |
|---|---|
| Suspected criminal conduct (fraud, hacking, theft) | Legal advises on police complaint, privilege, and admissibility; HR suspends employee pending investigation. |
| Employee policy violation | HR leads disciplinary process; Security provides evidence package; Legal reviews fairness and procedure. |
| Regulatory breach notification | Legal determines notification obligation; Security provides evidence of breach, impact, and remediation. |
| Customer or vendor dispute | Legal manages dispute; Security preserves contractually required evidence. |
| Insurance claim | Legal/Finance files claim; Security provides forensic report and evidence of loss. |
Size-Tiered Implementation
| Tier | Focus | Deliverables |
|---|---|---|
| Tier 1: Startup / Small | Keep it simple and affordable | One-page procedure; cloud log retention; basic chain-of-custody form; external forensic retainer |
| Tier 2: Growing companies | Formalise roles and integrate tools | Policy + procedure; SIEM/EDR evidence export; secure repository; quarterly tabletop exercise |
| Tier 3: Large Enterprise | Scale and automate | Forensic readiness program; dedicated CSIRT; e-discovery and legal hold automation; metrics dashboard; tool validation |
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
| Category | Purpose |
|---|---|
| Disk imaging | Create bit-for-bit forensic copies of storage media |
| Memory acquisition | Capture volatile RAM from live systems |
| Mobile forensics | Acquire and analyse smartphones and tablets |
| Network forensics | Capture and analyse network traffic |
| Log management / SIEM | Centralise, search, and export logs with integrity |
| Endpoint Detection and Response (EDR) | Capture endpoint telemetry, isolate hosts, export artefacts |
| eDiscovery / legal hold | Preserve electronically stored information for litigation |
| Chain-of-custody / case management | Track evidence lifecycle and custody |
| Immutable storage | Prevent alteration or deletion of evidence |
| Cloud forensics | Acquire logs and snapshots from cloud environments |
Tool Evaluation Criteria
When selecting evidence-collection tools, evaluate vendors against the following criteria:
| Criterion | Why It Matters | Questions to Ask |
|---|---|---|
| Court admissibility | Tools must produce evidence that courts and regulators accept. | Has the tool been tested in Indian or international courts? Can the vendor provide expert testimony? |
| Integrity verification | Hashes and write protection are essential for defensibility. | Does the tool generate SHA-256 hashes? Does it support hardware write blockers? |
| Coverage | Evidence exists across endpoints, servers, cloud, mobile, and network. | Does the tool support all platforms and evidence types in your environment? |
| Scalability | Enterprises need bulk acquisition and automation. | Can the tool scale to hundreds or thousands of endpoints? |
| Ease of use | Complex tools increase error rates. | How much training is required? Is the interface intuitive? |
| Integration | Tools should fit into SIEM, SOAR, EDR, and eDiscovery workflows. | Does the tool offer APIs and native integrations? |
| Support and updates | Forensic tools must keep pace with new operating systems and devices. | What is the update frequency? Is local support available in India? |
| overhead and licensing | Budget must cover initial purchase, maintenance, and training. | Is licensing per user, per endpoint, or per case? Are there hidden overhead? |
| Data residency | Indian regulations may require data to remain in India. | Can evidence be stored within Indian boundaries? |
| Vendor reputation | Trusted vendors reduce procurement and audit friction. | Is the vendor DSCI-empanelled or recognised by Indian regulators? |
Vendor Comparison Matrix
| Vendor / Tool | Category | Indian vs Global | licensing Indication | Best For |
|---|---|---|---|---|
| SANS SIFT / Paladin | Open-source forensic suite | Global | Free | Budget-conscious labs and training |
| Autopsy / The Sleuth Kit | Open-source disk forensics | Global | Free | Free, extensible forensic analysis |
| Volatility / Rekall | Memory forensics | Global | Free | Open-source RAM analysis |
| Wireshark / tcpdump / Zeek | Network forensics | Global | Free / lightweight | Packet capture and network analysis |
| AWS S3 Object Lock / Azure Immutable Blob / GCS Bucket Lock | Immutable cloud storage | Global | Pay-per-use | WORM storage for log and evidence preservation |
| HashiCorp Vault / AWS KMS / Azure Key Vault | Key management | Global | Pay-per-use | Encryption key management for evidence |
Tool Selection Guidance
| Organisation Profile | Recommended Stack |
|---|---|
| Bootstrapped Indian SaaS startup | CloudTrail/Azure/GCP audit logs + SIEM free tier + S3 Object Lock + external retainer |
| Growing-company IT/ITES | EDR + SIEM + Autopsy/Paladin + case management + SISA or Lucideus retainer |
| BFSI regulated entity | Enterprise SIEM + EDR + EnCase/AXIOM + eDiscovery + Big-4 forensic panel + immutable storage |
| Government / PSU | Indigenous/empanelled forensic labs + SIEM + network forensics + strict chain-of-custody |
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)
- Indian Evidence Act, 1872, Sections 65A and 65B
- 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
| Risk ID | Risk Description | Likelihood | Impact | Risk Level | Treatment |
|---|---|---|---|---|---|
| R1 | Evidence is lost because personnel power off systems before Security can capture volatile data | Medium | High | High | Procedure and training; "do not power off" rule; rapid SOC response |
| R2 | Evidence integrity is compromised due to lack of hashing or write protection | Medium | High | High | Mandate SHA-256 hashing and write blockers; validate tools |
| R3 | Chain of custody is incomplete, making evidence inadmissible | Medium | High | High | Standardised forms; training; two-person custody for high-risk cases |
| R4 | Evidence is accidentally or maliciously deleted from shared storage | Medium | High | High | Immutable/WORM storage; role-based access; audit logs |
| R5 | Legal hold is issued too late, resulting in spoliation | Low | High | Medium | Early Legal involvement; trigger matrix; automated legal hold integration |
| R6 | Employee under investigation deletes emails/files before preservation | Medium | High | High | Rapid preservation notices; DLP; litigation hold on mailboxes |
| R7 | Cloud logs are overwritten or expired before collection | Medium | High | High | Extend log retention; export to immutable storage; SIEM backup |
| R8 | Forensic tools are unlicensed or untrusted, damaging credibility | Low | High | Medium | Maintain tool inventory; licensing; validation records |
| R9 | Evidence contains personal data of unrelated individuals, violating DPDP Act | Medium | Medium | Medium | Redaction protocols; data minimisation; purpose limitation |
| R10 | External forensic vendor mishandles evidence | Low | High | Medium | Due diligence; contractual clauses; oversight; chain-of-custody handover |
| R11 | Timestamps are inconsistent across evidence sources | Medium | Medium | Medium | NTP synchronisation; timezone documentation; clock audit |
| R12 | Mobile or remote endpoint evidence is inaccessible after employee departure | Medium | High | High | MDM remote lock/wipe prevention; legal direction; cloud backup |
Audit and Compliance Checklist
| # | Audit Question | Expected Evidence | Red Flag |
|---|---|---|---|
| 1 | Is there an approved evidence collection and handling policy? | Signed policy, version history | No policy or outdated policy |
| 2 | Is there a documented evidence handling procedure? | Procedure with workflow diagrams | Informal or missing procedure |
| 3 | Are roles (Evidence Custodian, Legal, HR) clearly defined? | RACI matrix, role descriptions | No assigned custodian |
| 4 | Are evidence collection triggers defined? | Trigger matrix in policy/procedure | Triggers unclear or absent |
| 5 | Is there a chain-of-custody form in use? | Sample completed forms | No chain-of-custody records |
| 6 | Are cryptographic hashes generated and verified? | Hash logs, verification records | No hashing or mismatches unresolved |
| 7 | Is evidence stored in an access-controlled, secure repository? | Access control matrix, storage configuration | Evidence on writable shared drive |
| 8 | Is the evidence repository encrypted and audited? | Encryption config, access logs | No encryption or logging |
| 9 | Is volatile evidence captured before system changes? | Memory capture records, runbooks | Systems powered off immediately |
| 10 | Are write blockers or equivalent protections used for disk imaging? | Tool inventory, acquisition logs | Direct imaging without protection |
| 11 | Is there a legal hold process? | Legal hold notices, retention records | No legal hold capability |
| 12 | Are employees trained on evidence preservation behavioural rules? | Training records, attendance | No training evidence |
| 13 | Are incident responders trained in forensic acquisition? | Certificates, lab exercises | Untrained responders |
| 14 | Are forensic tools licensed, updated, and validated? | Licence inventory, validation records | Pirated or unvalidated tools |
| 15 | Is evidence retention aligned with legal/regulatory requirements? | Retention schedule, disposal records | Indefinite or arbitrary retention |
| 16 | Is evidence disposal documented and secure? | Disposal approvals, certificates | Evidence deleted without approval |
| 17 | Are external forensic engagements governed by contracts? | Contracts, NDAs, scope documents | Verbal engagements |
| 18 | Is law enforcement handover documented? | Handover forms, FIR copies | Informal handover |
| 19 | Are case files reviewed for completeness? | Case review records | Incomplete case files |
| 20 | Is there evidence of continuous improvement? | Post-incident reviews, updated procedures | Same failures repeated |
| 21 | Are cloud logs retained with integrity? | Cloud lock settings, export logs | Cloud logs unprotected |
| 22 | Is clock synchronisation maintained across evidence sources? | NTP config, clock audit | Timestamp discrepancies |
| 23 | Are personal data protection considerations addressed? | Redaction records, DPDP assessments | Unnecessary personal data exposure |
| 24 | Is privileged or confidential information protected? | Access restrictions, privilege logs | Overly broad access |
| 25 | Are tabletop exercises conducted to validate the process? | Exercise reports, action items | No exercises |
Metrics and KPIs
| # | KPI | Formula | Target | Frequency |
|---|---|---|---|---|
| 1 | Evidence Collection Activation Time | Time from incident declaration to evidence custodian activation | < 30 minutes | Per incident |
| 2 | Volatile Evidence Capture Rate | % of eligible incidents where volatile memory/logs captured before system change | ≥ 90% | Monthly |
| 3 | Hash Verification Success Rate | % of evidence items with matching hashes at acquisition and storage | 100% | Per acquisition |
| 4 | Chain of Custody Completeness | % of evidence items with complete chain-of-custody records | 100% | Monthly |
| 5 | Evidence Repository Access Review | % of access permissions reviewed quarterly | 100% | Quarterly |
| 6 | Legal Hold Implementation Time | Time from trigger to legal hold issuance | < 2 hours | Per legal hold |
| 7 | Evidence Retention Compliance | % of evidence disposed per approved retention schedule | 100% | Quarterly |
| 8 | Training Completion Rate | % of relevant personnel completing evidence awareness training | ≥ 95% | Annually |
| 9 | Forensic Tool Validation Coverage | % of forensic tools with current licence and validation record | 100% | Annually |
| 10 | Incident Case File Completeness | % of cases with complete evidence inventory, hashes, and custody forms | ≥ 95% | Monthly |
| 11 | Cloud Log Immutability Coverage | % of critical log sources stored in immutable/WORM storage | 100% | Quarterly |
| 12 | Evidence-Related Audit Findings | Number of nonconformities related to A.5.28 | 0 | Per audit |
| 13 | External Forensic Engagement Readiness | Time to engage external forensic support from retainer | < 4 hours | Per exercise |
| 14 | Employee Misconduct Case Evidence Sufficiency | % of HR cases with sufficient evidence to support decision | ≥ 90% | Annually |
| 15 | Evidence overhead Per Incident | Total evidence-handling overhead / number of incidents | Trend downward | Annually |
Common Pitfalls / Audit Failures & How to Avoid Them
| Pitfall | Cause | Fix |
|---|---|---|
| P1: Powering off systems too soon | First responders panic and reboot to "fix" the issue | Train helpdesk and IT: never power off suspected compromised systems without Security approval |
| P2: No chain-of-custody records | Informal evidence handovers, missing forms | Mandate a chain-of-custody form for every evidence item; audit quarterly |
| P3: Evidence stored on writable shares | Convenience, lack of secure repository | Deploy immutable or read-only evidence repository with access control |
| P4: Hashing skipped or hashes not verified | Time pressure, lack of tooling | Automate hash generation and verification; make it a checklist step |
| P5: Legal not engaged early enough | Security treats incidents as purely technical | Include Legal notification trigger in every runbook for high-severity events |
| P6: Cloud logs lost to retention limits | Default cloud log retention is too short | Configure extended retention and export to immutable storage |
| P7: Over-collection of personal data | Broad preservation notices | Use targeted preservation; redact unrelated personal data |
| P8: Unlicensed or pirated forensic tools | overhead-cutting, unawareness | Maintain approved tool list with licences; ban unauthorised tools |
| P9: Inconsistent timestamps | No NTP, mixed time zones | Enforce NTP, document time zones, synchronise clocks |
| P10: Mobile devices wiped before acquisition | Employee resigns or MDM policy auto-wipes | Suspend auto-wipe during investigations; legal hold on device backup |
| P11: Evidence disclosure without privilege review | Security hands reports directly to third parties | Route all external disclosure through Legal |
| P12: No disposal schedule | Fear of deleting potential evidence | Create retention schedule with Legal; dispose with certificate |
| P13: Tabletop exercises skipped | Competing priorities | Schedule at least one evidence-focused tabletop per year |
| P14: External vendor not bound by procedure | Contract lacks forensic clauses | Include evidence-handling, chain-of-custody, and confidentiality clauses in vendor contracts |
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 Singahi to implement an A.5.28 evidence management programme over eight weeks:
- Policy and procedure: Approved an Evidence Collection and Handling Policy and a step-by-step procedure.
- Forensic readiness: Deployed a SIEM with 12-month log retention and immutable S3-backed storage.
- Endpoint visibility: Implemented EDR on all employee laptops and DLP on file shares.
- Legal hold process: Established a rapid legal hold workflow with HR and Legal.
- Mobile forensics: Contracted a DSCI-empanelled forensic lab for smartphone acquisition.
- 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 IPC.
- The NBFC recovered approximately in 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 Singahi to build an A.5.28 capability:
- Incident runbook update: Added an "evidence preservation" workstream to every incident runbook.
- Behavioural rules: Trained all engineers on "do not power off" rules and rapid escalation.
- Automated evidence collection: Configured EDR to auto-isolate endpoints and export memory dumps and disk artefacts to a secure evidence repository.
- Cloud log immutability: Enabled AWS S3 Object Lock and CloudTrail organisation trails with multi-year retention.
- Forensic retainer: Signed a retainer with an Indian digital forensic firm for 24/7 incident response.
- 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 CISO reported A.5.28 as a strength in the annual ISO 27001 surveillance audit.
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 DPDP Act 2023 notification threshold was met.
Solution: The platform engaged Singahi under an emergency response engagement:
- Immediate preservation: Exported remaining logs and database snapshots to a new immutable storage bucket with object lock enabled.
- Forensic timeline: Reconstructed access history from cloud audit trails, database query logs, and application logs before they expired.
- Evidence integrity: Generated SHA-256 hashes for all exported data and maintained a chain-of-custody log.
- Impact assessment: Used preserved evidence to determine the exact records exposed, access duration, and whether unauthorised parties downloaded data.
- Notification decision: Legal used the evidence package to decide on regulator and customer notification.
- 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 2023 readiness assessment identified evidence collection as a strength.
- Cloud log retention was extended to 24 months, and SIEM integration was completed within 12 weeks.
Multi-Framework Mapping
| Framework / Standard | Mapping | Notes |
|---|---|---|
| ISO 27001:2022 | A.5.28 Collection of Evidence | Primary control. |
| ISO 27002:2022 | Section 5.28 | Implementation guidance. |
| SOC 2 Trust Services Criteria (2017) | CC7.2, CC7.3, CC7.4 | System operations, incident detection, and incident response; evidence collection supports incident handling and legal needs. |
| PCI DSS v4.0 | Requirement 10.3 ( protecting audit trail coverage), 10.4 (synchronise clocks), 12.10 (incident response plan), 12.10.5 (preserve evidence) | PCI DSS explicitly requires preservation of evidence for forensic investigation. |
| NIST SP 800-53 Rev 5 | IR-4 (Incident Handling), IR-5 (Incident Monitoring), IR-6 (Incident Reporting), IR-7 (Incident Response Assistance), IR-8 (Incident Response Plan), AU-6 (Audit Review), AU-11 (Audit Record Retention) | NIST provides detailed incident handling and audit record retention controls that align with A.5.28. |
| NIST CSF 2.0 | RS.AN (Analyse), RS.MI (Mitigate), RS.IM (Improve), ID.GV (Governance) | Evidence collection supports analysis, mitigation, and improvement activities. |
| CIS Controls v8 | Control 8 (Audit Log Management), Control 17 (Incident Response Management), Control 18 (Penetration Testing) | Logging and incident response controls produce and consume evidence. |
| COBIT 2019 | DSS05.02, DSS05.03, DSS05.04, DSS05.07 | Managed security services, incident identification, incident evaluation, and security monitoring. |
| GDPR | Article 5(1)(f) integrity and confidentiality, Article 32 security of processing, Article 33 breach notification | Evidence supports breach investigation, notification accuracy, and accountability. |
| DPDP Act 2023 (India) | Section 8 reasonable safeguards, breach intimation rules, Board powers | Documented evidence demonstrates reasonable security and supports breach reporting. |
| RBI Cyber Security Framework | Cyber Security Operations Centre, Incident Reporting, Cyber Crisis Management Plan | RBI-regulated entities must maintain evidence for cyber incidents and frauds. |
| SEBI Cyber Security Circular | Cyber Security Operations Centre, incident response, forensic audit | SEBI expects market infrastructure institutions to preserve and produce evidence. |
| IRDAI Cyber Security Guidelines | Incident management, logging, monitoring, forensic readiness | Insurers must maintain evidence of incidents involving policyholder data. |
Implementation Roadmap
Phase 1: Foundation (Weeks 1–2)
| Week | Activities | Deliverables |
|---|---|---|
| 1 | Appoint control owner; establish Evidence Management Committee; review legal/regulatory drivers | Charter, stakeholder list |
| 2 | Draft Evidence Collection and Handling Policy; define evidence categories and triggers | Policy draft v0.1 |
Phase 2: Procedure and Tools (Weeks 3–5)
| Week | Activities | Deliverables |
|---|---|---|
| 3 | Develop step-by-step evidence handling procedure; create chain-of-custody form and evidence inventory template | Procedure v0.1, forms |
| 4 | Identify and configure evidence repository (immutable storage, encryption, access control) | Repository configured |
| 5 | Select and procure forensic tools; establish external forensic retainer | Tool inventory, retainer contract |
Phase 3: Integration and Training (Weeks 6–8)
| Week | Activities | Deliverables |
|---|---|---|
| 6 | Integrate evidence preservation into incident response runbooks; define Legal/HR escalation | Updated runbooks |
| 7 | Train incident responders, IT admins, SOC, Legal, HR, and all employees | Training records |
| 8 | Conduct tabletop exercise; refine procedure based on findings | Exercise report, updated procedure |
Phase 4: Operation and Improvement (Ongoing)
| Frequency | Activities |
|---|---|
| Monthly | Review evidence cases for completeness and metrics |
| Quarterly | Review repository access, retention status, and tool licences |
| Annually | Policy review, refresher training, full forensic readiness assessment, management review |
| Trigger-based | Update procedure after major incidents, legal changes, or tool changes |
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).
- Indian Evidence Act, 1872, Sections 65A and 65B.
- 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 Circulars on Cyber Security and Cyber Resilience.
- 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 impact 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: The Definitive Implementation Guide by Singahi.