Expression of Interest (EoI)

Maintenance of existing Social Registry system

Reference number: 7000010372

Submission deadline: 01.06.2026

0. Context

Rwanda Social Protection is a core component of Rwanda’s development agenda, and it aims to protect those in poverty by providing support for an adequate lifestyle, promote sustainable graduation by enabling income opportunities, and prevent individuals and households from falling into poverty through income security, shock response and insurance mechanisms.

The Ministry of Local Government (MINALOC) has the overall policy lead of social protection. The National Social Protection System, under the main responsibility of MINALOC, aims to eradicate extreme poverty through social welfare activities, social insurance, and targeted support for vulnerable groups. In order to enhance the efficiency and quality of social protection service delivery, MINALOC is currently championing the use of the Imibireho Dynamic Social Registry to identify eligible households for the Government´s flagship social protection programme, the Vision Umurenge (VUP) and the Community Based Health Insurance.

1.1. Project background

Rwanda is committed to the digital transformation of its social protection systems to enhance service delivery and improve outcomes for its vulnerable populations. In line with this commitment, Rwanda has developed the Social Registry Information System (SRIS).

Launched in 2024, the SRIS is designed to streamline household registration and accurately target vulnerabilities within the population. The system's implementation demonstrates Rwanda's proactive approach to leveraging technology for social welfare enhancement.

The SRIS is actively utilized by approximately 20,000 field staff across various cells and around 20 central staff within the Ministry of Local Government (MINALOC). This widespread adoption underscores the system's critical role in supporting Rwanda's social protection initiatives and ensuring efficient and effective service delivery to those in need.

Regular maintenance is essential for the sustainability and efficiency of the Social Registry Information System. It ensures the system remains robust against potential threats, adapts to evolving requirements, and continues to deliver accurate and reliable data to support informed decision-making. Effective maintenance also helps prevent downtime, enhances user experience, and extends the lifespan of the system.

1.2. Objective of the commission/subject of the procurement

The primary objective of this commission is to ensure the ongoing maintenance and optimization of the Social Registry Information System, guaranteeing its effective, secure, and reliable operation.

The maintenance services will encompass:

1. 1. Bug Fixing: Addressing and resolving any system errors or malfunctions to ensure smooth operation.
   2. System Enhancements: Implementing improvements to optimize system performance and functionality, in order to enhance efficiency and quality of social protection service delivery, particularly with regards to targeting of Rwanda´s vulnerable populations.
   3. Regular Patches and Security Updates: Providing timely updates to safeguard the system against vulnerabilities and ensure compliance with security standards.
   4. Data Analysis: Conducting data analysis to continuously improve data quality, to minimize faults based on false or inconsistent data, and support data-driven decision-making processes, with the objective to improve targeting and support to vulnerable populations.
   5. System Documentation: Updating and expanding the existing system documentation so that it reflects the current system status and functionalities. In case of further development, keeping the system documentation at the respective current level.

1 .Software Solutions to be maintained

1.1.Description of the existing IT solutions

Functional Scope of the IT solution

The social registry holds socio-economic household data for all households in Rwanda. Its main function is to identify eligible households for social protection programmes. In order to do that it ranks households according to their poverty level using a programmed algorithm (proxy means test) and applies other programme based criteria (such as ability to work). It further can provide reports and dashboards at different levels 

It currently has the following functions:

• Household registration (Data collection) and household information updating, including archiving and transferring of households
• Targeting of vulnerable households according to poverty and other criteria
• Dashboards
• Reports
• Access control and user management

Technology Stack for the Social Registry Information System (SRIS)

The existing Social Registry Information System (SRIS) is built using a robust set of technologies to ensure optimal performance and scalability:

• Backend: JAVA 17 with Spring Boot 2.7
• Frontend: Angular 15
• USSD: JavaScript
• Mobile Application: React Native for both Android and iPhone platforms
• Database: PostgreSQL 12

Additionally, Survey JS is utilized for questionnaire creation, and Elasticsearch 7 is employed for efficient survey data search.

