We don't have a special "rollback plan" that's used only in emergencies. Since such a plan would only get tested in rare cases (i.e. when something went wrong), chances are it will be out of date and likely make things even worse.
But what we do have is a "Re-execute promotion", which can effectively be be used to rollback changes. Assuming you have your deployment plan configured correctly. Let's consider the state of a given application.
This tutorial was originally designed for BuildMaster v4. The screenshots and concepts may be a little out of date. An updated tutorial for BuildMaster v5 is coming soon.
You'll note below that Release 3.5 (Build 16) was deployed to Production.
To go back to Release 3.4 in production, navigate to the promotion details of the production-promoted build for that release.
You'll notice there's a big button called "Re-execute Promotion". Clicking on that will run the production deployment plan using 3.4 Build 2's context. Here's what the plan looks like.
The actions "Deploy Artifact" and "Deploy config files" are both designed to look at the execution context to determine what to do. In this case, "Deploy Artifact" will deploy the artifact associated with 3.4 Build 2. This will ensure that whatever files were deployed with 3.4 Build 2 will always be deployed with 3.4 Build 2.
Once the build has been re-deployed, the appropriate status is reflected in BuildMaster.
And like that, your changes are rolled back. Of course, this isn't a time machine and nothing (not even a time machine) can reliably and perfectly rollback all changes while keeping existing data.
So, be careful using re-executions / rollbacks.