Hantera regelverk och lagar genom affärsarkitektur

Du sitter tryggt på plats 20F på väg till Paris. Du hör fullgas och ni rullar startbanan. Efter lättning hörs en dov smäll, flygplanet girar kraftigt men rätas snabbt upp. En motor har stannat och piloten har rätat upp flygplanet med sidroder.

Återvändande och landning med en motor går enligt rutin. Lagar och standarder fungerade: flygplats, trafikledning, och flygplan var rätt utvecklat och implementerat. Operativt fungerad SAS, Swedavia och Luftfartsverket säkert, flygplanet var säkert och besättningen rätt tränad. Allt var förberett för att det kan gå fel.

Regelverk är inte regelvärk, det är samhällets skydd för dig. Det kan röra penningtvätt, finansmarknadsfunktion, eller samhällsviktiga funktioner. Regelverk dyker inte upp som en blixt från en klarblå himmel. Arbeta proaktivt och skapa inte en ineffektiv kravmaskin i jakten på paragrafer. Ension sätter ihop regler i en modell som ger samordnade krav mot dig

Ökad komplexitet och föränderlighet är svåra utmaningarna för företag och organisationer, inte minst de legala kraven. För t ex bank och finans finns en ständig mängd av nya och förändrade krav. GDPR, AML, MIFID, IDD, Dislcosureförordning, Taxonomiförordning och DORA är exempel.

För myndigheter, kommuner och regioner är det Förvaltningslagen, Hälso- och sjukvårdslag, Socialtjänstlagen,  Dataskyddsförordningen (GDPR), Patientdatalagen (PDL), cybersäkerhetslagen (NIS2), Arkivlag , Offentlighets- och sekretesslag, och Säkerhetsskyddslagen.

Svensk rätt

Svensk rätt är uppbyggd som en pyramid. Ju längre ner i pyramiden du kommer, desto mer detaljerat blir det:

• Lag (Riksdag): Sätter ramarna och målen (t.ex. Arbetsmiljölagen).
• Förordning (Regering): Förtydligar lagen och ger myndigheter rätt att skriva regler.
• Föreskrift (Myndighet): Detaljerade "skall-krav" som är juridiskt bindande, Vem som 
• Allmänna råd & Vägledningar: Myndighetens tolkning av hur du kan göra för att leva upp till kraven (ej bindande)

EU-rätt

EU-rätten är en överstatlig ram. Här är EU:s normhierarki, från de stora principerna ner till de tekniska detaljerna:

• Primärrätt (Fördragen): Detta är EU:s "grundlagar" med övergripande spelreglerna för EU.
• Sekundärrätt (Härledd rätt). Det är här de flesta företag hittar sina faktiska krav. Det finns tre huvudtyper:
  • Förordningar (Regulations): En lag som ej omsätts i svensk lag. Den gäller direkt.  Exempel: GDPR eller AI Act.
  • Direktiv (Directives): Regler som måste implementeras i nationell lagstiftning. Exempel: NIS2-direktivet.
  • Beslut (Decisions): Bindande i sin helhet, men ofta riktade till specifika mottagare.
•  Icke-bindande rätt (Soft Law). Rekommendationer, yttranden och Vägledningar (Guidelines): Myndigheter som ESMA (finans) eller ENISA (it-säkerhet) ger ut detaljerade riktlinjer för hur förordningar och direktiv ska tolkas.

1.3. Standarder

Harmoniserade standarder (Den tekniska nivån). När ett EU-direktiv (t.ex. Maskindirektivet) säger att en produkt måste vara "säker", blir det ofta för luddigt för en nulägesanalys. Då använder man harmoniserade standarder. Standardiseringsorgan: CEN, CENELEC och ETSI tar fram standarder på uppdrag av EU. Om du följer den harmoniserade standarden (t.ex. en specifik ISO- eller EN-standard), anses du automatiskt uppfylla de lagkrav som direktivet ställer.

För att uppnå Affärsvärdighet och Cybervärdighet krävs en symbios där juridik, teknik och ledning samverkar. Om du tar in jurister och säkerhetsexperter i ett sent skede har du redan byggt in brister i juridik och säkerhet. I min värld är compliance by design lika viktigt som safefty & security by design.