Environments

The SRIS operates across two distinct environments to maintain its reliability and functionality:

1. Dedicated Test Environment: Operated by AOS (Africa Olleh Services), Managed by the Ministry of Local Government (MINALOC)
2. Production Environment: Operated by AOS (Africa Olleh Services), managed by the Ministry of Local Government (MINALOC) 

1.2. Current maintenance and development context and set-up

Currently a small developer team maintains the system. The developers report directly to the Chief Digital Officer (CDO) of MINALOC. They operate in weekly sprints, which start with a sprint planning, where the tasks for the week are prioritized. The team operates a backlog using the tool “Trello”. 

1.3. Future set-up of system and processes 

System maintenance will be continuously improved, incl. standardized processes, roles, and responsibilities. This enhanced maintenance framework will be conceptualized and implemented with the assistance of an expert outside of this contract. The contractor is expected to aid in the implementation of this new maintenance framework and support MINALOC in adapting to the updated maintenance protocols.

1.4. Cooperation with partners, development partners and other contractors

Location

The contractor will deliver their maintenance services at the MINALOC offices. A workplace will be provided by MINALOC. The contractor will use their own laptops. RISA and MINALOC can request security measures to be implemented on the contractors equipment such as enrolment in MDM, health checks, virtualization solutions. Upon the start of the contract, a non-disclosure-agreement between the consultants of the contractor and MINALOC shall be signed.

Reporting structure

The contractor reports to (or a person appointed by) the CDO of MINALOC.

Collaboration with MINALOC staff

The contractor will collaborate closely with MINALOC staff. The contractor will be under full responsibility of MINALOC.

Furthermore, the MINALOC IT support team reports bugs and issues found by the users to the development team. The contractor will collaborate with the MINALOC support team in replicating, documenting and fixing reported bugs and other tasks.

Collaboration with GIZ

The contractor will cooperate closely with GIZ staff working on this project. This includes regular updates, exchanges and reporting on both administrative aspects (hours worked) and the broader objectives and tasks of the assignment. 

Collaboration with other contractors

Other consultants will also support the social registry to a) further improve IT operations and maintenance processes and b) further develop the system. The contractor collaborates closely with these consultants.

2. Responsibilities of the contractor

The contractor must deliver the following services and work packages (along with the corresponding milestones). The work packages have no chronological order and can also be implemented in parallel.

Onboarding

Workshop & shadowing period: There will be a series of onboarding workshops to ensure an understanding of the functional and technical aspects of the system, but also to ensure the mode of working, reporting and documentation are aligned and understood.

Overall Documentation and knowledge management

Existing documentation is updated and enhanced to reflect the current state of the system. Work products included but not limited to code, specifications, concepts, test cases and similar are to be documented thoroughly, and are subject to review and sign-off by MINALOC.

Overall: work towards the stable running of the process but also continuously support the improvement of internal processes as well.

The tasks specified below, are thus not exhaustive and might change, be expanded etc. by MINALOC to further improve household registration, vulnerability targeting, data quality and data-based decision making.

Separate monthly reports for the work packages below are to be provided by the contractor to GIZ and MINALOC. These reports can be extracts (possibly to be summarized, enhanced, amended) of the management tools used by MINALOC, and, in combination with the time sheets to be prepared will serve as stand-alone documentation of activities for GIZ.

3.1 Work package 1: System maintenance

The contractor is the main responsible for the maintenance of the system. The maintenance includes the following tasks: 

• Bug fixes
• Change requests in the context of household registration and vulnerability targeting 
• Unit testing
• Data queries (to extract data for further analysis) in the context of household registration and vulnerability targeting
• API endpoint monitoring and maintenance
• User support for application-related issues
• System monitoring and alerting configuration

Depending on criticality and priority of tasks, there will also be system development tasks assigned to the full stack developer.

Work package 1 shall mainly be fulfilled by one experienced full stack software developer, (see chapter 9.1 Human resources)

3.2Work package 2: DevSecOps (incl. monitoring and security patches)

