Locking configuration in a 12–24 month contract: clauses to include

Why lock the configuration for 12–24 months

Locking the configuration in a contract is not about "paper strictness" but about repeatability. When PCs and servers arrive identical, you prepare the OS image once, verify drivers once, and then replicate the process. This saves weeks of work and reduces incidents after commissioning.

Identical batches are especially important where standard images, mass deployments and strict procedures exist: government bodies, banks, healthcare and education. There any “minor swap” inside a system unit can quickly turn into downtime for a workstation or an entire department.

What happens if components change without notice

If a supplier replaces, for example, a Wi‑Fi module, storage controller or audio codec with an "equivalent," equivalence often ends at the price point in practice. Then consequences follow: the OS image installs but some devices are not detected, disk encryption or EDR behave differently, and drivers conflict.

Typically it looks like this:

• the OS image stops installing "like it did yesterday" and a new driver set is needed;
• BIOS/UEFI version or update logic changes and automation scripts break;
• peripherals and docking stations behave unstably because of different controllers;
• spare parts in stock don't fit the new revision and repairs turn into rebuilds;
• support load increases: different batches require different instructions.

What usually breaks first

Drivers and firmware almost always fail first. Next comes BIOS/UEFI and compatibility with security policies (Secure Boot, TPM, device control). Then small things surface: wake‑from‑sleep fails, the camera is detected incorrectly, the network disappears after sleep. These are annoying issues that are hard to catch in advance if batches differ.

A real example: IT prepared a golden image for 200 workstations. The first batch passed tests and deployment took a week. In the second batch the network controller was changed. Part of the machines showed a yellow triangle in Device Manager, PXE boot became unstable, and deployment stalled until a new driver package was available and retesting was complete.

Locking configuration for 12–24 months makes expectations transparent: you buy not an "approximately similar PC" but a repeatable platform. For manufacturers and integrators who manage lifecycle and support (for example, with local production and service networks like GSE.kz), this also means clear obligations on batches, firmware and replaceability of modules.

What exactly to lock: parameter checklist

To get identical batches, agree not only on "CPU and memory" but on the full set of modules and their versions. Contracts usually include this as an annex with a specification (BOM) and replacement rules. Then configuration locking becomes a verifiable set of requirements rather than an informal promise.

Basic hardware configuration

First decide what you consider "the same configuration." For workstations and servers it's better to lock the platform model and key components down to specific part numbers (or pre‑described equivalents) so an "analogue" replacement doesn't break compatibility.

It's convenient to group parameters:

• Platform: device model, board (revision), chipset, CPU (family and exact model), socket.
• Memory and storage: RAM type (DDR generation, frequency, capacity, module arrangement), SSD/HDD (form factor, interface, controller, model), encryption requirements.
• Network and wireless modules: Ethernet controller(s), throughput, Wi‑Fi/BT module and its version, presence of fiber or additional ports.
• Power and chassis: chassis type, PSU (power, connectors, efficiency), cables, fasteners, rails, blanks.
• Options: GPU (if any), card reader, additional controllers and ports, fingerprint reader and other integrated modules.

Separately lock completeness. If one batch includes mounting hardware and another doesn't, deployment standards are broken.

Items that affect images and compatibility

IT cares about identical hardware not for its own sake but because images, drivers and servicing depend on it. Therefore explicitly record items that are often changed quietly but can break installation, security and support.

Minimum items to lock:

• BIOS/UEFI: vendor, branch and version (or acceptable range), default settings, update policy.
• Security: TPM (version 2.0 and vendor), Secure Boot (enabled/disabled), UEFI/Legacy modes.
• Storage controllers: controller model, AHCI/RAID mode, RST/RAID driver, NVMe support.
• Device identifiers: requirement to preserve Device IDs for key devices (e.g. network and storage controllers) so your driver pack stays intact.
• Driver package: composition and version of the driver set, responsibility for compatibility checks after allowable replacements.

Example: you have a single image for 500 PCs. In a new batch the supplier swaps the Wi‑Fi module to a different one that is "better and cheaper." Formally the same class of device, but the image lacks the driver, automatic network connection fails, and deployments in branches stop. If the specification had pre‑locked the module model and replacement rules (only with written agreement and testing), the risk drops significantly.

If the supplier also performs assembly and support (as local manufacturers and integrators like GSE.kz do), add a contractual obligation to maintain a "compatibility matrix" by batch: which BIOS and driver versions correspond to which hardware revision and how this is confirmed at acceptance.