Juristen och enterprise-arkitekten översätter lagkrav till krav mot organisation och system. Genom att proaktivt tolka t.ex. AI-förordningen kan juristen ge arkitekten "fria tyglar" inom lagens ramar, Genom att bygga in lagkraven i  arkitekturen, säkerställer arkitekten att tekniken blir  lagligeffektiv och skalbar. När juristen intygar att lagen följs och arkitekten bevisar detta blir ledningen trygg. Cybervärdighet och affärsvärdighet skapas.

Ension analyserar lagen i förhållande till processer och funktionell arkitektur. 

1. Skapa atomär lag. För att i en modell ska bli spårbar mot lagen bryts lagen ner till sina minsta delar. Detta steg skapar grunden för den juridiska analysen av lagen och regeldetaljer att skapa spårbarhet mot.
2. Skapa Digital modell av lagen. Denna grundas på ett modelleringsspråk för Enterprisemodellering, Archimate. Här uttrycks lagen i förhållande till affärsentiteter som finansmarknadsbolag eller processer som duedilligense eller riskhantering. Här kan du som enterpricearkitekt kommunicera med juristen och lagen kan kommuniceras till ledningen.
3. Relatera krav till din organisation. Da har ju i föregående steg byggt modell av din organisation: Affärsarkitektur, processer och funktionell arkitektur. Nu nyttjas modellen av lagen för att mappa lagen mot modellen av din organisation.  
4. Justera Safety & Security by design. En del av de krav du hittat ställer krav på riskhantiring i din organisation, t ex NIS2. Ension har skapat en process för Safety & Security by Design. Denna beöver du justera för t ex Privacy by design i GDPR eller riskidentifiering enligt AI-förordningen 
5. Kör Safety & security by design. Kör den prrocess ension skapat och du justerat så att du följer dina legala krav både direkta och indirekta.

När detta är genomfört är det bara att fortsätta med Safety & Security by design.

I intressentanalysen har du hittat de grunden, lagarna specifika för din verksamhet. Tänk på att det även finns andra lagar som generellt träffar alla.

Här är juristen expert. Affärsmodell, processer och funktionell arkitektur hjälper er att hitta dokument. Men glöm inte att nyttja AI. Nedan ser ni resultatet för Gipsat.nu på en minut

Genom att mata in tidigare framtagen affärsmodell, processer och funktionell arkitektur kartlade vi tio kritiska lagrum på 60 sekunder.  Detta hade tidigare tagit timmar. Men som du ser fick jag inte med detaljerna, så här kommer dom,

Nu skall du spegla lagen i modellen, du ska segmentera regelverket ner i detaljerade paragrafer, stycken och punkter.  För varje sådan detaljerad rättslig bestämmelse  skapar du sedan ett unikt objekt. När detta är gjort kan du senare skapa spårbarhet till exakt rätt detalj i lagen, precis på det format regeln är skriven.

Här översätts lagens detaljkrav till till krav mot en generisk verksamhet beskriven med ett ramverk för att skapa enterprisemodeller. På denna site används genomgående ramverket archimate, så det används här också.

Varför en generisk verksamhet? Jo, lagstiftningekrivs ju mot verksamheter, inte direkt mot din verksamhet utan mot en generisk beskrivning av en verksamhet. Lagstiftaren syfte är att du ska kunna identifira på viket sätt du är en sådan verksamhet och om så är fallet vilka regler som gäller. Så, nu ska vi låtsas att lagsiftaren är en enterprisearkitekt. 

Man kopplar samman den råa texten med visuella krav-objekt. För varje artikelpunkt skapas objekt för kravet samt objekt för vad kravet riktas mot. Det är i ArchiMate Requirement-element i affärslager (Business Layer) och applikationslager (Application Layer). Exempelvis kan ett krav om "webbplatsinformation" (artikel 6) kopplas till både en affärsprocess och företagets externa webbportal.

För att förstå detaljetrade regler och kunna översätta dem till krav är det viktigt att titta igenom hela hierarkanin av regler.

Ett konkret exempel: Ska du förstå vilken säkerhet du ska hitta risker för behöver du ofta gå uppåt i hierarkin, det kan vara på traktatsnivå, skäl eller förarbetetn du måste titta. När du gör en riskanalys avseende cybersäkerhetslagen så är det samhällsviktiga tjänster som ska fungera. I det inledande exemplet så är det passagerare och besättning som ska överleva. För flygplanet utrrycks detta i luftfartslagen:

