How frequently is critical data backed up?
Frequency is how much work you lose. It is the other half of the recovery equation, and it is usually stated more precisely than it is configured.
What the carrier is actually asking
The carrier is asking for the interval between recovery points for the data that matters, which is the practical expression of your recovery point objective. Different systems usually have different intervals, and the honest answer is a small table rather than a single figure.
Why it is underwritten
The gap between the last recovery point and the incident is data that has to be reconstructed by hand, which is cost and delay the carrier absorbs through business interruption. For transactional systems the difference between hourly and nightly recovery points is a substantial claim difference.
Where the answer lives in Microsoft 365, Entra ID, and Azure
Backup schedules live in the backup product, so this is attested. Some cloud-native recovery point behaviour is readable.
| Platform | Where the setting lives | What has to be true |
|---|---|---|
| Backup product | Job schedules per protection group | Intervals per system class, with the interval matched to the tolerance for loss rather than to convenience |
| Azure | Database point-in-time restore windows and their retention | The effective recovery granularity for cloud databases, which is often finer than any backup job |
| Azure | Blob versioning and soft delete windows | The recovery granularity for object data, which behaves differently from a scheduled backup |
| Microsoft 365 | Retention and version history settings | The recovery granularity for collaboration data, which is version-based rather than interval-based |
| Backup product | Job success history over the last quarter | The achieved interval, which is what matters. A nightly job that failed eleven times last month is not a nightly recovery point |
The schedule says nightly. The success history says how often that actually happened. When an underwriter or an adjuster asks about frequency, the history is the answer, and it is worth looking at before you fill in the form.
What a defensible yes requires
- Intervals are stated per system class rather than as one number for the estate.
- Each interval derives from a stated tolerance for data loss.
- Job success history supports the stated interval over a meaningful period.
- Software-as-a-service and cloud-native data are included, with their own recovery granularity described.
- Failures alert, so a missed window is noticed within one cycle rather than at the next audit.
How this answer goes wrong
The answer usually describes intent. Nightly is the schedule; the estate has three systems whose jobs have been failing for a month, and one added in the spring that was never added to a protection group at all. The second gap is scope again: cloud databases and collaboration data governed by defaults nobody chose.
Frequently asked
Is nightly enough?
For many systems yes, and for transactional systems it means up to a day of re-keyed work. Match the interval to what losing that data actually costs.
Does continuous replication count?
It gives an excellent recovery point and does not replace backup, because replication faithfully copies corruption and encryption too. Carriers read them as different controls.
How do we evidence achieved frequency?
A job success report over the last ninety days, per protection group. It is more convincing than a schedule screenshot and it is usually one export away.
What about data in software-as-a-service platforms?
State its recovery granularity separately and honestly. Vendor retention is often version-based with a fixed window, which is a different property from a scheduled recovery point.
Related questions
Stop answering this from memory
Connect Microsoft 365, Entra ID, and Azure read-only. Insurance Posture reads the live configuration behind each application answer and shows you which ones you can prove before you sign.
Assess your posture