Terms and annexes you need in the contract to avoid disputes

A clause "supply PCs to specification" is not enough for a real configuration lock over 12–24 months. You need definitions and annexes understood the same way by procurement, IT and the supplier. Otherwise any replacement will be "equivalent" only in words and image and spare‑part compatibility will fall apart.

BOM as an annex: what to attach

The main annex is the BOM (list of components). It should contain not only general characteristics (e.g. "SSD 512 GB") but specific items: vendor, model, part number, revision (if applicable), key parameters and rules for allowed replacements.

The BOM must have a version and date. The contract should state that deliveries follow BOM version X and any adjustment is issued as a BOM change with a new version number and agreement.

Terms to define explicitly in the contract text

Disputes often start where words are used "by habit." It's useful to define core terms:

• Delivery batch: a single shipment with one set of documents and a fixed composition according to the BOM.
• Series: a group of items with common identifiers (e.g. serial number ranges) and identical hardware base.
• Revision: a board or component version that affects compatibility (drivers, BIOS, connectors, fastenings).
• Design change: any change that may impact OS images, drivers, stability or repairability.
• Equivalent replacement: replacement allowed only if pre‑specified criteria are met.

Equivalence should be described by verifiable attributes rather than "not worse": same chipset class, same network controller, compatible driver set, no BIOS feature changes, identical interfaces and fastenings, and preservation of declared operating modes.

Documents that prove batch composition

To avoid arguing later, define in advance what proves conformity to the agreed configuration:

• shipment specification listing components per the BOM (and BOM version);
• product datasheet or factory document with serial numbers and base parameters;
• packing/shipping lists linking serial numbers to positions;
• acceptance report noting BOM conformity and recording deviations.

If the supplier is a manufacturer and integrator like GSE.kz, specify that they provide documents proving hardware base unchanged within the agreed BOM version and notify in advance about changes that could affect the image, drivers or service procedures.

How to agree requirements: step‑by‑step process

To make a configuration lock effective for 12–24 months, start with procedure rather than wording: decide what counts as "the same" configuration, how inevitable component replacements are handled and who confirms compatibility.

Agreement process

1. Create a base BOM and a "configuration passport." Put precise models of key components, BIOS/UEFI versions, network and video modules, storage, PSUs, and driver/image requirements into annexes.