• System and framework patching and updates
• Software deployment and rollback procedures (managing CI/CD pipeline, incl. security gates)
• Configuration management database updates
• Environment maintenance & management
• Performance monitoring and tuning, this includes setting up Grafana based monitoring of systems
• Backup verification and restoration testing
• Vulnerability scanning and applying security patches

Work package 2 shall be the responsibility of a DevSecOps Engineer (see chapter 9.1 Human resources).

3.3. Work package 3: Data analysis

The contractor supports MINALOC in the analysis of the data for the following use cases: 

• Technical data analysis to improve data quality and consistency. The contractor analyses the data to find and eliminate data quality issues and inconsistencies, in order to prevent faults based on inconsistent or faulty data.
• Data analysis to support data-based decision making, including setting up more advanced dashboards (in collaboration with sector experts) to improve household registration and vulnerability targeting.
• Improve targeting results by adjusting the algorithm that forms the proxy means test (PMT). This includes to suggest adjustments of the PMT based on community feedback, estimation of targeting errors, new data available to inform the PMT (e.g. EICVs) etc.

Work package 3 shall be the responsibility of a data scientist. (see chapter 9.1 Human resources)

3.4. Work package 4: Quality assurance

The contractor supports MINALOC in ensuring that the system operates reliably and remains free of functional or data-related defects across all modules. The contractor performs systematic quality assurance activities throughout the development lifecycle, including:

• Conducting smoke, functional, and regression tests after each deployment to verify system stability.
• Executing end-to-end testing across modules and data flows to ensure seamless integration and accurate results.
• Using project management tools (e.g. Jira, Trello) to plan, track, and document testing activities in coordination with development sprints.
• Reporting, tracking, and verifying bugs within sprint cycles, and ensuring that fixes are retested and validated before release.
• Preparing and maintaining QA documentation, including test cases, bug reports, and workflow diagrams, to ensure traceability and accountability.
• Reviewing system behavior and data outputs to confirm alignment with business rules and user requirements.
• Collaborating with developers, data analysts, and business users to identify root causes and prevent recurrence of issues.

Work package 4 shall be the responsibility of a quality assurance engineer (see chapter 9.1 Human resources)

3.5. Other

There is a heightened workload expected yearly between April and June, here the contractor should be available (no/very limited leave days in that period).

3.6Schedule and milestones

The work is to be conducted over a period of 24 months from the start of the contract.

Milestones	Delivery date/period (weeks after contract starts)
Onboarding Workshop held	3 weeks after contract starts
Access to systems provided	4 weeks after contract starts
Clarity and mode of working and documentation	3 weeks after contract starts
First supervised system changes by contractor	4 weeks after contract starts
Reports complementing alignment and steering meeting	monthly
Participation in MINALOC sprint meetings	Weekly

4. Granting of rights of use (e.g. to partners)

The rights of use for the IT solution, and any changes to it that occur in the context of maintenance of the solution, are transferred to MINALOC.

5. Data protection and information security

Data protection and information security are laid out in annex 2

6 .Language

The services are to be provided in English and/or Kinyarwanda.

7 .Technical-methodological concept

In the conceptual design of the tender (technical-methodological approach, project management, if necessary other requirements), the tenderer is required to take specific objectives and requirements into consideration and describe them, as explained below.

Requirements for the technical-methodological concept (section 1 of the assessment grid) In the tender, the tenderer is required to show how the services specified in section 3, where relevant taking account of other specific methodological requirements (section 2), are to be provided (technical-methodological concept). Following the structure in the next chapter. The assessment is taking into consideration coherence, clarity and alignment with the context of Social Security in Rwanda and international best practices with regards to IT Operations (incl. Security) and Maintenance Concept.

7.1.1Understanding of context and work to be performed

The tenderer must summarize their understanding of the work (incl. work packages and content) and critically reflect on the resulting work packages.

7.1.2Project management 

The tenderer must briefly describe their approach towards project management and steering, incl. communication between relevant stakeholders.

7.1.3Maintenance concept

