
Vuosien ajan FedRAMP-valtuutuspaketti oli ennen kaikkea yhtä asiaa: paljon dokumentaatiota. Satojen sivujen järjestelmän tietoturvasuunnitelmia, hallintakeinojen kuvauksia Word-pohjissa, luetteloita ja testituloksia Excelissä. Vielä vuonna 2025 Rev5-valtuutukset perustuivat lähes kokonaan näihin pohjiin, vaikka OSCAL oli jo pitkään ollut olemassa koneluettavana vaihtoehtona.
Tammikuussa 2026 FedRAMP käynnisti suunnanmuutoksen RFC-0024:llä: valtuutustiedot on määrä toimittaa jäsenneltynä, koneluettavana datana asiakirjapinojen sijaan. Viranomaisille tämä tarkoittaa nopeampia tarkastuksia ja vertailukelpoisia paketteja. Pilvipalvelujen tarjoajille se tarkoittaa siirtymää, joka kannattaa suunnitella mieluummin aikaisin kuin myöhään.
Tie lopulliseen sääntöön on itsessään oppitunti julkisesta standardoinnista. Alkuperäisessä ehdotuksessa asetettiin tiukat takarajat jo 30. syyskuuta 2026. Kommentointijakson aikana, joka päättyi 11. maaliskuuta 2026, palveluntarjoajat pyysivät lähes yksimielisesti lisää valmistautumisaikaa.
FedRAMP reagoi: maaliskuussa 2026 julkaistu välitulos siirsi määräaikoja myöhemmäksi. Kaikki koottiin sitten lopullisiin Consolidated Rules for 2026 (CR26) -sääntöihin, jotka julkaistiin kesäkuun 2026 lopussa ja jotka jakavat vaatimukset sertifiointiluokkiin A–D. Viesti on ennallaan: koneluettavuus on tulossa – vain aikataulu muuttui realistisemmaksi.
Ratkaiseva on lopullinen CR26-aikataulu; aiemmat väliluonnokset luokkakohtaisine muototakarajoineen on korvattu.
Suunnittelun kannalta tärkeää: jokainen, joka tavoittelee uutta valtuutusta vuonna 2027, työskentelee käytännössä uusien formaattien parissa jo vuonna 2026 – paketin valmistelu, puuteanalyysit ja testaus alkavat hyvissä ajoin ennen takarajaa.
Lopulliset säännöt kiinnittävät koneluettavuuden JSON-dokumentteihin, jotka validoituvat julkaistuja FedRAMP-skeemoja vasten – FedRAMP ei määrää tiettyä laadintatyökalua. Käytännössä tie kulkee OSCALin kautta: NIST-standardi on vakiintunut avoin tietomalli juuri tälle sisällölle, FedRAMP tekee yhteistyötä OSCAL-yhteisön kanssa pohjien ja resurssien osalta, ja työkaluekosysteemi kasvaa siellä nopeimmin – OSCAL-työkalujen kenttää käsittelevä artikkelimme antaa yleiskuvan.
Sitä, miten dokumenttimallit sopivat yhteen – katalogista profiiliin, SSP:hen ja arviointiin – käsitellään johdannossamme Mikä on OSCAL?
Jäsennellyn vaatimustenmukaisuusdatan parissa tekemämme työn perusteella yksinkertainen järjestys on osoittautunut toimivaksi. Se toimii riippumatta siitä, onko kohteena FedRAMP vai jokin muu ohjelma, jossa on koneluettavuutta koskevia vaatimuksia.
Juuri tätä varten rakennamme Secania: alustaa, jossa valtuutustiedot ovat jäsenneltyjä alusta alkaen – lähteineen, hyväksyntöineen ja historioineen. Jos suunnittelet siirtymää, ota meihin yhteyttä.
Secani yhdistää rajaukset, todisteet, tehtävät ja tekoälyagentit yhteiseen työtilaan.
OSCAL muuttaa vaatimustenmukaisuusasiakirjat jäsennellyksi dataksi: kahdeksan asiakirjamallia, kolme tiedostomuotoa ja ekosysteemi, josta on tulossa sääntelyn standardi.
OLIR tarjoaa vastaavuussisällön ja sen hallinnan. OSCAL tarjoaa koneluettavan rakenteen, jonka avulla näitä vastaavuuksia voidaan käyttää puuteanalyysissa, näytön uudelleenkäytössä ja muutosvaikutusten työnkuluissa.
Jokainen OSCAL-validaattori väittää validoivansa OSCALia. Me luettelimme kaikki 348 rajoitteen esiintymää NIST:n lähteissä, todistimme tai rajasimme pois jokaisen ja ajoimme sitten vertailun Java CLI:tä vastaan oikeasti.