"Ett luftfartyg anses luftvärdigt om det är konstruerat, tillverkat, utprovat, utrustat och underhållet på ett sådant sätt samt har sådana flygegenskaper att flygsäkerhetens krav är uppfyllda."

Det säger mycket av vad du skall uppnå för flygplanet. Liknande formuleringar finna i alla laghierarkier.

Innan man implementerar måste man förstå vem lagen adresserar. En förordning pratar ofta om legala roller (t.ex. "Finansmarknadsaktör" eller "Finansiell rådgivare"). Aktivitet: Identifiera vilka entiteter i den egna koncernen (t.ex. Bens fonder AB eller Bens liv AB) som ikläder sig de olika legala rollerna. Kanaler: Mappa upp var informationen ska flöda – sker det via en distributörs webbplats, rådgivarens fysiska möte eller fondbolagets portal?

• Nu lämnar vi juridiken och tittar på den faktiska operativa verkligheten. Hur ser våra flöden ut idag?

• Aktivitet: Rita upp verksamhetens aktörer, tjänster och flöden. Här identifieras interna enheter och externa parter (t.ex. Morningstar för data eller MFEX för fondhandel).

• Syfte: Att skapa en "karta" över nuvarande nuläge för att kunna se var lagkraven kommer att "landa" i vardagen.

Detta är slutsteget och själva "kvittot" på analysen. Här sammanförs kravmassan med verksamhetsmodellen i en stor spårbarhetsmatris.

• Aktivitet: Dra kopplingar (Associationer/Realisationer) mellan de specifika Artiklarna (vänster i bild), de tolkade Kraven (mitten) och de faktiska Processerna/Systemen/Aktörerna (höger).

• Resultat: Du får en visuell och sökbar karta där du kan svara på frågor som: "Vilka processer påverkas om Artikel 9 ändras?" eller "Har vi täckt upp alla krav i Artikel 4 för vårt bolag i Bank-segmentet?"

Strategisk fördel: Genom att göra analysen på detta sätt blir regelverksefterlevnad (compliance) inte ett engångsprojekt, utan en integrerad del av företagets arkitektur. När nästa uppdatering av förordningen kommer, ser du direkt i modellen exakt vilka delar av din affärsmodell som behöver justeras.

Syftet med en sanktionsriskanalys är att identifiera de specifika riskerna för att din organisation drabbas av administrativa sanktionsavgifter, skadat rykte eller andra affärsmässiga konsekvenser på grund av bristande regelefterlevnad.

Med Cybersäkerhetslagen (NIS2) som ett tydligt exempel, fokuserar analysen på att identifiera glappen mellan verksamhetens faktiska förmåga och lagens explicita krav (exempelvis artikel 21 om riskhanteringsåtgärder). Resultatet blir en prioriterad åtgärdslista som minimerar risken för ingripanden från tillsynsmyndigheter, vilka under det nya regelverket kan resultera i kännbara ekonomiska straff.

Cybersäkerhetslagen (NIS2) är ett riskdrivet regelverk, men det är inte det enda (och absolut inte det första, då hade inte den inledande historien gått bra). Det här är en "fem i topp" -lista över riskdrivna lagar just nu.

Ension har haft som primärt syfte att sätte upp en metod som klarar cybersäkerhetslagens krav. I detta arbete har ension byggt en process baserat på en analys enligt metoden beskriven ovan.

Ension har skapat spårbarhet mot NIS2 med genomförandeförordningen, ISO 27001, ISO 27002 och IEC 61508. Utifrån dessa krav har Ension skapat en designmetod. Metoden kallar Ension Safety & Security by design. Att hantera både Safety och Security i designarbetet.

I det inledande exemplet så är security, ISO 27001, att ingen obehörig tar sig in i cockpit eller saboterar en motor på marken. Safety däremot, ISO 61508, är att flygplanet kan fortsätta flyga och landa tryggt även om en motor stannar.

Den här siten följer för utveckling strukturen i ISO 61508 tillsammans med ISO 15288. På detta sätt blir ensions ramverk en sammanhållern process inom ledarskap, arkitektur och säkerhet

Eftersom ensions ramverk haft som syfte att uppfylla kraven i cybersäkerhetslagen, kan det finnas behov att justera den baserat på dina behov och dina krav. T ex så behöver man tydliggöra arbetet med klassning av information och system för att klara GDPR och säkerhetsskyddslagen