The tenderer must outline their maintenance concept highlighting roles, how they would be embedded in existing structures and referencing best practices regarding IT Operations and IT Security.

7.1.4Test and documentation concept:

The tenderer must describe their suggested process for testing and documenting both change requests and bug fixes.

Additional requirements (section 2 of the assessment grid)

8. Human resources

8.3. Human resources concept

The tenderer is required to provide staff for the positions (‘experts’) referred to and described here in terms of the scope of tasks and qualifications on the basis of corresponding CVs (see section 7).

The qualifications specified below meet the requirements for achieving the highest score in the technical assessment. Qualifications exceeding the requirements specified below will not be granted with extra points. Qualifications 

Expert 1:Senior software developer(Section 3.1 of the assessment grid)

Education/training (section 3.1.1 of the assessment grid):	University degree (e.g. ‘master’s) in IT, science, Technology, Engineering or Mathematics
Language (section 3.1.2 of the assessment grid):	English C1-level in the Common European Framework of Reference for Languages and  Kinyarwanda C2 Level / mother tongue knowledge in the Common European Framework of Reference for Languages
General professional experience (section 3.1.3 of the assessment grid):	6 years of professional experience as full-stack software developer (in house or for an IT service provider), working on enterprise scale government systems and within Government Institutions in Rwanda.
Specific professional experience (section 3.1.4 of the assessment grid):	Having implemented and maintained software projects with the following stack:  Backend: JAVA 17, spring boot 2.7 Frontend: Angular 15 USSD: JS Mobile app: react native Database: PostgreSQL 12
Leadership/management experience (section 3.1.5 of the assessment grid):	3 years in a management position (incl. structuring work, assigning tasks and reviewing other developers work)
International professional experience outside the country/region of assignment (section 3.1.6 of the assessment grid):	-
Professional experience in the country/ region of assignment (3.1.7 of the assessment grid):	6 years professional working experience inRwanda
Experience in the field of development cooperation (section 3.1.8 of the assessment grid):	-
Other (section 3.1.9 of the assessment grid):	3 years of working in agile project management methods, particularly SCRUM

Expert 2:Data Scientist(Section 3.1 of the assessment grid)

Education/training (section 3.2.1 of the assessment grid):	University degree (e.g. ‘master’s or) in IT, science, Technology, Engineering, Data Analytics, Data Engineering or Mathematics
Language (section 3.2.2 of the assessment grid):	English C1-level in the Common European Framework of Reference for Languages and  Kinyarwanda C2 Level / mother tongue knowledge in the Common European Framework of Reference for Languages
General professional experience (section 3.2.3 of the assessment grid):	5 years of professional experience as data analyst (in house or for an IT service provider), incl. data cleansing, validation, and quality assurance techniques.
Specific professional experience (section 3.2.4 of the assessment grid):	3 years working with the ELK stack and working with script based data analysis. 3 years working experience in programming languages (e.g. Python, R) and SQL for data analysis.
Leadership/management experience (section 3.2.5 of the assessment grid):	-
International professional experience outside the country/region of assignment (section 3.2.6 of the assessment grid):	-
Professional experience in the country/ region of assignment (3.2.7 of the assessment grid):	5 years professional working experience inRwanda
Experience in the field of development cooperation (section 3.2.8 of the assessment grid):	-
Other (section 3.2.9 of the assessment grid):	3 years experience with Stata, PMT methodologies and calculating targeting errors.

Expert 3:DevSecOps engineer(Section 3.1 of the assessment grid)

