Policyer, godkjenninger og selskapsstyring

Alle styrte operasjoner følger samme løp, enten de flytter midler eller endrer organisasjonens egen konfigurasjon:

1 – Initiering. Et medlem med Initiate (eller Execute) i arbeidsflytprofilen sin starter en forespørsel. For uttak og overføringer trenger de også tillatelse til å flytte midler på de involverte kontoene.

2 – Kontroll av umiddelbar fullføring. Hvis medlemmet har Execute og arbeidsflytens innstilling «Krev alltid godkjenning» er AV, fullføres forespørselen umiddelbart. Ferdig. Ett unntak: en forespørsel som endrer en låst policy, venter alltid på godkjenning – uavhengig av hva initiatoren har tilgang til. Se «Låse policyer» nedenfor.

3 – Godkjenningskø. Ellers venter forespørselen på gjennomgang. Medlemmer med Approve på den aktuelle arbeidsflyten ser den i køen sin.

4 – Avgjørelse. Når det nødvendige antallet uavhengige godkjenninger er nådd, fullføres forespørselen og trer i kraft. En enkelt godkjenner kan i stedet avvise den, noe som avslutter forespørselen uten virkning.

Fullførte forespørsler registreres som sikkerhetshendelser, med kobling tilbake til forespørselen og godkjenningssporet.

Et medlem kan ikke godkjenne sin egen forespørsel. Systemet håndhever dette i alle arbeidsflyter, og ingen tillatelse, profil eller policy-konfigurasjon overstyrer det.

Den eneste måten et enkelt medlem kan fullføre en styrt operasjon alene på, er med Execute – og bare når arbeidsflytens policy tillater umiddelbar fullføring.

Hver arbeidsflytpolicy har to innstillinger:

Samspillet mellom Execute og «Always require approval»:

Execute fjernes aldri av en policy – den forblir på profilen, tydelig markert som inaktiv når «Always require approval» er PÅ, og begynner å virke igjen hvis innstillingen senere slås AV.

1. Gå til Retningslinjer og velg arbeidsflyten (for eksempel Uttaksforespørsel).
2. Angi nødvendig antall godkjenninger.
3. Velg om Krev alltid godkjenning skal være PÅ eller AV.
4. Se hvem som har hvert nivå i denne arbeidsflyten. Retningslinjeeditoren viser teamets nivåer ved siden av innstillingene, så du kan kontrollere at konfigurasjonen er gjennomførbar før du lagrer.
5. Bekreft.

Endringer av retningslinjer er selv styrte operasjoner i arbeidsflyten Administrer retningslinjer. Hvis den arbeidsflyten krever godkjenning, venter endringen i køen som alle andre forespørsler.

Hver retningslinje har også sin egen endringshistorikk: alle oppdateringer, låsinger og opplåsinger er oppført der med tilhørende godkjenningsforespørsel, så du alltid kan se hva som ble endret, hvem som ba om det, og hvem som godkjente det. Fullførte endringer registreres også som sikkerhetshendelser.

Låsing er det forpliktende steget i selskapsstyringen. Det krever uavhengig godkjenning for alle fremtidige endringer av arbeidsflytens policy, inkludert endring av antall godkjenninger, endring av «Krev alltid godkjenning» eller opplåsing.

Alle policyendringer behandles som en Administrer policyer-forespørsel, uavhengig av om målpolicyen er låst – låsen endrer ikke hvor en endring havner, bare hvordan den fullføres:

• En endring av en ulåst policy følger den normale forespørselssyklusen. Et medlem med Execute på Administrer policyer fullfører den umiddelbart, så lenge arbeidsflytens innstilling «Krev alltid godkjenning» er AV.
• En endring av en låst policy – enten det gjelder antall godkjenninger, innstillingen «Krev alltid godkjenning» eller opplåsing – venter alltid på gjennomgang av medlemmer med Godkjenn på Administrer policyer. Låsen overstyrer Execute for den aktuelle policyen og gjelder likt for alle: eierens endringer gjennomgår samme gjennomgang som alle andres.

Når den er låst, kan ingen enkeltperson svekke arbeidsflytens selskapsstyring alene. Endringer er fortsatt ordinære – ethvert medlem med godkjenningsrettighet på Administrer policyer kan gjennomgå og godkjenne dem, men det kreves alltid minst to personer.

Låsing gjelder per arbeidsflyt. Låsing av Uttaksforespørsel påvirker ikke Overføringsforespørsel eller andre arbeidsflyter – du strammer inn én arbeidsflyt om gangen, i ditt eget tempo. Se Innføring av selskapsstyring for anbefalt rekkefølge.

Låsing og opplåsing er også forespørsler

Tre typer forespørsler behandles under arbeidsflyten Administrer policyer. Du finner dem i godkjenningskøen, i endringshistorikken for hver policy og blant sikkerhetshendelser:

Låsing er ikke unntatt fra egne regler: en låseforespørsel følger samme livssyklus som enhver annen Administrer policyer-forespørsel. Hvis du har Execute på Administrer policyer og innstillingen «Krev alltid godkjenning» er AV, trer låsen i kraft umiddelbart; ellers venter den i køen, og policyen forblir ulåst til forespørselen er godkjent.

Slik fullføres en policyendring

Satt sammen ser utfallet av en hvilken som helst Administrer policyer-forespørsel slik ut:

