Power Platform Recovery: The ASD Blueprint Can Help Secure Power Platform. But Can You Recover It?
- Daniel Smith
- Jul 22
- 11 min read
Updated: Jul 24
Microsoft Power Platform is no longer just a collection of handy low-code tools. Inside many Australian organisations it now runs approvals, compliance workflows, reporting, field operations and internal applications that people depend on every day. A flow routes an urgent request to the right person. An app has quietly replaced a spreadsheet, an email chain and three manual processes. A Power BI report is the view executives use to make decisions. A Dataverse environment holds the data and logic tying it all together.
That is useful progress. It also means Power Platform has become part of the operational backbone, often without receiving the same recovery planning as more traditional business systems.
The Australian Signals Directorate’s Blueprint for Secure Cloud provides detailed guidance for configuring and governing Power Platform securely. Its Power Platform design guidance covers connectors, Data Loss Prevention policies, environments, administrative access, tenancy isolation and audit logging. The Blueprint describes these settings as a baseline implementation and makes clear that each organisation must adapt them to its own operating context.
That is exactly as it should be. But there is another question that deserves a place in the same conversation:
Once Power Platform has been secured, governed and monitored, how will the organisation recover it when something still goes wrong?
This is not a criticism of the Blueprint. It is the difference between reducing the chance of an incident and being ready for the consequences of one.
Power Platform has moved beyond "citizen development"
The phrase citizen development can make Power Platform sound less consequential than it really is. It suggests small productivity tools built at the edge of the business: a simple form, a departmental dashboard, an automation that saves someone a few minutes. Some Power Platform use still fits that description. A growing amount does not.
Power Apps and Power Automate can connect to Microsoft 365, Azure services, third-party platforms, on-premises systems and custom APIs. ASD’s own guidance recognises the breadth of these connections and the need to control how organisational data moves between them. That connectivity is where much of the value comes from. It is also why a failed app or broken flow can have consequences far beyond the app itself.
A single automated process could update a customer record, trigger a compliance review, create an approval, notify a field team, transfer information between systems and initiate a financial action. When that process stops, the technical failure may be small. The business interruption may not be.
The blunt truth is that many organisations now have production-grade dependencies running on Power Platform without production-grade recovery planning behind them. They may know who owns the Microsoft tenant, who administers Power Platform, and they may even have a mature Centre of Excellence. But ask which apps, flows, reports and Dataverse records must be recovered first — and how long that recovery can take — and the answer often becomes less certain.
What the ASD Blueprint gets right about Power Platform governance
The Blueprint’s Power Platform guidance deserves to be taken seriously. It recognises that low-code does not mean low-risk.
For example, the Blueprint addresses how connectors should be controlled through Data Loss Prevention policies. These policies classify connectors into business, non-business and blocked groups, helping stop organisational data from being moved into inappropriate services or combined in unsafe ways. Across its Power Platform pages the Blueprint also addresses:
These are practical controls, and they answer real questions: who should administer the platform, which connectors should be permitted, where applications should be developed and tested, how activity should be recorded, and how sensitive data can be prevented from travelling through inappropriate flows. This is the work of governing and hardening a platform properly. None of it should be skipped. But none of it eliminates the possibility of data loss, accidental change, malicious activity or operational failure.
Power Platform Recovery: Where the ASD Blueprint Stops
This is worth being precise about, because it is a scoping boundary rather than an oversight.
The Blueprint does address backup. It has a dedicated Backup and operational management page, and regular backups are one of the Essential Eight mitigation strategies. But that guidance sits under the platform layer. The eleven Power Platform pages listed above are concerned with secure configuration, governance and monitoring. None of them is a recovery page.
The Blueprint is explicit about the limits of its own prescription. Its Power Platform configuration section notes that the settings described provide a baseline implementation and should not be considered prescriptive as to how an organisation must scope, build, document or assess a system, and that implementation will differ depending on operating context and organisational culture. It also notes that the Blueprint does not currently provide a mechanism to automatically deploy or assess Power Platform settings.
So the recovery question is not missing from the Blueprint through neglect. It sits outside the scope of what the Power Platform guidance sets out to do, and ASD says as much. That leaves the work of translating backup principles into Power Platform practice with the organisation.
It is worth adding that the Blueprint is an open source project. ASD invites contributions and issues through its GitHub repository, so organisations that develop good Power Platform recovery patterns have a route to feed them back upstream rather than keeping them internal.
Security controls are not time machines
A good security control can prevent an inappropriate action, restrict access, raise an alert and record what happened. It cannot always return an application, flow, report or record to the state it was in before the damage occurred.
Audit logging may show that a privileged user changed a production flow at 2:17 pm. That is valuable. It does not rebuild the previous version of the flow. A DLP policy may stop a user from combining a business connector with an unapproved consumer service, which is exactly what the policy is designed to do. It does not recover a legitimate app that someone later deletes. Role-based access control can reduce the number of people capable of making a damaging change; it cannot guarantee that an authorised person will never make the wrong one. Tenancy isolation can reduce inappropriate cross-tenant communication. It does not recreate lost Dataverse records.
This is not unique to Power Platform. Preventive controls reduce risk. Detective controls reveal activity. Recovery controls provide a way back. Confusing those jobs leaves a gap.
What can actually go wrong?
The obvious answer is cyberattack. But focusing only on ransomware misses the more ordinary - and often more likely - causes of disruption.
An app is deleted. A developer, administrator or business user removes the wrong application. The mistake is discovered immediately, or three weeks later when someone tries to use it.
A flow is changed. A Power Automate flow is updated to support a new process. The change works in testing but behaves differently in production, overwriting records or routing actions incorrectly.
A deployment introduces a fault. A solution moved between environments replaces working components with incorrect versions or missing dependencies.
Dataverse information is altered. Records are deleted, overwritten or changed in bulk. The platform remains available, but the information inside it can no longer be trusted.
Permissions are damaged. An application still exists, but the people who need it can no longer access it, or the wrong people can.
A privileged account is compromised. An attacker need not encrypt the tenant - changing workflows, deleting apps or damaging access settings may be enough.
The problem is discovered too late. The organisation has a recovery option, but its retention window no longer reaches the last known-good state.
A worked example of the retention problem
Consider a mid-sized organisation running a monthly financial reconciliation. In early March, a solution deployment introduces a change to an approval flow that silently writes an incorrect cost-centre code on a subset of transactions. Nothing fails. No alert fires. The apps stay available, the audit log faithfully records every action, and DLP policies are working exactly as intended.
The problem surfaces on 12 April, when the finance team reconciles the quarter and the numbers do not agree. By then the damaging change is roughly forty days old. Every preventive and detective control performed correctly. The organisation still cannot roll back to a clean state, because its recovery window does not reach that far.
This is the scenario that retention limits decide, and it has nothing to do with an attacker.
Microsoft automatically backs up Power Platform environments that contain a database. As at July 2026, the default system backup retention period is seven days, and for production Managed Environments retention can be increased to a maximum of 28 days. Manual backups are generally retained for seven days unless extended for eligible production Managed Environments. Recently deleted environments can generally be recovered within seven days, with longer availability applying in some Dynamics 365 production scenarios. These figures change from time to time, verify current limits against Microsoft Learn before relying on them.
Those capabilities are useful and should form part of an organisation’s recovery approach. But a seven-day or 28-day window may not be enough when a damaging change remains unnoticed for longer. Nor does environment-level recovery answer the need to restore one specific app, flow, report or data item without affecting everything else that has legitimately changed since the recovery point.
Availability, disaster recovery and backup are not the same thing
This distinction is often lost in cloud discussions. Microsoft provides availability and disaster recovery capabilities, in-region resiliency and optional cross-region failover for eligible production environments, designed to keep services operating through infrastructure failures. That is important platform resilience, but it protects against a different class of problem. Failover preserves service when infrastructure fails; it does not undo logical changes made inside a working service. If a valid administrative action deletes information, a resilient platform faithfully preserves the deletion. If a compromised account changes a flow, high availability keeps the altered flow highly available. If corrupted data is replicated, the secondary copy contains the same problem.
This is why mature organisations separate four questions:
1. Can the service remain available?
2. Can the platform survive an infrastructure failure?
3. Can we recover information or configuration from before a damaging event?
4. Can we perform that recovery at the level and speed the business requires?
A "yes" to the first two does not automatically provide a "yes" to the last two.
ASD already treats backups as a core cyber control
ASD’s regular backups guidance does not describe backup as merely having another copy somewhere. It focuses on the ability to recover important data, software and configuration settings, and on protecting backups from compromise and unauthorised access. Higher maturity expectations include synchronising backups with the organisation’s essential business information, testing restoration, and preventing lower-privileged accounts from accessing or modifying backups.
That principle should not stop at servers and endpoints. If Power Platform now contains essential business information, business logic and operational processes, those assets belong in the recovery discussion too, which means knowing which apps, flows, reports and Dataverse tables are business-critical, how far back recovery must reach, whether a single item can be restored without an environment rollback, and whether any of it has been tested.
That is the point where backup stops being a product discussion and becomes an operational resilience discussion.
Native recovery is valuable - but understand what it is designed to do
There is no sensible argument for ignoring Microsoft’s native capabilities. They provide automatic system backups for supported environments, manual backup options, environment restoration and recovery mechanisms for recently deleted environments. Use them. Document them. Test them. But do not assume they satisfy every recovery requirement simply because they exist.
The right test is not whether Microsoft backs up Power Platform. The better questions are whether the available recovery method meets your required recovery point, recovery time, retention and granularity and whether it remains usable in the incident scenarios you are planning for.
For some environments, native recovery may be sufficient. For others, restoring an entire environment to recover one damaged component creates unnecessary disruption, a short retention period may not cover slow-moving corruption, and a recovery process depending entirely on the same administrative plane needs examination in scenarios involving compromised tenant credentials. There is no universal answer. There should, however, be a deliberate one.
The case for independent Power Platform backup
An independent backup does not replace Microsoft’s resilience, ASD’s guidance, good administration or disciplined application lifecycle management. It adds another recovery path.
Keepit protects Power Platform workloads including Power Apps, Power Automate, Power Pages and Power BI. Coverage includes canvas and model-driven apps, desktop and cloud flows, Power Pages, and Power BI dataflows and reports, with granular recovery so administrators can restore specific protected items rather than necessarily restoring an entire environment. Protected copies are held in Keepit’s independent cloud infrastructure rather than as another copy inside the production Microsoft platform; data is held across two mirrored data centres in the selected data-centre region and stored immutably.
For an Australian organisation, that can provide several useful capabilities:
A separate recovery boundary. The recovery copy sits outside the primary Microsoft environment, reducing dependence on one platform, one administrative plane and one failure domain.
Granular recovery. An administrator may be able to recover the affected app, flow, report or object without rolling back the entire environment and disturbing unrelated changes.
Longer historical reach. Retention can be aligned with business, regulatory and operational needs rather than a short native recovery window - which is precisely what the forty-day reconciliation scenario above turns on.
Faster investigation. Search and historical versions help determine when an item changed and identify a clean recovery point.
A clearer recovery workflow. Recovery becomes a defined operational process rather than an improvised response assembled after the incident has begun.
The point is not that every organisation must buy the same backup product. The point is that every organisation using Power Platform for meaningful work should decide whether its current recovery options are enough.
Start with the business process, not the product list
The fastest way to get Power Platform recovery wrong is to begin by counting apps. Not every app matters equally: a departmental lunch-ordering app and a field safety application should not receive the same recovery priority.
A sensible review begins with the business process. For every important Power Platform workload, identify the process it supports, the business and technical owners, the underlying environment, connected data sources, dependent identities and service accounts, maximum tolerable data loss, maximum tolerable downtime, required retention, required recovery granularity, recovery order, and evidence that the recovery process has been tested.
This work tends to expose uncomfortable truths. A critical application may have no clear owner. A flow may rely on the account of an employee who left six months ago. A production process may still be running in the default environment. A recovery test may never have been performed because everyone assumed somebody else was responsible. That is exactly why the review is worthwhile.
Questions to take into the review
1. Which Power Platform workloads would stop a business process if they failed? Start with operational impact rather than technical complexity.
2. Are critical apps and flows formally classified? If they are treated as informal departmental tools, they are unlikely to receive appropriate governance or recovery planning.
3. How long could damage remain unnoticed? A seven-day recovery window may sound reasonable until a faulty workflow is discovered during a monthly reconciliation.
4. Can the organisation recover one item, or does recovery require a full environment rollback?
5. What legitimate changes would be lost during an environment rollback? Recovering yesterday’s environment may also remove today’s valid work.
6. Is the recovery copy independent of the same cloud, identity system, administrative accounts and control plane?
7. Who can access or alter the backups? Recovery data should be protected from ordinary users, administrators who do not require access, and compromised production credentials.
8. Can the organisation recover during an identity or tenant incident, when normal administrative access is unavailable or untrusted?
9. Has restoration been tested? A documented capability is not the same as a demonstrated capability.
10. Is the result recorded in business continuity, disaster recovery, cyber incident and application lifecycle planning?
Secure configuration is the beginning - not the end
The ASD Blueprint gives Australian organisations a strong starting point for securing and governing Power Platform. Its controls should be understood, adapted and maintained. Secure configuration was never intended to answer every recovery question, and the Blueprint is explicit about that boundary.
Power Platform can still be affected by human error, damaging changes, compromised accounts, software faults, data corruption and incidents discovered beyond a native retention window. When the business depends on an app, flow, report or collection of Dataverse records, hoping the platform can recover it is not a strategy. The organisation should know what can be restored, how far back, how granularly, how long it will take, who can perform it, whether recovery survives a broader Microsoft or identity incident, and whether the process has actually been tested.
ASD’s Blueprint helps organisations reduce the risk. Microsoft helps keep the platform available. Independent backup can provide another route back when the running platform contains the wrong state, or when native recovery does not meet the requirement. Those are not competing ideas. They are different parts of the same resilience plan.
A secure platform is harder to compromise. A recoverable platform is harder to permanently disrupt.
Australian organisations using Power Platform for real business operations need both.