License document package for public procurement in Kazakhstan: checklist

Why prepare the license document package in advance

It's better to prepare the license document package for public procurement in Kazakhstan before submitting the bid, not "on request." Procurement deadlines are tight: if a letter, certificate or acceptance act is missing, fixing this on the last day is usually impossible.

The main risk is bid rejection due to formal mismatches. Even if the supplier can actually deliver the licenses, without confirmation of the right to supply and clear handover conditions the commission often avoids the responsibility of "double-checking" and chooses an option without unclear points.

The second risk is problems after contract signing. If documents do not specify support periods, service levels and update procedures, delays occur during commissioning, subscription end dates "float", and disputes arise about who should open incidents with the vendor support.

The customer and auditors usually look not only at the existence of licenses but also at the legal clarity of the supply chain. Documents should clearly state which license is being purchased, who will own it, for how long and whether the supplier has the right to transfer it. For organizations with higher transparency requirements this is critical.

Most disputes appear around three points: confirmation of the right to supply (who is authorized and for what exactly), support periods (when they start and what they include) and transfer of keys and accesses (how and by what act this is recorded).

To reduce the risk of rejection and conflicts, collect a minimal set of documents in advance and check that a non-lawyer can understand them. Product name, edition and validity period must match across all documents; there should be clear confirmation of the right to supply; support conditions and SLA must avoid vague wording; and the handover procedure to the customer must specify keys, accesses, accounts and acceptance acts.

If the supplier also performs integration and support (as often happens with system integrators), ask them to separately define the boundaries of responsibility: where vendor support ends and contractor support begins. This reduces bounced incidents and speeds up launch.

Types of licenses and rights encountered in IT procurements

In public procurement IT people often mix two layers: the customer's right to use a software product and the supplier's right to sell or transfer it. If you understand in advance what types of licenses and "rights" appear in bids, contracts and acceptance, it's easier not to collect unnecessary papers and not to miss key items.

User software can be licensed in different models. It may be perpetual licenses (one-time purchase) or time-limited subscriptions (for example, 12 months). Licenses can be "per device", "per user", "per server", "per core", or sometimes by number of connections. The customer must ensure the model matches how the product will actually be used. Otherwise you may get a formally "correct" license that does not fit operationally.

A separate topic is confirmation of the right to supply. This is not the same as the license itself. A license grants the customer the right to use the product, while the right to supply confirms that the supplier legally sells the product (as a partner, reseller, distributor or through a supply chain). In documents this is usually expressed by letters from the rights holder or its official partner, contractual relations, and indication of territory and validity periods.

Hardware with preinstalled software requires care. For example, when buying PCs or servers with an OS, it is important to distinguish between "preinstalled" and "licensed." Check that the license applies specifically to the supplied hardware (model, serial numbers or other identifier) and that the license type allows such a delivery method. For domestic hardware procurements, origin of the hardware is often confirmed separately from the legality of the software.

Service licenses, updates and support

Besides the "right to use" there are service rights: access to updates, knowledge base, vendor portal, technical support. Sometimes these are separate subscriptions or maintenance agreements. It's important to know in advance what is included: security updates, new versions, key replacement, incident response times.

Certificates, letters and contracts: how they differ

A certificate or license (in the sense of a key or right) confirms the right to use the product. A letter (authorization, warranty) usually confirms the right to supply, partnership, territory and validity, and may also record the composition of the supply.

Contracts (with the rights holder or distributor) show the legal basis of the chain, but they do not replace a document that explicitly permits supplying licenses to this particular customer and for this specific procurement.

Basic document package: what to request from the supplier

To avoid delays and reduce the risk of rejection, it’s useful to collect a license document package for public procurement in Kazakhstan in advance. It demonstrates that the supplier is authorized to provide the required licenses and that the customer will receive the rights and accesses stated in the procurement.

Start with confirmation of the supply channel. Usually this is a letter from the rights holder, manufacturer or official distributor stating who is authorized to sell, the territory covered and which products or editions are allowed for supply. The document must be valid on the bid submission date and worded so the public purchaser can interpret it unambiguously.

Next, get a document that removes ambiguity about the composition of the supply. The commercial offer should contain exact product names, editions, license type (subscription or perpetual), quantity, term, and renewal or migration conditions if relevant.

