RS.MA-01 says the incident response plan is executed in coordination with relevant third parties once an incident is declared. The answer to the outcome is simple to state: when someone with authority declares an incident, a written plan starts, a named person leads it, and outside parties such as your response firm, cloud provider, insurer and key suppliers are brought in according to that plan.
Most small companies have a plan on paper. The gap is usually the declaration moment and the third party coordination. Both are cheap to fix.
What good looks like
Declaration is a defined act. Someone is allowed to say "this is an incident", it is written in the ticket with the time, and from that moment the plan roles are active. Each incident has one lead. Everyone else knows their lane: technical response, communications, legal, and business owner.
Third parties are mapped before you need them. You know which supplier hosts what, who to call at each, what your contracts say about their support and notification duties, and whether you have an incident response firm on retainer. Detection tools can raise a confirmed incident automatically to the on call lead rather than waiting for a human to notice an email.
The plan also triggers other plans when needed, such as business continuity and disaster recovery.
How to implement it
- Write a one page plan. Include definition of an incident, who can declare, roles, severity levels, escalation, and links to playbooks.
- Name an incident lead rota with deputies. Make sure the lead can be reached out of hours.
- Build a third party table: name, service, what they can do for you in an incident, contact method, contract clause, and the information they will ask for.
- Agree in advance with your response firm or provider how you engage them, what access they get and who may authorize spend.
- Wire alerts to the on call path so confirmed detections open an incident record automatically where your tooling allows it.
- Create an incident record template: time declared, lead, severity, systems, actions, decisions, third parties contacted.
- Add triggers to start continuity and disaster recovery plans when the impact calls for it.
- Run a tabletop at least yearly and fix what it exposes.
Try it yourself
Click through it at your own pace, or open it full screen.
Evidence to collect
- The incident response plan with owner, version and review date.
- The incident lead rota.
- The third party contact table and relevant contract clauses.
- An engagement letter or retainer agreement with a response firm, if you have one.
- Incident records from real events or exercises showing declaration time and lead.
- Tabletop reports with actions and closure.
There is no CSF certification. What a customer or auditor wants is proof that the plan has been used, even if only in an exercise.
A worked example
At 02:40 a monitoring alert shows a production database exporting far more data than usual. The on call engineer checks it, believes it is real, and declares an incident in the tracker. The time is recorded and the engineer becomes interim lead.
The plan now does the work. The security lead is paged and takes over as incident lead, and the engineer moves to the technical lane. The cloud provider's support path from the third party table is opened with a request to preserve logs for the affected account. The response firm on retainer is called using the engagement steps agreed earlier, and the cyber insurer's notice line is noted for the morning because the policy requires prompt notice.
Because customer data may be involved, the plan also triggers the data breach playbook and starts the notification clock review with legal. Business continuity is not triggered yet, since service is up, but the lead sets a checkpoint in two hours to reconsider.
Every step is written into the incident record. By 04:00 there is a lead, a team, outside help engaged, and a clear list of open questions.
How to start this week
- Decide who may declare an incident and write it in the plan.
- Build the third party table for your five most important suppliers. Start with your cloud host, identity provider, source code host, email provider and payments provider.
- Send a test message down your on call path and measure how long it takes someone to respond.
- Ask your insurer or response firm what they need from you on first contact and keep it in the plan.
- Book the next tabletop and pick a scenario that involves a supplier.
Questions auditors and customers ask
- What triggers your incident plan? Show the definition and a declared incident.
- Which third parties do you involve and when? Show the table and a case where it was used.
- Who leads? Show the rota and an incident record naming the lead.
Common gaps
- Nobody is sure who may declare an incident, so people wait.
- The plan lists roles by name and the people have left.
- Third party contacts are a general support address with no after hours route.
- The incident response firm was never briefed and needs a week to get access.
- Cloud and SaaS providers are not in the plan even though they hold the logs you need.
- The plan has never been exercised.
Quick check
Who can declare an incident?
Name the roles in the plan. Many small teams let any on call engineer or the security lead declare, and let the lead downgrade later. Waiting for senior approval costs time.
Why involve third parties early?
They hold logs, controls and contractual duties. A cloud provider can often preserve evidence or restrict access faster than you can, and some contracts start notification clocks.
Sources
- NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, February 2024: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
- NIST CSF 2.0 implementation examples for RS.MA-01, as listed in the CSF 2.0 Reference Tool: https://www.nist.gov/cyberframework
CSF is voluntary guidance. There is no CSF certification, so use it to organize and show your own work.
