How to Answer Incident Response Plan Questions
Your customer asked: “Do you have an incident response plan?”
The short answer
A written incident response plan documents how the company prepares for and handles cybersecurity incidents. Do not treat an informal understanding, a cyber-insurance phone number, or a vendor service as proof that your company maintains a complete plan.
Educational guidance only. This page does not determine what is true about your company and does not create a security, compliance, testing, or certification claim.
What the customer is really asking
Understand the question before you answer it.
The reviewer wants confidence that your company knows how to identify, escalate, contain, communicate about, and recover from security incidents. Current NIST guidance treats incident response as part of broader cybersecurity risk management rather than a single document sitting on a shelf.
How to answer accurately
Start with the version that matches reality.
If a plan exists
State that it exists, identify its high-level scope or owner, and mention review or exercises only when those activities have occurred.
If you have procedures but no consolidated plan
Describe the current state accurately. Procedures or contacts can be useful, but do not call them a complete approved plan unless that is true.
If a third party helps with incidents
Explain the third party's role without implying that outsourcing assistance transfers all incident-response responsibility.
A useful answer structure
Status → scope → current practice → supporting information. Start with the direct answer, narrow it to what you can verify, explain how the practice works, and reference evidence only when that evidence actually exists.
Evidence that may help
These are examples, not requirements and not proof that your company has the practice. Use only evidence that really exists and is appropriate to share.
- Approved incident response plan
- Incident escalation or contact procedure
- Tabletop or exercise record
- Incident tickets or post-incident review records
What not to say
- That the plan is tested when it has only been approved.
- That cyber insurance constitutes an incident response plan.
- That a third-party service means your company has no internal responsibilities.
How Oredra handles this
Answer it once. Keep the truth behind the answer.
Oredra can help organize the approved plan and track whether review or exercise evidence actually exists before those stronger claims appear in a customer answer.
Inside Oredra, a written policy, stated company practice, implemented control, available evidence, tested control, and independent certification remain distinct. Oredra uses approved information to draft future answers and flags questions that the approved profile cannot support.
Authoritative references
Oredra uses primary guidance where a technical or assurance concept benefits from verification. These references do not determine your company's answer.
Related questionnaire questions
How do you notify customers of a security incident?
Describe the company process for deciding when and how affected customers are notified. Be careful with exact deadlines: notification timing can depend on contracts, laws, the facts of the incident, and the commitments your company has actually made.
Do you perform vulnerability scanning?
Vulnerability scanning generally means using tools or services to identify known weaknesses in systems, software, or configurations. Confirm the actual scope, frequency, and ownership before answering, and do not substitute penetration testing—or vice versa—as if they were the same activity.
Do you perform penetration testing?
Answer “yes” only when your company has actually had the relevant systems or application tested through a penetration-testing engagement. Vulnerability scans, automated security checks, and a written policy are not automatically penetration tests.