To måter å styre policyendringer på

De to kontrollene utfyller hverandre og kommer aldri i konflikt: uansett hvilken som gjelder, venter endringen på godkjenning – og å aktivere begge endrer ingenting ytterligere. Bruk låsen for gradvis innstramming; bruk Manage Policies-innstillingen når du vil at alle policyendringer gjennomgår godkjenning samlet.

Låsing av Manage Policies selv

Manage Policies er en arbeidsflyt som alle andre: den har sin egen policy, og den policyen har sin egen lås. Å låse den er den endelige forpliktelsen i en utrulling av selskapsstyring. Når Manage Policies-policyen er låst, krever alle regelendringer i organisasjonen – inkludert opplåsing av enhver policy og opplåsing av Manage Policies selv – uavhengig godkjenning. Fra det tidspunktet kan ingen enkeltperson lempe på selskapsstyringen via produktet.

Det er også derfor du bør bekrefte opplåsingsruten før du låser, som beskrevet under «Sikkerhetstiltak» nedenfor. Ingenting i produktet hindrer deg i å låse en policy i en tilstand ingen kan endre. Se Utrulling av selskapsstyring for når du bør ta dette steget.

Bekreft at opplåsing fortsatt er mulig før du låser. Opplåsing er en Manage Policies-forespørsel mot en låst policy, så Execute kan ikke omgå den. Du trenger ett medlem som kan starte en Manage Policies-forespørsel, pluss like mange andre medlemmer med Approve på Manage Policies som arbeidsflyten krever – alle verifiserte og aktive. Systemet kontrollerer ikke dette for deg, og en låst policy uten vei til en godkjent endring krever hjelp fra Kraken-support for å gjenopprettes.

Forebygging av utestenging. En endring avvises hvis den ville etterlate en arbeidsflyt uten noen som kan fullføre forespørslene som er startet på den. Siden medlemmer ikke kan godkjenne sine egne forespørsler, skjer dette så snart det påkrevde antallet overstiger det en enkelt initiativtaker kan nå for sine egne forespørsler. Kontrollen kjøres på begge sider: når du redigerer en policy, og når du endrer et medlems arbeidsflytprofil eller en kontosrolle.

Advarsel om deaktivering. Kontroller godkjennerdekning før du deaktiverer et medlem med Approve. Deaktivering gjennomføres selv om det bringer en arbeidsflyt under det påkrevde godkjennerantallet, og ventende forespørsler holdes til terskelen som gjaldt da de ble opprettet.

Når du har satt deg inn i policyene, viser Utrulling av selskapsstyring hvordan du innfører dem på en trygg måte: konfigurer, valider og lås – én arbeidsflyt om gangen, med konkrete eksempler.

«Always require approval» er PÅ for denne arbeidsflyten. Execute er inaktiv så lenge innstillingen er PÅ – alle forespørsler settes i kø for uavhengig godkjenning. Hvis du vil gjenopprette umiddelbar fullføring, slår du innstillingen AV under Policies. Merk at dette er en Manage Policies-handling og kan kreve godkjenning.

Hvis forespørselen gjelder en policy-endring, må du også sjekke målpolicyen: endringer i en låst policy venter alltid på godkjenning, uavhengig av Execute. Dette er låsen som fungerer som tiltenkt.

Låsing er i seg selv en Manage Policies-forespørsel. Hvis «Always require approval» er PÅ for Manage Policies, eller Workflow Profile-en din ikke har Execute på den, venter låseforespørselen på uavhengig godkjenning som alle andre forespørsler. Policyen forblir ulåst til låseforespørselen er godkjent – du finner den i godkjenningskøen, og i policyens endringshistorikk når den er fullført.

Tell opp de aktive medlemmene som har Approve på denne arbeidsflyten, unntatt deg selv. Bare medlemmer som har akseptert invitasjonen og fullført verifisering, teller som godkjennere: et invitert medlem teller ikke før begge deler er gjort, selv om de vises i teamlisten. Hvis en godkjenner ble deaktivert etter at forespørselen ble opprettet, kan de gjenværende godkjennerne ikke lenger nå opp til det påkrevde antallet – en ventende forespørsel holder seg til grensen som gjaldt da den ble opprettet, selv om policyen er endret siden. Reaktiver medlemmet eller gi Approve til et annet aktivt medlem for å frigjøre forespørselen.

Sjekk Workflow Profile-en din: låsing krever Initiate eller Execute på Manage Policies-arbeidsflyten. Hvis låseforespørselen ble opprettet men ingenting endret seg, venter den på godkjenning – den ble ikke avvist. Se punktet ovenfor.

Produktet avviser ikke en låsing fordi en uavhengig godkjenner mangler, så bekreft opplåsingsruten selv før du låser: et medlem som kan starte en Manage Policies-forespørsel, pluss så mange andre medlemmer med Approve på Manage Policies som arbeidsflyten krever.

Det nødvendige antallet godkjenninger overstiger hva et medlem som starter forespørsler kan innhente, ettersom ingen kan godkjenne sin egen forespørsel. Policyeditoren angir årsaken: ett eller flere medlemmer har både Initiate og Approve, slik at hver av dem har én færre godkjenner enn totalen. Reduser antallet påkrevde godkjenninger, eller gi Approve til et annet medlem som ikke starter forespørsler på denne arbeidsflyten.