To simplify matching during acceptance, request a specification and identifiers in advance: part numbers, SKUs, and composition descriptions. For hardware solutions add a delivery specification. When procuring servers with licenses it’s especially important that the OS, virtualization systems or client access licenses appear as separate lines and not "included" without breakdown.

Typically it is enough for the supplier to prepare:

• a letter of authority to supply (products, territory, validity period);
• a commercial offer with exact editions, terms and license types;
• a delivery specification with part numbers or other item identifiers;
• a draft contract or key terms: who transfers the rights, when and in what form;
• the handover procedure to the customer: keys, accesses, accounts, acts and confirmations.

If the supplier is also the manufacturer or a system integrator (for example, GSE.kz in complex deliveries), it’s convenient to separate hardware, software and services in the documents. During review it will be clear what is licensed and what is transferred to the customer.

Step by step: how to check documents before submitting the bid

Checking supplier licenses before submitting the bid eliminates half of the problems in advance. An error in edition name or mismatched dates quickly leads to clarifications, letters and the risk of rejection.

Step 1. Match what you are buying

Do a simple row-by-row check: product name, edition (Standard/Enterprise, etc.), validity (perpetual or subscription), quantity and metric (user, device, server, core). These parameters should match in the commercial offer, specification and contract draft. If any item is listed as an "equivalent" or "analog", ask for the precise name and article number (if applicable).

Step 2. Verify the right to supply and territory

The supplier should have clear confirmation that they may sell this license specifically in the Republic of Kazakhstan (or within KZ public procurement if the vendor phrases it that way). This is usually a letter from the rights holder or official distributor or a partner status confirmation with a valid period.

The document should indicate:

• who issued the confirmation (rights holder, distributor, sub-distributor);
• to which legal entity it was issued (exact supplier legal name);
• validity period and territorial limitations.

Step 3. Cross-check documents against each other

A common trap: the commercial offer promises one thing, the authorization letter confirms another, and the contract shows a third. Put together four sources: commercial offer, right-to-supply letter, specification and contract draft. Check that product names, quantities, terms and the named end recipient match.

Step 4. Clarify support, updates and response times

Check whether support is included in the price or purchased separately, and for how long. If an SLA is stated, it should be described without vague phrases: hours for submitting requests, response time, support channels, language and escalation conditions.

For subscriptions, fix what happens after expiry: do updates stop, is access disabled, how is renewal handled.

Step 5. Fix the handover to the customer

Agree in advance on the form of handover: keys, vendor account access, registration to the customer, certificates, confirmation letters and acts. Documents must clearly state who receives the accesses, within what time after delivery, and which materials accompany the license (instructions, registration confirmation, credentials).

If the procurement includes both hardware and software (for example, a server and licenses), separately define who is responsible for initial setup and license binding. For complex deliveries and integration this is usually recorded in the specification and acceptance act.

Confirming the right to supply: what to look for in letters

For public procurement it's important not only that licenses exist, but that the rights chain is readable: who may sell, who may issue or transfer the license to the customer, and who will support it afterwards. Therefore confirmation of the right to supply often becomes the key part of the license document package for public procurement in Kazakhstan.

Manufacturer letter: required details

The most reliable option is an authorization letter from the manufacturer or rights holder. It should be drafted so the commission has no doubt that the letter relates to supply for the procurement, not a general permission to sell.

Check that the letter contains:

• exact supplier name (and BIN if needed) authorized to supply;
• product name or product family, license type (subscription or perpetual) and edition if necessary;
• territory and channel: Republic of Kazakhstan, public procurement, specific customer type (if relevant);
• validity period or the period when supply is permitted;
• signature of an authorized person, date, outgoing number, seal (if customary for the rights holder).

A useful addition is wording that allows transferring licenses to the end customer and registering licenses/tenants/accounts on the customer organization.

Partner or distributor status: how it should read

Sometimes instead of a manufacturer letter you receive partner or distributor confirmation. This works if the text clearly states that the status grants the right to sell the required product and is current on the procurement date.

Look for specifics: partner level, list of products or directions, validity period and who issued the confirmation. If the text is generic ("is a partner" without date or product), ask for a clarifying letter.

When an integrator confirms the right to supply

If an integrator delivers and implements the solution and the licenses come via its contract with the rights holder, ask for the document linking the integrator to the rights holder: partner certificate, a letter from the vendor to the integrator or confirmation from the partner program.

