6 Data protection and information security

6.1 Data Protection

When the GIZ hires a contractor to build or upgrade a data processing system (platform, website, app etc.) on behalf of a local partner, who determines the purposes and means of the data processing activity, the GIZ does not bear ANY responsibility for such processing. Although the GIZ builds such systems in conformity with the highest data protection standards, however, its responsibilities end with the handing over of the systems to the partner. As a data controller, the partner must ALONE comply with all local and regional laws applicable to such processing (including the GDPR, where applicable). Consequently, the data protection principles such as lawfulness, data minimization, accuracy, purpose limitation, storage limitation, transparency, integrity and confidentiality, and accountability, as well as the numerous rights of the data subject should be paid due attention. We equally recommend the partner to conclude data protection agreements with the hosting service provider(s) and the maintenance service provider(s), where applicable. The GIZ would be available to support the partner whenever the need arises.

The contractor should comply with the data protection and privacy law according to the data protection offices of ICGLR Member states.

6.2 Information security

The following points must be considered by the contractor and if they are not within the

contractor's responsibility or scope of work, they must at least be discussed with the partner's

project team in order to close any existing security gaps.

The Contractor must inform the Client immediately and in an appropriate form about security

incidents that may affect the Client. If the Customer has appointed an IT security officer or

another person to receive such information, the information must be sent directly to this person.

A firewall must be installed upstream of the server (e.g., authorized IP addresses/GEO

blocking or address ranges for logging on to the system can be entered here or also excluded for this purpose).

Up-to-date anti-virus software must be used on the server and configured accordingly for

automatic updates.

Network communication between the components of the application should be encrypted.

Hard-coded keys (symmetric/asymmetric) should not be included in the application. If this is

unavoidable, the handling of the key must be described. The information security risks related to the storage of the key must be evaluated.

The transmission of authentication information (especially passwords) must be encrypted. The storage and transmission of sensitive and/or personal data must comply with current

encryption standards.

Session cookies used for logins must be deleted after logging out from the client.

Separation of application and data is to be provided, i.e. an application server and a separate

server for the database and file storage is provided, with communication through a firewall.

A system log is to be implemented in which at least logins and logouts of all users and actions such as updates, backups, uploads and downloads, changes to account data and

authorizations, as well as all security-relevant actions and events are to be logged and

documented. The inclusion of further log data is still to be discussed in detail with the project.

The system log is to be documented in the operating manual.

The error messages generated by the application (especially exception handling/exceptions)

must not provide any information that allows conclusions to be drawn about the architecture or software/software versions used.

When configuring the web server, you must pay attention to the following:

• Disable Trace HTTP Request

• Run as a separate User & Group

• Disable signature

• Disable banner

• Restrict access to a specific network or IP

• Use only TLS 1.2

• Disable Directory Listing

• Remove unnecessary DSO modules

• Disable Null and Weak Ciphers

• periodically updates of the system -> stay current!

• periodically checks of the system log files

The system must be hardened against SQL injection. In detail, this concerns the validation,

filtering and cleansing of user input. The inputs may only have expected properties and

characters and may not contain any unauthorized metacharacters that are passed to the SQL interpreter.

When implementing API interfaces, it is essential to harden them against malicious code

injection (SQL injection, etc.) via the URL.

The system must be protected against Cross Site Scripting (XXS) on the client side. The

server(s) must be protected against reflected or persistent cross site scripting by securing the

server source code. All data to be processed by the server must be validated befor execution.

Whitelists of permitted data can be used for this purpose. General conversion of certain script characters is also a popular method. It is to be prevented that executable metacharacters of the scripts are read by the server. Cookies should only be read by the server (HttpOnly) and not by JavaScript in the browser.

A password policy must be implemented, which should look like this:

• minimum number of digits e.g. 12

• latin capital letters (A-Z)

• lower case Latin letters (a-z)

• basic digits (0-9)