Education/training (section 3.3.1 of the assessment grid):	University degree (e.g. ‘master’s) in IT, science, Technology, Engineering, Data Analytics, Data Engineering or Mathematics
Language (section 3.3.2 of the assessment grid):	English C1-level in the Common European Framework of Reference for Languages and  Kinyarwanda C2 Level / mother tongue knowledge in the Common European Framework of Reference for Languages
General professional experience (section 3.3.3 of the assessment grid):	5 years’ experience as devsecops engineer, incl. responsibility for system security.
Specific professional experience (section 3.3.4 of the assessment grid):	5 years experience in System and Framework Patching and Updates, Software Deployment and Rollback procedures (incl. setting up, improving and managing CI/CD pipelines), Configuration Management Database (CMDB) Updates, Infrastructure Maintenance and Management, Performance Monitoring and Tuning, Backup Verification and Restoration Testing.
Leadership/management experience (section 3.3.5 of the assessment grid):	-
International professional experience outside the country/region of assignment (section 3.3.6 of the assessment grid):	-
Professional experience in the country/ region of assignment (3.3.7 of the assessment grid):	5 years professional working experience inRwanda
Experience in the field of development cooperation (section 3.3.8 of the assessment grid):	-
Other (section 3.3.9 of the assessment grid):	3 years with Grafana / Prometheus 3 years with configuration management tools (e.g. Ansible, Puppet, Chef) 3 years with containerization (e.g. Docker, Kubernetes)

Expert 4: Quality Assurance Engineer

Education/training (section 3.4.1 of the assessment grid):	University degree (e.g. Bachelor’s or Master’s) in Information Technology, Computer Science, Software Engineering, Quality Assurance, or a related technical field.
Language (section 3.4.2 of the assessment grid):	English C1-level in the Common European Framework of Reference for Languages and  Kinyarwanda C2 Level / mother tongue knowledge in the Common European Framework of Reference for Languages
General professional experience (section 3.4.3 of the assessment grid):	5 years professional experience as Quality Assurance Engineer or Software Tester, including test management and coordination within agile development environments.
Specific professional experience (section 3.4.4 of the assessment grid):	5 years experience in software testing and quality assurance, including: Functional, regression, integration, and end-to-end testing of web-based systems, including cross-browser and cross-device checks. Design and maintenance of test cases, bug reports, and QA documentation. Use of issue tracking and sprint management tools (e.g. Jira, Trello, or similar). Experience with test automation tools (e.g. Selenium, Cypress, Postman, or similar)
Leadership/management experience (section 3.4.5 of the assessment grid):	3 years’ experience in leading or mentoring junior QA engineers or coordinating testing activities within agile or scrum teams.
Professional experience in the country/ region of assignment (3.4.6 of the assessment grid):	5 years professional working experience inRwanda
Other (section 3.4.7 of the assessment grid):	5 years’ experience in version control (e.g. Git) and continuous testing practices integrated with CI/CD pipelines. 5 years’ experience in evaluating user interfaces for clarity, usability, and functional accuracy. 5 years’ experience in writing and maintaining unit, integration, and end-to-end automated tests.

9. Costing requirements

9.3. Assignment of experts

In your tender, please do not deviate from the specification of quantities required in these Terms of Reference under sections 8 and 9 (the number of experts and expert days, the budget specified in the price schedule), because this is part of the competitive tender and is used to ensure that the tenders can be compared objectively. There is no entitlement to use the total number of expert days or the specified budget.

Expert days form the basis for the calculation of the specification of quantities. Expert days are eight-hour working days.

The number of expert days corresponds to the working days.

Expert	Expert days
Expert 1: Senior Software Developer	240
Expert 2: Data Scientist	100
Expert 3: DevSecOps Engineer	80
Expert 4: Quality Assurance Engineer	120

9.4. Travel expenses

Travel expense budget: 25,700,000 RWF 

As the number and duration of the business trips are not yet clear, the aforementioned fixed, unalterable travel expense budget for all trips in Rwanda and abroad for all experts is specified in the price schedule. The budget includes the following travel expenses:

• Per-diem allowances and accommodation allowances
• Flights and other transport costs
• Ancillary travel expenses (visa, etc.)

