A Solo Founder's One-Page Incident Response Plan

A solo founder incident response plan should tell you what to do when a security report arrives: record the facts, decide who can help, choose the next action, and set a time to reassess. Keep that first page available offline, with links to the detailed procedures you will need. Then rehearse it using a fictional report.

On November 2, 2026, NIST published Small Business Cybersecurity: Non-Employer Firms, a guide for businesses whose owners are their only paid employees. Its appearance on Hacker News makes this a timely moment to ask a practical question: if someone reports a problem tonight, can you start responding without inventing your process?

You do not need a large security team to write down the answer. You do need to know where your own ability ends and whose help you can actually reach.

Start with a plan you can use while your normal tools are unavailable

Your first page is a decision aid, not a full security manual. It should point to your support contacts and procedures even if your business email or usual document account is unavailable.

NIST’s new guide introduces cybersecurity in plain language and pairs actions with ways to begin and develop them as a business grows. Our one-page format below is an editorial adaptation for a founder running a small software business. NIST does not require this format, a particular response time, or a vulnerability disclosure platform.

Fill it in for one service first. Choose the product customers depend on, rather than trying to document every device you own. Store an offline copy securely; put access instructions on it, not passwords or recovery codes.

A name alone is not enough. If your technical contact is a freelancer, confirm whether they have agreed to help, when they are reachable, and what access they would need. Do not discover during an incident that “call someone technical” means searching for a stranger.

Separate the incoming report from the incident decision

A security report is information to assess. It may describe a genuine vulnerability, a misunderstanding, or evidence of an ongoing compromise. Your first reply should acknowledge receipt without pretending you have established which one it is.

Use this decision table as a starting point for your own procedures. It is our operational example, not a NIST severity scale.

Do not ask a researcher to collect additional customer records to prove the issue. Use your own authorized test accounts and involve a qualified responder when investigation could expose more data or interrupt service.

A first reply can be brief: “We received your report and are reviewing the affected feature. Please avoid accessing or sending additional customer data. We will update you by [time and time zone].” Choose a time you can keep, including when the update is that investigation continues.

For the separate task of defining a public reporting channel and its scope, see our vulnerability disclosure program guide. The response plan answers what you do after that channel brings you a report.

Rehearse one fictional report before a real one arrives

A rehearsal should expose missing contacts and decisions without changing production systems. Walk through a fictional scenario, record where you get stuck, and repair the plan.

The Australian Signals Directorate’s small business guidance recommends simple drills, checking response times and decision-making, and refining plans from the results. The following SaaS exercise is our suggested way to apply that principle.

Imagine a researcher writes: “I can access another customer’s exported file from this URL.” No real file or customer data is needed. Mark the exercise clearly and keep it out of public reporting channels.

1. Find the page. Assume your work email is unavailable. Can you locate the offline plan and identify your support contacts?
2. Open an exercise record. Write down when the fictional message arrived, what it claims, what is unknown, and who owns the next decision.
3. Draft the acknowledgment. Give the reporter a next update time without asserting that you have confirmed a breach or completed a fix.
4. Choose the escalation. Identify who can inspect the relevant access logs and who could restrict the affected export feature. Describe the action; do not perform it in production.
5. Locate the recovery procedure. Identify the access you would need and the checks that would establish the service is safe to resume.
6. Record the gaps. Replace “check logs” with the actual location and access method. Replace “contact host” with the support route you verified.

Set aside enough time to work through the decisions. Finishing quickly does not prove readiness. If you cannot name the person who could assess the reported exposure, that is a useful result: arrange that help before you rely on the plan.

Keep a factual record through response and recovery

Record what you know separately from what you suspect. Each consequential action should have a time, an owner, and a reason, so you can explain how your understanding changed.

NIST’s response guidance in CSWP 50 calls for documenting detection time, relevant logs and screenshots, and actions taken. It also addresses practicing the plan, keeping important contacts offline, and verifying backup integrity before recovery. These are useful checks to apply to your first page and the procedures it references.

For the fictional export report, an entry might read: “14:10 UTC: report received. Researcher claims cross-customer file access. Not yet reproduced. Owner: founder. Next step: technical responder reviews export authorization and available access logs.” A later entry can correct the working hypothesis without rewriting the earlier record.

A deployed fix, a restored service, and a verified resolution answer different questions. Decide which checks your service needs and who can perform them. If you use a backup, follow your recovery procedure and validate the restored service before treating recovery as complete.

Also locate your applicable notification obligations in advance. The guide is not a universal legal deadline, and a vulnerability report alone does not establish that customer notification is required. Record where your contractual and jurisdiction-specific requirements are documented and whom you would consult.

Use Kit for report coordination alongside your response plan

A report workflow can keep ownership, correspondence, and progress together. Your offline plan still needs to cover support contacts, system recovery, and decisions outside that workflow.

Kit’s Security workflow supports assigned reports, researcher correspondence, internal notes, and a report timeline. Its report lifecycle distinguishes investigation and resolution from fix verification. Those capabilities can help you keep a vulnerability report moving while you investigate it; they do not establish whether an incident occurred or recover your infrastructure for you.

If you already use Kit, rehearse with a clearly labeled exercise record and check that you can find the owner, correspondence, and next action. Keep sensitive supporting material restricted to the people who need it. You can review the Security workflow when deciding whether it fits your report-handling process.

Start with the page you can use tonight: a reachable contact, an evidence location, a decision owner, and the next update time. Run the fictional report through it, fix one missing step, and save the revised offline copy.