• non-alphanumeric characters (like !, $, #, -, &)

• your password must not contain the whole or parts of your login name!

• after 5 wrong entries the account should be locked for 3 minutes

• max. password age 90 days

• password history, at least 5 different passwords in before a previously used password is accepted again, new passwords that differ only by consecutive numbers should not be accepted.

Passwords must not be stored in plain text. Passwords may only be stored as hash values.

The hash algorithm must conform to the current recommendations of the BSI (technical guidelines).

Hard-coded passwords must not be included in the application. The transmission of authentication information (especially passwords) must be encrypted.

2-factor authentication is to be implemented; Google Authenticator is not to be used for this.

2FA is to be possible via multiple channels (app, SMS or e-mail).

A role and authorization concept must be implemented that includes at least the roles of system admin (full authorization to the entire system), CMS admin (+account management), editor and author (editing content/articles). The application to be developed must be operable with minimal system rights. Only the following user groups may have access to the backend:

Developers and administrators of the Contractor as well as employees for editorial maintenance of the Contractor.

Access to the backend at the operating system level may therefore only be granted to very limited user groups with the appropriate expertise.

There must be a documented authorization concept for each application (e.g. in the operating manual).

In order to minimize operating errors (human errors), the ergonomics of the application should be designed safely according to the need for protection.

Changes to account data that are required for registration may only be made by the administrators and are to be blocked for the user.

For the upload of files, appropriate file filters are to be provided so that no files with executable content (scripts, programs or SQL codes) can be uploaded and executed.

The regular backups of the complete system are to be carried out by the Contractor and checked accordingly for usability (restore). The backup can be stored on the server, but a copy must always be stored offline to prevent loss through hacker attacks. The intervals for the backups are to be coordinated with the project.

Important backups always belong offline on another system and must be validated!

The deletion procedure must be proven upon request. Legal retention obligations remain unaffected.

7. Language

In deviation from sections 1.2, 6.1 and 8.1 of the Supplementary Terms of Contract for IT Services – EVB-IT Standard Business Terms for IT Services (EVB-IT-Service-AGB), the services are to be provided in English.

8. 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.

8.1 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).

8.1.1 Assessment of the requirements:

The tenderer must assess the objective and the requirements of the IT solution (see sections 1 and 2) in relation to feasibility and to what particular (non-)technical difficulties must be considered in the IT solution to be developed by the tenderer regarding the objective (section 1.1 of the assessment grid).

8.1.2 Project management and development methodology:

The tenderer should consider the design of the project management process and describe his or her methodology for development/implementation, considering the described requirements (section 2 and 3) and compliance with the milestones (section 3) (section 1.2 of the assessment grid).

8.1.3 Operational plan/personnel assignment plan:

The tenderer must create and explain an operational plan that also includes a personnel assignment plan for all the specialist staff that he or she offers. The operational plan must depict the assignment periods (time and expert days) and describe the necessary work steps and take account of and, where necessary, supplement section 3.3 (section 1.3 of the assessment grid).

8.1.4 Test and documentation concept:

The tenderer must describe the process for testing and documenting the IT solution and the IT security and documentation standards used (section 1.4 of the assessment grid).

9 Human resources

9.1 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 based on corresponding CVs (see section 7).

The qualifications specified below meet the requirements for achieving the highest score in the technical assessment.

Expert 1:Team Leader and Project Manager (Section 3.1 of the assessment grid)

Tasks of the Expert

• Overall responsibility for the advisory packages of the contractor (quality and deadlines and scope).

• Coordinating and ensuring communication with GIZ, ICGLR, partners and others involved in the project.

• Personnel management, identifying the need for short-term assignments within the available budget, as well as planning and steering assignments and supporting local and international short-term experts.

• IT Architecture for the solution

• Regular reporting in accordance with deadlines; and

• Making himself/herself available when needed by the GIZ and ICGLR as beneficiary.

Qualifications:

Expert pool 1 ‘Software Development Team’ with minimum of 1 to maximum 3 experts Section 3.5 of the assessment grid)

