Part II — Institutionalizing Incident Management

When a digital security incident occurs - a device seized, an account compromised, data exfiltrated - the organisation's response in the first hours determines whether the incident is contained or catastrophic. But the quality of that response is not determined at the moment. It is determined weeks, months, and years before the incident occurs, by the governance decisions the organisation has already made.

Governance, in the context of this guidebook, means the structures, policies, roles, and legal obligations that shape how an organisation responds when things go wrong. It is the difference between a team that knows exactly who to call, what to preserve, and what to report - and a team that improvises under pressure, destroys evidence inadvertently, and misses a 72-hour legal reporting deadline.

The data from Kenya's own HRD community illustrates the cost of weak governance:

• 79% of Kenyan HROs have no written Incident Management Policy, meaning the majority have no agreed-upon process for responding to a breach.
• 82% rely on WhatsApp for incident reporting - a channel that creates no audit trail, produces no legally admissible records, and exposes sensitive investigation details to surveillance.
• 51% have no access to legal counsel - meaning most organisations have no route to competent legal advice when a 72-hour regulatory notification clock is running.

These are not failures of technical skill. They are governance failures — and they are fixable before the next incident occurs.

This section provides the governance foundations that connect legal obligation to forensic practice. It explains what Kenyan law requires of organisations that hold personal data and are subject to digital attacks, how to build playbooks and role assignments that enable a coordinated response, and how to use the internationally recognised NIST incident-handling lifecycle as a practical framework adapted for HRD contexts.

How governance connects to digital forensic response: Every digital forensic procedure in this guidebook - collecting evidence, generating hash values, documenting chain of custody -is designed to satisfy specific legal requirements. Understanding the governance framework first means understanding why each technical step matters and what it is protecting. Digital Forensic work done without governance awareness may be technically excellent but legally inadmissible.

Table 3: Glossary:

This section establishes the legal foundation for all incident management activities in this guidebook. Every forensic procedure, evidence collection protocol, and incident report described in this and subsequent sections are designed to satisfy the requirements of Kenyan law. Understanding these frameworks is not optional - for any organisation processing personal data in Kenya, compliance is a mandatory legal obligation.

You do not need to be a lawyer to understand what this section requires of you. In plain terms: (1) collect evidence in the right way or it cannot be used in court;

(2) report certain breaches to regulators within strict time limits or face legal penalties; and

(3) some types of digital attack are criminal offences that must be reported to the police. This section tells you which law covers each of these requirements.

The table below summarises the four primary legislative instruments governing digital security and incident management for Kenyan Human Rights Organisations:

Table 4: Legislative laws

2.1.1 Section 106B of the Kenya Evidence Act (Cap. 80) - Electronic Record Admissibility

Section 106B: The provision of the Kenya Evidence Act that sets the conditions under which electronic records - including digital photos, device logs, spyware captures, and WhatsApp threads - are admissible as evidence in Kenyan courts.

Section 106B is the keystone provision for digital forensics in Kenya. It establishes that for an electronic record to be admissible as evidence, the party presenting it must satisfy four conditions:

1. Operational Integrity - the computer or device that produced the record must have been functioning properly at the time the record was created. This means evidence collected from a device that was visibly malfunctioning, or that was processed using an untrusted or infected machine, is at risk of exclusion.

2. Proof of Non-Tampering - the contents of the record must be shown not to have been altered since they were first created. This guidebook achieves this through SHA-256 cryptographic hashing: a mathematical fingerprint generated at the moment of evidence collection that can prove, in court, that not a single byte has changed.

3. Regular Use - the record must have been produced in the regular course of the activity in question, not created after the fact.

4. Certificate of Authenticity - digital evidence typically requires a certificate signed by a responsible person in an official capacity, describing the record and the manner in which it was produced.

LEGAL REQUIREMENT | Evidence Act Cap. 80, s.106B: Any HRD or organisation seeking to use digital evidence in Kenyan legal proceedings must satisfy all four Section 106B conditions. Informal screenshots shared via WhatsApp without metadata, hash verification, or chain of custody documentation are highly likely to be ruled inadmissible.

