Part III — Technical Forensics & Investigative Tools

The tools and procedures in this Part exist for one reason: to ensure that digital evidence collected by HRDs can be used in a Kenyan court of law. Without that goal, forensic procedure is just paperwork.

Understanding why courts reject evidence - and what makes evidence legally strong - is not a lawyer's job alone. Every person who handles digital evidence in your organisation is making decisions that affect admissibility. The programme officer who takes a screenshot of a threatening message, the paralegal who saves an email, the IT lead who attempts to clean an infected device: all of them are either building or destroying a legal case, depending on what they know.

This section gives every member of your team — lawyers, paralegals, and non-technical staff alike — the foundation they need to make those decisions correctly.

The Three Questions Every Evidence Handler Must Be Able To Answer:

1. Was the device or system functioning correctly when this evidence was created? (Operational integrity — Kenya Evidence Act s.106B)
2. Has the evidence been altered since it was first collected? (Non-tampering — verified by SHA-256 hash)
3. Can I prove, with a signed paper trail, who handled this evidence and when? (Chain of custody — required for court submission)

If the answer to any of these three questions is "no" or "I don't know", the evidence is at serious risk of being ruled inadmissible — regardless of how clearly it shows what happened.

3.1.1 Paralegal Capacity Building Pathway

LEVEL 1 — AWARENESS (All Staff, Including Non-Technical)

Target: Every person who might encounter a suspicious message, file, or device incident in the course of their work.

Core knowledge required:

• What digital evidence is and why it matters in Kenyan courts
• The three questions above (operational integrity, non-tampering, chain of custody)
• What NOT to do: do not click, do not clean, do not wipe, do not share via WhatsApp before documenting
• Who to call: your organisation's digital safety officer or Tatua DRC

Delivery: 2-hour awareness session. Can be delivered by a paralegal or IT lead who has completed Level 2. Does not require a lawyer.

LEVEL 2 — PRACTITIONER (Paralegals, Programme Officers, Case Managers)

Target: Staff who will handle, document, or transmit digital evidence in the course of legal support or case management work.

Core knowledge required:

• All Level 1 content
• How to extract and read an email header (section 3.2(a))
• How to complete a chain-of-custody form correctly (Appendix B)
• How to take legally admissible screenshots (section 3.4 OpSec rules)
• How to complete the First 30 Minutes evidence checklist (Part II, section 2.3(b))
• Triage classification using the section 3.1(a) decision table

Delivery: 1-day workshop. Facilitated by Tatua DRC or a trained legal officer. Includes practical exercises for each skill above.

Recommended: Annual refresher and debrief after any real incident.

LEVEL 3 — ADVANCED (Legal Officers, Digital Safety Officers)

Target: Staff responsible for submitting evidence to authorities, supporting prosecutions, or advising other staff on evidence handling.

Core knowledge required:

• All Level 1 and Level 2 content
• Full Section 106B analysis and its practical implications
• Passive and active investigation tools (section 3.2, section 3.3)
• Mobile device triage procedures (section 3.5)
• Preparation of evidence for ODPC, KE-CIRT, and DCI submission
• Chain-of-custody documentation for court proceedings

Organisational Legal Literacy Self-Assessment

Legal Literacy Self-Assessment

Answer honestly. Each 'No' identifies a gap that increases your legal risk.

• Does every staff member know not to wipe or factory-reset a suspected compromised device? YES / NO
• Does your organisation have a named person responsible for evidence handling during an incident? YES / NO
•  Do you have blank chain-of-custody forms accessible offline? YES / NO
•  Can at least one staff member extract a raw email header? YES / NO
• Do staff know the difference between a screenshot for internal use and a screenshot admissible in court? YES / NO
• Has your organisation ever conducted a legal literacy or evidence-handling training session? YES / NO
• Do you have pre-established contact with legal counsel who understands digital evidence in Kenyan courts? YES / NO

Scoring:

• 7 / 7 Yes — Strong foundation. Focus on maintaining and testing.
• 4–6 Yes — Partial capacity. Prioritise gaps as training actions.
• 0–3 Yes — High legal risk. Contact Tatua DRC to plan a capacity-building programme before the next incident.

Before any technical tool is opened, investigators must establish two things: the emotional safety of the person reporting the incident, and the nature and scope of the threat. These two steps are not optional preamble - they are the foundation of the entire investigation. A distressed person will misremember critical details. A misclassified incident will receive the wrong response.