The costs are reimbursed in accordance with the country table in the BMF circular on travel expense reimbursement dated 3 December 2020 (available at: https://www.bundesfinanzministerium.de) (German only) as a lump sum (per-diem allowances and accommodation allowances up to the highest rates under tax law for the country in question) or on submission of documentary proof (accommodation costs which exceed this up to an appropriate amount, the cost of flights and other main forms of transport). All business travel must be agreed in advance by the officer responsible for the project. Travel expenses must be kept as low as possible.

9.5. Equipment

– Not applicable –

9.6. Workshops, training

– Not applicable –

9.7. Hosting

The contractor is not required to host any environment or solution.

9.8. Other costs

– Not applicable –

9.9. Flexible remuneration item

Budget for flexible remuneration: 25,700,000 RWF

The fixed, unalterable budget stated above for flexible remuneration is earmarked in the price schedule. Flexible remuneration is intended to facilitate the flexible management of the contract by the officer responsible for the commission at GIZ. The contractor can make use of the funds in accordance with section 3.1.3.2 of the General Terms and Conditions of Contract.

9.10 Cofinancing arrangements

– Not applicable –

10. Requirements on the format of the tender

The language in which the tender must be written is English.

The technical-methodological concept of the tender (section 7 of the ToR) is not to exceed 12 pages (not including the cover page, list of abbreviations, table of contents and brief introduction). The technical-methodological concept can be provided as slides, not exceeding 12 pages.

The CVs of the staff proposed in accordance with section 9 of the ToR must be in the EU format and not 4 four pages in length. The CVs must clearly show what position the proposed person held, which tasks he or she performed and how many expert days he or she worked during which period in the specified references. 

We strongly request that you do not exceed the number of pages specified.

11 .Options

– Not applicable –

12. Submission of the offers

Please submit your self-declaration of eligibility using the designated form and your technical and financial bids by 01.06.2026 inEnglish only to RW_Quotation@giz.de.

The offer must be submitted in 2 separated emails in PFD format. The email subject line should be in the form of:

• 7000010372 -Technical Offer This includes eligibility documents and technical proposal in two separate PDF files
• 7000010372 - Financial Offer in the format of price schedule provided 

Details of our submission requirements are explained in the enclosed terms and conditions for application. Tenders which are submitted after the deadline, or which do not comply with the terms and conditions for application, will not be considered.

By submitting your tender, you accept GIZ’s General Terms and Conditions of Contract (in the currently valid version).

The tender documents listed below must be submitted in full and as separate documents:

• Completed self-declaration and annexes
• General administrative documents (RDB registration certificat, Tax clearance certificat and VAT certificat)

• Financial bid in the format provided (price schedule)
• Technical bid, including an up-to-date curriculum vitae (CV) for each expert and concept 

When preparing the financial bid, you must adhere to the requirements of the specification of inputs as set out in the Terms of Reference. The tenders received will be subject to a technical evaluation based on the CV and the concept in accordance with the technical assessment grid (see annex). Only tenders that score over 500 points in the technical evaluation will be accepted for the financial evaluation. Technical bids that fail to reach this cut-off point will be regarded as unsuitable. The technical bid is weighted at 70% and the financial bid at 30%.

Sustainability

We have developed a Guide for Practising Corporate Sustainability (GPS) so that our contractors can learn about corporate sustainability at GIZ. We encourage all tenderers to complete the GPS online course and obtain the certificate.

Completing the GPS will not influence the award decision in this procedure. However, we would very much welcome your participation: https://gps.giz.de/en/.

13. Annexes 

1. data protection standards for developing digital tools meant for GIZ's partners
2. Technical requirements to data protection and information security
3. Leveraging interoperability for social impact in Rwanda - Digital Convergence Initiative
4. General Terms and Conditions of Contract for Supplying Services and Works 
5. Technical proposal template 
6. Assessment grid for the technical evaluation of tenders
7. Self-declaration of eligibility
8. Eligibility assessment grid
9. Price schedule

14. List of abbreviations

GIZ                    Deutsche Gesellschaft für Internationale Zusammenarbeit / German International Cooperation

MINALOC            Ministry of Local Government

NSDS                 Nutrition Support Scheme

PMT                    Proxy Means Test

RISA                   Rwanda Information Society Authority

SRIS                   Social Registry Information System

ToR                     Terms of Reference

VUP                     Vision Umurenge