Practical Implications for HRDs

• Take a bit-for-bit forensic image before any troubleshooting. Simple file-system copies can alter metadata timestamps and render evidence inadmissible. See Part IV for forensic imaging procedures.
• Generate and record SHA-256 hashes immediately upon collection - before any other action is taken on the evidence.
• Document every person who handles the evidence, with timestamps and signatures, using the Chain of Custody form in Appendix B.
• Capture volatile data (active network connections, running processes, open sessions) before shutting down any device - this data is lost permanently once power is removed.

Worked Example: Spyware Suspected on a Staff Member's Android Device

Situation: A programme officer notices their phone's battery draining unusually fast, the microphone indicator activating when no app is open, and unfamiliar apps appearing in settings.

Correct evidence preservation sequence:

1. Do not factory reset the phone. The instinct to "clean" the device will destroy the forensic artefacts needed to identify the spyware.
2. Photograph the phone screen with another device: capture the battery usage screen, the unfamiliar app listing, and any permissions screens.
3. Put the phone in aeroplane mode — not off — to prevent remote data deletion while preserving volatile state for forensic analysis.
4. Record the IMEI and model number from the phone's settings.
5. Contact the Tatua Digital Resilience Centre: share the photographs and the phone model. Do not attempt to remove apps or run antivirus tools until advised.
6. When forensic analysis begins, the analyst will generate a SHA-256 hash of the forensic image both before and after acquisition. Retain a copy.

Section 106B also intersects with the NIST SP 800-61r2 standard adopted in this guidebook. The 'Identification' phase of NIST maps directly to establishing the operational integrity of a device; the 'Documentation' requirements of NIST map to the certificate of authenticity requirement. Use both frameworks together - neither is sufficient alone.

2.1.2 The Data Protection Act, 2019 (DPA)

Data Controller: Under the DPA 2019, any organisation that determines the purposes and means of processing personal data. Any HRD handling victim statements, witness identities, beneficiary information, or staff personal data is a data controller and is legally bound by the Act.

The Data Protection Act 2019 transitions digital security from a voluntary practice into a mandatory legal obligation for every HRO operating in Kenya. Its most operationally significant provisions for incident management are:

Mandatory Breach Notification Timelines

LEGAL REQUIREMENT | DPA 2019, Section 43: Data controllers must notify the Office of the Data Protection Commissioner (ODPC) within 72 hours of discovering a personal data breach. If the breach poses a real risk of harm to affected individuals, those individuals must be notified within the same 72-hour window.

A breach notification to the ODPC must contain, at minimum:

•  The nature of the breach and the categories of personal data affected.
• The approximate number of individuals whose data was compromised.
• The name and contact details of the Data Protection Officer (or equivalent responsible person).
• The likely consequences of the breach for affected individuals.
• The measures the organisation has taken or proposes to take to address the breach and mitigate its effects.
• Practical advice for affected individuals on how to protect themselves (e.g., change passwords, monitor accounts).

Report a data breach at ODPC website :https://www.odpc.go.ke/report-a-data-breach/

Governance Gap - The Current Reality^[a][b]

Despite these clear legal obligations, survey data confirms a severe compliance deficit among Kenyan HROs:

What does this mean for your organisation right now? If you discovered a breach today and had to notify the ODPC within 72 hours, could you do it? Do you know what information to include? Do you have a lawyer's number to call? Do you have a record of what data you hold and who has access to it? If the answer to any of these is no, this section provides the steps to fix that before an incident forces the question.

Data Minimisation as a Protection Strategy

The DPA's data minimisation principle - collect only what is necessary, for as long as necessary - is both a legal requirement and a practical security measure. The less personal data an organisation holds, the less is at risk in any breach, and the lower the potential regulatory penalty. Organisations should conduct a data audit and implement secure deletion protocols for records no longer needed.

What This Means For You

