Puolustusalan ohjelmistotoimittajien arviointi: teknisen due diligencen opas hankintaupseereille

Puolustusalan ohjelmistohankinnat epäonnistuvat useammin toimittaja-arviointivaiheessa kuin missään muussa hankintasyklin vaiheessa. Ei siksi, että hankintaupseereilta puuttuisi huolellisuutta — vaan siksi, että heidän käyttämänsä arviointikehykset on suunniteltu kaupalliselle IT:lle, jossa riskit ovat palvelukatkoksia, kustannusylityksiä ja integrointiongelmia. Puolustushankinnat lisäävät täysin erilaisen riskiluokan: turvallisuusvikoja, joilla on operatiivisia seurauksia, toimitusketjun altistumista vihollisen tiedustelulle ja sopimuslukuja, jotka ilmenevät vasta kun järjestelmää tarvitaan eniten.

Tämä opas tarjoaa strukturoidun teknisen due diligence -kehyksen, joka on suunniteltu erityisesti puolustusalan ohjelmistotoimittajien arviointiin. Se kattaa kahdeksan arviointialuetta: miksi kaupalliset lähestymistavat epäonnistuvat, miten arvioidaan tekninen arkkitehtuuri, mitkä turvallisuussertifikaatit todella merkitsevät, lähdekoodin escrow-vaatimukset, SLA- ja tukiarviointi pitkäsyklisille ohjelmille, asiakasviitteiden varmennus, PoC-rakenne sekä sopimusoikeudet dataan.

Miksi kaupallinen toimittaja-arviointi epäonnistuu puolustuksessa

Kaupalliset toimittaja-arviointikehykset on rakennettu neljän riskin ympärille: toimittaako toimittaja luvatut ominaisuudet, ilmoitetulla hinnalla, integroituina olemassa olevaan pinoon, hyväksyttävällä käytettävyydellä? Nämä ovat todellisia riskejä — mutta eivät puolustusalan ohjelmistohankintojen hallitsevia riskejä. ITAR-vaatimustenmukaisuus, pitkäikäisyysvaatimukset (15–20 vuoden käyttöikä), operatiivinen jatkuvuus vihamielisessä ympäristössä ja akkreditointi luokitustasolla ovat pakollisia arviointidimensioita, jotka kaupalliset kehykset järjestelmällisesti sivuuttavat.

Teknisen arkkitehtuurin tarkastelu

Arkkitehtuuridokumentaation laatu on yksi luotettavimmista toimittajan insinööriosaamisen varhaisista indikaattoreista. Pyydä jokaiselta lyhyen listan toimittajalta: komponenttiarkkitehtuurikaavio, käyttöönottarkkitehtuurikaavio, API-dokumentaatio, Software Bill of Materials (SBOM) SPDX- tai CycloneDX-muodossa sekä Architecture Decision Records (ADRs).

Turvallisuussertifikaattien tarkistus

ISO 27001 sertifioi tietoturvallisuuden hallintajärjestelmän. SOC 2 Tyyppi II arvioi operatiiviset turvallisuuden hallintakeinot toimintakauden aikana. ITAR-vaatimustenmukaisuus ei ole sertifikaatti vaan lakisääteinen velvoite: koalitionjakamisvaatimuksia sisältäville ohjelmille tarvitaan riippumaton oikeudellinen tarkastus. NATO AQAP-2110 on NATOn standardi ohjelmiston laadunhallinnalle, jota vaaditaan toimitettaessa ohjelmistoa NATO-ohjelmalle.

Lähdekoodin escrow ja liiketoiminnan jatkuvuus

Lähdekoodin escrow on sopimusjärjestely, jossa toimittaja tallettaa lähdekoodin, koontiskriptit, testisarjat ja dokumentaation puolueettomalle escrow-agentille. Puolustusalan ohjelmille, joilla on 15–20 vuoden käyttöikä, tämä on liiketoiminnan jatkuvuusmekanismi. Määrittele sopimuksessa: talletuksen laajuus, päivitystiheys, laukaisuehdot, koonnin toistettavuuden varmennus ja akkreditoitu escrow-agentti.

Tuen ja SLA:n arviointi

Puolustusalan SLA-arvioinnissa on katettava neljä ulottuvuutta: vastausaikasitoumukset vakavuusasteittain (P1 tunneissa, ei päivissä), tietoturvapaikkaustahti, pitkäaikaistuen ikkunan pituus (sotilasjärjestelmät tarvitsevat vähintään 10–15 vuotta) ja tukitiimin kapasiteetti kriisitilanteissa.

Asiakasviitteiden varmennus

Toimittajan toimittamat viitelistat ovat lähtökohta, eivät päätepiste. Ota suoraan yhteyttä ohjelmapäällikköön tai tekniseen johtajaan viiteorganisaatiossa. Esitä operatiivisia kysymyksiä: mikä epäonnistui käyttöönoton aikana? Mikä kesti kauemmin kuin toimittaja lupasi? Valitsisitko tämän toimittajan uudelleen? Priorisoi viitteet, joilla on samankaltaiset käyttötapaukset ja luokitustasot.

Pilotin ja PoC:n rakenne

Puolustettava PoC vaatii: etukäteen sovitut mitattavat onnistumiskriteerit, realistisen testiympäristön, joka heijastaa operatiivisia rajoitteita, pisteytysohjeen, puolueettoman arviointitiimin erillään hankintapäätöksentekijöistä sekä epäonnistumisten dokumentointiprotokollan.

Sopimusnäkökohdat: IP, dataoikeudet ja ITAR-alavirta

Kriittiset sopimuslausekkeet: IP-omistusoikeudet julkisilla varoilla kehitetylle ohjelmistolle, muokkausoikeudet ilman toimittajan hyväksyntää, oikeudet operatiiviseen dataan ja johdettuihin tiedustelututkimuksiin, ITAR-vaatimustenmukaisuusvelvoitteet alihankkijaketjussa sekä poistumis- ja siirtymismääräykset.