In this blog post Immutable Azure SQL and PostgreSQL Backup Checklist for CIOs we will explain why a backup dashboard full of green ticks can still leave your business exposed to ransomware—and what to check before you rely on those backups.
The risk is not simply that ransomware encrypts a database. Attackers increasingly target administrator accounts, backup settings and recovery points. If they can delete backups, shorten retention periods or steal the credentials needed for recovery, a technically successful backup may offer little practical protection.
What is an immutable database backup?
An immutable backup is a recovery copy that cannot be changed or deleted during a defined retention period. Even an administrator with powerful access should not be able to remove it once the protection has been locked.
The underlying model is often called Write Once, Read Many, or WORM. In plain English, the backup can be created and later read for recovery, but it cannot be overwritten, shortened or erased before its retention period expires.
CPI Consulting helps organisations design, build and secure Azure AI solutions, from Azure OpenAI and Microsoft Foundry to agents, governance and production deployment.
Visit CPI ConsultingThis matters because ordinary backup security often depends on permissions. If an attacker compromises a sufficiently powerful account, those permissions can potentially be changed. Locked immutability creates a stronger barrier that does not rely solely on the account remaining secure.
Azure SQL and PostgreSQL need different backup designs
Azure SQL Database includes automatic point-in-time restore backups. Point-in-time restore means you can rebuild a database as it existed at a selected time, such as ten minutes before malicious changes began.
Microsoft automatically protects up to the most recent seven days of these Azure SQL recovery points with default immutability. An optional locked capability can align immutability with the database’s full point-in-time retention period, although CIOs should confirm its current production status and suitability before depending on it.
For longer retention, Azure SQL Database supports immutable long-term retention backups. These can preserve selected full backups for up to ten years, making them useful for ransomware recovery, audit requirements and historical data retention.
Azure Database for PostgreSQL Flexible Server has its own automatic operational backups, with point-in-time recovery available within the configured retention window. For longer and more isolated protection, Azure Backup can copy PostgreSQL backups into a separate Backup vault.
That vault can be made immutable and locked. Microsoft is also developing a newer PostgreSQL backup option using physical disk snapshots, with more frequent schedules and direct server recovery. Where a feature is still in preview, however, it should not become your only production recovery path.
The CIO ransomware recovery checklist
1. Identify the databases the business cannot operate without
Do not begin with Azure settings. Begin with payroll, ordering, customer service, finance, warehouse and operational systems. Ask what happens if each database is unavailable for four hours, one day or three days.
Classify the most critical databases as priority-zero systems. These receive the strongest backup controls and are restored first during an incident.
2. Agree on acceptable data loss and downtime
Set a recovery point objective, which is the maximum amount of recent data the business can afford to lose. Also set a recovery time objective, meaning how quickly the service must be operating again.
A daily PostgreSQL vaulted backup may be suitable for an archive but unacceptable for an ordering platform processing transactions every minute. The schedule must follow the business requirement—not the default setting.
3. Check which recovery points are genuinely immutable
- Confirm whether Azure SQL protection covers only the recent automatic backup window or the full required retention period.
- Check that long-term Azure SQL backup immutability has been enabled and locked where required.
- Confirm that PostgreSQL vaulted backups are stored in an immutable Backup vault.
- Record which databases remain outside immutable protection and why.
Enabling immutability without locking it may leave a path for someone to disable the setting. Locking is normally irreversible, so retention periods and legal requirements must be reviewed before the change is approved.
4. Separate backup authority from production administration
The person who manages a production database should not automatically have unrestricted power over its final recovery copy. Otherwise, one compromised administrator account could affect both production and backup.
For PostgreSQL Backup vaults, use multi-user authorisation through Azure Resource Guard. This requires separate approval for sensitive actions such as reducing retention or stopping protection. Where practical, place this approval control in a different subscription or tenant with a different owner.
5. Protect the keys and accounts required for recovery
A backup is not useful if encryption keys, secrets or recovery identities disappear during the incident. Protect Azure Key Vault, maintain previous key versions where required and document which identities can restore each database.
Use phishing-resistant multi-factor authentication for privileged users and provide access only when needed. Emergency accounts should be tightly controlled, monitored and tested rather than created during a crisis.
6. Keep evidence that helps identify a clean recovery point
Immutability protects a backup from deletion, but it does not prove the data inside it is clean. If an attacker quietly changes records for two weeks before detection, yesterday’s immutable backup may preserve those changes perfectly.
Retain database audit logs, Azure activity records, identity sign-in information and security alerts separately from production. These records help investigators estimate when the compromise began and select a safer recovery point.
7. Restore into an isolated environment
Never assume that restoring the newest available backup is safe. Recover into an isolated network, scan connected systems and validate the database before allowing employees or applications to reconnect.
Check critical record counts, transactions, permissions, automation accounts and application behaviour. Rotate passwords, keys and application secrets before production access is restored.
8. Test the complete recovery process
A successful backup job is not a recovery test. At least quarterly for critical systems, restore a database and measure how long it takes to reach a usable business service.
Document every delay, including missing permissions, slow data imports, unavailable specialists and application configuration problems. For more detail on turning this into executive evidence, see our Azure SQL ransomware recovery plan boards can trust.
9. Monitor for weakening backup protection
Create alerts for failed jobs, reduced retention, changed backup policies, disabled logging and unexpected privileged access. Review these alerts alongside Microsoft Defender, which detects threats across Microsoft environments, and Wiz, which identifies cloud risks and exposed attack paths.
Your monthly report should answer three questions: Are all priority systems protected? Are their recovery points immutable? When was each system last restored successfully?
A common mid-market recovery gap
Consider a composite example based on environments we regularly assess. A 180-person company has Azure SQL for finance and PostgreSQL for a customer portal. Both platforms show successful automatic backups, so management believes ransomware recovery is covered.
The review finds that PostgreSQL has only short-term operational backups, Azure SQL has no immutable long-term copy, and the same administrators control production and backup settings. Nobody has completed a full application recovery in the past year.
The company adds locked long-term protection, separates backup approval, preserves security logs and runs a timed recovery exercise. The main outcome is not more backup storage. It is a defensible answer to the board’s real question: “How do we know the business can recover?”
Immutability supports Essential Eight but does not complete it
Regular backups are one of the Essential Eight, the Australian government’s baseline cybersecurity framework. Immutable recovery points support this strategy by making it harder for ransomware or a compromised administrator to destroy every usable copy.
Essential Eight maturity still requires broader controls, including restricted administrator access, multi-factor authentication and regular restoration testing. Our Azure resilience checklist for Australian mid-market CIOs explains how backups fit with wider continuity planning.
The outcome CIOs should expect
A strong design gives the business protected recovery points, separate approval for destructive changes, evidence for choosing a clean backup and proof that restoration works within an agreed timeframe. That reduces downtime, financial loss, regulatory exposure and uncertainty during an already stressful incident.
CloudProInc is a Melbourne-based Microsoft Partner and Wiz Security Integrator with more than 20 years of enterprise IT experience. We take a practical, hands-on approach across Azure, PostgreSQL, Microsoft Defender and cloud security rather than treating backups as another box to tick.
If you are not sure whether your Azure SQL and PostgreSQL backups would survive a compromised administrator account, we are happy to review the setup and identify the recovery gaps—no strings attached.