If you discover today that personal data - even a single beneficiary's name and phone number - has been accessed without authorisation, you have 72 hours to notify the ODPC. Not 72 working hours. 72 calendar hours.

Start the clock from the moment you suspect a breach, not from the moment it is confirmed. Do not wait for certainty before notifying - the law does not require certainty, only reasonable belief. Notify early and update later.

2.1.3 Computer Misuse and Cybercrimes Act, 2018 (CMCA)

The CMCA establishes the criminal framework for digital offences in Kenya and creates the institutional infrastructure for national incident coordination.

Relevant Institutions to the Implementation of the CMCA

• National Computer and Cybercrimes Coordination Committee (NC4) - The apex policy body providing strategic oversight of Kenya's national cybersecurity response. NC4 coordinates cross-government responses to major cyber incidents affecting national security.
• National KE-CIRT/CC (Kenya Computer Incident Response Team / Coordination Centre) - The operational hub that manages 24/7 threat monitoring, coordinates sector-specific Security Operations Centres (SOCs), and serves as the primary reporting destination for significant cyber incidents.
• DCI Cybercrime Unit - The investigative body responsible for pursuing criminal prosecutions under the CMCA. Forensic evidence that satisfies Section 106B of the Evidence Act is the foundation for any prosecution brought to the DCI.

For HRDs, the CMCA is significant in three ways:

1. It defines the specific criminal offences - unauthorised access, interception of communications, deployment of malware - that your forensic evidence may be used to prosecute. Knowing the legal standard helps you collect the right type of evidence in the right way.
2. It provides a legal basis for HRDs to document and report digital threats against them - including surveillance, interception of communications, and unauthorised device access - not only as civil claims but as criminal offences.

Understanding your legal obligations is the foundation. But legal knowledge alone does not protect you - it tells you what the law requires; it does not tell you who in your organisation does what, in what order, when an incident occurs at 2 am on a Sunday. That is what an incident response playbook does.

Section 2.2 below translates the legal obligations set out in Section 2.1 into pre-assigned, step-by-step operational procedures. Playbook in Section 2.2 is designed to satisfy the legal requirements you have just read.

Incident Response Playbook: A pre-approved, role-specific, step-by-step guide that defines exactly what actions to take, in what order, and by whom, when a specific type of security incident occurs. Playbooks replace improvisation with coordination.

The most damaging characteristic of an incident is not the attack itself - it is the delay, confusion, and duplicated effort that occurs when organisations respond without a plan. Research across incident response contexts consistently finds that organisations with pre-prepared playbooks contain incidents faster, make fewer evidence-destroying mistakes, and recover more completely than those responding ad hoc.

2.2.1 Strategic vs. Technical Playbooks

Playbooks fall into two complementary categories that serve different audiences and purposes. Both are necessary - neither is sufficient alone:

Table 5: Strategic vs. Technical Playbooks

2.2.3 The Minimum Set of Playbooks Every HRD Needs

The following table defines the minimum set of playbooks that every Human Rights Organisation should maintain. Organisations should prioritise building the Foundation playbook first, then develop technical and non-technical playbooks in order of the threats most relevant to their context:

Table 6:The Minimum Set of Playbooks Every HRD Needs

2.2.3 Stakeholders to Involve in Playbook Development

A playbook built by the IT team alone will fail to account for the legal, communications, and human dimensions of a real incident. Involve these stakeholders in the development process:

• Incident Response / IT Team - define detection and response steps, tooling, and technical escalation logic.
• SJO Leadership / Executive Team - define authority thresholds for major decisions: when to go public, whether to pay a ransom, when to suspend operations.
• Legal Counsel - ensure all actions comply with DPA, CMCA, and Evidence Act obligations. Review and pre-approve regulatory notification templates.
• HR / People Team - contribute to insider threat, staff misconduct, and access revocation procedures.
• Communications / PR - prepare public statement templates and internal messaging protocols in advance.
• Regulatory Liaison - ensure alignment with KE-CIRT, ODPC, and sector regulator expectations.
• Third Parties and Vendors - clarify their roles and obligations during a supply-chain-affecting incident.

