RTO and RPO Explained: Disaster Recovery Questions for Your eSignature Platform
RTO and RPO are the two numbers that describe how bad an outage can get. The recovery time objective (RTO) is how long a service may be down before it must be back. The recovery point objective (RPO) is how much data, measured in time, could be lost. When signing and notarization move onto a platform, its numbers become yours.
Two numbers, in plain terms
RTO answers “how long until we can work again?” An RTO of four hours means the provider commits to restoring service within four hours of a disaster. For a signing platform, that is half a working day with no approvals, no contracts, and no notarizations.
RPO answers “how much will we have to redo?” An RPO of one hour means that, in the worst case, everything done in the hour before the failure could be lost. For a signing platform, that could mean signatures that were collected and then vanished, and signers who now have to be found and asked again.
A lower number is better for both, and costs more to deliver. That is why they should be stated, not assumed.
Why documents raise the stakes
Losing a draft is an inconvenience. Losing an executed document is a different kind of problem. A signature records a person’s act at a moment in time. If it is lost, it can’t be restored from a template; the person has to sign again, and the counterparty has to agree to it.
Notarization raises the stakes further. Each act is entered in a notarial register, and the record is the legal evidence that the act happened. That is why the Supreme Court’s Rules on Electronic Notarization (A.M. No. 24-10-14-SC) require every accredited Electronic Notarization Facility to back up notarial books in real time and to guarantee 99.9% uptime, except for maintenance announced in advance.
It helps to translate that number. 99.9% uptime allows about 8 hours and 46 minutes of downtime a year, or about 43 minutes in a 30-day month. And uptime is not the same as RTO. Uptime is an average over a period; RTO is the limit on a single incident.
High availability, backup, and disaster recovery aren’t the same thing
| Term | What it protects against | What it doesn’t |
|---|---|---|
| High availability | A component failing, by switching to a standby with little or no interruption | Bad data: a standby faithfully copies an accidental deletion |
| Backup | Lost or corrupted data, by keeping copies to restore from | Downtime: restoring takes time |
| Disaster recovery | A major event, with a planned, tested way to restore service and data | Anything it was never tested against |
| Business continuity | Disruption to the business as a whole, people and processes included | Gaps in the technical plans underneath it |
A vendor that answers every resilience question with “we have high availability” has answered only the first row.
Questions to ask any platform
- What are your RTO and RPO, and are they in our agreement?
- When did you last test disaster recovery, and what happened?
- Is the database replicated to a standby, and how far behind can it fall?
- Are backups protected from deletion, including by someone with administrator access?
- How long are backups kept?
- What happens to work in progress during an outage: an envelope halfway through signing, or a scheduled notarization?
- How, and how quickly, will we be told about an incident?
- Can we download our documents, and the proof that they are genuine, at any time?
- What still works if your platform is down?
The last question is the one most often skipped, and the one that matters most for records.
How Twala approaches it
Twala runs on enterprise-grade cloud infrastructure, engineered for high availability. Its database keeps a standby in sync, ready to take over, and background work such as blockchain anchoring is retried automatically when it fails. Behind that sit a formal Disaster Recovery Plan and Business Continuity Plan, continuous security monitoring, and documented incident response procedures. If a personal data breach may cause harm, Twala will notify the National Privacy Commission and affected users within the period the Data Privacy Act requires.
As an accredited Electronic Notarization Facility, Twala is held to the Rules’ requirements for real-time backup of notarial books and 99.9% uptime. Enterprise plans add a guaranteed SLA. If you are running a vendor assessment, our team can walk your reviewers through the details.
What still works when Twala doesn’t
Some of the most useful resilience is the kind that doesn’t depend on Twala at all:
- The notarized record leaves at once. Each eNotarized document is uploaded to the Supreme Court’s Central Notarial Database as soon as it is sealed.
- The proof sits on a public blockchain. Each sealed document’s fingerprint is anchored on Polygon, which Twala doesn’t run and can’t alter.
- The file proves itself. A completed PDF carries its own seal, timestamps, and validation evidence, which any PDF reader that checks signatures can read.
- You can keep your own copies. Completed documents and their anchor proofs can be downloaded, so your records system holds an original that can be verified without asking anyone.
That last point is your side of the RPO. For executed documents, the strongest recovery point is the copy already in your own records.
To fit this into your own plan, read eNotarization for businesses and our explainer on why Twala anchors on a public blockchain. For the full set of controls, see the trust center, or contact us to start an enterprise review.
Twala is a Supreme Court-accredited Electronic Notarization Facility (ENF). Twala is a technology provider and does not give legal advice.
