Government Digital Services Vendor Checklist for Nigeria

Vendor Selection Is Part of Service Design

A government digital service can have a sensible policy objective and still fail in daily use. The failure often begins before development, when an agency selects a vendor from a polished proposal without testing how that team handles citizen journeys, legacy systems, security, support, and handover.

The right evaluation asks more than whether a bidder can build a portal. It asks whether the vendor can deliver a dependable public service across Nigerian operating conditions, explain its technical decisions, and leave the agency able to govern the system after launch.

This checklist is for ministries, departments, agencies, state institutions, programme teams, and advisers comparing technology vendors. It complements our broader guide to government digital services in Nigeria by focusing on procurement and delivery evidence. Procurement rules, data obligations, and approval processes vary by institution, so legal and procurement teams should confirm the binding requirements for each project.

Define the Service Before Evaluating the Vendor

Do not begin with a list of frameworks or a request for "a modern portal." Give bidders a service brief that describes:

• The citizen or staff outcome the service must support
• Primary users, including assisted-digital users and internal case officers
• The complete journey from application to decision, payment, notification, and appeal
• Existing databases, identity systems, payment platforms, and manual records
• Data collected, document uploads, approval roles, and retention needs
• Expected locations, devices, connectivity conditions, and transaction peaks
• The first release boundary and what remains outside scope
• Acceptance evidence required before each milestone is approved

If the agency still needs to turn policy goals into a technical roadmap, an IT consulting engagement can help define requirements, risks, architecture options, and a phased delivery plan before the main procurement.

1. Check Relevant Delivery Evidence

Ask for working examples, not screenshots alone. A useful evidence review includes a live product, a technical walkthrough, the vendor's exact role, the launch date, current operating status, and a reference who can discuss problems as well as successes.

The example does not need to be another government portal. A live health, payments, logistics, or operations product may demonstrate identity, permissions, audit trails, notifications, and support more clearly than an abandoned public-sector website. Techzoid's product portfolio, for example, lets evaluators inspect real software categories rather than rely only on claims in a proposal.

For each reference project, ask:

• Which components did this vendor design, build, integrate, and operate?
• What changed after real users tested the service?
• How were defects, incidents, and scope changes handled?
• Who owns the source code, cloud accounts, domains, and data?
• Is the system still maintained, and by whom?

Treat vague ownership answers as a risk. A bidder should distinguish its own work from a consortium partner's work.

2. Test Architecture and Interoperability

Government systems rarely operate alone. They may need to exchange data with identity, payment, records, finance, messaging, or reporting platforms. The proposal should explain these boundaries without pretending every integration is already available.

Request:

• A high-level architecture showing users, applications, databases, external systems, and trust boundaries
• Documented APIs with versioning, authentication, error handling, and usage limits
• A clear system of record for every important data type
• Stable identifiers that prevent duplicate citizen or case records
• Import, export, and reconciliation procedures
• An approach to unavailable or slow external systems
• Open data formats and a tested exit path from proprietary components

Ask the vendor to walk through one transaction from submission to final status. The team should explain what happens when a payment succeeds but a callback is delayed, when an identity service is unavailable, or when two officers update the same case. These operational details reveal more than a list of technologies.

3. Review Security and Data Protection Controls

A public service may handle identity records, contact details, payment references, health information, business records, or uploaded evidence. Security should therefore appear in the delivery plan, acceptance tests, and operating model.

At minimum, evaluate:

• Data inventory and purpose for each collection point
• Role-based access and multi-factor authentication for privileged users
• Audit logs for sensitive reads, exports, approvals, and configuration changes
• Encryption, secret management, and controlled production access
• Secure development review and independent testing appropriate to the risk
• Incident detection, escalation, notification, and evidence preservation
• Retention, archive, correction, and deletion processes
• Backup protection and tested restoration
• Hosting locations, support access, and cross-border transfer review where relevant

Do not accept a bare claim of compliance with the Nigeria Data Protection Act (NDP Act) as sufficient evidence. Ask which controls, records, responsibilities, and tests support the statement. Legal advisers should confirm statutory interpretations, while technical reviewers verify that the implemented controls match the approved design.

4. Design for Nigerian Operating Conditions