Playbooks tell you what to do during a specific type of incident. But incidents do not always arrive labelled. Sometimes you cannot be certain whether what you are seeing is an attack, a technical fault, or a false alarm.

Section 2.3 provides the overarching NIST incident handling lifecycle within which all your playbooks operate. Think of it as the container- and your playbooks as the contents. The lifecycle tells you which phase you are in; the playbook tells you what to do within that phase.

NIST SP 800-61r2: The National Institute of Standards and Technology's Computer Security Incident Handling Guide - the internationally recognised standard for structuring incident response. Adopted in this guidebook as the primary procedural framework, adapted for HRD contexts. The NIST incident handling lifecycle provides a systematic, repeatable structure for responding to security incidents. It is not a rigid checklist - it is a mental model that ensures critical phases are not skipped under pressure. For HRDs, the NIST framework has been adapted to incorporate trauma-informed approaches, legal notification obligations, and the specific threat context of Kenyan civil society.

Table 7: The Incident Response lifecycle.

2.3.1 Stage 1 - Preparation (The Most Critical Phase)

Preparation is universally acknowledged as the most critical - and most consistently neglected phase of incident response. An organisation that has never prepared cannot respond effectively. For HRDs, preparation is not a one-time activity but a continuous cycle that occurs before any incident begins.

Preparation: Operational Requirements

• Forensic Kit - a pre-assembled kit of trusted tools on sanitised, write-protected media, including: forensic imaging software, hash verification tools, encrypted storage, offline copy of key playbooks, emergency contact directory, blank chain-of-custody forms.
• Contact Directory - secure, offline list of: internal escalation contacts (by role, with backup), KE-CIRT ( ke-cirt.go.ke), ODPC (odpc.go.ke), DCI Cybercrime Unit (0800 722 203), Tatua Digital Resilience Centre, Defenders Coalition, legal counsel.
• Training and Drills - at minimum one annual tabletop exercise per year testing the most likely incident scenario for your organisation. Include non-technical staff in every drill.
• System Documentation - up-to-date network diagrams, device inventories with serial numbers and IMEI numbers, and a list of cloud accounts and data processing activities.

Preparation: Information Sharing

A vital and often overlooked preparation activity is active participation in information sharing networks. Proactively sharing Indicators of Compromise (IOCs) - malicious domains, phishing templates, file hashes - from your own threat intelligence with peer organisations provides early warning across the entire HRD community. Connect with:

• Tatua Digital Resilience Centre /Defenders Coalition - regional rapid response coordination and technical support.
• KICTANet - policy advocacy and information sharing across the Kenyan digital rights community.
• Access Now Digital Security Helpline - 24/7 international civil society incident response support.
•  Citizen Lab - forensic analysis of sophisticated spyware targeting civil society.

2.3.2 Stage 2 - Detection and Analysis

In practice, many HRD incident responses begin here - when a defender contacts a support organisation with a report of suspicious behaviour. The goal of this stage is to verify that the observed behaviour constitutes a genuine digital security incident, characterise its scope, and determine the appropriate response level.

FIRST 30 MINUTES: EVIDENCE PRESERVATION CHECKLIST
 (Complete before any remediation, troubleshooting, or device restart)

• STOP. Do not wipe, reset, uninstall, or troubleshoot the device.
• Photograph the device screen with a separate device. Include the clock, URL bar, and any visible error messages.
• Note the exact time and date you first observed the suspicious behaviour.
•  Do NOT connect the device to a charger, network, or computer until instructed.
• If the device is a laptop or desktop: do not shut it down. Capture running processes and active network connections before taking any power action.
• Secure the physical device: limit access to one named person from this point.
• Contact your designated forensic contact before taking any further action.
• Begin a handwritten or printed incident log recording: date, time, who found it, what they observed, and what they did. Sign and date each entry.

WHY THIS MATTERS: Legal consequences of skipping these steps

