A Public IT Tender: What to Check Before You Bid

Who can actually bid on a public IT tender?#

Any company can bid on a public IT tender if it meets the participation conditions set out in the tender documentation – economic and financial standing, technical and staffing capability, and the required references. A bidder who fails to meet or prove these conditions is excluded before the offers are even compared on substance, regardless of how strong the technical solution is.

Conditions differ between tenders because the contracting authority scales them to the project's risk and scope. A minor website upgrade will carry lighter requirements than the rollout of a full information system connecting several departments and existing records. Before a company starts drafting a bid, it should confirm it meets the formal conditions – otherwise the effort spent on the substantive part of the offer is wasted.

The formal conditions section is exactly what the search phrase public IT tender requirements is usually looking for. It is a separate part of the documentation from the award criteria used to rank compliant bids: conditions are a pass/fail check, criteria decide which of the qualifying bids is the most advantageous for the buyer.

• Economic and financial standing (credit rating, turnover, liability insurance)
• Technical capability shown through comparable references
• Staffing capability (education and experience of key personnel)
• Business registration and any required permits
• A completed ESPD self-declaration form
• No grounds for exclusion (no convictions, settled obligations)

What should you check in the technical specification before bidding?#

The first thing to check in the technical specification is whether the required functionality, the integrations with the buyer's existing systems, and the acceptance criteria are described precisely enough to be delivered and verified without a later dispute over scope. A vague, generically worded specification is one of the biggest risks in public IT tenders, because what the buyer actually meant only becomes clear during delivery.

Pay particular attention to requirements for connecting to the buyer's existing systems, such as an ERP, CRM or document management system. The specification should state which data is exchanged, through which interface or API, and who is responsible for access to the existing system during delivery. If that information is missing, it is worth raising the question with the buyer before submitting a bid, since integration scope is often the biggest source of extra work after the contract is signed.

The same applies to the data that needs to migrate from the old system to the new one. The specification should define the volume and condition of the data, its source format, and who verifies the migrated records. When the source is an old, undocumented or partly duplicated system, the time needed for migration is routinely underestimated – worth weighing before deciding to bid at all.

Finally, check the acceptance criteria: when is the system considered functionally complete and compliant with the specification. Without clear, measurable acceptance criteria, handover can drag on and payment can be withheld even though the contractor's work is effectively done, so it is worth proposing at bid stage how acceptance testing should be structured.

References and proof of capability#

References are the part of a bid where the buyer checks whether the bidder has already delivered projects of comparable scope and complexity. For information systems that usually means experience with larger, multi-department projects, not just individual small websites. The bidder must also be able to prove the reference – with a contract, a buyer's confirmation, or whatever evidence the tender documentation requires, or the reference is not counted in the evaluation.

Public-sector experience carries particular weight, since these projects usually come with clearly defined procurement procedures, documentation requirements and oversight of public spending. Epix delivered such a project for the Municipality of Sevnica, building a software solution and interactive content for a public space on a 55-inch touchscreen – from configuring the kiosk environment and integrating hardware and software, to on-site installation, documentation and post-launch support.

A reference like this shows a contractor can handle a full public-space project cycle: from technical design to on-site installation and the documentation a buyer needs for its own records and audit trail. A company preparing a bid should describe its own past projects with the same level of detail – not just naming them, but describing scope, team role and the outcome achieved.

Tender documentation: what to read before deciding to bid#

Tender documentation for a public IT system usually consists of several separate documents that need to be read together, not in isolation. Participation conditions, the technical specification, the award criteria and the draft contract complement each other – the draft contract, for instance, often contains obligations the specification never mentions, such as ownership of source code, documentation or data after the project ends.

The draft contract deserves particularly close reading, since it sets payment terms, penalty clauses, post-launch maintenance obligations and the dispute-resolution process. A company that drafts its bid quickly and focuses only on the technical specification can easily miss a contract clause that significantly raises the project's risk – for example, a disproportionately high late-delivery penalty that also depends on actions the buyer controls.

Beyond the draft contract, check any annexes as well – data-security requirements, a reference description form, or a draft schedule. Annexes often carry details the main body of the documentation only mentions in passing, so they need to be read as equally binding requirements, not as an afterthought, since a single annex clause can change the entire risk picture for a bidder.

• Invitation to tender and instructions to bidders
• Participation conditions and exclusion grounds
• Technical specification of the subject matter
• Award criteria for the most advantageous bid
• Draft contract and its annexes (SLA, security requirements)
• ESPD form and other bidder declarations

Data security and regulatory compliance#

Public IT tenders increasingly include personal-data protection and cybersecurity requirements, since the system often processes data belonging to citizens, employees or the buyer's business partners. GDPR compliance requirements, and where relevant obligations that follow from the NIS2 directive for essential and important entities, can appear in the specification either as a participation condition or as a technical requirement for the system itself.

