Disaster Recovery Rights Under SPLA

Disaster recovery looks like a place to save SPLA cost, and it can be, but the rights are narrow and conditional. The intuition that a backup server is free because it is not in production is roughly half right and dangerously incomplete. Under SPLA the question is never whether an instance is labelled disaster recovery. It is whether the instance stays genuinely passive. Cross that line, even briefly, and the standby becomes a reportable instance like any other. This article sets out where the line sits, why it is so easy to cross without noticing, and how to document a recovery estate so an audit cannot reprice it.

What a disaster recovery right actually grants

The Services Provider Use Rights, the SPUR, allow a passive secondary instance to be maintained for failover without a separate license, but only under strict conditions and only for products where the right exists. The core idea is that a truly cold standby, one that does no work, serves no users, and runs no workload until a genuine disaster forces a failover, is not consumption. Because SPLA is pay as you consume, an instance that consumes nothing can sit outside the monthly report. The right is an exception to the rule that every running instance is reported, and like every exception it is read narrowly.

Where hosters cross the line without realizing

The trouble is that a useful standby is rarely fully passive. Operations teams want confidence the failover works, so they warm it, sync it actively, run reporting or backups against it, or test a failover quarterly. Each of those activities can convert a passive instance into an active one for SPLA purposes, and an active instance must be reported. The most common ways a recovery right is lost are mundane:

• The standby is kept warm and queryable rather than truly idle
• A failover test runs production workload on the secondary for a period
• Backups, reporting, or analytics are pointed at the secondary to offload the primary
• The secondary serves any user, even read only, even briefly
• The product is one for which no passive failover right exists in the SPUR at all

None of these feel like licensing decisions when an engineer makes them. They are operational choices. But an auditor reconstructing the 36 month lookback will read server configuration data, usage logs, and failover records, and any period where the standby did work becomes a period that should have been reported.

How an audit reprices a misread standby

A Big Four firm conducts the SPLA audit under the MBSA audit clause, with authority to request the very records that reveal standby activity. When the audit finds that an instance claimed as passive was in fact active for some months, it treats those months as under reported consumption. That produces back fees at the price file rate, which are not negotiable, plus a penalty uplift of 25 to 125 percent. A recovery estate misread across a long lookback can turn a small operational habit into a multi month finding, because the same warm standby was probably warm every month.

A worked illustration of the two readings

The figures below are indicative and chosen only to show how the reading changes the result, not to quote any real outcome. Picture one database product held for recovery.

Indicative illustration of how standby state changes the obligation, not a quoted outcome.

How to hold the right defensibly

The recovery right survives an audit only when the evidence shows the standby was genuinely passive throughout. That is a documentation problem, and it is the same discipline that protects the rest of a SPLA estate. Treat every recovery instance as something you must prove was idle, not something you assume is free.

• Record, per product, whether a passive failover right exists in the current SPUR before relying on it
• Keep configuration evidence that the standby is cold and serves no users between real disasters
• Log every failover test with start and end times, and report consumption for any period the secondary did work
• Keep reporting, backups, and analytics off the standby, or accept that it becomes reportable
• Map the recovery instance to the same customer and product version records as the primary it protects

Done monthly, this folds the recovery estate into the same reconciliation that governs the rest of your reporting, so there is no separate, undocumented corner for an auditor to reprice. The SPLA program allows only a short window to correct a reporting mistake, so a standby that quietly went warm is far cheaper to catch in the same cycle than to defend years later.

Where this fits in the wider defense

Disaster recovery is one product of the broader principle that SPLA rewards reporting discipline. The instinct to read SPUR rights generously is exactly what creates under reporting, and the cure is the same reconciliation that catches every other gap. For the foundations, see how to read the SPUR correctly, and for the wider pattern of reporting mistakes that become findings, read common SPLA reporting errors. Both sit under the pillar guide.

The next step

If part of your estate is held for failover and you are not certain it stays passive, that uncertainty is exactly what an audit will price. The SPLA Audit Defense Guide covers how recovery rights interact with the lookback, and a Strategy Call will tell you whether your standby is defensible as passive or is quietly reportable.

If you would rather not face that alone, our SPLA audit defense team challenges the counting before back fees are set.