3.2.1 The Five-Step Triage Sequence

 This sequence applies whether you are experiencing the incident yourself or supporting someone else. In both cases: people first, tools second.

STEP 1 | Establish emotional safety

Before asking any technical questions, acknowledge the person's experience. Ask how they are feeling. Confirm they are physically safe. Allow them to speak without interruption. A person who feels heard and not judged will provide far more accurate information than a person who feels blamed or rushed. Only proceed to technical questions when the person is calm enough to recall details accurately.

STEP 2 | Establish consent and explain what comes next

Explain in plain language: what information you will collect, who will have access to it, what the risks of sharing externally are, and what the investigation process involves. Confirm explicit consent before proceeding. Make clear that the person can stop at any point for any reason without consequence.

STEP 3 | Gather threat context

Ask: Did you receive a suspicious message or link, and did you click it? When did you first notice something unusual? Has anyone else in your organisation reported similar issues? Have you been in contact with sensitive sources or attended high-profile events recently? Has your device been out of your direct control at any point? These questions determine whether you are dealing with an opportunistic scam, a targeted campaign, or a sophisticated spyware infection - three completely different response pathways.

STEP 4 | Classify using the triage table

Use the triage decision table below to classify the incident and determine the immediate response pathway. Classification determines: (a) whether internal handling is appropriate or immediate escalation is required; (b) what tools are safe to use; (c) what evidence preservation steps must happen before any other action. When in doubt between two classifications, always choose the higher-severity one.

STEP 5 | Verify through a different channel

The fastest way to confirm whether a suspicious communication is genuine is to contact the apparent sender through a completely different channel - a Signal message to a saved number, a phone call, or a face-to-face conversation. Never reply to the suspicious message to verify it. Never click a link to confirm whether it is safe.

Use the expanded triage decision table below to classify the incident and select your response pathway:

Table 13: Triage Decision & Response pathway

Triage: 'What happens if you skip triage classification?'

Legal Outcome: Misclassified Incident

An HRD organisation received what appeared to be generic spam and deleted it without investigation. The same email had been sent to twelve staff members with individually personalised content. It was a spear-phishing campaign targeting the organisation's case management system. Without triage, the organisation had no record that the campaign had occurred. When credentials were later compromised, there was no documented incident timeline to support a criminal complaint.Skipping triage does not reduce risk — it eliminates the evidence trail that would have established a legal case.

Passive Investigation: Gathering intelligence about a threat using publicly available data and cloud-based analysis services, without making direct contact with attacker-controlled infrastructure. Passive investigation does not trigger the threat and does not alert the attacker that an investigation is underway.

Passive investigation is the appropriate starting point for nearly all incidents. All tools in this section can be used safely from your own device - they require only a web browser and do not require you to click suspicious links, open malicious files, or install any software. The single most valuable passive investigation skill for non-technical HRDs is reading an email header.

3.3.1 How to Read an Email Header - Plain Language Guide

Every email carries a hidden technical record - the 'header' - containing metadata about its real origin, routing path, and authentication status. The visible 'From:' address you see in your email client can be completely fabricated. The header reveals the truth.

Step 1: Extract the Raw Email Header

• Open the email. Click the three-dot menu (top right of the message). Select 'Show original'. The full header is in the top half of the page that opens. Copy all text above the blank line. Gmail:
• Open the email. Click the three-dot menu. Select 'View > View message source'. Copy the header section at the top. Outlook Web:
• Open the email. Go to File > Properties. The 'Internet headers' box contains the header. Copy all text. Outlook Desktop:
• Open the email. Go to View menu > Message > All Headers. Copy the expanded header. Apple Mail:

Step 2: Paste into MxToolbox or Google Admin Toolbox

Navigate to mxtoolbox.com/EmailHeaders or toolbox.googleapps.com/apps/messageheader. Paste the entire raw header text into the input box and click 'Analyse'. You will receive a visual breakdown of:

• PASS means the sending server is authorised to send on behalf of the claimed domain. FAIL or SOFTFAIL means the email was not sent from an authorised server - strong spoofing indicator. SPF Result:
• PASS means the email content was cryptographically signed by the domain and has not been modified in transit. FAIL means the signature is invalid - the email may have been altered or the sender is impersonating the domain. DKIM Result:
• PASS means the email aligns with the domain's published email security policy. FAIL is a strong indicator of spoofing or domain impersonation. DMARC Result:
• Read from bottom to top. The bottommost 'Received:' line is where the email originated. Does the originating server's IP address belong to the claimed sender's organisation? Look up the IP in ipinfo.io to check.

Received chain:

 If all three results - SPF, DKIM, and DMARC - show FAIL, the email almost certainly did not come from the claimed sender. This is not proof of malicious intent on its own (legitimate emails sometimes fail authentication due to forwarding) but combined with suspicious content, it is strong evidence of spoofing.

For advanced email forensics: the 'Authentication-Results' header from the final receiving mail server is the most authoritative source for SPF/DKIM/DMARC results - it is added by the server you control, not by the sender. Earlier 'Authentication-Results' headers added by intermediate servers can be spoofed by a sophisticated attacker. Always use the last (topmost in order) authentication result header.

3.2(b) Passive Investigation Tools - Complete Reference

The table below provides a comprehensive reference for all passive investigation tools, including user level, privacy risk rating, and specific operational guidance for HRD contexts:

Table 14:Passive Investigation Tools

Web Sandbox: A remote, isolated cloud environment in which suspicious files and URLs are executed or visited on your behalf, allowing you to observe their behaviour - spawned processes, network connections, file changes, registry modifications - without any risk to your own device, network, or identity.

Active investigation involves interacting with suspected malicious content, but doing so exclusively through remote sandbox environments. The fundamental rule is: never execute or open suspicious content on your primary device, your organisation's network, or any device connected to accounts you use for real work.

Table 15:Active Investigation tools

3.3(a) Safe Attachment Analysis - Correct Sequence

STEP 1 | Never open the attachment on your primary device

Save to an isolated drive. Do not double-click. If you have accidentally opened it: disconnect from the network immediately, capture volatile data, and escalate to a technical responder.

STEP 2 | Compute the SHA-256 hash first using CyberChef

Navigate to gchq.github.io/CyberChef. Operations panel: search 'SHA2', drag into recipe, set to 256 bits. Input: 'Open file'. Copy the resulting 64-character hash. Record in your investigation notes.

STEP 3 | Search by hash - MalwareBazaar then VirusTotal

Check MalwareBazaar (bazaar.abuse.ch) first - if found, full analysis may already exist. Then check VirusTotal by searching the hash in the search bar (not uploading the file). If either platform returns a positive identification, you have your answer without submitting the file.

STEP 4 | Submit to Any.Run if hash lookups return no result

Navigate to app.any.run. Upload the file or paste the hash. Use Interactive mode to simulate user actions. Observe the full execution report: processes spawned, network connections made, registry keys modified, files dropped. Record all findings as IOCs.

STEP 5 | Document all IOCs and share appropriately

Record: SHA-256 and MD5 hashes; malware family if identified; all domains and IPs contacted; all files dropped; all registry modifications. These indicators are used for threat hunting across your organisation and can be shared with the HRD peer network via TLP:AMBER.

An investigator who exposes their own identity, location, or analysis activity to the attacker has compromised both the investigation and their personal safety. Operational security for forensic investigators is a mandatory discipline applied at every stage of every investigation.

3.4(a) Core OpSec Rules

• Use a reputable, independently audited, no-log VPN whenever accessing investigation platforms. This prevents your real IP address from being logged by attacker-controlled infrastructure or by analysis services whose logs could be subpoenaed. Recommended: ProtonVPN (protonvpn.com). Free VPNs with no verifiable no-log policy must not be used for investigation work - they may log and sell your queries. VPN - always active during investigation.
• Perform all active investigation from either a dedicated virtual machine or a separate physical device that is not logged into any personal or organisational accounts. Never investigate malware on the same device you use for email, Signal, or work documents. Isolated analysis environment - always.
• All communication about a live investigation must occur on a separate device via Signal. Never discuss an ongoing investigation through an account or device that may be compromised. Out-of-band coordination - always.
• When recording malicious links in reports, evidence logs, or shared documents, always defang them: replace 'https://' with 'hxxps://' and enclose dots in square brackets. Example: hxxps://malicious-site[.]com/payload[.]exe. This prevents accidental clicks and prevents the URL from being followed automatically by email clients or document viewers. URL defanging - in all documentation.
• Screenshots used as legal evidence must include the full URL bar, browser name, date and time visible in the system clock, and the full page content showing the relevant indicator. Partial screenshots that omit the URL or timestamp are significantly weaker as evidence under Section 106B. Evidence screenshots - always complete.
• Before sharing any file externally for analysis, strip metadata using ExifTool (exiftool.org) or the built-in metadata removal in Word/PDF tools. Document metadata can reveal the investigator's name, organisation, internal file paths, and device details. Metadata stripping before sharing.