A bidder should be able to explain how real personal data will be kept separate from test data across the development, test and production environments – production data is not used in the test environment, a standard practice at Epix. It is equally worth defining in advance who has access to production data, how that access is logged, and how the system provides the audit trail that public records often require.

On more demanding projects, buyers increasingly check whether the bidder, or its delivery network, holds recognised quality and information-security standards. Epix and its specialist partner network maintain standards such as ISO 9001, ISO 20000/20001, ISO 27001 and ISO 27701 within their delivery structure, alongside access to individuals holding certification profiles in cloud, security and project management. Credentials like these are often an added advantage in public tenders, not just a formal requirement.

When is it worth bidding on a public IT tender?#

It is worth bidding when a company genuinely has the staffing capacity to deliver the project at the scope the specification demands, and when the risks written into the contract – penalty clauses, guarantees, post-delivery obligations – do not outweigh the benefit the project brings. If the answer to either question is no, the sums behind the bid need a hard second look, or the company should sit this one out.

Risk assessment should also weigh how precise the technical specification is and how many questions it leaves open. A loosely written specification means the actual delivery scope is likely larger than the documentation suggests – a risk the bidder has to price in up front, since a submitted price generally cannot be changed unilaterally afterwards.

Financial risk instruments – required insurance, performance guarantees and penalty clauses – tend to be stricter in public tenders than in private ones, because the buyer is protecting public funds. A company unfamiliar with these instruments should let its legal and finance teams weigh in, not just the technical team, since a single contract clause can put the business at risk even when the project itself is delivered successfully.

SLA obligations after go-live#

Public IT tenders often cover not just development but also a post-launch support obligation – fixing defects, technical and security updates, and agreed response priorities based on severity. A bidder needs to work out how it will organise that support before submitting the bid, since it is an obligation that outlasts the project itself and often weighs heavily in the overall risk assessment of the deal.

At Epix, post-launch obligations are sorted into four classes: outage, where the system or a key part of it is down and handling gets top priority; disruption, where the system works but a specific function does not; defect, a minor issue with no business impact that gets scheduled into the next regular release; and request, a change or enhancement whose scope is assessed and scheduled by agreement. That kind of breakdown is a useful framework when drafting your own tender response too, since it shows the buyer that support is structured, not ad hoc.

Documentation, access credentials and passwords are part of the handover after go-live, while source code and data remain the buyer's property. Changes to the production system go through the same review and testing after launch as during development, and separate development, test and production environments stay in place after the project ends if the buyer keeps maintenance with the same contractor – which also makes a later switch to another contractor easier, since all documentation and code remain accessible.

Subcontractors and consortia: when to bring in partners#

When a specification demands a broader set of competences than a single company has in-house – development, mobile apps, data analytics and cybersecurity all at once, say – it is worth considering a bid with a subcontractor or as a consortium. Tender documentation usually specifies how such an arrangement must be declared and what conditions each member of the group has to meet individually, so this needs settling before the bid goes in, not during delivery.

A project can be taken on in full or as a single work package, which applies equally to acting as a subcontractor on a larger public tender. Within a broader delivery network it is possible to assemble a project team combining senior engineers, solution architects, cloud infrastructure specialists, cybersecurity and AI experts, without any single company having to employ all of that expertise permanently.

In a consortium, it pays to agree in advance on each partner's responsibilities, project governance, how reporting to the buyer works, and how contractual liability is split if one partner causes a delay or defect. Unclear division of roles is a common source of disputes between partners during delivery, even though such friction should never reach the buyer – which is exactly why it needs a written agreement before the joint bid is submitted.

How do you choose a technical partner for the bid and delivery?#

You choose a technical partner for a public IT tender by checking whether it can take responsibility for a specific work package, demonstrate comparable references, and slot into the project on the terms the tender documentation sets – including the deadlines for submitting the evidence the buyer requires. A partner unfamiliar with these formalities can slow down the whole bid, no matter how strong its technical solution is.

It is also worth checking how the partner approaches taking over an existing or unfinished system, when the buyer is tendering an upgrade rather than a new build. Epix takes on such projects after reviewing the source code, architecture, infrastructure and data – something public tenders often require, since a buyer rarely tenders a system built entirely from scratch, and instead builds on existing records and systems that first need to be understood.

A final, equally important criterion is how the partner communicates during delivery – who the project manager is, how often they report, and how scope changes get handled, since larger public tenders almost always produce some. On bigger projects, Epix assigns a project manager and defines each team's responsibilities, deadlines, and reporting approach right from the start, which makes it easier for the buyer to keep oversight throughout delivery.

• Provable references from comparable projects, ideally in the public sector
• Clear division of responsibility between buyer, contractor and any subcontractors
• Familiarity with the tender documentation's requirements, not just the technical spec
• Ability to take over an existing system after reviewing its code and data
• A defined post-launch support model and SLA
• Separate development, test and production environments with test-data protection