A service tested only on office broadband and a current laptop is not ready for national or statewide use. Require evidence for the conditions citizens and field officers will actually face.

The evaluation should cover:

• Mobile-first flows on affordable Android devices
• Useful behaviour on slow or intermittent connections
• Saved progress for long applications
• Clear recovery from failed payments or interrupted uploads
• Accessible forms, readable error messages, and keyboard support
• Assisted-digital workflows for service desks and authorised agents
• SMS, email, or WhatsApp notifications chosen around user needs and consent
• Support for local payment and reconciliation processes where payments are in scope
• Capacity testing based on a documented demand model, not an invented traffic promise

Offline capability is not necessary for every service, but the vendor should explain what users see when connectivity fails and how duplicate submissions are prevented.

5. Inspect Delivery Governance

Large launch dates can hide weak progress. Prefer milestone evidence that agency teams can inspect throughout delivery.

A credible plan includes:

1. Discovery with service owners, frontline staff, security, legal, procurement, and representative users.
2. A prioritised backlog connected to the approved service scope.
3. A staging environment with frequent demonstrations.
4. Written acceptance criteria and test evidence for each milestone.
5. A risk, decision, dependency, and change log owned jointly with the agency.
6. Named people for product, engineering, security, quality assurance, and operations.
7. A pilot with a bounded user group before wider rollout.

Ask who can make day-to-day decisions on both sides. Projects stall when every wording change or integration question waits for a large steering committee.

6. Protect Operations and Handover

Launch is the beginning of service operations, not the end of the contract. Evaluate how the system will be monitored, patched, supported, and transferred.

Require the proposal to address:

• Service hours, incident priorities, response process, and escalation contacts
• Availability and performance monitoring with agency access
• Backup schedules and restoration exercises
• Security update ownership and dependency maintenance
• User support, staff training, and administrator guides
• Source repository access and an agreed branching and release process
• Infrastructure configuration, deployment instructions, and environment ownership
• Data export, credential transfer, and transition support at contract exit

The agency should control, or have a documented route to control, critical domains, cloud accounts, repositories, encryption keys, and service data. A handover clause without usable documentation and access is not a handover plan.

Use a Consistent Vendor Scorecard

Score every bidder against the same evidence categories:

• Service understanding: Journey map, assumptions, and scope boundaries
• Relevant delivery: Live systems, references, and the vendor's role
• Architecture: Diagram, integration plan, and data ownership
• Security and privacy: Controls, tests, incident response, and retention plans
• Inclusive operations: Mobile, low-bandwidth, accessibility, and assisted service
• Delivery governance: Team, milestones, demonstrations, and risk control
• Support and handover: Monitoring, documentation, access, and exit plan
• Commercial clarity: Itemised cost, assumptions, and change process

Publish evaluation rules before proposals are opened where the procurement process allows it. Reviewers should record the evidence behind each score. Price matters, but a low bid that omits integration, testing, support, or handover is not comparable with a complete delivery plan.

Red Flags to Resolve Before Award

Pause for clarification if a proposal:

• Promises full transformation without a discovery phase
• Claims guaranteed adoption or performance without assumptions
• Uses "proprietary" to avoid explaining data export or integration
• Provides references that cannot be verified
• Leaves security testing until after launch
• Makes the agency dependent on one unnamed developer
• Excludes training, monitoring, maintenance, or handover
• Assumes every citizen has reliable broadband, email, and a recent smartphone

A written clarification can resolve a genuine omission. Repeatedly vague answers usually indicate delivery risk.

Make the First Release Small Enough to Verify

The safest first release is a complete but bounded service, not a thin front end over an unchanged manual process. Choose one user group, transaction type, or location. Test the full journey, including internal review, payment reconciliation if relevant, notifications, support, reporting, and exception handling.

Use pilot findings to update requirements before expanding. This gives the agency evidence about adoption and operations without inventing headline KPIs in advance.

The strongest government digital services vendor is not the one with the longest feature list. It is the team that can connect policy to a usable service, show working evidence, manage risk openly, and leave the institution in control.

If your agency or delivery partner needs an independent technical review of requirements, vendor proposals, architecture, or handover plans, contact Techzoid Innovation to discuss a focused assessment.