For investigators assessed as targets of nation-state adversaries: consider Tails OS for the most sensitive investigations. Tails is a live operating system that runs from a USB drive, leaves no trace on the host machine, routes all traffic through Tor, and has no persistent storage. It cannot be compromised by malware on the host computer because it runs entirely in RAM. Consult Tatua Digital Resilience Centre for guidance on integrating Tails into your investigation workflow.

Mobile devices are the primary target for advanced surveillance in the Kenyan HRD community. All surveyed Kenyan HRDs rely on mobile devices for day-to-day work under BYOD arrangements - yet technical forensic capacity for mobile triage remains critically underdeveloped. This section provides the step-by-step procedures that were absent from the original guidebook.

3.5(a) Warning Signs of Mobile Device Compromise

Investigate a mobile device when it exhibits two or more of the following indicators without an alternative explanation:

• Battery draining more than 30% per hour during idle periods (screen off, no active apps).
• Device overheating when idle, during calls, or when plugged in and not running intensive apps.
• Significantly increased background data consumption - compare to your normal monthly average in carrier settings.
• Screen activating or lighting up without any user interaction.
• On iOS 14+: the orange dot (microphone active) or green dot (camera active) appearing without user-initiated action.
• Unexplained performance degradation, freezing, or crashes on a device that was previously reliable.
• Unusual call quality issues - static, echo, or clicking - that were not previously present.
• Contacts or colleagues reporting receiving messages, calls, or files from your number that you did not send.
• Missed calls from unknown international numbers - particularly with no voicemail - that correlate with the onset of other symptoms. This is a documented Pegasus zero-click delivery vector.

3.5(b) Android Device Triage - Step-by-Step

 Follow these steps in order. Stop and document immediately if you find anything suspicious. Do not attempt to remove suspicious apps or change settings before documenting - you may destroy the evidence. Take a screenshot of every suspicious finding before taking any action.

Table 16: How to perform Android Triage

3.5(c) iOS Device Triage - Step-by-Step

 iOS provides stronger user-facing privacy controls than Android, but these controls do not protect against zero-click exploits used by commercial spyware. If sophisticated spyware is suspected, do not proceed past documentation.

3.5(e) Device Seizure - Before, During, and After

Before Entering a High-Risk Situation

• Keep your device OS fully updated - updates patch vulnerabilities exploited by forensic extraction tools including Cellebrite.
• Use a strong alphanumeric passcode (minimum 8 characters mixing letters, numbers, and symbols). A 6-digit PIN can be brute-forced by commercial tools in minutes. A strong alphanumeric passcode raises this to years.
• Enable Lockdown Mode on iPhones (Settings > Privacy & Security > Lockdown Mode) - specifically designed to block the attack vectors used by commercial forensic tools.
• Enable Advanced Data Protection on iPhone if available in your region (Settings > [Your Name] > iCloud > Advanced Data Protection) - enables end-to-end encryption for iCloud backups.
• Enable Advanced Protection on Android 16+ devices.
• Minimise sensitive data stored on the device before high-risk situations - archive sensitive documents to encrypted offline storage and delete them from the device.
• At the point of highest risk (police station, border crossing, protest environment): fully power off the device. A powered-off device is significantly harder to extract data from than a locked but powered-on device.

If Your Device Is Seized

• Immediately, from a different device: change the passwords to all accounts accessible from the seized device, including those accessed through its browsers.
• Check all accounts for unrecognised login sessions and revoke them.
• Contact your organisation's legal counsel immediately.
• Contact Defenders Coalition for guidance on the legal aspects of the seizure.
• Contact Tatua Digital Resilience Centre for efficient incident response
• Do NOT factory reset or wipe the device if you intend to use the seizure as evidence of harassment or unlawful state action - the seizure itself, and what was done to the device, is the evidence. Factory reset destroys it.