The experts can be exchanged during the contractual period in consultation with the officer responsible for the commission.

A CV for each expert must be added to the tender.

Exclusion criterion: If one of the marked exclusion criteria is not fulfilled the entire offer will be excluded.

Task of the Expert Pool

• Support team leader in the implementation of the defined tasks

Qualifications:

The tenderer must provide a clear overview of all the proposed experts and their individual qualifications.

Soft skills of all team members

In addition to their specialist qualifications, the following qualifications are required of team members:

1. Team skills

2. Initiative

3. Communication skills

4. Socio-cultural competence

5. Efficient, partner- and client-focused working methods

6. Interdisciplinary thinking

7. Physical availability at the beneficiary site when required.

10. Costing requirements

10.1 Assignment of personnel and travel expenses

Per-diem and overnight accommodation allowances are reimbursed as a lump sum up to the maximum amounts permissible under tax law for each country as set out in the country table in the circular from the German Federal Ministry of Finance on travel expense remuneration (downloadable at https://www.bundesfinanzministerium.de).

Accommodation costs which exceed this up to a reasonable amount and the cost of flights and other main forms of transport can be reimbursed against evidence.

All business travel must be agreed in advance by the officer responsible for the project.

10.2 Sustainability aspects for travel

GIZ would like to reduce greenhouse gas emissions (CO₂ emissions) caused by travel. When preparing your tender, please incorporate options for reducing emissions, such as selecting the lowest emission booking class (economy) and using means of transport, airlines, and flight routes with a higher CO₂ efficiency. For short distances, travel by train (second class) or e-mobility should be the preferred option.

If they cannot be avoided, CO₂ emissions caused by air travel should be offset. GIZ specifies a budget for this, through which the carbon offsets can be settled against evidence.

There are many different providers in the market for emissions certificates, and they have different climate impact ambitions. The Development and Climate Alliance (German only) has published a list of standards (German only). GIZ recommends using the standards specified there.

10.3 Specification of assignment of experts and travel

11. Requirements on the format of the tender

The structure of the tender must correspond to the structure of the ToR. It must be legible (font size 11 or larger) and clearly formulated. 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 CVs of the staff proposed in accordance with section 0 of the ToR must be in the EU format and not exceed 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. The CVs should be submitted in English.

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

12. Options

Not applicable.

12.1 Follow-on measure/extension of service-delivery period

Not applicable.

12.2 Expansion of the service content

Not applicable.

13 Annexes

13.1 Annex 1: Architecture Vision Minerals Flow Data Vault

./annex/Architecture Vision Minerals Flow Data Vault v27.3.2024.docx

13.2 Annex 2: Digital Registries building block specifications.

./annex/Digital Registries – 23Q4.pdf

13.3 Annex 3: RCM Manual

./annex/ 49111368 RCM.pdf

13.4 Annex 4: Data Protection standards

./annex/ Data-protection-standards-for-developing-digital-tools-meant-for-GIZ-s-partners.pdf

Annex / Attachments

Submission of offer: The Expression of Interest should contain the following:

Technical Proposal:

• A cover letter expressing your interest in this assignment

• Technical proposal with a brief description of why you would be considered as the most suitable for the assignment, relevant expertise, and a detailed, clear methodology, your approach to complete the assignment, template attached.

• Company registration certificate (RDB)

• VAT-Registration certificate

• Latest tax clearance certificate

• Proof of successful completion of related assignments.

Financial Proposal: The price per service category must contain all relevant costs supported by a breakdown of each cost. The costs must be in RWF and VAT

Please submit electronically your EoI (technical & Financial offer) in 2 separated emails and should be in PDF files to this email ONLY: RW_Quotation@giz.de until latest 17^th September 2024

Please you must write on each email subject this sentence: 

83472480 Technical/financial offer, without this sentence, your offer may not be considered

Hard copies are not allowed this time

GIZ reserves all rights