diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst
index 4c34bcfb59ceb28a82b893f3f3dae7de47f53981..8d9c96011c9e04f1173d66b52c3ee9f2fd3fe85c 100644
--- a/source/chapter1-about.rst
+++ b/source/chapter1-about.rst
@@ -71,7 +71,8 @@ without UEFI is outside the scope of this document.
 - Update process can target a single firmware component or multiple components.  Updating multiple
   components and multiplexing boot combinations can be very challenging.  In this document we treat
   the firmware as a single entity regardless of the components it comprises.
-  Failing to update one of the components will lead to rollbacks of every affected component
+  Failing to update one of the components will result in an overall failure,
+  forcing the firmware to remain on the current bank.
 - Updating the firmware and the OS at the same time is prohibited.
 - A hardware watchdog **must** always be active when critical components are executed.
   It's advisable the watchdog is activated on the earliest possible boot stages.
@@ -83,8 +84,7 @@ Transactional updates
 ---------------------
 Since firmware updates are independent from the OS upgrades, an important aspect of the update
 policy is the device functionality.  If the OS ends up being unusable after a firmware update (while the platform is in the Trial state [FWU]_),
-the device must be able to detect this occurrence and steps must be taken to move the platform to
-the previously working firmware.
+the device must be able to detect this and force the platform to the previously working firmware.
 Two scenarios can be considered:
 
 #. The FW acceptance tests, executed by the OS, fail: The OS must request a FW downgrade by using the methodology described in :ref:`revert-sec`.
@@ -115,16 +115,19 @@ will go into a reboot loop.
 Brick protection
 ----------------
 The brick protection mechanism not only addresses the bricking during the firmware update, but
-addresses potential hardware failures.  The rollback counter might or might not be always bumped
-during an update.  If the secondary partition contains a valid firmware and the primary partition
-is unable to boot the device (e.g flash corruption),  the device is allowed to fallback on the
-secondary partition.
+can optionally protect the device against hardware failures.  The rollback counter might or 
+might not be always bumped during an update.  If the secondary partition contains a valid 
+firmware and the primary partition is unable to boot the device (e.g flash corruption),  
+the device is allowed to fallback on the secondary partition.
 
-If the update is going to update the rollback counters it's strongly advised to update both of the
+If the update is going to bump the rollback counters it's strongly advised to update both of the
 partitions.  In that case the upgrade process will run once to update the secondary partition.  Once
 that's finished and accepted,  the firmware update agent should update the former primary partition
 as well.  This process must not necessarily go through the entire update procedure.  Simply writing
 and verifying the firmware is enough.
+Similarly if an update of the secondary partition fails (e.g write failed),
+then the firmware update agent must restore the partition to a known working
+state (e.g overwrite it with the current working firmware)
 
 .. image:: images/rollback_protection_simple.png
   :width: 200px