When the Device Is Returned

If the device is returned to you, seek forensic examination from a qualified professional BEFORE using the device again. Such an examination may reveal what forensic tools were used on it, what data was accessed, and whether any surveillance software was installed. This information can support legal challenges to the seizure and complaints to regulatory bodies.

Research by Citizen Lab has documented the use of Cellebrite forensic extraction technology against Kenyan activists and politicians. If your device has been seized and returned, treat it as potentially compromised until examined. Do not sign back into any accounts on the device until it has been cleared by a qualified examiner.

 3.6 Learning from Legal Outcomes

All case studies are composite and anonymised but based on documented patterns in East African digital rights cases.They illustrate the immediate consequence of correct versus incorrect procedure.

Case Study 1: The Wiped Device

Category: Evidence rejected due to poor collection practice

Maps to: section 3.5(b) Android Triage, section 3.3(a) Attachment Analysis

What Happened:

A civil society organisation in East Africa received a complaint from a staff member that their Android phone was behaving strangely - overheating and showing unusual battery drain. An IT-confident colleague offered to 'clean' the device. They uninstalled several unfamiliar apps, ran an antivirus tool, and eventually performed a factory reset when the problems continued. The device 'felt clean' afterwards.

Three weeks later, the organisation sought to file a complaint with authorities about suspected targeted surveillance. Their lawyer requested the forensic evidence from the device.

What The Court Found:

The factory reset had destroyed all forensic artefacts. No spyware samples, no network traffic logs, and no evidence of unauthorized processes remained. The complaint could not be supported with any technical evidence. The case was dropped at the preliminary stage.

What Went Wrong:

✗ The device was 'cleaned' before any forensic image was taken

✗ Apps were uninstalled before their package names were documented

✗ The factory reset destroyed all evidence permanently

✗ No SHA-256 hash was generated before any action was taken

✗ No chain-of-custody record was created

What Should Have Happened:

✓ Enable aeroplane mode immediately - no reset, no cleaning

✓ Photograph every suspicious screen before touching any settings

✓ Contact Tatua for forensic triage before taking any action

✓ A forensic image should have been taken before any remediation

✓ SHA-256 hash generated and chain-of-custody form completed

Legal Lesson:

Under Section 106B of the Kenya Evidence Act, evidence must demonstrate that it has not been altered since collection. A factory reset ensures that it cannot. There is no technical recovery from this mistake. The first 30 minutes after discovering a suspected compromise determine whether a legal case is possible at all.

Case Study 2 — Evidence Rejected: Unverified Screenshot

What Happened:

A human rights defender received a threatening message via social media. She took a screenshot and cropped it to show only the threatening text, removing the sender's profile, the platform URL, and the timestamp. She then shared the cropped screenshot via WhatsApp with her colleagues, who forwarded it further. By the time it reached the organisation's lawyer, it had been downloaded, re-uploaded, and compressed twice.

What The Court Found:

The defence challenged the screenshot on three grounds: (1) no timestamp was visible, so the date could not be verified; (2) no URL or platform was visible, so the source could not be confirmed; (3) the image had been shared multiple times and compressed, meaning its metadata was from the final save, not the original capture. The court ruled the screenshot inadmissible as it could not satisfy the authenticity requirements of Section 106B. The threatening message was excluded from the record.

What Went Wrong:

✗ The screenshot was cropped, removing the timestamp, URL, and sender identity

✗ The screenshot was shared via WhatsApp, modifying its metadata

✗ No original device retained the unmodified screenshot

✗ No SHA-256 hash was generated at the point of capture

✗ No record was kept of who took the screenshot, when, or on what device

What Should Have Happened:

✓ Full screenshot taken with timestamp, URL bar, sender name, and full message visible

✓ Screenshot stored in a secure, encrypted folder immediately

✓ SHA-256 hash generated using CyberChef at the point of capture

✓ Device used for capture identified and logged in the incident record

✓ Original file shared only via encrypted, traceable channels (Signal, secure file transfer) — never via WhatsApp

Legal Lesson:

A screenshot is only as strong as its provenance. A court needs to know: when it was taken, on what device, by whom, and whether it has been altered. Cropping, WhatsApp sharing, or any re-saving breaks that proof chain. Take complete screenshots. Hash them immediately. Store them once.

