Incident response writing assumes you have an incident response team — a designated commander, a forensics specialist, a comms lead, a legal liaison. Most small businesses don't have any of those, won't have any of those, and shouldn't pretend to. Pretending you have an IR team you don't have is worse than admitting you don't have one, because it produces unrealistic plans that fall apart on contact with a real incident.
The IR playbook for a 30-person business is short and honest. Step one: decide, before anything happens, who makes the call when something goes wrong. This person is the incident commander for that incident, full stop, regardless of their normal role. Their job is not to fix the problem; it's to coordinate everyone who's trying to fix the problem. Usually this is the CTO, the head of IT, or a designated technical co-founder. Make the decision now, write it down.
Step two: have a phone list. Who do you call when the website is down? Who do you call when ransomware is suspected? Who do you call when an employee notices their email has been sending phishing for the last hour? For each scenario, the answer should be a name and a phone number, not a vendor's general support email. The phone list lives somewhere outside the systems that might be compromised — printed on paper, stored on a personal phone, anywhere accessible during an outage. Test the phone list once a year.
Step three: pre-write the customer-comms template. Most small business breaches go badly not because of the technical impact, but because of the messaging vacuum during the eight hours between "we have a problem" and "we know what to say about it." If you have a template — a generic "we're aware of an issue affecting [X], we're investigating, we'll update by [time]" — somebody can send it out in three minutes when it matters. That communication is often the single most important thing you do during an incident, and it should not be drafted at 11 PM under pressure.