What government agencies should look for in a web vendor: MOF, security and accessibility

Government agencies should check that a web vendor is registered with the Ministry of Finance under the right ICT field codes, can show similar public-sector work, builds security and accessibility in from the start, and hands over full documentation and access. Price matters, but a portal that fails a security review or locks you in costs more later.

Is the vendor registered with MOF under the right codes?

Start here, because it decides whether the vendor can take part in the procurement at all. Ask for the company’s MOF supplier registration and check two things.

The validity dates. Registration expires. Make sure it covers the whole project period, including any warranty or maintenance that follows the launch.

The field codes. MOF registration lists specific codes for the kinds of work a supplier is registered to do. For web projects, the relevant ones are usually in the ICT group, such as software and system development, customisation and maintenance (210104), or ICT security and firewall (210107). Check that the codes match what you are buying, and confirm with your procurement unit which codes a particular tender requires.

For reference, SawangVille Tech Ventures is registered with MOF until 30 June 2029 under codes 210103, 210104, 210106, 210107 and 210108.

Have they built something similar for the public sector?

Agency websites are different from business websites. They serve the whole public, often in Bahasa Melayu and English. They go through internal reviews and approvals. They are expected to stay online and stay correct for years.

Ask to see live portals the vendor has built for other agencies, and ask specific questions about them:

• Which parts did your team build, and which were done by others?
• Who looks after the site today?
• How were content updates handled after launch?

We have built portals for MOTAC and SPR, and those are the kinds of references worth asking any vendor for.

How do they handle security?

A government site is a target simply because it is a government site. Security should be part of the build, not an add-on at the end. Ask the vendor to explain how they handle:

• HTTPS everywhere, with modern security headers
• Admin access, with two-factor authentication and separate roles for editors and administrators
• Forms and logins, with rate limiting and bot protection to stop automated abuse
• Updates, including who applies security patches and how quickly
• Backups, including how often they run and when a restore was last tested
• Hosting access, with each person given only the access they need
• Security assessments, and whether they will fix findings from a penetration test or review your agency arranges

A vendor who answers these clearly and in writing is easier to hold to account than one who says “don’t worry, it’s secure”.

Will the site be accessible to everyone?

A public website should work for people with visual, hearing, motor and cognitive impairments, for older users and for people on slow phones. The Web Content Accessibility Guidelines (WCAG) at level AA are a common benchmark.

Ask the vendor how they test for accessibility, not just whether they do. A good answer includes both automated checks and manual testing: using the site with only a keyboard, checking colour contrast, writing proper alternative text for images, and trying key pages with a screen reader.

Also ask how the site handles both languages. Menus, forms, error messages and documents should all be available in the languages your public uses.

What should the handover include?

Lock-in is one of the most expensive mistakes an agency can make. Before you sign, agree in writing that at the end of the project the agency will hold:

1. The full source code, including any custom themes, plugins or applications
2. Administrator access to the content management system, on accounts in the agency’s name
3. Control of the domain and the hosting account
4. Technical documentation: how the site is built, deployed and backed up
5. A content editing guide and training for your team
6. A clear defect period after launch, with response times agreed in writing

If a vendor is reluctant to hand over source code or admin access, treat that as a warning sign.

What about hosting, data and ongoing support?

Ask where the site will be hosted, who can reach the server, and how personal data collected through forms is stored, who can see it and how long it is kept.

Then ask what happens after launch. Most agency sites need regular updates, security patches and content changes. Agree a support arrangement, with response times, before the project ends rather than after something breaks.

What should you ask in the vendor briefing?

If you only have time for a few questions, use these:

1. Can we see your MOF registration and field codes?
2. Which public-sector sites have you built, and what exactly did you do on each?
3. How do you secure admin access, forms and logins?
4. How do you test accessibility?
5. What will we own and receive at handover?
6. What does support look like after launch, and how quickly do you respond?

Our Custom Development service covers agency portals, from custom WordPress to Laravel web apps, and our government page explains how we work with agencies. Government projects are priced by quotation.