2. Split parameters into two groups: "must not change" (items that break images, compatibility or repair) and "may change within limits" (for example, replacing an SSD with an equivalent controller and characteristics if it doesn't affect drivers or encryption).

3. Agree a "change window." Fix how often the supplier may propose replacements (e.g. quarterly or only upon EOL) and state that without the customer's written consent changes do not apply to already confirmed configurations.

4. Define compatibility testing. Specify who runs tests, on which bench, mandatory tests (image install, driver checks, stress test, peripherals), test cycle duration and who pays for samples and work.

5. Set notifications and documentation. Specify advance notice periods (e.g. 30–60 days) and format: official letter + updated BOM with changed lines highlighted, reason for replacement and confirmation of equivalence.

Then lock what constitutes "a same‑configuration batch": identical BIOS versions, identical device identifiers, unchanged drivers. This reduces the chance that the next delivery "won't boot" on your standard image.

Example: an organisation procures workstations and servers for 18 months. The supplier wants to replace the network controller due to discontinued parts. They send notice and a new BOM, provide 2 test samples, and the customer verifies corporate image deployment and domain behaviour. Only after written consent does the change go into subsequent deliveries.

The contract should require updating:

• the BOM and configuration passport;
• the driver list and versions;
• BIOS/UEFI version and default settings;
• test plan and protocol of results.

This procedure is useful both for buying typical PCs and for supplies from local manufacturers with serial product lines, where batch stability and service rely on disciplined change management throughout the contract term.

Managing changes: how not to break compatibility

Even with a configuration locked for 12–24 months, changes still happen: items go EOL, shortages occur, board revisions are released, new BIOS versions appear. The problem isn't change itself but when it's "silently" introduced into deliveries and compatibility of images, drivers and spares breaks.

Describe a simple, mandatory Change Request (CR) process in the contract. It should state who can initiate changes (supplier, manufacturer, customer), acceptable reasons (EOL, shortage, backward‑compatible improvements), review timelines and the rule "without customer approval deliveries follow the previous specification."

What a Change Request must include

To make decisions fast and clear, the request should not be "we replaced the SSD" but should come with evidence. Ask that CRs include:

• comparison of old and new components (model, revision, key parameters, compatibility);
• updated BOM and list of affected part numbers;
• list of affected drivers, BIOS/firmware and utilities;
• test report (minimum: image install, network, disks, sleep/wake, load);
• transition plan: effective date and which batches the change applies to.

This is crucial when equipment goes to standard workplaces or branches where a different controller leads to manual reconfiguration of hundreds of PCs.

Customer rights and transition rules

State that the customer may accept the change, reject it, request an alternative or condition approval on holding deliveries until tests complete. Also define a transition period: forbid mixing revisions within a single batch and, if necessary, at a single site (for example, "only one revision per branch"). This avoids having two image variants and multiple spare‑part stocks.

Identical batches: acceptance, labelling and control

The requirement "identical batches" should be specified not by "same model" but by composition and revision. Otherwise the next delivery may contain a different Wi‑Fi module, SSD or motherboard revision, and the set of drivers, disk image or spare parts will no longer match. This extends the configuration lock idea: you lock not the name but what the device is actually built from.

To avoid disputes at acceptance, predefine what "identical" means. Usually it's the same BOM, the same critical node revisions and the same BIOS/UEFI version (or allowed version range).

Batch labelling and identification

Require each delivery to have a "batch passport" so devices can be quickly matched to documents:

• device serial numbers (in documents and on the chassis);
• batch identifier (on the box and in the waybill);
• BOM version and revision numbers of key nodes (in the batch passport);
• BIOS/UEFI version and build date (in the batch passport);
• note if the delivery is a replacement/supplement to an existing batch.

This way you can distinguish a truly identical batch from a "close enough" one without opening every unit.

Acceptance rules: how to check without full teardown

Selective inspection plus comparison to a reference unit usually works. For example, when a hospital receives an add‑on shipment to previously deployed workstations, the inspector checks the batch passport and spot‑checks several units (via system info, component labels, manufacturer inventory data).

Predefine sample size, list of parameters to check (BOM, revisions, BIOS/UEFI, network/graphics modules) and what counts as the reference: the configuration in the contract annex or "the first delivered unit accepted without remarks."

What to do on deviations

If a deviation is found, follow a pre‑agreed scenario. The contract should state that unauthorized deviation from BOM/revision is a delivery nonconformity, even if the specifications look similar.

Typical steps:

• issue a nonconformity report listing differences;
• block commissioning of the batch until resolved;
• replace with conforming units or agree an adjustment through the change process;
• set remediation deadlines and liability for downtime.

Image compatibility: drivers, BIOS and tests

If you deploy machines from a golden image, any unnoticed hardware change quickly causes downtime: the image won't install, drivers won't match, encryption breaks, peripherals act unpredictably. Therefore specify OS, driver and BIOS/UEFI rules explicitly when locking configuration for 12–24 months.

What to include in documentation

Stability of versions matters most. In the contract and annexes lock:

• The golden image as an artifact: OS build and edition, language, disk layout, enabled roles, security policies, required agents (EDR, DLP, monitoring), encryption settings (e.g. BitLocker and key storage).
• Driver model: one approved driver pack for the lock period or separate driver packs per hardware revision with a clear rule which pack applies to which revision.
• BIOS/UEFI: base version, allowed version ranges and ban on "silent" updates without agreement. Define which BIOS changes are critical (Secure Boot, TPM, SATA/NVMe mode, virtualization, boot order).
• Notification regime: how many days the supplier must warn about necessary changes due to EOL and who approves the new variant (IT, security, image owner).

Minimum test set before mass rollout

Agree on a short set of checks and acceptance criteria. Usually enough:

• image install and first boot without manual tweaks;
• domain join, GPO application, user login;
• network: Ethernet and Wi‑Fi, VPN (if used), access to key services;
• peripherals: printer, headset, camera, second monitor or docking station (as per your scenario);
• sleep/hibernation and wake‑up, plus check of encryption and key recovery.

For local manufacturers and integrators like GSE.kz it's useful to record test results per revision. Then even allowed component changes keep deployments and support predictable.

Spare parts and service: so repairs don't become rebuilds

When locking configuration for 12–24 months, service must follow the same logic. Otherwise a repair becomes a hidden platform change: a different controller, another memory module, a new board revision — and the standard image, drivers or even fastenings start to conflict.

First agree which nodes are critical for compatibility and must be fixed as service items with clear part numbers. Typically: SSD (and interface), RAM (type/frequency/module capacity), motherboard (revision or list of allowed revisions), PSU and fans (form factor, connectors, power). For all‑in‑ones, separate screen and touch module items (panel, controller, cables).

Then specify availability windows and service times in measurable terms. This is crucial for regions with long delivery times.

Useful things to lock:

• response time by city/region;
• recovery time (repair or replacement) for typical faults;
• where the spare pool is stored (customer, supplier, hybrid);
• logistics rules: who collects, who packs, who bears transit risk;
• repair report format: what was changed, to what, with which part numbers.

A separate warranty clause: allow alternatives only through an "approved replacement list" with compatibility checks: same interface, same driver set, no degraded performance, preserved functions (TPM, network interfaces, ports). For government and large organisations this reduces the chance that a repair will drop part of the fleet out of the unified image.

Keep a unified part catalog for service requests and warehouse accounting: base configuration, service items, approved equivalents. Manufacturers and integrators with lifecycle control and service networks, like GSE.kz, can often establish this mapping more easily because product lines and service are tied to common specifications.

Common contract mistakes and how to avoid them

A typical problem: the contract says "supply PC model X" and six months later a "same" PC arrives with another network card, Wi‑Fi module or SSD. Procurement sees it as compliant, but IT gets broken drivers, changed images, complicated repairs and inventory.

Error 1: only fix the marketing name and basic specs. If the contract lists just CPU/RAM/SSD, the supplier can change internal parts without breaching text. Ask for a BOM annex with exact part numbers of key nodes (motherboard, network controller, Wi‑Fi/BT, TPM, SSD, PSU, panel for all‑in‑ones), BIOS/UEFI versions and, where relevant, board revisions.

Error 2: allow "equivalent" without criteria. If replacements are allowed but equivalence isn't defined, image and driver compatibility becomes a lottery. Better to allow replacements only through BOM change management: preserve interfaces, meet performance, not affect image compatibility, prove with tests and obtain written agreement.

Error 3: don't forbid mixing revisions in one delivery or site. Even acceptable individual replacements result in multiple revisions that need different drivers or BIOS settings. Require homogeneous batches and state "transition to a new revision in a separate batch."

Error 4: fail to define who tests changes on images and peripherals. If not set, the supplier may deem a replacement acceptable without your tests. Specify who tests, on which reference images, which peripherals are checked (printers, scanners, tokens, docking stations) and acceptance criteria (boot, network, domain, encryption, sleep).

Error 5: forget spare part availability and sameness in warranty replacements. Without these the "repair" becomes a rebuild. State minimum availability periods (e.g. contract term plus N months) and require warranty replacements to preserve the approved configuration or follow the approval procedure.

If you buy from a local manufacturer and integrator like GSE.kz, agree BOM format, change notification rules and pre‑series tests up front. That's usually cheaper than supporting a heterogeneous fleet of similar but different batches.

Quick checklist and next steps before signing

Before signing, walk through the contract as a risk checklist. The goal: in 6–18 months you should receive the same machines and your images, drivers and spares should still fit without surprises.

Check that the contract and annexes explicitly record:

• the reference specification (BOM) with exact models of key components and allowed replacements;
• BOM change management: Change Request, notice periods, mandatory agreement and the right to reject changes;
• acceptance rules for identical batches: what is checked (serials, revisions, completeness) and what documents must be attached;
• batch labelling and configuration identification requirements;
• compatibility package: BIOS/UEFI versions, driver list and criteria for when an OS image is considered compatible.

Also include a minimal set of annexes: reference specification, approved driver pack (with versions and dates), batch labelling requirements and templates for acceptance reports.

To avoid argument on the first mass delivery, include a pilot batch. Its purpose is not quantity but verifying repeatability.

Mass rollout criteria can be:

• the pilot passes acceptance with no BOM or labelling deviations;
• the OS image deploys on 100% of devices, no unknown devices in Device Manager, no critical errors;
• BIOS and driver versions match the agreed list and updates follow the approval procedure;
• confirmed availability of key spare parts and clear replacement rules.

Next step — agree a reference configuration and delivery schedule with the integrator or manufacturer. If you work with GSE.kz (gse.kz), link this to their serial lines of PCs, all‑in‑ones and servers and immediately lock the change process, image compatibility requirements and service rules.