If you restart, wipe, or troubleshoot a device before preserving evidence, you may permanently destroy the data needed to satisfy Section 106B of the Kenya Evidence Act. Evidence that cannot satisfy s.106B cannot be used in court proceedings - the attacker goes unpunished. Do not troubleshoot first.

Evidence Gathering

Handlers must collect all available artefacts before any remediation action alters the system state. This is the evidence that will satisfy Section 106B of the Evidence Act. Collect:

• System logs (automated records of activity on a device or application) and network logs (records of data traffic into and out of a network), for example, access logs, authentication logs, firewall logs.
• Screenshots - capturing the URL bar, timestamps, and system state.
• Email headers - extracted in raw format, not just the visible display.
• Error messages - photographed or screenshotted with timestamp visible.
• Volatile data - active network connections and running processes captured before any shutdown.

Trauma-Informed Triage

For civil society contexts, the detection and analysis phase must incorporate a trauma-informed approach. Gathering information from a distressed defender can be re-victimising if handled insensitively. Key principles:

• Prioritise emotional safety before technical information gathering. Ask how the person is feeling before asking what happened.
• If the affected person is too distressed to provide accurate information, work through a trusted, less-distressed colleague as an intermediary.
• Conduct technical analysis in collective team settings where possible - this prevents individual misinterpretation and distributes the emotional weight of the investigation.

2.3.3 Stage 3 - Containment, Eradication, and Recovery

Containment - Stopping the Bleeding

Containment prioritises limiting damage above all else. This stage begins the moment an incident is confirmed. Short-term containment actions for common HRD incident types:

• Account compromise - immediately reset passwords, revoke active sessions, enforce MFA, revoke OAuth permissions.
• Device malware - disconnect from network (with caution - see logic bomb warning below), preserve volatile data first.
• Data exfiltration - identify and block the exfiltration channel; audit what data was accessible to the compromised account or device.
• DDoS - switch website to static mirror; contact Deflect or Project Galileo for DDoS mitigation.

Eradication - Removing the Threat

Eradication removes the attacker's presence from your systems and closes the vulnerabilities that allowed entry. Key actions:

• Delete all malware artefacts - malicious files, scripts, scheduled tasks, and registry entries.
• Remove backdoor accounts - audit all user accounts created or modified during the incident window.
• Conduct a full threat hunt - using all discovered IOCs (hashes, domains, IPs, email sender addresses) to confirm no persistence mechanism remains.
• Patch the exploited vulnerability - if a software flaw was used, apply the patch before restoring the system.
• Reimage if necessary - in cases of deep compromise, a complete reimage from a known-clean backup is the only reliable eradication method. Always preserve a forensic image first.

Recovery - Returning to Business as Usual

Recovery restores affected systems to service in a controlled, verified manner:

• Restore only from verified, clean backups - never from media that was connected during the incident window.
• Validate restored systems - run integrity checks and monitor for abnormal behaviour for a minimum of 72 hours post-restoration.
• Coordinate timing with leadership - do not restore to full operations during a crisis without explicit decision-maker approval.
• Train the beneficiary - because direct monitoring of a defender's personal device is not always possible, this step frequently transitions into training the defender to monitor their own device for recurrence indicators.

2.3.4 Stage 4 - Post-Incident Review (PIR)

The Post-Incident Review is the most consistently omitted phase of incident response. It is also the phase that determines whether an organisation learns from its experience or repeats the same incident. A PIR is not a blame session - it is a structured, blameless inquiry into systemic failures and systemic strengths.

Table 8: Post-Incident Review Phases

 The PIR report should be classified and stored securely - it contains a detailed account of your vulnerabilities and response weaknesses. Share only anonymised, aggregated lessons with peer networks, never the full internal report.

Filing a regulatory or criminal report is not the end of the process. Following submission to the ODPC, KE-CIRT, or the DCI Cybercrime Unit, your organisation has ongoing obligations — and ongoing recourse if authorities fail to respond. Section 2.3(e) below provides the escalation and follow-up framework for the period after your initial report is filed.

