The first step on incident response is to think on what are all the circunstances that are not desirable and define what is the action plan in case that occurs.
For instance, when there’s a new Amazon GuardDuty finding that is reporting bitcoin mining or outgoing connections to malicious command and control IP addresses from Amazon EC2 instances, you could define as action plan to change the security groups setting one that does not allow outgoing connections, and only allows incomming connections for remote access (SSH/RDP) from an IP address of the workstation used by the incident forensics team.
It’s recommended to establish those scenarios where actions should be taken, document it in playbooks, and test it thru table-top exercises to teach the blue team and to verify that they know how to respond according to the corporate guildelines, and they are prepared.
Having a documented plan helps with consistency and scale, as when the most senior security resource is not available (i.e.: if she/he’s on vacations), if the plan is documented junior personnel can respond in a similar way, following the instructions of the most qualified resource.
A incident response plan not tested, is equal to a backup that never had a restore test… one does not know if it will work until you actually tested it.
https://d1.awsstatic.com/whitepapers/aws_security_incident_response.pdf
https://github.com/aws-samples/aws-customer-playbook-framework