Case Study 3 — Evidence Rejected: Consent and Ethical Breach

Category: Evidence rejected due to ethical and procedural breach

Maps to: section 3.1 Step 2 — Consent Protocols

What Happened:

A digital security support organisation assisted a defender with the triage of their compromised laptop. During the investigation, the investigator accessed and photographed files on the device to document evidence of malware, including some personal documents unrelated to the investigation. The defender was distressed and had not been clearly informed of what the investigation would involve. No written consent form was completed. The investigator believed the urgency of the situation justified proceeding without formal consent.

When the case reached proceedings, the defence argued that the forensic evidence had been obtained in violation of the defender's right to privacy and without informed consent, rendering the chain of custody ethically compromised.

What the court found:

The court questioned the admissibility of the evidence on consent grounds and asked the support organisation to produce documentation showing the scope of consent given. No such documentation existed. The investigator's access to personal documents outside the scope of the investigation was noted as a breach of the Data Protection Act's data minimisation principle. The evidentiary record was significantly weakened.

What Went Wrong:

✗ No written consent form was completed before the investigation began

✗ The scope of the investigation was not explained to the defender

✗ Personal documents outside the investigation's scope were accessed

✗ The DPA data minimisation principle was violated

✗ The emotional distress of the defender was not addressed before the technical investigation began

What Should Have Happened:

✓ Establish emotional safety first (§3.1 Step 1)

✓ Explain in plain language what the investigation will involve, who will have access to the findings, and the risks of sharing them externally

✓ Obtain explicit written consent before any device access

✓ Define and document the scope: only data relevant to the incident

✓ Complete a consent form (see Appendix) before proceeding

Legal Lesson:

Forensic evidence collected without consent, or outside its consented scope, can be challenged on both ethical and legal grounds. Consent is not a formality - it is a legal protection for both the defender and the investigator. Take five minutes to do it correctly every time.

Case Study 4 — Admissibility Achieved: Correct Procedure

What Happened:

A journalist in Kenya reported to their organisation that they had received a suspicious email appearing to come from a trusted regional media partner. The email contained a link and an attached PDF. The journalist had not clicked the link or opened the attachment.

The organisation's digital safety officer followed the correct procedure:

1. TRIAGE: Emotional safety was established. The journalist was confirmed to be calm and clear on the facts. The incident was classified as a spear-phishing attempt using the journalist's real name and organisation details.
2. CONSENT: A written consent form was completed. The journalist was informed that the email header and attachment would be submitted to external analysis tools. Scope agreed: email and attachment only.
3. PASSIVE INVESTIGATION: The raw email header was extracted from Gmail and analysed via MxToolbox: SPF FAIL, DKIM FAIL, DMARC FAIL. The sending IP was traced to a server with no relationship to the claimed sender's domain. The domain had been registered three days earlier. Clear spoofing was identified.
4. SAFE ATTACHMENT ANALYSIS: A SHA-256 hash was computed via CyberChef before any other action. The hash was searched on MalwareBazaar, where a match was found — a known malware dropper used in previous targeted campaigns against East African civil society. VirusTotal confirmed: 47/70 engines detected a malicious payload.
5. DOCUMENTATION: All findings were recorded with timestamps. Full screenshots were taken, including URL bars, timestamps, and tool names. SHA-256 hashes of all screenshots were generated and stored. A chain-of-custody form was completed.
6. REPORTING: A full IOC report was submitted to KE-CIRT within 24 hours. The ODPC was notified within 72 hours, as the journalist's contact data was held in the targeted email account.

WHAT THE COURT FOUND:

When the case reached a regulatory hearing, the digital safety officer was able to produce: the original email with its header, the MxToolbox analysis report, the SHA-256 hash of the attachment matched to the MalwareBazaar record, all timestamped screenshots, the completed chain-of-custody form, and the signed consent form. The evidence was ruled fully admissible. The case demonstrated a clear targeted attack.

What Went Right:

✓ Emotional safety was established before any technical questions were asked

✓ Written consent was obtained, and the scope was defined

✓ Passive investigation only — no suspicious content was opened

✓ A SHA-256 hash was generated before any file action

✓ The hash was searched before the file was submitted, preserving confidentiality

✓ All screenshots were complete: URL, timestamp, and tool name visible

✓ Chain-of-custody was documented throughout

✓ Notifications were filed within legal timeframes