Wat is RPO?
RPO (Recovery Point Objective) is het moment in het verleden waarnaar gegevens na een incident minimaal hersteld moeten kunnen worden, uitgedrukt als de maximale hoeveelheid dataverlies in tijd die een organisatie nog aanvaardbaar vindt. Een RPO van 15 minuten betekent dat u na een crash, storing of cyberaanval hooguit de gegevens van de laatste 15 minuten kwijt mag zijn. De RPO is een doel dat u vooraf vastlegt en bepaalt hoe vaak u een back-up maakt of data repliceert. Samen met de RTO vormt zij de kern van elk disaster recovery- en business continuity-plan.
Hoeveel data mag u maximaal verliezen bij een crash of cyberaanval?
🧠 Hoe is de RPO precies gedefinieerd?
De Amerikaanse richtlijn NIST SP 800-34 Rev. 1 (mei 2010) voor contingency planning definieert de RPO kort als het tijdstip waarnaar gegevens na een uitval hersteld moeten worden. De continuïteitsnorm ISO 22301, met de begrippen uit ISO 22300, formuleert het vanuit het bedrijfsproces: het punt waarnaar de informatie die een activiteit gebruikt hersteld moet worden, zodat die activiteit bij hervatting weer kan werken.
Beide definities zeggen hetzelfde, maar met een andere nadruk. NIST denkt vanuit het systeem, ISO vanuit de activiteit. Dat verschil is in de praktijk belangrijk: een historian kan technisch perfect hersteld zijn, terwijl de batchrapportage die erop leunt toch onbruikbaar is omdat er een gat van een uur in de meetreeksen zit.
Een rekenvoorbeeld maakt het concreet. Maakt u elk uur om heel uur een back-up en crasht de server om 10:50, dan is de laatste bruikbare kopie die van 10:00 en verliest u 50 minuten aan gegevens. Het slechtste geval is dus niet het back-upinterval zelf, maar het interval plus de tijd die het maken en wegschrijven van de kopie kost. Een RPO van 1 uur vraagt daarom een interval dat duidelijk korter is dan 1 uur.
🔄 Wat is het verschil tussen RPO, RTO en back-upfrequentie?
RPO wordt vaak verward met verwante begrippen. Elk getal beantwoordt een andere vraag:
| Begrip | Vraag die het beantwoordt | Soort getal | Voorbeeld in OT |
|---|---|---|---|
| RPO (Recovery Point Objective) | Hoeveel recente data mag verloren gaan? | Doel, vooraf vastgelegd | Maximaal 15 minuten historian-data kwijt |
| RTO (Recovery Time Objective) | Hoe snel moet het systeem weer werken? | Doel, vooraf vastgelegd | SCADA-server binnen 4 uur weer beeld |
| Back-upfrequentie | Hoe vaak wordt een kopie gemaakt? | Technische instelling | Elke 10 minuten een incrementele back-up |
| MTTR (Mean Time to Repair) | Hoe lang duurde herstel werkelijk gemiddeld? | Meting achteraf | Gemeten herstel van een HMI: 3 uur |
De RPO kijkt terug in de tijd, vanaf het incident naar de laatste goede kopie. De RTO kijkt vooruit, vanaf het incident naar het moment dat het proces weer draait. Volgens NIST SP 800-34 maakt de RPO geen deel uit van de maximaal toelaatbare uitvaltijd: zij gaat over dataverlies, niet over tijd zonder dienst. In de praktijk beïnvloeden ze elkaar wel. Een kleinere RPO vraagt vaak meer herstelpunten of logbestanden die u bij een restore moet terugzetten, en dat kan de hersteltijd verlengen.
🔧 Welke techniek past bij welke RPO?
Hoe kleiner de RPO, hoe duurder en complexer de oplossing. De gangbare koppeling:
| RPO-klasse | Passende techniek | Voorbeeld in OT |
|---|---|---|
| Nul (geen verlies) | Synchrone replicatie of spiegeling: een schrijfactie is pas klaar als ook de tweede locatie haar heeft opgeslagen | Redundante DCS-servers, gespiegelde databases voor batchrecords |
| Seconden tot minuten | Asynchrone replicatie, transactielogs of continue gegevensbescherming (journaling) | Historian-replicatie naar een tweede site |
| Minuten tot uren | Frequente snapshots van virtuele machines of incrementele back-ups | Snapshots van een gevirtualiseerd SCADA-platform |
| Uren tot een dag | Dagelijkse back-up naar een aparte opslag | Rapportage- en MES-servers |
| Per wijziging | Back-up direct na elke wijziging, met versiebeheer | PLC-programma’s en HMI-projecten |
Een valkuil: synchrone replicatie en high availability beschermen tegen uitval van hardware, maar niet tegen fouten in de data zelf. Versleutelt ransomware een database of schrijft een operator een verkeerde receptuur weg, dan staat die fout binnen milliseconden ook op de tweede locatie. Een RPO van nul heeft daarom alleen waarde in combinatie met losstaande herstelpunten in de tijd, bij voorkeur onveranderbare back-ups die ransomware niet kan wissen of versleutelen.
🏭 Waarom is RPO in OT-omgevingen anders?
In OT gaat het niet alleen om databases en bestanden. Vier soorten gegevens vragen elk een andere benadering:
- Procesdata in de historian - meetwaarden uit sensoren en SCADA zijn na verlies vaak onherstelbaar, want een temperatuur van gisteren kunt u niet opnieuw meten. Veel historians bufferen data op de bron (store-and-forward) op een interface-node of edge device. Zolang die buffer groot genoeg is, leidt een netwerkstoring niet tot dataverlies.
- Configuraties en programma’s - bij PLC-code, HMI-projecten en netwerkinstellingen wilt u geen enkele goedgekeurde aanpassing verliezen. Hier is de RPO eerder gebeurtenisgestuurd dan tijdsgebonden: na elke wijziging een back-up, vastgelegd via configuratiebeheer en change management.
- Batch- en kwaliteitsrecords - in de farmacie en voedingsindustrie moeten batchrecords volledig en betrouwbaar zijn. Een gat in de registratie kan betekenen dat een batch niet vrijgegeven mag worden, dus hier ligt de RPO dicht bij nul.
- Operator-instellingen - setpoints en alarmgrenzen die tijdens bedrijf veranderen, zitten vaak alleen in de controller. Verlies ervan betekent dat een installatie na herstel met verouderde instellingen opstart.
Illustratieve waarden, die per installatie sterk verschillen: een RPO van nul voor operator-instellingen in een batchproces, 5 minuten voor alarmlogboeken, 15 minuten voor historian-data met lokale buffering en 24 uur voor rapportage-omgevingen. Elk getal moet volgen uit de impact van verlies, niet uit gewoonte.
🛠️ Hoe stelt u een RPO op in vijf stappen?
- Inventariseer de gegevens - gebruik de asset-inventaris en noteer per systeem welke data het bevat: procesdata, configuratie, records of rapportage.
- Bepaal de impact van verlies - leg in de business impact analysis vast wat het kost als een uur, een dienst of een dag aan data ontbreekt, inclusief kwaliteit, wettelijke registratieplicht en veiligheid.
- Kies de RPO met de proceseigenaar - de eigenaar van het bedrijfsproces besluit, beheerders adviseren over haalbaarheid en kosten.
- Ontwerp de techniek met marge - kies replicatie, snapshots of back-ups waarvan het slechtste geval binnen de RPO blijft, en bewaar ten minste één kopie gescheiden of via een air gap.
- Test en controleer - doe periodiek een echte restore en controleer of de herstelde data werkelijk tot het verwachte tijdstip loopt. Oefen het scenario ook in een tabletop-oefening.
🔐 Welke wetten en normen vragen om een RPO?
- NIS2, artikel 21 lid 2 onder c - verplicht bedrijfscontinuïteit, zoals back-upbeheer en herstel na calamiteiten.
- Cyberbeveiligingswet - de Nederlandse omzetting van NIS2, sinds 15 augustus 2026 van kracht. Het Cyberbeveiligingsbesluit vraagt in artikel 9 om herstelprocedures, periodiek geverifieerde back-ups en een getest continuïteitsplan.
- ISO 22301 - laat organisaties hersteldoelen, waaronder de RPO, afleiden uit de business impact analysis.
- ISO 27001:2022 - beheersmaatregel A.8.13 (back-up van informatie) en A.5.30 (ICT-gereedheid voor bedrijfscontinuïteit).
- IEC 62443-3-3 - systeemeisen SR 7.3 (back-up van het industriële besturingssysteem, het control system) en SR 7.4 (herstel naar een bekende, veilige toestand).
❓ Veelgestelde vragen
Wat is een goede RPO voor een OT-systeem?
Een goede RPO voor een OT-systeem volgt uit de impact van dataverlies op het proces, niet uit een standaardgetal. Voor batchrecords en operator-instellingen ligt de RPO vaak dicht bij nul, voor rapportageservers kan een dag acceptabel zijn. Leg de RPO per systeem vast in de business impact analysis.
Is een RPO van nul haalbaar?
Een RPO van nul is haalbaar met synchrone replicatie, maar alleen tegen uitval van hardware of een locatie. Logische fouten en ransomware worden direct mee gerepliceerd. Daarom combineert u een RPO van nul altijd met losstaande, onveranderbare herstelpunten.
Hoe vaak moet ik een back-up maken voor een RPO van 1 uur?
Voor een RPO van 1 uur moet het back-upinterval plus de duur van het maken en wegschrijven van de kopie samen korter zijn dan 1 uur. In de praktijk kiest u dan een interval van bijvoorbeeld 30 tot 45 minuten. Controleer bovendien dat back-ups niet stilletjes mislukken.
Wat is het verschil tussen RPO en RTO?
De RPO bepaalt hoeveel data u mag verliezen, de RTO hoe lang een systeem mag uitliggen. De RPO kijkt terug naar de laatste goede kopie, de RTO vooruit naar het moment van hervatting. Beide doelen legt u per systeem apart vast.
Geldt een RPO ook voor PLC-programma’s?
Een RPO geldt ook voor PLC-programma’s, maar is daar eerder gebeurtenisgestuurd dan tijdsgebonden. Na elke goedgekeurde wijziging hoort een back-up met versiebeheer, zodat u nooit een aanpassing kwijt bent. Zo kan een PLC na een storing of aanval terug naar de laatst bekende goede versie.
Wie bepaalt de RPO?
De RPO wordt bepaald door de eigenaar van het bedrijfsproces, op basis van de business impact analysis. IT- en OT-beheer adviseren over wat technisch haalbaar is en wat het kost. Het management accepteert de keuze, inclusief het restrisico.
📌 Samengevat
De RPO bepaalt tot welk moment in het verleden u gegevens na een incident moet kunnen herstellen, en daarmee hoeveel dataverlies aanvaardbaar is.
Hoe kleiner de RPO, hoe minder dataverlies, maar ook hoe hoger de eisen aan de back-up- en replicatie-architectuur. In OT geldt de RPO niet alleen voor historian-data, maar ook voor PLC-programma’s, HMI-projecten, batchrecords en operator-instellingen. Replicatie alleen is geen bescherming tegen ransomware; pas losstaande, geteste herstelpunten maken een RPO waar.