
I många år var ett FedRAMP-auktorisationspaket framför allt en sak: en stor mängd dokument. Systemsäkerhetsplaner på hundratals sidor, beskrivningar av säkerhetsåtgärder i Word-mallar, förteckningar och testresultat i Excel. Så sent som 2025 byggde Rev5-auktorisationer nästan helt på dessa mallar – trots att OSCAL sedan länge fanns som det maskinläsbara alternativet.
I januari 2026 inledde FedRAMP kursändringen med RFC-0024: auktorisationsdata ska lämnas in som strukturerade, maskinläsbara data i stället för som buntar med dokument. För myndigheter innebär det snabbare granskningar och jämförbara paket. För molntjänstleverantörer innebär det en övergång som är betydligt bättre att planera tidigt än sent.
Vägen till den slutliga regeln är i sig en lärdom i offentlig standardisering. Det ursprungliga förslaget satte fasta brytpunkter redan den 30 september 2026. Under remissperioden, som avslutades den 11 mars 2026, bad leverantörerna nästan enhälligt om mer tid för förberedelser.
FedRAMP lyssnade: det preliminära utfallet som publicerades i mars 2026 sköt fram tidsfristerna. Allt konsoliderades sedan i de slutliga Consolidated Rules for 2026 (CR26), som publicerades i slutet av juni 2026 och som delar in kraven i certifieringsklasserna A till D. Budskapet är oförändrat: maskinläsbarheten kommer – det är bara tidsplanen som har blivit mer realistisk.
Det som gäller är den slutliga tidsplanen i CR26; tidigare preliminära utkast med formatbrytpunkter per klass har ersatts.
Viktigt för planeringen: den som siktar på en ny auktorisation 2027 arbetar i praktiken med de nya formaten redan 2026 – förberedelse av paket, gapanalyser och tester börjar långt före brytpunkten.
De slutliga reglerna förankrar maskinläsbarheten i JSON-dokument som validerar mot publicerade FedRAMP-scheman – FedRAMP föreskriver inget specifikt verktyg för att ta fram dem. I praktiken går vägen via OSCAL: NIST-standarden är den etablerade öppna datamodellen för just detta innehåll, FedRAMP samarbetar med OSCAL-communityn om mallar och resurser, och det är där verktygsekosystemet växer snabbast – vårt inlägg om landskapet av OSCAL-verktyg ger en översikt.
Hur dokumentmodellerna hänger ihop – från katalog till profil till SSP och bedömning – beskrivs i vår introduktion Vad är OSCAL?
Utifrån vårt arbete med strukturerade data för regelefterlevnad har en enkel ordningsföljd visat sig fungera. Den fungerar oavsett om målet är FedRAMP eller ett annat program med krav på maskinläsbarhet.
Det är precis detta vi bygger Secani för: en plattform där auktorisationsdata är strukturerade från början – med källor, godkännanden och historik. Om ni planerar övergången, prata med oss.
Secani kopplar samman omfattningar, bevis, uppgifter och AI-agenter i en gemensam arbetsyta.
OSCAL gör efterlevnadsdokument till strukturerade data: åtta dokumentmodeller, tre format och ett ekosystem som håller på att bli standard för regelverk.
OLIR tillhandahåller mappningsinnehåll och styrning. OSCAL ger den maskinläsbara strukturen för att använda mappningarna i gapanalyser, återanvändning av underlag och arbetsflöden för konsekvensanalys vid förändringar.
Varje OSCAL-validator påstår sig validera OSCAL. Vi räknade upp alla 348 förekomster av constraints i NIST:s källor, bevisade eller undantog var och en och körde sedan jämförelsen mot Java-CLI:t på riktigt.