If the integrator supplies software as part of a server modernization project (hardware plus software), the letter should state that the integrator may include licenses in a complex supply and transfer them to the customer.

If supply goes through a chain of sub-suppliers

A chain "supplier -> distributor -> rights holder" is acceptable, but it must be readable. Request that letters or contractual confirmations do not contradict each other on product names, terms and participants.

If the chain is long, record the ultimate supplier in the letter, attach confirmations of key links (at least the distributor) and agree in advance who registers licenses to the customer and who will be the first-level support.

Support periods and service conditions: how to avoid ambiguity

In public procurement people often confuse two things: vendor support and supplier support. The first usually covers updates, fixes and the right to receive vendor help. The second concerns how you will be supported "on the ground": ticket intake, on-site visits, replacement, administration.

Record exactly what is being purchased: right to use, subscription for updates, extended support or a separate service. The phrase "support for 12 months" without breakdown almost always creates different expectations: the supplier may mean consultations, the customer may expect full maintenance.

Tie support and update periods to specific events: "from the date of signing the acceptance act", "from the date of license registration to the customer account" or "from the delivery date." Also specify the level: basic, extended, 24/7, and whether critical updates are included.

To make SLA and support conditions clear, include them as a separate annex or contract section. Use simple, measurable parameters:

• response time;
• recovery time;
• working hours and contact channels (phone, email, service desk);
• severity levels;
• what is excluded from support.

Separate warranty obligations for hardware and software. For hardware specify warranty period, diagnostics procedure, repair or replacement times, who pays shipping and what happens if the model is discontinued. For software specify who is responsible for activation, what to do when a key fails and how the right to updates is confirmed.

Example: you buy servers and licenses. For hardware you need a warranty with part replacement and on-site response times; for licenses you need a confirmed subscription to updates and a clear process for contacting support. If the supplier has nationwide 24/7 technical support, such conditions should be written in the contract rather than assumed. For example, GSE.kz may claim 24/7 technical support, but for procurement it must be reflected in the contract and annexes.

Rules for handing over to the customer: keys, accesses and acts

Handover of licenses is not just "gave the key." In public procurement it’s important to record that usage rights have actually passed to the customer and that access to licenses will not remain with the supplier by default.

There are usually three handover methods: a key (or license file), access to a vendor account, or registering licenses on the customer's corporate account. The safest option for the customer is immediate registration of licenses on the organization and tying them to a corporate email, not a supplier employee's personal address.

Who owns the account and how to arrange access

If the license is managed in a vendor portal, decide in advance who is the account owner. The owner should be the customer, and the supplier should act as administrator or implementer during the project. Specify how passwords will be changed, two-factor authentication enabled and what happens if the responsible person changes.

It is useful to include short rules in the contract or technical specification:

• to whom licenses are registered (full customer name, BIN, corporate email);
• what access roles are granted to the supplier and for how long;
• how credentials are transferred and when passwords are changed;
• what counts as the moment of handover (registration on the customer account and confirmation);
• how handover is handled for bundled deliveries (hardware + software).

Acts and documents that confirm handover

For the license document package for public procurement in Kazakhstan one document is usually not enough. You need confirmations of rights and completeness so it’s clear what was transferred, to whom and on what terms.

Commonly used documents:

• acceptance-transfer act of rights (or license handover act) listing items, quantities, terms and identifiers;
• delivery note (if applicable) referencing the specification;
• license certificate or a vendor/partner letter naming the customer as the end user;
• an export or portal confirmation showing licenses tied to the customer account;
• an acceptance act for configuration/activation services (if the supplier activates and configures).

Provide an instruction file for the customer and include it in the package. It should state where keys are stored and who is responsible, activation steps (including deadlines), what to do on reinstallation or hardware replacement, and support contacts.

Example: a hospital receives a server and licenses as part of a project. If keys remain on the supplier engineer’s email, access can be lost after six months. When licenses are registered to the hospital’s account and the transfer is confirmed by an act with identifiers, the issue is closed for acceptance and later audits.

Common document mistakes and how to avoid them

The worst case in public procurement is a strong bid rejected over paperwork details. In licensing this happens often because product names, rights and support details are spread across documents. Keep everything consistent: the same product name, the same customer, clear dates and clear license handover.

Where the package usually "breaks"

Typical errors:

• inconsistent product names and editions across commercial offer, specification and rights letter (e.g., "Office Standard" vs "Office 2021" vs no edition). For the commission this looks like different goods.
• support described vaguely: "updates provided", "support included". Without dates, service level and contact channels the wording doesn’t protect the customer.
• the right to supply exists but doesn’t relate to specific procurement items: a generic partner letter without product, term or territory.
• licenses or accesses are registered to an employee (email, personal account) instead of the customer organization, so access is lost when the person leaves.
• mixing hardware warranty and software support in one clause even though they are different obligations with different terms.

How to avoid: practical edits that help

Before submission, align all documents to a single terminology and run this checklist:

• product name, edition, license type, quantity and term match across all files;
• the right-to-supply confirmation specifies your items, not a general phrase "may supply";
• support is fixed with dates (start and end) and clear description of inclusions;
• handover is done to the customer BIN and authorized person, not a personal account;
• hardware warranty is separate from software support and updates.

Short example: a public body buys a PC with preinstalled software. The supplier gives a 36-month warranty for the PC but writes "support during operation" for the software. In a dispute that wording is unclear. Fixing it is simple: two lines in the contract or annex stating 36 months for hardware warranty and, say, 12 months of software support with renewal rules.

If you buy hardware with preinstalled software, ask the supplier for a template license handover act and a filled example. This often uncovers mismatches faster than lengthy email explanations.

Short checklist before submission and signing

Before submitting a bid and before signing the contract check that all documents present a single consistent set: product names, versions, quantities, terms and rights. In public procurement problems usually stem not from the license itself but from mismatches between the technical specification, commercial offer, vendor letters and contract draft.

A practical scenario: what you buy, who may supply it, how it is supported, how it is handed over to the customer and how this is evidenced.

Control list:

• Items match in all documents: product name, edition/type of license, metric (user, device, core), quantity and validity. Any discrepancy requires correction before submission.
• There is a confirmation of the right to supply the specific product and term: letter, certificate or supplier authorization clearly naming products, territory and validity period.
• Support is described unambiguously: term, level, request procedure, response time and incident definition. If SLA matters, include it as an annex.
• Handover rules to the customer are clear: what is transferred (key, account, certificate, vendor portal access), when, who receives it and what to do if a key fails to activate.
• Ready documents for acceptance: template license handover act, completeness act, list of serial numbers or identifiers, and instructions needed by accounting and IT.

Check a typical risk: the commercial offer states "license for 1 year" while the contract automatically lists "12 months of support" but without update rights. These are different things legally and are easier to fix before submission.

If the procurement includes hardware + software, agree in advance how you will accept the kit. It is convenient to prepare a separate handover act for rights so auditors can see the license was transferred to the customer as part of the delivery.

Practical example and next steps

A public body procured employee PCs, several servers for an agency system and licenses for OS and office apps. The technical specification looked clear, but at bid review a typical blocker appeared: hardware documents were fine, but software lacked confirmation of the right to supply and a clear license handover procedure.

To avoid such risks, collect the license document package as two blocks: hardware and software. For hardware you usually need a passport or specification, proof of origin (if important), warranty terms and service scheme. For software you need different documents: confirmation of the right to supply, description of license type, support terms and, most importantly, a clear mechanism for transferring rights and access.

In that procurement the customer requested for software: letters or certificates proving the partner’s right to sell, a list of licenses with exact names and quantities, and a description of the transfer chain (who creates accounts, where keys are bound, who administers). This removed ambiguous interpretations when the supplier said "licenses will be transferred" but did not fix the form and deadlines.

Agree 24/7 support in advance with a short SLA: contact channels, response time, recovery time and escalation procedure. In practice it helped to require that each critical incident have a named owner at the supplier and a clear escalation ladder.

Next steps that usually work:

• Ask the supplier to compile a single document set and align wording with the technical specification and contract draft.
• Separate responsibilities: what belongs to hardware warranty and what is software support and subscriptions.
• Fix the handover: act, list of transferred keys or accounts, deadlines and confirmation that access belongs to the customer.
• Agree SLA 24/7 and escalation before submitting the bid to avoid disputes after winning.

For complex procurements (PCs + servers + licenses + implementation) it is often easier to work with a manufacturer or a system integrator in Kazakhstan that helps assemble the supply, documents and support into one coherent set. For example, GSE.kz as manufacturer and integrator can provide consultation on the required document package and service scheme to keep the package from falling apart into inconsistent parts.