2.3.5 Escalation Matrix — When and Where to Escalate

Filing a report with the ODPC, KE-CIRT, or the DCI Cybercrime Unit begins a process - it does not end one. This section guides you through what to expect, what to document, and what to do if the system does not respond.

Mandatory Follow-Up Documentation

After filing any external report, your organisation must maintain:

• A copy of every notification submitted (ODPC, KE-CIRT, DCI), with the date and method of submission.
• Any reference numbers, acknowledgement receipts, or case numbers received.
• A log of all follow-up communications — including calls, emails, and in-person meetings — with dates and the names of officials contacted.
• A record of any responses received and the actions taken as a result.
• ESCALATION PATHWAYS (if no response within expected timelines)

ODPC — if no acknowledgement within 5 working days:

• Re-submit via the ODPC online portal,-(https://www.odpc.go.ke/report-a-data-breach/ ) noting the original submission date and reference number.
• If still no response within 14 days: escalate to KICTANet via info@kictanet.or.ke for advocacy support and formally document the delay.

KE-CIRT — if no response to a major incident report within 48 hours:

• Follow up via the KE-CIRT duty phone (+254 709 745 000) or complaints portal- https://ke-cirt.go.ke/report-an-incident/
• Copy your submission to the CA Complaints portal as a parallel record.

DCI Cybercrime Unit (0800 722 203 -toll-free)— if no response within 14 days of a criminal report:

•  Escalate to the Inspector General's office in writing.
•  Engage legal counsel to file a formal complaint regarding non-response.
• Contact the Defenders Coalition for advocacy support.- info@defenderscoalition.org

Peer Network Escalation

Where national authorities have not responded, or where the incident exceeds national response capacity, escalate to regional and international civil society networks:

• Tatua Digital Resilience Centre — first point of contact for technical support and escalation coordination.

Email:help@tatua.digital or via online portal https://helpdesk.tatua.digital/

• Access Now Digital Security Helpline — 24/7 international civil society incident response (accessnow.org/help). Email helpline:help@accessnow.org
• Citizen Lab — forensic analysis of sophisticated spyware targeting HRDs.

Email helpline:inquiries@citizenlab.ca

• Defenders Coalition — advocacy support and legal referrals within Kenya 

Email helpline:info@defenderscoalition.org

2.3.6 Accountability Pathways After an Incident

What Recourse Do HRDs Have?

Effective incident response does not end with technical remediation. For Human Rights Defenders, an attack is frequently also a rights violation - and accountability for that violation requires deliberate, structured action. The following pathways are available to Kenyan HRDs following a confirmed digital security incident:

1. Regulatory Accountability - Office of the Data Protection Commissioner (ODPC) - If a personal data breach occurred, file the mandatory notification under DPA 2019, Section 43. Beyond mandatory reporting, organisations may also file a formal complaint if the breach resulted from a third party's failure to protect data. The ODPC has powers to investigate, order remediation, and impose penalties.
2. Criminal Accountability - DCI Cybercrime Unit via CMCA 2018 - Unauthorised access, interception of communications, and deployment of spyware are criminal offences under the Computer Misuse and Cybercrimes Act 2018. Forensic evidence collected in accordance with Section 106B of the Kenya Evidence Act forms the evidentiary basis for any prosecution. Report to the DCI Cybercrime Unit with your documented evidence package. Engage legal counsel before making a report to ensure evidence is presented correctly.
3. Civil Litigation - Defenders and organisations may pursue civil claims for damages arising from a digital attack, particularly where the identity of the perpetrator can be established or where a third party's negligence enabled the breach. This route requires legal counsel and a strong evidence record.
4. International Accountability Mechanisms - Where attacks are linked to state actors or involve surveillance tools supplied to the government, defenders may submit documentation to international human rights bodies, including the UN Special Rapporteur on the situation of human rights defenders, regional mechanisms, or international civil society investigative organisations such as Citizen Lab and Access Now. Thorough forensic documentation is the foundation for any international submission.
5. Community Accountability - Information Sharing - Sharing anonymised technical indicators (IOCs) with the HRD peer network via Tatua or KICTANet is itself a form of accountability - it denies attackers the advantage of operating undetected across multiple targets and increases the collective cost of attacking civil society.

LEGAL NOTE: Accountability processes must be initiated carefully. Premature disclosure of an investigation, or sharing evidence through insecure channels, can alert an adversary, compromise a prosecution, and endanger witnesses. Always engage legal counsel before initiating any formal accountability process.

2.3.7 Organisational and Psychosocial Recovery

Post-Incident Organisational Recovery

Technical recovery is only one dimension of recovery from a significant digital incident. Organisations also need to address the human, operational, and reputational consequences of an attack.

Table 9:Post-Incident Organisational Recovery

Table 10:Unified Response Timeline Reference

Incident response depends on communication. Every phase of the NIST lifecycle — from detection through post-incident review — requires sharing sensitive information with colleagues, lawyers, regulators, and external support organisations. The channel used to share that information matters as much as the content itself.

This section provides the channel selection guidance that underpins every communication act in the lifecycle above.

2.4.1 Secure Channel Selection

The first rule of incident communication: never use the channel you suspect is compromised to discuss the compromise. All coordination regarding a suspected incident must immediately shift to a separate, trusted, out-of-band channel on a separate device.

Table 11:Secure communications for HRDs & SJOs

The following is a complete, ready-to-adapt playbook template for phishing incidents with the most frequently reported incident type among Kenyan HRDs. As a user, you are required to customise all bracketed fields for your organisation before using this in a real incident. It is advised to always review and test this playbook at least once per year.

Table 12: Sample Playbook - Phishing Response

The procedures in Part II can only function if the institutions toward which they direct HRDs are accessible, responsive, and safe to approach. For many Kenyan HRDs - particularly those working on governance, accountability, and security sector reform - this is not always the case.

This section identifies the institutional reforms that would most significantly improve digital security outcomes for Kenyan civil society, and provides advocacy reference points for HRD networks engaging with regulators.

The Current Gap

Existing reporting mechanisms - KE-CIRT, the ODPC, and the DCI Cybercrime Unit - were designed for corporate and government entities, not civil society. HRDs face specific challenges that these mechanisms do not address:

• Lack of confidential intake: HRDs may be unable to report to authorities whose principals are the subject of the attack.
• Slow response cycles: Reporting timelines designed for large institutions do not account for the rapid escalation of threats facing individual defenders.
• No dedicated triage: No mechanism exists to prioritise reports from HRDs at acute physical or operational risk.

Proposed Reforms

1. KE-CIRT HRD Desk - Establish a dedicated reporting channel within KE-CIRT for civil society organisations, with guaranteed 24-hour triage and a confidential intake protocol. Model: the EU's ENISA SME/CSO advisory unit.

2. ODPC Civil Society Liaison - Designate a civil society liaison officer within the ODPC to provide pre-breach compliance support and expedited breach assessment for HROs.

3. Legal Aid Integration - Establish a referral pathway between Tatua/Defenders Coalition and pro bono legal counsel for HRDs who need to respond to a breach within the 72-hour DPA window without retained legal counsel.

4. Anonymised Threat Intelligence Sharing - Create a formal mechanism for KE-CIRT to share anonymised threat intelligence with civil society networks - and for civil society networks to submit indicators of compromise (IOCs) for integration into the national threat picture.

Comparable Models

• Czech Republic: CZ.NIC's national CSIRT provides a dedicated support track for civil society and media organisations.
• Canada: CSE's Cyber Centre maintains a dedicated NGO advisory programme.
• Global: Access Now's Digital Security Helpline provides 24/7 HRD-specific incident response across more than 200 countries.

HRD networks are encouraged to reference these proposals in engagements with KE-CIRT, the CA, and the ODPC. KICTANet can provide policy advocacy support for organisations wishing to advance these reforms through formal channels.