Wat is RPO? Recovery point objective binnen ISO 22301
De RPO (recovery point objective) is de maximale hoeveelheid data die een proces mag verliezen bij uitval, uitgedrukt in tijd. Een RPO van één uur betekent dat je hooguit het laatste uur aan gegevens kwijt mag raken. Je bepaalt de RPO in de business impact analyse en kiest daarna de back-up- of replicatiefrequentie die daarbij past. Het is één van de drie kerngetallen naast de RTO en de MTPD, en het hoort bij de eisen van ISO 22301.
RPO gaat over dataverlies, RTO gaat over hersteltijd. Een systeem kan binnen één uur terug zijn (RTO) maar wel een dag aan gegevens kwijt zijn (RPO).
RPO in gewone taal
De uitleg hieronder is een eigen formulering. De officiële definitie staat in ISO 22300, die niet vrij beschikbaar is. In de praktijk druk je de RPO uit in tijd, zoals hierboven.
Stel dat je om 10:00 uur een back-up maakt en om 10:45 uur valt het systeem uit. Dan staat in de back-up alles tot 10:00 uur. De 45 minuten daarna zijn weg, tenzij je ze op een andere manier kunt herstellen. Die 45 minuten zijn je werkelijke dataverlies.
De RPO beschrijft wat je acceptabel vindt. Als het management zegt dat maximaal één uur aan orders mag verloren gaan, dan moet je back-up of replicatie minimaal elk uur plaatsvinden. Vindt het management dat niet acceptabel, dan moet je de frequentie verhogen of een andere techniek kiezen.
Waarom RPO een bestuurlijke keuze is
De RPO bepaalt wat het kost om data te beschermen. Frequenter back-uppen kost meer opslag, meer netwerkcapaciteit en meer tijd. Een RPO van vijf minuten is technisch mogelijk, maar kost veel meer dan een RPO van één dag.
Daarom hoort de RPO niet bij één technicus, maar bij het management. Het management weegt het dataverlies af tegen de kosten. Dat besluit leg je vast in de BIA.
Hoe je de RPO per systeem bepaalt
Werk per systeem, niet per bedrijf. Een boekhoudsysteem en een interne wiki hebben zelden dezelfde RPO.
- Vraag per proces: hoeveel werk raakt je kwijt als de laatste gegevens verdwijnen? Denk aan orders, betalingen, dossiers.
- Vertaal dat naar tijd: hoeveel uur werk zit er in een gemiddeld uur? Dat geeft je een eerste schatting.
- Leg de schatting voor aan de proceseigenaar en het management, en laat ze een getal kiezen.
- Controleer of je huidige back-up of replicatie aan dat getal voldoet.
Uitgewerkt voorbeeld: vier systemen, vier RPO’s
Een zorgorganisatie met een kleine praktijk heeft vier systemen. De BIA levert deze tabel op:
| Systeem | Wat er verloren gaat | RPO | Huidige back-up | Voldoet? |
|---|---|---|---|---|
| Patiëntplanning | Afspraken van het uur | 1 uur | Elk uur, geautomatiseerd | Ja |
| Declaraties | Ingevoerde declaraties van de dag | 1 dag | Elke nacht | Ja |
| Mailarchief | E-mails van de afgelopen dag | 1 dag | Elke nacht | Ja |
| Interne wiki | Wijzigingen van de afgelopen week | 1 week | Elke week | Ja |
In dit voorbeeld voldoet elke back-up aan de RPO. Let op de laatste kolom. Die moet je elk jaar opnieuw controleren, omdat systemen veranderen en back-ups stilletjes kunnen stoppen.
Het getal “1 uur” voor de patiëntplanning is fictief. Je bepaalt je eigen getallen met je eigen BIA.
Samenhang met back-ups en replicatie
De RPO bepaalt de techniek, niet andersom. Een paar veelgebruikte keuzes:
| RPO die je nodig hebt | Passende techniek | Let op |
|---|---|---|
| Dagen tot een week | Nachtelijke of wekelijkse back-up | Ook de terugzettest moet je uitvoeren |
| Uren | Back-up meerdere keren per dag | Back-up moet ook buiten het systeem staan |
| Minuten | Replicatie naar een tweede locatie | Fouten worden ook gerepliceerd, dus ook een back-up nodig |
Een back-up die je niet terugzet, telt niet als bewijs. Dat geldt voor elke RPO. Lees bij oefenen en testen hoe je dat test.
Veelgemaakte fouten
| Fout | Waarom het misgaat | Beter |
|---|---|---|
| RPO gelijk aan “zo min mogelijk” | Geen meetbaar doel, niet te toetsen | Kies een getal in uren of minuten |
| RPO bepaald zonder de back-upfrequentie te kennen | Het doel is technisch niet haalbaar | Stem RPO af op de bestaande back-up |
| Eén RPO voor alle systemen | Duur voor onbelangrijke data, te zwak voor kritieke data | Per systeem bepalen |
| Vergeten dat fouten worden gerepliceerd | Een verwijderd bestand is overal weg | Combineer replicatie met een back-up |
RPO controleren na een terugzettest
Een RPO is pas bewezen als je hem in de praktijk haalt. Na elke terugzettest doe je dit:
- Noteer het tijdstip van de laatste bruikbare back-up vóór de test.
- Noteer het moment waarop je de test als uitval hebt gedefinieerd.
- Reken het verschil uit. Dat is het gemeten dataverlies.
- Vergelijk het gemeten dataverlies met de afgesproken RPO.
- Haalt het systeem de RPO niet, dan maak je een actie aan met eigenaar en datum.
Een voorbeeld: de RPO is één uur, de laatste back-up was 09:00 uur en de test vond plaats om 10:30 uur. Het gemeten dataverlies is anderhalf uur. Dat haalt de RPO niet, dus de back-upfrequentie moet omhoog of de back-up moet vaker lopen.
Wat auditors willen zien
Een auditor vraagt om de RPO-waarden per kritiek systeem, het besluit van het management, en het bewijs dat de back-up die waarde haalt. Dat bewijs is meestal een logbestand met back-uptijden plus een terugzetverslag. Zie het auditproces voor wat je verder moet voorbereiden.
Veelgestelde vragen over RPO
Is RPO hetzelfde als RTO? Nee. RPO gaat over hoeveel data je verliest, RTO over hoe lang het duurt om terug te zijn.
Kan de RPO nul zijn? In theorie ja, maar het vraagt om synchrone replicatie en kost veel. Voor de meeste bedrijven is een kleine, bewuste RPO realistischer.
Wat is het verband met de MTPD? De MTPD (maximum tolerable period of disruption) is de maximale uitvaltijd voordat het echt misgaat. De RTO ligt daar altijd binnen. De RPO staat los van de tijd: die gaat over data, niet over uitvaltijd. Zie de BIA uitgelegd.
Meer over het hele traject vind je in het stappenplan.