Moving business systems to the cloud changes where your information lives. It also changes how you need to protect it. For a Knoxville or East Tennessee business, an important question is whether the accounts managing everyday operations could also damage the resources needed to recover from an incident.
A backup report showing successful jobs is useful. A recovery plan should also explain who can delete those backups, change their retention, or disable the protections around them.
On September 25, Microsoft published an investigation into destructive activity in an Azure cloud environment. Attackers used compromised application identities to discover resources, delete systems, and collect credentials. They also attempted to interfere with backup and recovery protections. Some safeguards blocked destructive actions. Microsoft did not confirm successful data exfiltration or observe a ransom note in the activity described.
The report concerns a specific Azure investigation. It does not mean every cloud customer is affected. Its broader lesson is useful: recovery planning should account for an attacker gaining administrative access.
Here are five questions to discuss with your technology provider.
1. Who can delete our backups?
Ask for a clear explanation of backup access. An employee who needs to restore an accidentally deleted file does not necessarily need permission to erase recovery history. Likewise, an application performing a narrow task should not automatically receive broad administrative privileges.
Include automated integrations in that conversation. Applications and scheduled jobs can use their own identities, sometimes called service principals. These accounts may operate without a person signing in each time, so reviewing only employee accounts leaves part of the picture unexplored.
The business goal is straightforward: give each identity the access its job requires, with additional oversight for destructive actions.
2. What prevents a compromised administrator from destroying recovery points?
Different backup products offer different safeguards. Examples include immutable storage, delayed permanent deletion, and approval by a separate authorized person for sensitive operations.
Microsoft documents these options for Azure Backup, including locked immutable vaults, enhanced soft delete, and multi-user authorization. Their availability and effectiveness depend on configuration. Having a product with these features does not establish that they are enabled for your environment.
Ask your provider to identify the protections actually in place, their limits, and the procedure for changing them. Be cautious with settings described as irreversible: retention and capacity requirements should be considered before locking them.
3. What happens if an application credential is exposed?
An application credential can grant access to business resources even when no employee password has been stolen.
Microsoft’s investigation reinforces an important response principle: removing an exposed credential from a webpage or document does not invalidate it. The credential must be revoked or rotated, and its previous use investigated.
For your business, establish who owns each integration and who responds when its credentials are suspected of exposure. Record that information somewhere your team can reach during an outage. An abandoned integration with unclear ownership can turn a manageable problem into a prolonged investigation.
4. When did we last test a meaningful restore?
A successful backup job establishes that a job completed. Your business also needs evidence that the right information can be recovered and used.
Choose a representative recovery exercise with your provider. Depending on your systems, that could involve restoring a business application, a collection of shared files, or a cloud workload into a controlled location.
Check whether the restored information opens correctly, whether required permissions are present, and how long the process takes. Compare that result with the downtime your business can tolerate. Document any missing dependencies, such as application licenses, encryption keys, or administrator access.
5. Can we reach the recovery plan when normal systems are unavailable?
Consider a practical scenario: staff cannot access email, the main administrator account is disabled, and the usual documentation portal is unavailable.
Who calls your provider? Where are emergency contact details? Who can authorize recovery work? Which business functions should return first?
Keep an accessible copy of essential procedures and agree on an alternative communication method. Include a process for verifying urgent instructions, especially requests involving credentials or remote access.
For small and midsize organizations, these questions turn backup protection into a business conversation. Owners define acceptable downtime and priorities; the technology team explains the controls and tests recovery.
CNS can help businesses in Knoxville and East Tennessee review those expectations and identify gaps. The aim is a recovery plan supported by protected backups, appropriate access, and evidence that restoration works when it matters.