GAZETTE NOTICE NO. 12835

IN EXERCISE OF THE MANDATE OF THE COMMISSION ON REVENUE ALLOCATION COMMISSION ON REVENUE ALLOCATION STANDARDS AND GUIDELINES ON THE INTEGRATED COUNTY REVENUE MANAGEMENT SYSTEM (ICRMS) Preface The Commission on Revenue Allocation (CRA) issues this Integrated County Revenue Management System (ICRMS) Standards and Guidelines pursuant to Article 216 (1) (c) of the Constitution of Kenya, 2010, which mandates the Commission to recommend measures concerning the financing and financial management of County Governments. In exercising this mandate, and in accordance with Article 216 (2), the Commission seeks to promote and give effect to the criteria set out in Article 203 (1) (e); to define and enhance, where appropriate, the revenue sources of both the National and County Governments; and to encourage fiscal responsibility in the management of public resources. The purpose of these Standards and Guidelines is to establish a uniform, secure, interoperable, and accountable framework for the design, procurement, deployment, operation, and oversight of Integrated County Revenue Management Systems (ICRMS) across all 47 County Governments. It responds to systemic challenges in Own Source Revenue (OSR) mobilization, including fragmented systems, weak integration, poor auditability and lack of standardization. These Standards and Guidelines supersedes any other guidelines issued in regard to revenue management systems and shall serve as reference for all National Government agencies, County Governments, service providers and intergovernmental institutions. 1. Introduction and Executive Summary 1.1. The Commission on Revenue Allocation (CRA), in consultation with the National Treasury, Council of Governors (CoG), Office of the Auditor-General (OAG), Office of the Controller of Budget (CoB), ICT Authority (ICTA), and County Governments, hereby issues the Integrated County Revenue Management System (ICRMS) Standards and Guidelines. 1.2. These Standards and Guidelines establishes a national framework to standardise the management of Own Source Revenue (OSR) through the implementation of integrated, secure and interoperable revenue systems within and across all County Governments. 1.3. The ICRMS aims to: 1. Enhance OSR mobilisation and support financial autonomy of counties; 2. Standardize own source revenue collection and management across all county governments 3. Promote transparency, accountability, and efficiency in revenue collection and reporting; 4. Ensure interoperability with national financial and regulatory systems; 5. Standardise functional and technical capabilities across counties; 6. Strengthen data governance, auditability, and compliance. 12:13 PM THE KENYA GAZETTE 9th September, 2025 6152 6152 1.4. These Standards and Guidelines s are issued under the constitutional and statutory mandate of the CRA and shall apply to all National Government agencies , County Governments, service providers, and intergovernmental institutions involved in the development, procurement, deployment, or support of revenue management systems. 1.5. The document further outlines the minimum requirements for: 1. Functional capabilities (Annex 1); 2. Technical specifications (Annex 2); 3. Procurement, compliance, and audit tools (Annexes 3–4); 4. Operational frameworks including risk management, data migration, change management, and reporting (Annexes 5–12). 1.6. The adoption of these Guidelines will enhance consistency, interoperability, security, and data governance across counties, thereby promoting equitable and prudent management of public resources. 2. Problem Statement and Rationale 2.1. Despite constitutional empowerment under Article 209(3) to collect property rates, entertainment taxes, and service charges, many counties continue to underperform in OSR collection due to: 1. Fragmented and manual revenue systems; 2. Limited automation and functional coverage; 3. Poor integration with national databases (e.g. IPRS, BRS, IFMIS); 4. Non-standard procurement practices leading to vendor lock-in; 5. Inadequate audit trails and data security; 6. Resistance to digital adoption; 7. Weak institutional capacity in ICT and revenue automation. 8. Inadequate assurance of data migration during vendor transitions: 2.2. These challenges result in: 1. Revenue leakages and reduced fiscal sustainability; 2. Inconsistent reporting standards, limiting the comparability and reliability of financial data across counties and over time. 3. Compromised service delivery, as unpredictable or declining revenues constrain budget execution and public investment. 4. Weakened oversight by PFM institutions due to fragmented or unreliable revenue data 5. Increased exposure to fraud, abuse, and system manipulation, particularly where audit trails, access controls, and transaction logs are inadequate. 6. Ineffective transition between administrations, with incoming county leadership unable to access or trust inherited digital systems, records, or service contracts. 2.3. Unified Standards and Guidelines framework is therefore necessary to ensure consistency, interoperability, compliance, and long-term sustainability of county revenue systems. 3. Legal and Institutional Framework 3.1. Constitutional Basis These Standards and Guidelines is anchored in the Constitution of Kenya, 2010, which provides the foundation for county revenue management and fiscal responsibility. The relevant provisions include: 1. Article 6(2): Recognition of County Governments as distinct and interdependent units of governance that must conduct their mutual relations on the basis of consultation and co-operation. 2. Article 201: Public finance principles, which require that revenue raising and expenditure be guided by openness, accountability, equity, and prudent use of public resources. 3. Article 203(1)(e and i): In determining the equitable share of national revenue, one of the criteria is the need to provide incentives for each County to optimize its capacity to raise revenue. This underscores the constitutional basis for strengthening County Own Source Revenue (OSR) through integrated systems such as the ICRMS. 4. Article 209(3): Authority of County Governments to impose property rates, entertainment taxes, and charges for services they provide, subject to national legislation. 5. Article 216(2)(c): Mandate of the Commission on Revenue Allocation (CRA) to recommend measures concerning the financing and financial management of County Governments. 6. Article 216(2)(b) and (c): In exercising this mandate, the CRA is required to define and enhance revenue sources of both the National and County Governments, and to encourage fiscal responsibility. This directly supports the adoption of standardized, technology-driven revenue management systems. 3.2. Legislative Framework The Standards and Guidelines is operationalised under the following statutes: 1. Public Finance Management (PFM) Act, 2012: Sections 12(e), 125, 133, and Part VI–VII on financial systems, revenue collection, and oversight. 2. County Governments Act, 2012: Sections 104 and 115 on transparent financial management and public participation. 9th September, 2025 THE KENYA GAZETTE 3. Public Procurement and Asset Disposal Act (PPADA), 2015: Ensures competitive, transparent procurement of ICT systems. 4. Data Protection Act, 2019: Governs lawful processing, storage, and protection of personal and financial data. 5. Intergovernmental Relations Act, 2012: Facilitates co-ordination between national and county governments. 4. Standards and Guidelines Objectives 4.1. General Objective To establish a standardised, secure, and interoperable revenue management framework that enhances Own Source Revenue mobilisation, ensures prudent public financial management, and upholds the principles of equity, transparency, and accountability. 4.2. Specific Objectives 1. Standardise functional and technical specifications for ICRMS across all counties. 2. Improve OSR performance through automation, reconciliation, and enforcement. 3. Ensure compliance with the Constitution, PFM Act, PPADA Act, and Data Protection Act. 4. Enable seamless integration with IFMIS, SCOA, IPRS, KRA, BRS, NTSA, and GIS systems. 5. Safeguard data integrity, confidentiality, and availability. 6. Strengthen transparency and auditability through digital logs and reporting. 7. Build institutional capacity for sustainable system management. 8. Promote shared services and joint procurement to reduce costs. 9. Preserve county autonomy in system administration and revenue decision-making. 10. Promote fiscal prudence, reduce leakages, and support equitable development. 5. Scope and Application 5.1. Institutional Scope These Standards and Guidelines applies to: 1. All 47 County Governments 2. National government agencies 3. Intergovernmental bodies 4. Private sector vendors, contractors, and service providers. 5. Development partners supporting digital revenue reforms. 5.2. Functional Scope The Standards and Guidelines covers the full lifecycle of ICRMS, including: 1. Planning, budgeting, and needs assessment; 2. Procurement and contracting; 3. System development, acquisition, or customisation; 4. Deployment, data migration, and integration; 5. Operation, maintenance, and user management; 6. Audit, reporting, and continuous improvement. 6. Guiding Principles All ICRMS implementations shall adhere to the following principles: 1. Constitutionalism and Rule of Law: Compliance with the Constitution and all applicable laws and legislations . 2. Accessibility to all: Equal access to revenue services for all ratepayers, including marginalised groups . 3. Accountability and Transparency: Full traceability of transactions and decisions. 4. Data Integrity and Protection: Compliance with the Data Protection Act, 2019. 5. Interoperability and Standardisation: Use of open APIs and national standards. 6. County Autonomy: Counties retain administrative control over local system functions. 7. Collaboration: Encouragement of shared infrastructure and joint initiatives. 8. Accessibility: Systems must be accessible via web, mobile, and USSD, and compliant with disability standards. 9. Efficiency: Systems must minimise costs and maximise revenue collection. 7. Roles and Responsibilities The successful implementation and sustainability of the Integrated County Revenue Management System (ICRMS) requires coordinated participation by County Governments, constitutional commissions, and national institutions. The following roles and responsibilities shall guide execution, oversight, and compliance. 12:13 PM THE KENYA GAZETTE 9th September, 2025 6154 6154 7.1. County Governments SHALL: 1. Have full operational and administrative control over its local instance of the Integrated County Revenue Management System (ICRMS), including user management, system configuration, and workflow customisation for its revenue processes. 2. Be responsible for the day-to-day operation and management of the system, including data entry, transaction monitoring, user support, and system maintenance at the county level. 3. Provide and maintain the last-mile ICT infrastructure necessary to support system functionality within its jurisdiction, including connectivity, power backup, equipment, and related support services. 4. Ensure full compliance with the Public Finance Management Act, 2012, and any other applicable law governing financial management, including the timely generation and submission of revenue performance reports to relevant institutions. 5. Ensure that all bank accounts receiving county revenue are integrated with the ICRMS to enable real-time reconciliation, transparency, and effective monitoring of revenue inflows. 6. Establish a Project Implementation Unit (PIU) or Technical Working Group to oversee system implementation at the county level. 7. Coordinate and Conduct training and build internal technical capacity at the county level. 8. The County to establish a monitoring and evaluation Unit to ensure the ICMRS efficiency. 9. Submit quarterly system compliance and performance reports to the PFM institutions. 10. Conduct periodic internal audits of the ICRMS, including audit trail verification, system usage controls, and reconciliation processes, in line with the internal audit framework established under the PFM Act and county legislation. 7.2. Commission on Revenue Allocation (CRA) SHALL: 1. Serve as the Standards and Guidelines custodian of the Integrated County Revenue Management System (ICRMS), providing strategic guidance, technical advice, and intergovernmental co-ordination, in accordance with Article 216(2), 216(3)(a) and (b), and Article 203(1)(e) and (i) of the Constitution. 2. Develop and periodically review the Standards and Guidelines governing the implementation, functionality, and reporting requirements of ICRMS. 3. Provide technical support to County Governments and relevant institutions on matters related to ICRMS deployment, integration, and continuous improvement. 4. Analyze Own Source Revenue (OSR) performance reports generated from ICRMS platforms and issue advisory notes to the County Governments ,PFM Institutions, , and intergovernmental bodies. 5. Undertake independent assessments to evaluate the performance, effectiveness, and operational efficiency of ICRMS platforms deployed across counties, and recommend corrective or enhancement measures as necessary. 7.3. National Treasury 1. Develop and gazette regulations to guide the implementation, standardization, and oversight of Integrated County Revenue Management Systems (ICRMS), in accordance with its mandate under the Public Finance Management Act, 2012. 2. Coordinate the design, development, and implementation of a centralized ICRMS platform for County Governments, ensuring functional completeness, scalability, and alignment with these standard and guidelines on ICRMS 3. Bear the cost of core system development and infrastructure for ICRMS platform, including licensing, hosting, and national-level support components 4. Oversee the integration of ICRMS with national financial and identity systems, including IFMIS, Standard Chart of Accounts (SCOA), Business Registration Service (BRS), Integrated Population Registration System (IPRS), and any other relevant government platforms. 5. Initiate and operationalize intergovernmental framework agreements with participating County Governments to govern the deployment, financing, ownership, and operational responsibilities for shared ICRMS platforms 7.4. Ministry of ICT and the Digital Economy 1. Verify system compliance with the Kenya Government Enterprise Architecture (KGEA) and the Kenya National Interoperability Framework (KNIF), as developed and issued under the Ministry’s mandate for ICT standards and infrastructure co-ordination. 2. Conduct cybersecurity assessments of ICRMS platforms to ensure conformance with national cybersecurity standards, including data protection, access controls, and system resilience requirements. 7.5. Office of the Controller of Budget (CoB) 1. Exercise oversight over the implementation of County Government budgets in accordance with Article 228(4) and (6) of the Constitution and Section 9 of the Controller of Budget Act, 2016, with specific reference to Own Source Revenue (OSR) collection and reporting through the Integrated County Revenue Management System (ICRMS). 2. Have secure, read-only access to ICRMS-generated revenue reports approved by the County Executive Committee Member responsible for Finance, for the purpose of monitoring revenue performance, verifying budget execution, and advising on fund releases. 3. Analyze ICRMS data to assess whether actual revenue collection aligns with budget projections, and to identify any shortfalls, variances, or inconsistencies that may affect budget implementation and fiscal planning. 4. Prepare and submit quarterly and annual reports to Parliament and County Assemblies on the status of budget implementation across counties, incorporating findings derived from ICRMS revenue data. 9th September, 2025 THE KENYA GAZETTE 7.6. Office of the Auditor-General (OAG) 1. Access and audit the Integrated County Revenue Management System (ICRMS) in all County Governments to verify that revenue collected, receipted, reported, and managed through the system complies with the Public Finance Management Act, 2012, and related regulations. 2. Undertake regular financial, compliance, and performance audits of ICRMS platforms pursuant to Article 229 of the Constitution and the Public Audit Act, 2015. 3. Assess the adequacy of internal controls, system configurations, audit trails, and reconciliation mechanisms embedded within the ICRMS, to determine whether the system safeguards revenue integrity and accountability. 4. Issue statutory audit reports and management letters detailing findings, risks, and recommendations for corrective action, and submit such reports to County Assemblies, Parliament, CRA, CoB, and other oversight bodies as required. 5. Follow up on the implementation of audit recommendations by County Governments or national implementing agencies, and track remedial measures to close audit queries, enhance controls, and prevent recurrence of identified weaknesses. 8. Technical and Functional Standards 8.1. Technical Standards (See Annex 2) All ICRMS must meet minimum technical requirements in: 8.1.1. Architecture, hardware, software, security, integration, disaster recovery, and data governance. 8.2. Functional Standards (See Annex 1) All ICRMS must include: Revenue registration, assessment and billing, payment processing, debt management, reporting, self-service portals, alerts, and audit trails. 9. Governance, Ownership and Administration The Integrated County Revenue Management System (ICRMS) shall operate as a unified, centrally coordinated platform, developed and maintained under the leadership of the National Treasury and adopted by all 47 County Governments through formal intergovernmental arrangements. This governance framework shall be guided by the principles of intergovernmental co-operation, fiscal accountability, and mutual administrative responsibility, as envisaged under Article 6(2) of the Constitution, the Intergovernmental Relations Act, 2012, and section 12(e) of the Public Finance Management Act, 2012. 9.1. Centralized Governance and Custodianship 9.1.1 The National Treasury shall serve as the lead implementing agency and system custodian, responsible for the development, hosting, integration, and core administration of the ICRMS platform. It shall also coordinate linkages with national systems such as IFMIS, SCOA, BRS, and IPRS, and oversee technical service providers. 9.2 Intergovernmental Framework Agreement 9.2.1 County Governments will adopt the system through an Intergovernmental Framework Agreements with the National Treasury to be agreed upon by the parties. 9.3 System Ownership and Administrative Rights 9.3.1 Ownership of the ICRMS platform, including core infrastructure and vendor contracts, shall vest in the National Treasury. 9.3.2 Each County Government shall retain exclusive operational administrative rights over its local instance, including user management, system configuration, data access, and revenue reporting. 9.4 Standards and guidelines Compliance 9.4.1 The ICRMS platform shall fully comply with all provisions of these Standards and Guidelines, including the functional requirements outlined in Annex 1, technical standards in Annex 2, and service-level provisions in Annex 6. 9.4.2 No deviation from these standards shall be permitted unless formally reviewed and approved through the governance structure established herein. 9.5 Joint Governance and Oversight Mechanism 9.5.1 A Joint Governance Committee shall be established, co-chaired by the National Treasury and the Council of Governors, with representation from CRA, ICTA, CoB, OAG, and County Governments. 9.5.2 The Committee shall oversee policy decisions, system upgrades, vendor performance, and provide strategic guidance on the ongoing development of ICRMS. 9.6 Data Sovereignty and Security 9.6.1 Each County Government shall retain full ownership and custodianship of its own revenue data and any other party shall only access the data after approval from the county government. 9.6.2 The platform shall comply with the Data Protection Act, 2019, and applicable national cybersecurity standards. 9.7 Local User Administration and Support 9.7.1 County Governments shall establish internal administrative structures to manage user roles, provide frontline support, and escalate system issues. 9.7.2 The National Treasury shall operate a national helpdesk and coordinate change management, capacity building, and periodic training for county users 10. Procurement, Development and Deployment The procurement, development, and deployment of the ICRMS shall be governed by the following provisions: 12:13 PM THE KENYA GAZETTE 9th September, 2025 6156 6156 10.1. The National Treasury shall be the lead implementing agency and shall undertake the procurement, design, customisation, and national- level deployment of the ICRMS in accordance with the Public Procurement and Asset Disposal Act, 2015, the Public Finance Management Act, 2012, and applicable ICT standards. 10.2. The ICRMS platform shall be acquired or developed as a shared system, with modular capabilities that allow county-level configuration, autonomy in operations, and independent access to reporting and user management tools. 10.3. County Governments shall adopt the platform by entering into a formal Intergovernmental Framework Agreement with the National Treasury, detailing governance, roles, financial obligations (where applicable), data rights, and service-level expectations. 10.4. The procurement of third-party components, hosting, and core infrastructure shall be managed centrally by the National Treasury, including vendor contracting, software licensing, support services, and integration with national systems such as IFMIS, SCOA, BRS, and IPRS. 10.5. County Governments shall be responsible for financing and executing their respective local deployment activities, including hardware provisioning, staff training, onboarding, change management, and localised support infrastructure. 10.6. All components of the system including development, configuration, and rollout must conform to the functional specifications (Annex 1), technical standards (Annex 2), and SLA requirements (Annex 6) set out in these Standards and Guidelines . No customisation or divergence from the approved architecture shall be permitted outside the provisions of the agreed governance framework. 10.7. All contracts and implementation arrangements shall include explicit provisions for data protection, source code escrow, knowledge transfer, and system sustainability to ensure long-term performance and institutional ownership. 10.8. Counties and National Treasury shall develop and approve a Change Management Plan (Annex 9) prior to go-live, addressing stakeholder engagement, process redesign, and resistance mitigation. 10.9. All development must follow open standards and avoid vendor lock-in. 11. Implementation Framework The process will entail preparation by the multi-agency, acquisition of the ICRMS by the National treasury, Commissioning and system implementation. 11.1. Co-ordination Mechanisms Effective co-ordination of the ICRMS platform shall be ensured through structured multi-level committees and technical units that promote intergovernmental collaboration, operational oversight, and accountability. The following co-ordination mechanisms shall be established: 11.1.1 National ICRMS Committees The governance of the centralized Integrated County Revenue Management System (ICRMS) shall be anchored in two interlinked committees: the National ICRMS Steering Committee and the National ICRMS Technical Committee. Both shall be co-chaired by the National Treasury and the Commission on Revenue Allocation (CRA), with representation from the Council of Governors (CoG), the Office of the Controller of Budget (CoB), the Office of the Auditor-General (OAG), the ICT Authority (ICTA), and selected County Executive Committee (CEC) Members for Finance. Committee Membership Mandate Key Responsibilities National ICRMS Steering Committee - Co-Chairs: National Treasury and CRA - Members: CoG, CoB, OAG, ICTA, selected CECs Finance Strategic and policy- level oversight of the centralized ICRMS 1. Provide strategic leadership and direction for ICRMS implementation. 2. Approve major policy directives, system enhancements, and rollout schedules. 3. Resolve policy-level disputes and foster intergovernmental consensus. 4. Endorse intergovernmental framework agreements and service level arrangements. 5. Guide sustainability, compliance, and accountability in line with the Constitution and PFM Act, 2012. National ICRMS Technical Committee - Co-Chairs: National Treasury and CRA (technical representatives) - Members: ICTA, CoG technical reps, County ICT Directors, system vendors (as needed) Technical and operational oversight in support of the Steering Committee 1. Coordinate system design, configuration, and integration with IFMIS, SCOA, BRS, IPRS. 2. Develop and enforce technical and functional standards. 3. Evaluate system changes, upgrades, and vendor deliverables. 4. Monitor performance, manage incidents, and track KPIs. 5. Support capacity building, training, and technical support. 6. Advise the Steering Committee on risks, innovations, and emerging issues. 11.1.1. County ICRMS Committees 11.1.2. Each County Government shall establish a County ICRMS Committee, chaired by the CEC Member for Finance, with membership from ICT, internal audit, legal, revenue, and planning departments. 11.1.3. The committee shall oversee local deployment, ensure cross-departmental co-ordination, approve system customisations, and escalate policy issues to the national level. 11.1.4. Project Implementation Units (PIUs) 11.1.5. Dedicated Project Implementation Units shall be established at both national and county levels: 9th September, 2025 THE KENYA GAZETTE 11.1.5.1. The National PIU, domiciled at the National Treasury, shall coordinate vendor engagement, configuration, helpdesk services, national training, integration testing, and release management. 11.1.5.2. Each County PIU shall coordinate local infrastructure setup, user training, change management, and day-to-day liaison with the National PIU during rollout and support phases 11.2. Financing and Cost-Sharing Framework The Integrated County Revenue Management System (ICRMS) shall be centrally developed and coordinated by the National Treasury. The financing structure shall be guided by the Public Finance Management Act, 2012, and uphold the principles of sustainability, transparency, and value for money. 11.3.1 The National Treasury shall finance the core platform development, infrastructure, licensing, hosting, and national-level support services. 11.3.2 Each County Government shall budget for its respective local deployment costs, including equipment, internet connectivity, training, onboarding, and change management. 11.3.3 Cost-sharing obligations, where applicable, shall be defined and agreed upon in the Intergovernmental Framework Agreement signed between the National Treasury and County Governments. 11.3.4 All financial commitments shall be reflected in approved budgets and implemented in accordance with the Public Finance Management Act, 2012. 11.3. Risk Management 1. Counties shall adopt the Risk Management Framework (Annex 5) to identify, assess, mitigate, and monitor risks. 2. Key risks: Prolonged System breakdown, Data loss, vendor lock-in, user resistance, privacy breaches. 11.4. Data Migration 11.4.1. All data migration shall follow the Data Migration and Cutover Plan (Annex 8) to ensure accuracy, integrity, and minimal disruption. 12. Monitoring, Evaluation and Compliance 12.1. Purpose To ensure accountability, continuous improvement, and compliance with Standards and Guidelines. 12.2. Monitoring and Evaluation Principles 1. Accuracy: Data must be factual and verifiable. 2. Timeliness: Reports submitted on schedule. 3. Transparency: Findings accessible to authorised stakeholders. 4. Consistency: Standardised formats across counties. 5. Actionability: Findings used for corrective action. 12.3. Monitoring Framework A robust monitoring mechanism shall be instituted to ensure the proper functioning, compliance, and continual enhancement of the centralized ICRMS platform. Responsibilities are delineated as follows: 12.3.1 Continuous System Monitoring The County, in collaboration with the National Treasury, shall conduct daily system checks to ensure real-time system integrity, data accuracy, uptime, and incident management. 12.3.2 Strategic Compliance Reporting The County shall submit quarterly compliance reports using the Risk and Compliance Reporting Template (Annex 5) to CRA, National Treasury, and other oversight agencies. 12.3.3 Annual System Audits The Office of the Auditor-General (OAG), in conjunction with County Internal Audit departments, shall conduct annual audits of ICRMS to evaluate system controls, financial accuracy, legal compliance, and data governance. 12.3.4 Performance Assessment by CRA In alignment with its constitutional mandate under Article 216(2) (to advise on financial management), the Commission on Revenue Allocation (CRA) shall periodically assess the efficacy and efficiency of ICRMS deployment and usage across counties 12.3.5 Targeted Compliance Audits Periodic compliance audits shall utilize the standardised Compliance Audit Checklist (Annex 4) to evaluate alignment with functional requirements, technical standards, data governance, and service-level commitments. 12.4. Key Performance Indicators (KPIs) The performance of the ICRMS shall be monitored and evaluated using the following minimum Key Performance Indicators (KPIs). These indicators shall guide service-level agreements (SLAs), compliance audits, and overall system performance assessments. 12.4.1 System Uptime The system shall maintain a minimum uptime of 99.5% on a monthly basis, excluding scheduled maintenance windows. 12:13 PM THE KENYA GAZETTE 9th September, 2025 6158 6158 12.4.2 Integration Compliance The system shall comply with all mandatory integration requirements, including seamless interoperability with IFMIS, SCOA, BRS, IPRS, and other designated national platforms. 12.4.3 Customer Ledger Auto-Reconciliations All transactions processed by the system shall automatically post to the customer and transaction ledgers, with no manual interventions required, ensuring reconciliation accuracy and auditability. 12.4.4 User Satisfaction Index User feedback shall be periodically measured through structured surveys, with a minimum target satisfaction index of 80% across system usability, responsiveness, and support services. 12.4.5 Security Incidents The system shall maintain zero tolerance for unresolved critical security incidents, with all reported incidents addressed within defined SLA timelines, and continuous monitoring for vulnerabilities. 12.4.6 Reporting Capability The system shall demonstrate the ability to generate all mandatory statutory, financial, audit, and management reports in real-time or near real-time, in accordance with formats prescribed in these Guidelines. 12.4.7 Transaction Processing Capacity The system shall process a minimum of 2,000,000 transactions per second (TPS), ensuring scalability to handle peak demand across all 47 counties without performance degradation 12.5. Compliance Enforcement 12.5.1 Notice and Corrective Action In the event of material non-compliance with these Standards and Guidelines by a County Government or the National Treasury: 12.5.2 The Commission, in co-ordination with the National Treasury and Council of Governors shall issue a formal Compliance Notice, specifying the breach and a mandatory 90-day remediation period. 12.5.3 The entity in breach shall submit a written Remedial Plan, monitored by CRA, to restore compliance within the allotted timeframe. 12.5.4 Escalation for Continued Non-Compliance If the breach persists or is recurrent: 12.5.4.1 CRA shall escalate the matter to the Intergovernmental Budget and Economic Council (IBEC) as per procedures in the Intergovernmental Relations Act. 12.5.4.2 Access to support or updates may be temporarily suspended for non-compliant counties, subject to agreed terms. 12.5.5 Dispute Resolution 12.5.5.1 Dispute resolutions shall be conducted as per the intergovernmental relations Act 12.5.6 Documentation and Transparency 12.5.6.1 All compliance actions, resolutions, and outcomes shall be documented and shared with relevant oversight bodies. 12.5.6.2 CRA may publish anonymized compliance summaries to promote transparency and peer accountability 13. Review, Amendment and Effective Date 13.1. These Standards and Guidelines shall be reviewed every three (3) years by the Commission on Revenue Allocation in consultation with the relevant stakeholders. 13.2. An early review may be triggered by: 1. Major legal or constitutional changes; 2. Technological advancements; 3. Persistent non-compliance or systemic failures. 13.3. The review process shall include: 1. Stakeholder consultations; 2. Technical validation; 13.4. Revised guidelines shall be gazetted as a statutory notice. 13.5. These Standards and Guidelines takes effect immediately upon gazettement. 14. Annexes Note: All annexes are binding and form an integral part of these Standards and Guidelines . GIVEN under the Hand of the Chairperson, Commission on Revenue Allocation, this 8th day of September, 2025. CPA MARY WANYONYI CHEBUKATI, Chairperson, Commission on Revenue Allocation. 9th September, 2025 THE KENYA GAZETTE ANNEXES INTEGRATED COUNTY REVENUE MANAGEMENT SYSTEM (ICRMS) STANDARDS AND GUIDELINES Annex No. Title Annex 1: Minimum Functional Requirements Checklist for the ICRMS Annex 2: Minimum Technical Requirements Checklist for the ICRMS Annex 3: Procurement and Compliance Evaluation Matrix Annex 4: Compliance Audit Tool for the ICRMS Annex 5: Risk Management Framework for the ICRMS Annex 6: Sample Service Level Agreement (SLA) for the ICRMS Annex 7: Stakeholder Consultation Record Annex 8: Data Migration and Cutover Plan Annex 9: Change Management and Training Plan Annex 10: Standard Reports Catalogue Annex 11: Data and Records Governance Annex 12: Glossary and Acronyms (i) Annex 1: Minimum Functional Requirements Checklist for the ICRMS Section 1: Purpose This annex specifies the minimum functional requirements for the Integrated County Revenue Management System (ICRMS) to ensure that deployments are compliant, interoperable, and support the complete revenue lifecycle from source registration to reporting and audit. Section 2: Scope These requirements apply to all ICRMS deployments, whether county-specific or part of a national centralized system, and must be adhered to in procurement, development, implementation, commissioning, and operation. Functional Requirements Ref No. Functional Area Requirement Description Priority Test Procedure Evidence Required FR.1 Registry and Identity Management Maintain a central register of taxpayers/ratepayers/businesses with National ID, KRA PIN, and BRS Number; support many-to- many relationships (entity↔revenue streams, parcels, accounts) and scale to ≥1M records. M Create/update/search sample records; merge duplicates; run API query. Screenshots; search logs; API spec. FR.2 Registry and Identity Management Link a single entity to multiple revenue streams (land rates, SBP, parking, market fees, etc.). M Link ≥3 streams to one taxpayer; generate consolidated account. Consolidated account report. FR.3 Registry and Identity Management Store and retrieve supporting documents (ID, licences, plans) against each profile. M Upload and retrieve documents for sample record. Document logs. FR.4 Registry and Identity Management Detect and flag duplicate accounts for review; merge with audit trail. M Create duplicate entries; system flags; merge. Duplicate detection report. FR.5 Registry and Identity Management Maintain full history of all interactions (applications, inspections, bills, payments, licences). M Open sample record; review history. History log export. FR.6 Registry and Identity Management Maintain individual customer/ratepayer ledgers showing all transactions, running balances, and aging, in addition to system journals. M View sample ledger; verify accuracy against transactions. Ledger report. FR.7 Registry and Identity Management Maintain full transaction ledgers for each revenue stream with SCOA coding. M Generate stream ledger report; verify SCOA mapping. Transaction ledger export. FR.8 Registry and Identity Management Search registry by multiple criteria (name, ID, PIN, location, status). M Run multi-criteria search; verify results. Search results screenshot. FR.9 Registry and Identity Management Bulk import/export registry data (CSV/Excel) with validation. M Import test file; review validation logs. Import/export logs. FR.10 Revenue Source and Tariff Management Configure revenue streams as per Finance Act, Tariff and Pricing Policy, or Schedules. M Load tariff schedule; check application. Tariff configuration logs. FR.11 Revenue Source and Tariff Management Add new revenue streams without vendor intervention; set tariffs, SCOA codes, and parameters. M Create a new stream; generate bill. Stream creation log. 12:13 PM THE KENYA GAZETTE 9th September, 2025 6160 6160 Ref No. Functional Area Requirement Description Priority Test Procedure Evidence Required FR.12 Revenue Source and Tariff Management Rule-based engine to compute fees, penalties, interest; maintain version history with effective/expiry dates, reason codes, and audit trail of changes. M Configure 10+ tariffs; simulate bulk changes; show version history. Config guide; change log. FR.13 Revenue Source and Tariff Management Upload multiple tariffs in bulk from Finance Bill or Tariff Policy, including zone-based rates. M Import bulk tariff file; verify in system. Import log; tariff list. FR.14 Revenue Source and Tariff Management Map all revenue items to Standard Chart of Accounts codes; enforce mapping before billing. M Attempt unmapped billing; system blocks. SCOA mapping report. FR.15 Revenue Source and Tariff Management Maintain register of county-owned assets tied to revenue streams (markets, buildings, equipment). M Add asset; link to revenue stream. Asset register export. FR.16 Revenue Source and Tariff Management Geo-reference revenue sources for spatial planning and enforcement; support shapefiles/GeoJSON import, layer-based queries, and spatial analytics. S Map sample sources; view on GIS layer. GIS map screenshot; integration doc. FR.17 Revenue Source and Tariff Management Configure billing frequencies per stream (daily, monthly, annually, seasonal). M Change billing cycle; generate bills. Billing config logs. FR.18 Revenue Source and Tariff Management Apply penalties/interest automatically; approve waivers/exemptions with thresholds, reason codes, and document attachments; enforce maker-checker. M Process penalty and waiver; check audit trail. Waiver workflow log. FR.19 Revenue Source and Tariff Management Categorize streams (by ward, market, category) and set revenue targets. S Assign targets; run performance report. Target allocation file. FR.20 Applications, Billing, Payments, Receipting End-to-end workflow from application → inspection → billing → payment → licence/permit. M Apply for service; follow to licence issue. Workflow screenshots. FR.21 Applications, Billing, Payments, Receipting Customizable checklists for each service; enforce before billing. M Configure checklist; submit application. Checklist config export. FR.22 Applications, Billing, Payments, Receipting Auto-flag accounts for renewal; send reminders via SMS/email/USSD. M Simulate renewal period; send reminder. Reminder logs. FR.23 Applications, Billing, Payments, Receipting Accept payments via mobile money, EFT, cards, USSD, agency banking; support offline queueing with sync; handle reversals/chargebacks. M Process payments via each channel; simulate offline sync. Payment logs. FR.24 Applications, Billing, Payments, Receipting Issue receipts instantly; send confirmation to payer. M Complete payment; check confirmation. Receipt copy; SMS/email log. FR.25 Applications, Billing, Payments, Receipting Match daily collections with bank/wallet statements (T+1); maintain exception worklists and closure SLAs (≤1% unresolved after T+3). M Import bank file; auto-match; review exceptions. Reconciliation report. FR.26 Applications, Billing, Payments, Receipting Process refunds and reversals with approval workflow and audit trail. M Initiate reversal; check logs. Reversal log. FR.27 Applications, Billing, Payments, Receipting Support partial payments, overpayments (credit wallets), and split payments. S Test each case; verify balances. Payment allocation report. FR.28 Applications, Billing, Payments, Receipting Generate invoices (PDF + e-bill); unique payment refs; mass billing; re-billing with traceability; batch ≥100k invoices in <30 mins. M Run batch test; verify lineage. Batch report; runbook. FR.29 Debt Management and Enforcement Generate aging reports (30/60/90/180+ days), by stream/ward. M Produce report for sample data. Aging report. FR.30 Debt Management and Enforcement Create installment plans; monitor compliance. M Set plan; test missed payment alert. Payment plan report. FR.31 Debt Management and Enforcement Automated reminders (SMS/email/app), dunning workflow with escalation. M Trigger reminders; check logs. Reminder logs. FR.32 Debt Management and Enforcement Case management; field assignment; GPS/time- stamped actions; outcome tracking; ≥90% cases geo-stamped. S Issue e-ticket; inspect GPS logs. Enforcement logs; field app demo. FR.33 Debt Management and Enforcement Restrict repeat offenders; allow policy-based exemptions. S Add/remove from list; verify block. Blacklist log. FR.34 User, Collector and Agent Management Register revenue staff; assign roles per organogram. M Add staff; assign role. Staff registry export. 9th September, 2025 THE KENYA GAZETTE Ref No. Functional Area Requirement Description Priority Test Procedure Evidence Required FR.35 User, Collector and Agent Management Assign collectors to sources/targets; monitor performance. M Allocate targets; review report. Target assignment log. FR.36 User, Collector and Agent Management Register/manage external collection agents; assign roles and targets. S Add agent; set target; check report. Agent assignment log. FR.37 User, Collector and Agent Management Real-time staff/agent performance metrics. S Display live dashboard. Dashboard screenshot. FR.38 Self-Service and Access Channels Allow taxpayers to access accounts, bills, payments, receipts, applications, support tickets; OTP login; WCAG accessibility compliance. M Log in; complete payment; verify accessibility. Portal transaction log; test scripts. FR.39 Self-Service and Access Channels Enable low-bandwidth access via USSD for key services. S Dial USSD; complete task. USSD session log. FR.40 Self-Service and Access Channels Provide officer app (assess, inspect, enforce) and taxpayer app (pay, view, renew); offline-first with sync conflict handling. S Demo apps; test offline sync. App demos; device policy. FR.41 Self-Service and Access Channels Ensure compliance with accessibility standards; multilingual support (EN/SWA). S Switch language; view accessibility tools. Accessibility settings log. FR.42 Configuration, Period Close and Reporting Update rates, cycles, penalties without coding changes; support multi-language and geo parameters (wards, streams, holidays). M Change rate; apply in bill. Config change log. FR.43 Configuration, Period Close and Reporting Perform daily ledger posting, reconciliation, and reporting with system lock; support authorised re- opens. M Run EoD; attempt back- dated entry. EoD report; lock log. FR.44 Configuration, Period Close and Reporting Period lock, roll forward balances, age debt, generate monthly reports. M Run EoM; check ledgers/reports. EoM reports. FR.45 Configuration, Period Close and Reporting Close fiscal year, carry forward arrears/balances, archive year-specific parameters and tariffs. M Run EoY; verify opening balances. EoY close report. FR.46 Configuration, Period Close and Reporting Generate statutory, management, and ad-hoc reports (≥30 standard reports); ad-hoc builder; export CSV/XLSX/JSON. M Run sample reports; export. Report catalogue; samples. FR.47 Configuration, Period Close and Reporting Produce SCOA-coded exports compatible with IFMIS. M Export sample; import to IFMIS test. Export file; IFMIS log. FR.48 Configuration, Period Close and Reporting Generate maps and spatial reports for mapped revenue sources. S Run GIS query. GIS map screenshot. FR.49 Configuration, Period Close and Reporting Produce logs of all sensitive actions/configuration changes; tamper-evident hash; role-based retrieval; retain ≥7 years. M Generate audit report; verify hash. Audit log export. FR.50 Configuration, Period Close and Reporting Provide REST/JSON APIs (OAuth2/OpenID), webhooks, API throttling and versioning; API uptime ≥99%, p95 latency ≤2s. M Review API docs; run test calls. API documentation; monitoring screenshots. (ii) Annex 2: Minimum Technical Requirements Checklist for the ICRMS Section 1: Purpose This annex outlines the minimum technical specifications and compliance requirements for the ICRMS to ensure security, scalability, interoperability, and operational performance across county governments. Section 2: Scope Applies to all ICRMS implementations, whether developed in-house, procured commercially, or provided as part of a centralized national platform, and must be adhered to during procurement, implementation, commissioning, and operation. Technical Requirements Table Ref No. Technical Area Requirement Description Priority Test Procedure Evidence Required TR.1 System Architecture and Hosting Adopt modular/service-oriented or microservices architecture; include stateless APIs and message queue for asynchronous jobs; support independent upgrades; scale to ≥200% projected volumes over 5 years; define auto-scaling thresholds. M Review architecture diagrams; simulate load test. Architecture doc; load test results. TR.2 System Architecture and Hosting Support on-premises, GoK-approved data center, compliant local cloud, or hybrid; conduct security and Total Cost of Ownership (TCO) assessment for chosen deployment. M Inspect hosting setup; review assessment. Hosting certificate; TCO/security report. TR.3 System Architecture and Hosting For centralized deployments: provide logical data segregation, per-county encryption keys, and per- M Inspect multi-tenancy config; run segregation Multi-tenancy config report. 12:13 PM THE KENYA GAZETTE 9th September, 2025 6162 6162 Ref No. Technical Area Requirement Description Priority Test Procedure Evidence Required tenant admin roles. tests. TR.4 System Architecture and Hosting Achieve ≥99.5% uptime per quarter; include failover mechanisms and load balancing. M Review monitoring logs; conduct failover test. Uptime report; failover log. TR.5 System Architecture and Hosting Provide separate dev, test, training, and production environments; enable controlled promotion of configurations. M Inspect environment structure. Environment config report. TR.6 Infrastructure Use enterprise-grade redundant infrastructure; NVMe/SAN storage for DB; TLS termination at load balancer. M Inspect hardware specs; test TLS. Infra inventory; TLS config log. TR.7 Infrastructure On-premises setups to have UPS, generator backup, controlled access, CCTV, and environmental monitoring. M Inspect facilities; review monitoring. Facility inspection report. TR.8 Infrastructure Automated, encrypted backups (daily full + hourly incrementals); quarterly restore tests. M Review backup config; perform restore. Backup log; restore report. TR.9 Software Stack and Development Practices Use supported Long-Term Support (LTS) operating systems; relational database with ACID compliance; implement read replicas for analytics workloads. M Review OS/DB versions; verify replica configuration. OS/DB version list; replica status report. TR.10 Software Stack and Development Practices Implement CI/CD pipeline; perform SAST(Static Application Security Testing) and DAST(Dynamic Application Security Testing); maintain artifact repository; adopt Infrastructure as Code (IaC). M Review DevSecOps configuration; check automated test reports. CI/CD configuration docs; SAST/DAST reports. TR.11 Software Stack and Development Practices Maintain centralized logging (ELK or equivalent), performance metrics, and APM traces; define and configure alert thresholds. M Inspect logging setup; trigger alerts to validate thresholds. Logging configuration; sample alert records. TR.12 Software Stack and Development Practices Ensure compliance with Government Enterprise Architecture (GEA), Government Interoperability Framework (GIF), and OWASP ASVS(Open Web Application Security Project / Application Security Verification Standard.) M Review compliance checklist and test results. Compliance certification or signed checklist. TR.13 Integration and Interoperability Provide secure APIs/files for two-way integration with IFMIS; enforce Standard Chart of Accounts (SCOA) mapping on all transactions. M Generate SCOA-coded export; perform IFMIS import in test environment. SCOA export file; IFMIS import log; mapping validation. TR.14 Integration and Interoperability Integrate with IPRS, BRS, NTSA, HMIS, and GIS platforms; use REST/JSON APIs with OAuth2/OpenID; apply mutual TLS (mTLS) for sensitive transactions. M Conduct API test calls; inspect secure connection configurations. API test logs; API documentation; connection configs. TR.15 Integration and Interoperability Support integration with bank host-to-host, ISO 20022/8583 messaging where applicable, and mobile money APIs; ensure automated reconciliation. M Process test transactions across all financial rails; validate reconciliation outputs. Payment logs; reconciliation reports; integration certificates. TR.16 Integration and Interoperability Provide documented, version-controlled APIs; enforce versioning (e.g., /v1); apply rate limits; ensure ≥99% API uptime and p95 latency ≤2s. M Inspect API documentation; run uptime and latency tests. API monitoring reports; API portal screenshots. TR.17 Integration and Interoperability Provide sandbox credentials, Swagger/OpenAPI docs, sample payloads, error catalog, and integration test cases for all mandatory integrations. M Review artefact package; run sample integration tests. Artefact inventory; integration test logs. TR.18 Security and Privacy Implement RBAC and ABAC to enforce least- privilege, segregation of duties, and maker-checker controls. M Review role/attribute matrix; simulate access; verify maker-checker. Role/attribute config; access logs. TR.19 Security and Privacy Require MFA for privileged/admin accounts; support SSO(Single Sign-On) using SAML (Security Assertion Markup Language) and OIDC (OpenID Connect) M Attempt admin login to verify MFA; test SSO login. MFA screenshots; SSO setup logs. TR.20 Security and Privacy Encrypt data in transit (TLS 1.2+) and at rest (AES- 256); rotate keys regularly. M Inspect encryption configuration; review key rotation logs. Security config; key rotation schedule. TR.21 Security and Privacy Conduct quarterly vulnerability scans and annual penetration tests; remediate critical vulnerabilities ≤30 days; high ≤60 days. M Review scan results and pen test reports; confirm remediation timelines. Scan reports; pen test; remediation logs. TR.22 Security and Privacy Conduct DPIA(Data Protection Impact Assessment) for all modules; implement consent/notice M Inspect DPIA docs; test consent capture in DPIA reports; consent logs. 9th September, 2025 THE KENYA GAZETTE Ref No. Technical Area Requirement Description Priority Test Procedure Evidence Required mechanisms; embed privacy-by-design. workflows. TR.23 Security and Privacy Maintain registry of authorized devices; enforce session timeouts and concurrent login limits; provide remote wipe. M Simulate lost device and perform remote wipe; review session logs. Device registry; remote wipe report. TR.24 Security and Privacy Enable anti-tamper protections; log and alert on suspicious activities/config changes. M Attempt unauthorized alteration; review tamper logs. Tamper protection config; tamper log export. TR.25 Performance and Resilience Process at least 1,200 transactions per second (TPS) across all channels during peak. S Perform load testing with simulated peak volumes. Load test results; benchmark report. TR.26 Performance and Resilience Complete key transactions (billing, payment posting, receipting) within ≤2 seconds under normal load. M Time transactions during testing; verify thresholds. Transaction timing logs. TR.27 Performance and Resilience Provide offline operation for core functions (billing, receipting, enforcement) with secure store-and- forward synchronization. M Simulate offline activity and sync; confirm data integrity. Offline transaction logs; sync report. TR.28 Performance and Resilience Make GIS layers accessible offline on enforcement devices; synchronize updates when online. S Load and navigate offline GIS map; sync updates. Offline GIS logs; sync confirmation. TR.29 E-Enforcement and Field Operations Integrate with mobile/POS devices for issuing enforcement notices, tickets, penalties with GPS/time-stamping. M Issue test e-ticket via device; verify GPS/time stamp. Enforcement case log; GPS data report. TR.30 E-Enforcement and Field Operations Capture photographic, video, and document evidence linked to case records. M Upload test evidence to a case file; confirm linkage. Case file with media. TR.31 E-Enforcement and Field Operations Provide configurable workflows for enforcement actions, assignment, escalation, and SLA tracking. M Execute sample workflow; verify SLA alerts. Workflow config; SLA log. TR.32 E-Enforcement and Field Operations Enable export/API integration with external judicial systems for escalation to court or recovery agencies. S Export sample enforcement case; verify data receipt. Export log; receiving system confirmation. TR.33 Disaster Recovery and Business Continuity Maintain in-country DR site with Recovery Point Objective(RPO) ≤15 minutes and Recovery Time Objective (RTO)≤2 hours. M Review DR architecture; conduct failover test. DR documentation; failover logs. TR.34 Disaster Recovery and Business Continuity Conduct bi-annual DR drills; document failover/fallback with success criteria. M Execute DR drill; review results. DR drill report; recovery metrics. TR.35 Disaster Recovery and Business Continuity Maintain BCP with manual fallback procedures, communication tree, and stakeholder notification templates. M Review BCP; simulate communication process. Approved BCP; simulation report. TR.36 Disaster Recovery and Business Continuity Automated daily full backups and hourly incrementals; quarterly restore tests. M Inspect backup logs; perform test restoration. Backup logs; restore verification. TR.37 Disaster Recovery and Business Continuity Automatic failover for critical services; quarterly failover tests. M Simulate outage and trigger failover; measure downtime. Failover test results; monitoring logs. TR.38 Reporting and Analytics Reporting engine with ≥30 standard reports and ad- hoc builder; export to PDF, CSV, XLSX, JSON. M Generate sample reports; test exports. Report catalogue; files. TR.39 Reporting and Analytics Configurable real-time dashboards showing revenue performance, targets, arrears, trends; data matches reports. M Compare dashboard metrics to reports. Dashboard screenshots; comparison logs. TR.40 Reporting and Analytics Forecasting tools to project revenue trends and arrears recovery based on historical data. S Run forecast analysis on test data; verify model accuracy. Forecast report; analytics configuration. TR.41 Configuration and Extensibility Allow rates, penalties, waivers, workflows, and forms via parameters; audit configuration changes. M Update parameters; verify change logs. Config change log; settings. TR.42 Configuration and Extensibility Support English and Kiswahili interfaces and multiple currency formats. S Switch language; test currency display. Language/currency settings logs. TR.43 Configuration and Extensibility Add new revenue streams with tariffs, SCOA codes, workflows, and reporting templates without vendor intervention. M Add new stream in test; verify. Stream creation log; billing test. 12:13 PM THE KENYA GAZETTE 9th September, 2025 6164 6164 Ref No. Technical Area Requirement Description Priority Test Procedure Evidence Required TR.44 Data Management Implement validation rules to prevent incomplete/invalid data; enforce mandatory fields. M Attempt to save invalid data; review errors. Validation error log; config. TR.45 Data Management Provide migration tools including mapping, cleansing, trial loads, and reconciliation. M Perform trial migration; reconcile data. Migration plan; reconciliation report. TR.46 Data Management Archive inactive records per retention; purge only after multi-level authorisation and audit logging. M Archive and purge samples in test. Archive/purge logs; authorizations. TR.47 Documentation and Handover Deliver system design dossier, data model and dictionary, API docs, configuration runbooks, SOPs, admin/user manuals, test reports, training materials, and an escrow package (source code, build scripts). M Review documentation set for completeness and compliance. Documentation inventory; escrow confirmation. (iii) Annex 3: Procurement and Compliance Evaluation Matrix Section 1: Purpose To provide a standard evaluation matrix for uniform, transparent, and objective assessment of ICRMS proposals during procurement, commissioning, and compliance reviews. Section 2: Scope Applies to Procurement Evaluation Committees, Commissioning Teams, and Oversight/Audit Teams. Procurement and Compliance Evaluation Matrix Table Evaluation Area Criteria Linked FR/TR Weight (%) Scoring Method Preliminary Evaluation Submission of mandatory documents (bid security, tax compliance, signed forms, eligibility requirements). N/A Pass/Fail All must be provided to proceed. Functional Requirements Compliance Meets all Mandatory FR items in Annex 1. FR.1–FR.50 25% Pass/Fail for mandatory; optional scored proportionally (0–1 per item). Functional Requirements Compliance Meets Optional/Should Have FR items. FR.16, FR.19, FR.27, FR.30, FR.31, FR.33, FR.35, FR.39, FR.40, FR.42, FR.48 5% Weighted score by optional items implemented. Technical Requirements Compliance Meets all Mandatory TR items in Annex 2. TR.1–TR.47 (Mandatory) 25% Pass/Fail for mandatory; points for exceeding minimum specs. Technical Requirements Compliance Meets Optional/Should Have TR items. TR.25, TR.28, TR.32, TR.40, TR.42 5% Weighted score by optional items implemented. Integration and Interoperability Successful integration with IFMIS, SCOA, IPRS, BRS, GIS, HMIS, NTSA, payment channels. FR.14, FR.47, TR.13–TR.17 5% Live/sandbox test evidence; error- free transactions. Security and Compliance Meets security, privacy, and data protection requirements; passes vulnerability and penetration testing. TR.18–TR.24, TR.20–TR.22 5% Review audit logs, security reports, test results. Performance and Resilience Meets throughput, uptime, offline capability, DR/BCP benchmarks. TR.1, TR.4, TR.25– TR.28, TR.33–TR.37 5% Load tests, DR drill reports, offline simulation. Implementation Approach and Plan Methodology, migration plan, training, change management, post-go-live support. TR.45, TR.47, FR.42–FR.45 10% Review project plan, timelines, resource allocation. Vendor Experience and Capacity ICRMS deployments in ≥3 counties; references; local technical team. N/A 5% Reference checks, team CVs. Total Cost of Ownership (TCO) 5-year TCO including licences, hosting, maintenance, upgrades, training. N/A 5% Evaluate detailed cost breakdown. Risk and Exit Strategy Data portability, escrow, exit/migration plan, SLA commitments. TR.47, FR.11, FR.49 5% Review SLA, escrow agreement, exit plan. (iv) Annex 4: Compliance Audit Tool for the ICRMS Section 1: Purpose Structured compliance checklist for commissioning, post-implementation, annual audits, and spot checks. Section 2: Scope Applicable to all County Governments and National Implementing Agencies operating the ICRMS; used by Internal Audit, CRA, National Treasury, Auditor-General, and QA consultants. 9th September, 2025 THE KENYA GAZETTE Compliance Audit Checklist Table Ref No. Audit Area Compliance Standard Linked FR/TR Test Procedure Evidence Required Compliance Rating* Remediation Actions A4.1 Registry and Identity Management Central registry linked to National ID, KRA PIN, BRS; supports many-to-many relationships; ≥1M record capacity. FR.1 Inspect registry; search and link records; run API query. Screenshots; API logs. A4.2 Registry and Identity Management Customer and transaction ledgers with SCOA coding in place. FR.6, FR.7 View ledgers; verify SCOA mapping. Ledger reports; SCOA export. A4.3 Revenue Source and Tariff Management All streams configured per Finance Act/Tariff Policy; version history maintained. FR.10, FR.12 Compare system tariffs to legal schedule; review change logs. Tariff config logs. A4.4 Revenue Source and Tariff Management SCOA mapping enforced for all billable items. FR.14, TR.13 Attempt unmapped billing; confirm block. SCOA mapping report. A4.5 Applications, Billing, Payments Batch billing capacity (≥100k in <30 mins) met; re-billing maintains lineage. FR.28 Run batch; review logs. Batch run logs. A4.6 Applications, Billing, Payments All mandatory payment channels active; offline queue and sync functional; reversals tracked. FR.23, TR.27 Process payments; simulate offline mode. Payment logs. A4.7 Applications, Billing, Payments Receipts issued instantly; confirmation sent to payer. FR.24 Complete payment; verify receipt/SMS. Receipt copy; SMS log. A4.8 Applications, Billing, Payments Daily T+1 reconciliation; ≤1% unresolved after T+3. FR.25 Inspect recon reports; check closure rates. Reconciliation logs. A4.9 Debt Management and Enforcement Aging reports generated; dunning workflow active. FR.29, FR.31 Run arrears report; check reminders. Aging report; reminder log. A4.10 Debt Management and Enforcement GPS/time-stamped enforcement actions logged; ≥90% geo-stamped. FR.32, TR.29 Issue e-ticket; verify GPS logs. Enforcement logs. A4.11 Debt Management and Enforcement Evidence capture linked to case files. TR.30 Upload sample evidence to case; confirm. Case file with media. A4.12 Security and Privacy Roles and attributes correctly configured; maker-checker in place. TR.18 Review role matrix; simulate access. Role config report. A4.13 Security and Privacy MFA enforced for privileged accounts; TLS 1.2+/AES-256 encryption active. TR.19, TR.20 Test MFA; inspect encryption setup. MFA logs; encryption config. A4.14 Security and Privacy Quarterly scans; annual pen test; critical vulns fixed ≤30 days. TR.21 Review reports; confirm remediation dates. Security reports. A4.15 Security and Privacy DPIAs completed; consent capture mechanisms functional. TR.22 Inspect DPIA; test consent prompts. DPIA docs; consent logs. A4.16 Performance and Resilience ≥1,200 TPS at peak; ≤2s transaction response time. TR.25, TR.26 Run performance test; measure response. Load test reports. A4.17 Performance and Resilience Offline billing, receipting, enforcement operational; sync works. TR.27 Simulate offline ops; sync data. Offline logs. A4.18 Disaster Recovery and BCP DR site operational; RPO ≤15m; RTO ≤2h; 2 drills/year. TR.33, TR.34 Inspect DR site; review drill reports. DR drill report. A4.19 Disaster Recovery and BCP Daily full + hourly incremental backups; quarterly restores successful. TR.36 Check backup jobs; perform restore. Backup and restore logs. A4.20 Disaster Recovery and BCP Automatic failover tested quarterly; meets uptime SLA. TR.37 Simulate outage; verify failover. Failover logs. A4.21 Reporting and ≥30 standard reports; ad-hoc builder; all export formats FR.46, Generate reports; test Report catalogue. 12:13 PM THE KENYA GAZETTE 9th September, 2025 6166 6166 Ref No. Audit Area Compliance Standard Linked FR/TR Test Procedure Evidence Required Compliance Rating* Remediation Actions Analytics functional. TR.38 exports. A4.22 Reporting and Analytics Real-time dashboards match report data. TR.39 Compare dashboard vs. reports. Dashboard screenshot; comparison log. A4.23 Configuration and Extensibility Rates, penalties, waivers, workflows updated via parameters; changes logged. TR.41 Update config; review change logs. Config logs. 4.24 Configuration and Extensibility New streams added without vendor; fully functional. TR.43 Create new stream; test billing and reporting. Stream creation log. A4.25 Documentation and Handover All required documentation and escrow package delivered. TR.47 Inspect documentation inventory. Documentation list; escrow confirmation. (v) Annex 5: Risk Management Framework for the ICRMS Section 1: Purpose Establish a standard approach for identifying, assessing, mitigating, and monitoring risks during the lifecycle of the ICRMS. Section 2: Scope Applies to county ICRMS operations, national central deployments, and third-party service providers. ICRMS Risk Register and Management Matrix Risk ID Risk Category Risk Description Potential Impact Likelihood (L/M/H) Impact Severity (L/M/H) Risk Owner Mitigation Measu res Contingency / Response Plan Key Risk Indicator (KRI) R1 Technical – Infrastructure System downtime due to hardware failure or hosting outage. Revenue loss; public dissatisfaction. M H ICT Unit / Vendor Redundant infrastructure; HA design; monitoring. Activate DR site; failover within RTO ≤2h. Uptime %; MTTR. R2 Technical – Application Bugs/defects disrupt billing, payments, reconciliation. Delayed collections; inaccurate data. M H ICT Unit / Vendor QA/UAT before updates; DevSecOps pipeline with rollback. Revert to last stable version; patch within SLA. Defect density; time to patch. R3 Security Data breach or unauthorised access to taxpayer data. Legal penalties; reputational damage. M H ICT/Security Officer Role-based access control (RBAC) and attribute-based access control (ABAC); MFA; encryption; security audits. Incident response; notify regulators and affected parties. Security incidents; failed logins. R4 Integration Failure of integration with IFMIS, SCOA, payment channels, or registries. Delayed reporting; revenue posting errors. M H ICT/Finance/Ven dor Integration testing; API monitoring; SLAs. Manual upload; escalate to partner. API success rate; recon variance. R5 Data Management Loss/corruption of financial records. Loss of accountability; compliance breach. L H ICT/Vendor Encrypted backups; quarterly restore tests. Restore from backup; forensic analysis. Backup success rate; restore success. R6 Operational – Collection Fraudulent collection/diversion by staff/agents. Revenue leakage; legal action. M H Revenue Dept / Internal Audit Cashless collections; recon controls; monitoring. Suspend accounts; initiate audit. Collector performance variance. R7 Operational – Enforcement Delay/failure in enforcement due to technical/logistical issues. Drop in compliance; revenue shortfall. M M Enforcement/ICT E-enforcement devices; SLA monitoring. Escalate cases; manual logs. Enforcement completion rate. R8 Change Management User resistance to system/process changes. Low adoption; parallel manual processes. M M HR/Change Lead Training; sensitisation; support channels. Coaching; leadership escalation. Adoption rate; helpdesk tickets. R9 Regulatory Non-compliance with Data Protection, PFM, procurement laws. Fines; legal sanctions; halted operations. L H Legal/Compliance Compliance reviews; legal vetting. Suspend risky processes; remediate. Audit findings count. 9th September, 2025 THE KENYA GAZETTE R10 Business Continuity Disaster (fire, flood, cyberattack) disrupts operations. Extended downtime; loss of revenue. L H ICT/DR Lead DR site; BCP drills; environmental controls. Activate BCP; failover to DR. BCP drill success; recovery time. R11 Vendor Management Vendor insolvency/disputes/ poor performance. Delays; loss of support. M M Procurement/ICT/ Legal SLAs; escrow for source; alternate vendor readiness. Activate escrow; alternate vendor. SLA breach rate. R12 GIS and Field Ops Inaccurate GIS mapping or field data capture failures. Poor targeting; incomplete asset register. M M GIS/ICT GPS audits; offline GIS maps; training. Manual validation; re-map. % verified GIS assets. (vi) Annex 6: Sample Service Level Agreement (SLA) for the ICRMS Section 1: Purpose Defines performance standards, responsibilities, and remedies for the provision, operation, and support of the ICRMS by the Vendor to the Client. Section 2: Scope of Services Hosting and infrastructure (if applicable); application maintenance; integration maintenance; security management; DR/BCP; helpdesk and incident management; training and documentation updates. Section 3: Performance Metrics Service Area Metric Target Linked FR/TR System Availability Uptime per quarter ≥99.5% TR.4 Incident Response Acknowledge Priority 1 (Critical) incidents ≤15 minutes TR.18, TR.19 Incident Resolution Restore service (Critical) ≤2 hours workaround; ≤8 hours full fix TR.18, TR.19 Reconciliation Accuracy Daily reconciliation completion 100% T+1; ≤1% unresolved after T+3 FR.25 Integration Availability Success rate for mandatory integrations ≥99% TR.13–TR.17 Security Compliance Vulnerability remediation Critical ≤30 days; High ≤60 days TR.21 Backup and Restore Quarterly restore test success rate 100% TR.36 DR Drill Success Meet RPO/RTO targets RPO ≤15m; RTO ≤2h TR.33, TR.34 Training Delivery Completion of agreed training plan 100% attendance and evaluation TR.47 Documentation Updates Updated within 5 working days after change TR.47 Section 4: Priority Levels and Resolution Targets Priority Definition Response Time Resolution Target P1 – Critical Complete outage; core revenue functions unavailable. ≤15 min Workaround ≤2 hrs; Full fix ≤8 hrs P2 – High Major function degraded; workaround available. ≤30 min Full fix ≤24 hrs P3 – Medium Minor function affected; low business impact. ≤2 hrs Full fix ≤5 days P4 – Low Cosmetic/UI issue; no business impact. ≤4 hrs Fix in next planned release Section 5: Reporting and Review Monthly service performance reports; quarterly review meetings for SLA performance and continuous improvement. Section 6: Penalties and Service Credits Breach Penalty / Service Credit Uptime below 99.5% 5% of monthly service fee per 0.5% shortfall Missed Critical issue resolution time 10% of monthly service fee per incident Missed DR RPO/RTO targets 15% of monthly service fee per failed test Failure to remediate critical vulnerability in time 10% of monthly service fee per breach 12:13 PM THE KENYA GAZETTE 9th September, 2025 6168 6168 Cumulative penalties in a quarter shall not exceed 25% of the quarterly service fee. Persistent non-compliance may trigger contract termination. Section 7: Escalation Path 1. Service Desk / Helpdesk Officer 2. Vendor Support Manager 3. Vendor CTO / Senior Management 4. Client ICRMS Steering Committee Section 8: Change Management All system changes must be approved by the Client and tested in a staging environment before production deployment. Section 9: Termination and Exit Management Upon termination, Vendor shall provide latest system backup in open format, updated documentation, transfer of source code/configurations (as per contract), and knowledge transfer to Client or replacement vendor. (vii) Annex 7: Stakeholder Consultation Record Section 1: Purpose This annex documents the stakeholder engagement process undertaken in the formulation of the Integrated County Revenue Management System (ICRMS) Standards and Guidelines, in compliance with Article 10 and Article 232 of the Constitution of Kenya and applicable public participation laws. Section 2: Scope The consultation record covers identification of relevant stakeholders, engagement methods used, key issues raised, and how they were addressed in the final Guidelines. Section 3: Stakeholder Groups Consulted 1. National Government Agencies: The National Treasury and Economic Planning; Ministry of ICT and Digital Economy; Ministry of ICT; Office of the Controller of Budget; Office of the Auditor-General; Commission on Revenue Allocation 2. County Governments: County Executive Committees for Finance and ICT; County Treasuries; County Assemblies’ Finance Committees; County Revenue Boards/Directorates 3. Intergovernmental Bodies: Council of Governors (CoG); Intergovernmental Budget and Economic Council (IBEC) 4. Development Partners and Civil Society: World Bank; UNDP; GIZ; USAID; civil society organisations advocating for transparency and good governance 5. Private Sector: ICRMS solution providers and integrators; banking and payment service providers; telecommunications companies 6. General Public: Taxpayers; business associations; resident associations; traders Section 4: Consultation Record Table Date Stakeholder Group Organisation / Representative Mode of Engagement Key Issues Raised How Addressed in Final Guidelines Evidence / Reference Section 5: Supporting Evidence Checklist [ ] Stakeholders notices and invitations issued [ ] Draft guidelines circulated for comment [ ] Attendance registers for all meetings [ ] Minutes and recordings of consultations [ ] Written submissions from stakeholders [ ] Feedback matrix linking comments to guideline changes (viii) Annex 8: Data Migration and Cutover Plan Section 1: Purpose This annex provides a structured framework to ensure safe, accurate, and efficient migration of data from legacy revenue management systems and/or manual records into the ICRMS, with minimal disruption to service delivery and no loss of data integrity. 9th September, 2025 THE KENYA GAZETTE Section 2: Scope Applies to all County Governments and National Implementing Agencies deploying ICRMS, including migration from legacy systems (e.g., LAIFOMS and earlier RMS), transition from manual registers, and consolidation of multiple systems into ICRMS. Section 3: Migration Principles 1. Accuracy: Migrated data must match verified source data exactly. 2. Completeness: All relevant historical and current records must be migrated. 3. Integrity: Relationships between records (e.g., customer-ledger-transactions) must be preserved. 4. Compliance: Data must comply with SCOA coding, Data Protection Act, and statutory retention rules. 5. Auditability: Every migration step must be logged and documented. 6. Minimal Downtime: Cutover must be planned to avoid prolonged service interruptions. Section 4: Migration Phases and Activities Phase Activity Description Linked FR/TR Deliverable Pre-Migration Assessment Data Inventory Identify all existing data sources and repositories. TR.45 Data inventory report Pre-Migration Assessment Data Mapping Map each data element from source to ICRMS target field, ensuring SCOA mapping. FR.14; TR.13 Data mapping matrix Pre-Migration Assessment Data Cleansing Remove duplicates, fix inconsistencies, complete missing data. FR.4; TR.44 Cleansed dataset Pre-Migration Assessment Migration Tool Setup Configure vendor-supplied migration utilities and scripts. TR.45 Tool setup log Pre-Migration Assessment Migration Plan Approval Secure sign-off for migration scope, schedule, and responsibilities. TR.47 Approved migration plan Trial Migration Trial Load Perform migration in a test/staging environment. TR.45 Trial migration logs Trial Migration Reconciliation Compare trial migrated data to source records; verify ledgers and balances. FR.6; FR.7 Reconciliation report Trial Migration User Verification Departmental review and sign-off of trial data. FR.1–FR.3 User sign-off forms Cutover Preparation Freeze Changes Halt non-critical changes to source data during migration window. TR.5 Change freeze notice Cutover Preparation Final Backup Take full backup of source systems pre- migration. TR.36 Backup confirmation log Cutover Preparation Communication Notify stakeholders of cutover date, downtime, and contingency plan. TR.35 Communication plan Final Migration and Go- Live Final Load Load final dataset into production ICRMS. TR.45 Final migration log Final Migration and Go- Live Validation Run validation checks and sample reports post-load. FR.43–FR.47 Validation checklist Final Migration and Go- Live Cutover Execution Switch operations to ICRMS and decommission legacy entry points. TR.35 Cutover report Post-Go-Live Support Hypercare Period Provide dedicated vendor/on-site support for defined period. TR.47 Support logs Post-Go-Live Support Parallel Reconciliation Compare ICRMS vs legacy data for a defined period. FR.25 Reconciliation reports Post-Go-Live Support Final Sign-off Formal acceptance of migrated data. TR.47 Acceptance certificate Section 5: Roles and Responsibilities Role Responsibility County ICT Unit Co-ordinate migration; validate technical tools; manage backups and environments. County Finance/Revenue Dept Validate SCOA mappings; verify ledger and transaction accuracy. Vendor Migration Team Provide migration tools; execute migration and cutover; resolve issues. Data Protection Officer Ensure compliance with privacy laws during migration. Project Manager Oversee migration timeline, scope, and resources. Audit/QA Team Independently verify migration quality and compliance. Commission on Revenue Allocation Offer Technical Capacity Assistance 12:13 PM THE KENYA GAZETTE 9th September, 2025 6170 6170 Section 6: Key Risks and Mitigation Risk Potential Impact Mitigation Data loss during migration Missing or incomplete records Multiple backups; trial runs; reconciliation checks Incomplete SCOA mapping Reporting and IFMIS errors Pre-validation of mappings; enforce SCOA codes Extended downtime Service disruption Plan migration window; define fallback plan User resistance Continued use of old processes Early training; user participation in migration Privacy breach Legal penalties Secure handling; role-based access; encryption (ix) Annex 9: Change Management and Training Plan Section 1: Purpose This annex outlines the structured approach for managing organisational change, stakeholder adoption, and capacity building during the transition to the ICRMS. Section 2: Change Management Phases Phase Key Activities Deliverables Linked FR/TR Readiness Assessment Assess current processes, systems, skills, and stakeholder perceptions. Readiness report; stakeholder mapping TR.47 Communication Planning Develop strategy, key messages, channels, and timeline. Communication plan; briefing materials TR.35 Stakeholder Engagement Meetings with user groups, management, oversight bodies. Engagement logs; feedback matrix FR.1; FR.38 Impact Analysis Identify process and role changes; KPIs affected. Change impact report TR.47 Resistance Management Identify potential resistance; plan mitigation. Resistance plan TR.47 Change Champion Network Appoint departmental champions to support adoption. Champion roster; role descriptions TR.47 Section 3: Training Plan Structure Training Type Target Audience Objectives Responsibility Delivery Method Duration Linked FR/TR System Overview Executive leadership; managers Understand system purpose, benefits, governance TNT Workshop/Briefing 0.5 day FR.1–FR.3; TR.47 Functional User Training Revenue and finance officers; enforcement staff Operate modules for billing, receipting, reconciliation, enforcement TNT Hands-on workshops 2–3 days FR.20–FR.32 Technical/Admin Training ICT and system administrators Manage users, roles, configurations, integrations, backups, security CG, TNT Lab sessions 3–5 days TR.9–TR.24; TR.36 Integration Training ICT and finance integration staff Manage IFMIS, SCOA, payment and registry integrations Practical configuration sessions 2 days FR.14; TR.13–TR.17 Security and Compliance Training All users Data security, privacy laws, role-based controls E-learning/Interactive 1 day TR.18–TR.22 Reporting and Analytics Training Management; Mand E; finance teams Generate statutory and management reports, dashboards, analytics Workshop 1 day FR.43– FR.48; TR.38–TR.40 DR/BCP Training ICT and operations staff DR drills, backup restores, continuity processes Simulation 0.5–1 day TR.33–TR.37 Change Champion Coaching Change champions Support peer adoption; escalate feedback Peer coaching Ongoing TR.47 Section 4: Communication Guidelines 1. Pre-Go-Live: Weekly updates, FAQs, early demos. 2. Go-Live: Daily updates, escalation contacts, public notices. 3. Post-Go-Live: Success stories, usage stats, surveys. Section 5: Adoption Monitoring and Success Criteria 1. User login frequency and transaction volumes. 2. Helpdesk ticket trends and resolution times. 3. Compliance with new processes and decommissioning of manual systems within 3 months. 9th September, 2025 THE KENYA GAZETTE 4. ≥90% of targeted users trained; ≥80% competency scores post-training. 5. ≥80% stakeholder satisfaction in surveys; adoption metrics meet projections. (x) Annex 10: Standard Reports Catalogue Section 1: Purpose This annex defines the minimum set of reports that the ICRMS must produce to meet statutory, operational, management, analytical, and transparency requirements. Section 2: Report Categories Category Description Frequency Linked FR/TR Statutory and Financial Reports Legally required; SCOA-coded; IFMIS- compatible Monthly/Quarterly/Annual FR.44; TR.13 Management and Operational Reports Support internal decision-making Daily/Weekly/Monthly FR.43; TR.38 Debt and Enforcement Reports Track arrears, payment plans, enforcement actions Weekly/Monthly FR.29–FR.33; TR.29–TR.31 GIS and Asset Reports Spatial insights for revenue assets Monthly/Quarterly FR.16; FR.48; TR.28 Analytical and Forecasting Reports Predictive insights for planning Quarterly/Annual TR.39; TR.40 Section 3: Minimum Standard Reports Ref No. Report Name Description and Purpose Frequency Format Linked FR/TR SR.1 County Revenue Summary Consolidated revenue by stream, ward, SCOA code; IFMIS-ready. Monthly PDF; XLSX; SCOA CSV FR.44; TR.13 SR.2 Daily Collections Report Daily revenue by stream, collector, payment channel. Daily PDF; XLSX FR.43; FR.25 SR.3 Bank and Channel Reconciliation Report Matches transactions to bank/mobile money; flags exceptions. Daily PDF; XLSX FR.25; TR.15 SR.4 SCOA Export File SCOA-coded export for IFMIS posting. Monthly SCOA CSV FR.44; TR.13 SR.5 Arrears Aging Report Outstanding balances by age buckets. Monthly PDF; XLSX FR.29; TR.39 SR.6 Payment Plan Compliance Report Lists payment plans, instalments, defaults. Weekly PDF; XLSX FR.30 SR.7 Enforcement Action Register All enforcement cases, GPS-stamped actions, outcomes. Monthly PDF; XLSX FR.32; TR.29 SR.8 Waivers and Exemptions Report Approved waivers/exemptions with details. Monthly PDF; XLSX FR.18 SR.9 Top Revenue Sources Ranked streams/accounts with trends. Monthly PDF; XLSX FR.19; TR.39 SR.10 Revenue vs Target Performance Actual vs target collections by stream/ward. Monthly PDF; XLSX FR.19; TR.39 SR.11 Licence and Permit Register All licences/permits: active, expired, pending. Monthly PDF; XLSX FR.20–FR.22 SR.12 Asset Revenue Report Revenue from county assets. Quarterly PDF; XLSX FR.15 SR.13 GIS Asset Map and Revenue Overlay Map assets/revenue sources with collections data. Quarterly PDF; GIS Shapefile FR.16; FR.48 SR.14 Transaction Audit Report All transactions with user/timestamp/action. Monthly PDF; XLSX FR.49; TR.15 SR.15 Configuration Change Audit All config changes (tariffs, SCOA, roles). Monthly PDF; XLSX FR.42; TR.41 SR.16 Security Incident Report Failed logins, access violations, resolved vulnerabilities. Quarterly PDF TR.18–TR.21 SR.17 Revenue Forecast Report Predictive revenue per stream/ward. Quarterly PDF; XLSX TR.40 SR.18 DR/BCP Test Report DR and BCP test results. Bi-Annual PDF TR.33–TR.35 SR.19 Public Transparency Report Non-confidential summary for public release. Quarterly PDF; Web FR.38; TR.39 SR.20 Collector Performance Report Collections per collector/agent; efficiency metrics. Monthly PDF; XLSX FR.35 12:13 PM THE KENYA GAZETTE 9th September, 2025 6172 6172 (xi) Annex 11: Data and Records Governance Section 1: Purpose Establish the rules, responsibilities, and standards for secure, accurate, and compliant management of all data and records within the ICRMS, ensuring transparency, accountability, and long-term integrity. Section 2: Scope Covers all data captured, processed, stored, or transmitted by the ICRMS including taxpayer and revenue records, SCOA-coded transactions, audit logs and configuration changes, backups, archives, and purged records. Section 3: Data Ownership and Stewardship Role Responsibility County Government (Data Owner) Legal ownership of ICRMS data within its jurisdiction. National Implementing Agency (Central System- National Treasury) Ownership of central repository and inter-county integration data. ICT Unit Technical custodian of databases, backups, and recovery operations. Revenue Department Custodian of taxpayer and transaction records; enforces SCOA compliance. Data Protection Officer Ensures compliance with data protection laws and privacy policies. Internal Audit Verifies governance controls and data accuracy. Section 4: Data Classification Classification Description Examples Public Accessible without restriction. Aggregated revenue reports Internal For internal staff use only. Operational dashboards Confidential Restricted to authorised roles. Taxpayer profiles; SCOA codes Restricted Highest sensitivity. Encryption keys; investigation records Section 5: Data Quality Standards Standard Requirement Linked FR/TR Accuracy Records must match source documents. FR.6; FR.7; TR.44 Completeness Mandatory fields enforced; no nulls where not permitted. TR.44 Consistency Standard formats for dates, SCOA codes, IDs. FR.14; TR.13 Timeliness Updates in real or near-real time. TR.26 Integrity Maintain referential integrity across related datasets. FR.1; FR.2 Section 6: Retention, Archiving and Disposal 1. Retention: Financial, transactional, and audit data retained for at least 7 years. 2. Archiving: Inactive records archived after 2 years but retrievable for audit. 3. Purging: Allowed only after retention period, with multi-level authorisation and audit logging. 4. Backup: Daily full + hourly incremental; quarterly restore tests (TR. 36). Section 7: Records Management Controls Control Area Requirement Linked FR/TR Audit Trails Immutable logs for all create/update/delete actions. FR.49; TR.15 SCOA Compliance All transactions SCOA-coded. FR.14; TR.13 Source Documentation All records linked to scanned/uploaded documents. FR.3 Version Control Maintain history of tariffs, SCOA updates, configuration changes. FR.12; TR.41 Retrieval and Search Multi-criteria search for any record. FR.8 Section 8: Access and Security Auditing 1. Quarterly review of user access rights; immediate revocation after role change or exit. 2. Annual penetration testing; quarterly vulnerability scans. 3. Review logs for suspicious activity and investigate anomalies. Section 9: Compliance Monitoring and Indicators 1. Annual Data and Records Governance Audit by Internal Audit; CRA/National Treasury oversight inspections. 2. Key Governance Indicators (KGIs): % records with complete SCOA mapping; % records meeting accuracy benchmarks; unauthorised access incidents; backup and restore success rates. 9th September, 2025 THE KENYA GAZETTE (xii) Annex 12: Glossary and Acronyms Section 1: Purpose Standardises the definitions and abbreviations used throughout the Standards and Guidelines to ensure clarity, accuracy, and uniform interpretation. Section 2: Glossary of Key Terms Term Definition Access Control The process of granting or denying requests to obtain and use information and system services, managed via Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC). Ad-hoc Report A report created on demand to meet specific information needs outside scheduled reporting. API (Application Programming Interface) Protocols and tools that enable communication between systems. Audit Trail A secure, chronological record of all system activities showing the user, action, and time. Business Continuity Plan (BCP) Documented procedures to ensure continued operations during and after a disruption. Cutover The planned process of switching operations from a legacy system to a new system. Customer Ledger A detailed account record showing all transactions, charges, payments, and balances for a taxpayer. Data Cleansing Detecting and correcting (or removing) corrupt, inaccurate, or incomplete data. Data Protection Impact Assessment (DPIA) An assessment to identify and minimise data protection risks. Disaster Recovery (DR) Strategies and procedures to restore IT systems, applications, and data after a disruption. End-of-Day (EoD) Process Daily procedure of closing financial transactions, reconciling, and locking entries. End-of-Month (EoM) Process Monthly closing procedure to roll forward balances, age debt, and lock the period. End-of-Year (EoY) Process Annual closing procedure for the fiscal year, carrying forward balances and archiving. Failover Automatic switching to a standby system when the primary fails. Finance Act Legislation outlining revenue streams, rates, and penalties for a fiscal year. Geographic Information System (GIS) A system for capturing, storing, analysing, and displaying spatial or geographic data. Hypercare Period Intensive vendor and project team support immediately after go-live. Immutable Log A log file that cannot be altered or deleted, ensuring audit integrity. Integration Test Verification that separate system components work together as intended. Maker-Checker Control A control where one user initiates a process and another approves it. Multi-Factor Authentication (MFA) A security measure requiring more than one verification method for login. Multi-Tenancy Architecture where one system instance serves multiple clients with data segregation. Parametric Configuration Configure system behaviour through parameters without changing code. Payment Channel Method used to process payments, such as mobile money, EFT, USSD, or POS. Reconciliation Matching system records to bank or payment provider records to ensure accuracy. Recovery Point Objective (RPO) Maximum acceptable amount of data loss measured in time. Recovery Time Objective (RTO) Maximum acceptable time to restore services after a disruption. Standard Chart of Accounts (SCOA) Uniform coding framework for government accounting. Tamper-Evident Feature that shows when an attempt has been made to alter data or logs. Transaction Ledger Record of all transactions for a specific revenue stream, with SCOA coding. Version Control System that records changes to files or configurations and allows rollback. Section 3: Acronyms Acronym Full Form ABAC Attribute-Based Access Control API Application Programming Interface BCP Business Continuity Plan BRS Business Registration Service 12:13 PM THE KENYA GAZETTE 9th September, 2025 6174 6174 Acronym Full Form CEC County Executive Committee CoG Council of Governors CRA Commission on Revenue Allocation CSV Comma-Separated Values DPIA Data Protection Impact Assessment DR Disaster Recovery EoD End-of-Day EoM End-of-Month EoY End-of-Year ELK Elasticsearch, Logstash, Kibana FR Functional Requirement GEA Government Enterprise Architecture GIF Government Interoperability Framework GIS Geographic Information System HMIS Health Management Information System ICT Information and Communication Technology ICRMS Integrated County Revenue Management System ID Identification IFMIS Integrated Financial Management Information System IBEC Intergovernmental Budget and Economic Council IPRS Integrated Population Registration System JSON JavaScript Object Notation KPI Key Performance Indicator KRA Kenya Revenue Authority LTS Long-Term Support MFA Multi-Factor Authentication NTSA National Transport and Safety Authority OCOB Office of the Controller of Budget OTP One-Time Password PDF Portable Document Format PFM Public Finance Management POS Point of Sale RBAC Role-Based Access Control RPO Recovery Point Objective RTO Recovery Time Objective SAML Security Assertion Markup Language SAST Static Application Security Testing SCOA Standard Chart of Accounts SLA Service Level Agreement SSO Single Sign-On TR Technical Requirement TCO Total Cost of Ownership TLS Transport Layer Security UAT User Acceptance Testing UPS Uninterruptible Power Supply 9th September, 2025 THE KENYA GAZETTE Acronym Full Form USSD Unstructured Supplementary Service Data UUID Universal Unique Identifier VAT Value Added Tax XML Extensible Markup Language CERTIFICATION These Annexes to the Integrated County Revenue Management System (ICRMS) Standards and Guidelines have been reviewed and approved for publication and implementation by the Commission on Revenue Allocation (CRA) in accordance with its constitutional mandate under Article 216 of the Constitution of Kenya, the Public Finance Management Act and all other relevant statutory provisions. In setting out these guidelines, the Commission seeks to promote prudent use of public resources, ensure value for money, and enhance revenue generation and management across all County Governments and National Government implementing entities. Approved on the 8th September, 2025. MARY WANYONYI CHEBUKATI, Chairperson, Commission on Revenue Allocation. ROBLE NUNO, Ag. Commission Secretary/Chief Executive Officer.