minor

Author: montyly

development-guidelines/incident_response.md

@@ -6,7 +6,7 @@ How you respond during an incident is a direct reflection of your efforts to pre
 
 - **Identify the components that should/should not be**
   - **Pausable**. While pausing a component can be beneficial during an incident, you must assess its potential impact on other contracts.
-  - **Migrable or upgradeable**. Discovering a bug might necessitate a [migration strategy](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) or contract upgrade to fix the issue; note, however,   that upgradeability has its own [sets of risks](https://blog.trailofbits.com/2020/12/16/breaking-aave-upgradeability/). Making all contracts upgradeable is not a solution in and of itself. 
+  - **Migratable or upgradeable**. Discovering a bug might necessitate a [migration strategy](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) or contract upgrade to fix the issue; note, however, that upgradeability has its own [sets of risks](https://blog.trailofbits.com/2020/12/16/breaking-aave-upgradeability/). Making all contracts upgradeable might not be the best approach.
   - **Decentralized**. Using decentralized components can sometimes restrict rescue measures.
 - **Evaluate what events are needed**. A missed event in a critical location might result in unnoticed incidents.
 - **Evaluate what components must be on-chain and off-chain**. On-chain components are generally more at risk, but off-chain components push the risks to the off-chain owner.
@@ -16,7 +16,7 @@ How you respond during an incident is a direct reflection of your efforts to pre
 
 - **Document how to interpret abnormal events emission**. Only emitting events isn't sufficient; proper documentation is crucial, and users should be empowered to decode them.
 - **Document how to access wallets**. Clearly outline how to access wallets. Both the location and access procedures for every wallet should be clear and straightforward.
-- **Document the deployment and upgrade process**. Deployment and upgrade processes are risky and must be thoroughly documented. This should include how to test and valide the deployment/upgrade (ex: using fork testing). 
+- **Document the deployment and upgrade process**. Deployment and upgrade processes are risky and must be thoroughly documented. This should include how to test the deployment/upgrade (ex: using fork testing) and how to validate it (ex: using a post-deployment script).
 - **Document how to contact the users and external dependencies**. Define guidelines regarding which stakeholders to contact, including the timing and mode of communication in case of incidents.
 
 ## Process
@@ -34,7 +34,8 @@ How you respond during an incident is a direct reflection of your efforts to pre
 - **Identify dependencies, and monitor their behaviors to be alerted in case of compromise.** Follow twitter, discord, newsletter, etc.
 - **Maintain open communication lines with your dependencies owners**. This will help you to stay informed if one of your dependency is compromised.
 - **Subscribe to https://newsletter.blockthreat.io/**. BlockThreat will help you stay informed about recent incidents. 
-- Consider conducting a threat modeling exercise. This exercise will identify risks that an application faces at both the structural and operational level. If you're interested in undertaking such an exercise and would like to work with us, [contact us](https://www.trailofbits.com/contact/).
+
+Additionally, consider conducting a threat modeling exercise. This exercise will identify risks that an application faces at both the structural and operational level. If you're interested in undertaking such an exercise and would like to work with us, [contact us](https://www.trailofbits.com/contact/).
 
 ## Incident Response Plan Resources