Rollback
Sometimes a remediation needs to be reversed. Perhaps the fix introduced an unexpected side effect, broke a downstream dependency, or was applied to the wrong resource. Guardian Pro's rollback capability lets you safely undo a remediation and restore the resource to its pre-remediation state.
When Rollback Is Available
Not every remediation is reversible. Whether rollback is available depends on the nature of the change:
- Reversible remediations -- Changes that can be cleanly undone, such as modifying a security group rule, changing an encryption setting, or updating a configuration parameter. These show a Rollback button after successful remediation.
- Non-reversible remediations -- Changes that cannot be automatically undone, such as deleting a resource, rotating credentials, or making structural changes. These are clearly marked as non-reversible in the remediation preview.
Reversibility is displayed during the remediation preview, before you confirm the fix. If rollback capability is important to you, check this information before proceeding.
How Rollback Works
The rollback process is a structured pipeline that ensures safety at every step.
Step 1: Initiation
Click the Rollback button on a remediated finding. Guardian Pro begins the rollback process, which moves through several validation stages before any changes are made.
Step 2: Snapshot Retrieval
When a remediation is applied, Guardian Pro captures a snapshot of the resource's configuration before the change. During rollback, this snapshot is retrieved and used as the target state. The rollback will restore the resource to exactly the configuration it had before the remediation.
Step 3: Cascade Analysis
Before executing the rollback, Guardian Pro performs a cascade analysis to determine whether reversing the change could affect other resources in your environment.
What Cascade Analysis Checks
Guardian Pro examines the dependency graph of your infrastructure to identify:
- Dependent resources -- Other resources that rely on the remediated resource's current configuration.
- Downstream effects -- Services or workloads that might be affected if the configuration is reverted.
- Blocking conditions -- Situations where rolling back would be unsafe or impossible.
Analysis Results
The cascade analysis produces one of three outcomes:
| Result | Meaning | Action |
|---|---|---|
| Clear | No downstream dependencies or risks identified. Rollback can proceed safely. | Rollback executes automatically. |
| Soft blockers | Potential impacts identified, but rollback is possible with acknowledgment. Examples: production environment, shared resource, high-impact change. | You are prompted to review and approve before proceeding. |
| Hard blockers | Rollback cannot proceed safely. Examples: resource no longer exists, resource is locked, access denied. | Rollback is blocked with an explanation. Manual intervention is required. |
Pay close attention to soft blockers. They do not prevent rollback, but they indicate that the rollback may have wider effects than expected. Review the listed impacts before approving.
Step 4: Execution
Once the cascade analysis clears (or you approve soft blockers), Guardian Pro executes the rollback:
- The resource's current configuration is compared against the snapshot.
- The required API calls are made to restore the pre-remediation state.
- The resource is returned to its original configuration.
Step 5: Completion
After a successful rollback:
- The finding's status changes to Rolled Back and then returns to Active, since the original issue is now present again.
- The health score recalculates to reflect the re-opened finding.
- An audit trail entry records the rollback, including who initiated it and the full timeline.
Rollback Statuses
The rollback process moves through several statuses, which you can track in real time:
| Status | Description |
|---|---|
| Pending | Rollback has been initiated and is queued. |
| Validating | Pre-conditions are being checked. |
| Initializing | Rollback resources are being prepared. |
| Snapshot Retrieved | The pre-remediation snapshot has been loaded. |
| Cascade Analyzed | Dependency analysis is complete. |
| Executing | The rollback changes are being applied. |
| Completed | Rollback finished successfully. |
| Failed | Rollback encountered an error and could not complete. |
| Blocked | Cascade analysis found hard blockers preventing rollback. |
| Cancelled | Rollback was cancelled by the user. |
If a rollback fails, no partial changes are left behind. Guardian Pro ensures that either the rollback completes fully or the resource remains in its current (remediated) state.
Rollback Time Window
Rollback is available as long as the remediation snapshot is retained. Snapshots are kept for a defined retention period. After this period, the rollback option is no longer available for that remediation.
We recommend initiating rollbacks as soon as you identify the need, rather than waiting. The sooner you roll back, the less likely that subsequent infrastructure changes will complicate the process.
What Happens After a Rollback
After a rollback completes:
- The finding returns to Active status. Since the original issue is restored, the finding reappears in the Action Centre as an active item.
- The health score drops. The re-opened finding contributes to health score deductions again.
- You can re-remediate. The finding can be remediated again at any time, either with the same automated fix or with a different approach.
Rollback and Infrastructure-as-Code
If the original remediation triggered a Template Update Needed advisory (because the resource was CloudFormation-managed), rolling back the remediation also resolves the template drift concern, since the resource returns to its original state matching the template.
Frequently Asked Questions
Can I roll back a rollback?
No. Rolling back returns the resource to its pre-remediation state. If you want to re-apply the fix, use the standard remediation workflow on the now-active finding.
What if the resource was modified after remediation but before rollback?
The cascade analysis detects configuration changes that occurred after remediation. If the resource has been modified since the remediation was applied, Guardian Pro will flag this as a potential concern during the analysis. The rollback will restore the pre-remediation snapshot, which may overwrite changes made after the remediation.
Can I roll back a bulk remediation?
Yes. Each finding that was remediated as part of a bulk action can be rolled back individually. There is no requirement to roll back the entire batch.
What if cascade analysis finds hard blockers?
Hard blockers mean that rollback cannot proceed automatically. Common hard blockers include:
- Resource not found -- The resource was deleted after remediation.
- Resource locked -- The resource is protected by a resource lock or deletion protection.
- Access denied -- The IAM role lacks permissions to modify the resource.
In these cases, you will need to address the blocker manually. Guardian Pro provides specific details about what is blocking the rollback and guidance on how to resolve it.
Next Steps
- Remediation -- Review the full remediation workflow.
- Bulk Actions -- Learn about batch operations.
- Understanding Findings -- Review finding statuses and lifecycle.
- Action Centre Overview -- Return to the full overview.