Summary

  • RFC 2350 tells a CSIRT to describe whom it serves, how to report, what authority it has and which services it offers; those declarations define expectations, not the state of a particular case.
  • Receipt, incident confirmation, attribution, eradication, recovery and inter-party coordination are separate propositions. Each needs its own case-specific record.

Imagine a reporter sends an encrypted message to the address printed in a CSIRT description. The document is current, the public key is valid and the operating hours include the moment of submission. Those facts establish that the reporter used a declared channel under declared conditions. They do not establish that the message reached the working queue, that a human or system acknowledged it, or that anyone classified the contents.

This is the useful limit at the centre of June 1998’s RFC 2350, BCP 21. The memo responded to misunderstandings about what communities could expect from computer security incident response teams. Its answer was an information architecture: publish the team’s identity and contacts, charter, constituency, sponsorship, authority, policies, services, reporting forms and disclaimers. Constituents could then know where to report, what support was offered and what the team expected from them.

The document therefore improved accountability before an incident. It did not create a receipt after one.

A contact surface has several clocks

RFC 2350 asks teams to publish a time zone, operating hours, holiday schedule and whether a 24-hour hotline exists. That is more precise than merely listing an email address. It allows a reporter to judge whether immediate handling is a reasonable expectation.

But operating hours are a condition of service, not an observed response time. Four timestamps remain distinct: submission by the reporter, delivery to the advertised system, acknowledgement by the team, and a triage decision. A public statement can define the first route and its intended availability. Only message transport records, ticket creation, acknowledgements or equivalent case records can establish the later steps.

The distinction matters because “open around the clock” is easily converted into “this report was handled in real time.” RFC 2350 makes no such conversion. It even says support can vary with workload and the completeness of information supplied. A usable assessment should preserve the queue state, priority, requests for additional information and actual handoff times instead of inferring them from the service page.

A reported matter is not yet a confirmed incident

RFC 2350 defines triage as interpreting and prioritising incoming reports, relating them to ongoing incidents and trends, and helping determine whether an incident really occurred and its scope. The sequence is decisive: verification follows the report.

The later FIRST CSIRT Services Framework 2.1 makes the branch even clearer. Initial information may show a real incident, require more data, reveal a misconfiguration or hardware fault, be treated as a false alarm, or be forwarded to another responsible group. Report acceptance, incident analysis and forensic analysis are separate services with separate outcomes.

Accordingly, neither an address nor a ticket number proves the event described by the reporter. A ticket can prove that a claim entered a process. Confirmation requires the evidence and analysis that moved the case out of intake.

Constituency, authority and control do not collapse into one perimeter

RFC 2350 asks a CSIRT to define its constituency: the users, sites, networks or organisations to which it provides service. It separately asks the team to disclose its authority. A community team may be advisory, and even an organisational team may not have authority to intervene in every system inside the constituency boundary.

That separation prevents a common overread. A team may accept a report about a constituent, coordinate with another party and offer technical advice without having the power to isolate a host, preserve a device, compel a vendor, patch a service or restore production. The sponsoring organisation identifies where authority comes from; it does not prove that every operational owner has delegated every action.

An incident record therefore needs both the proposed action and the actor authorised to perform it. A request sent to a system owner is not containment. Advice to remove persistence is not evidence that persistence was removed.

The service catalogue contains different verbs

RFC 2350 divides incident response into triage, coordination and resolution. Triage assesses reports and helps verify occurrence and scope. Coordination categorises information under the disclosure policy and notifies involved parties on a need-to-know basis. Resolution services are described as usually additional or optional: technical assistance, eradication of the exploited vulnerability and its effects, and help restoring affected systems and services.

This ordering does not make every case a conveyor belt that automatically reaches the final station. A team can provide core triage while not offering local restoration. It can notify a counterpart without receiving confirmation. It can advise on eradication without controlling the affected system. RFC 2350’s own Security Considerations state that the memo is not concerned with particular responses and reactions to incidents, but with the appropriate description of responses provided by CSIRTs.

The FIRST framework preserves this granularity by listing report acceptance, incident analysis, artefact and forensic evidence analysis, mitigation and recovery, coordination and crisis-management support as distinct possible offerings. It also explicitly declines to assess the capability, capacity, maturity or quality of a particular team. A shared vocabulary is not a performance audit.

Attribution requires more than coordination language

RFC 2350 does not assign a general attribution verdict to a CSIRT description. It discusses secure communication, disclosure, cooperation, information categorisation and contact with other sites. None of those fields identifies an attacker.

Attribution may involve technical artefacts, timelines, infrastructure, identity evidence, intelligence, competing hypotheses and legal or organisational standards. RFC 3227 treats evidence collection and archiving as its own discipline, including identifying involved systems and evidence sources. FIRST likewise separates confirmed-incident analysis from artefact and forensic-evidence analysis. A service page can say that such analysis is offered; it cannot supply the missing artefacts or decide what they prove.

The defensible wording is narrower. “The CSIRT accepts reports and offers coordination” describes an interface. “The CSIRT attributed this incident to actor X” requires a dated conclusion, method, scope, confidence and supporting evidence. Without that record, the actor remains unestablished.

Recovery is a measured state, not a service label

RFC 2350 defines recovery as aid in restoring affected systems and services to their pre-incident status. The word “aid” matters: it does not necessarily place execution or final authority with the CSIRT.

Current NIST SP 800-61 Rev. 3 shows the operational records that a recovery claim normally needs. Recovery actions are selected and performed; restoration assets are checked; essential services and normal operation are confirmed; restored systems are monitored; asset integrity is verified; the end of recovery is declared against criteria; and documentation is completed.

Those are observations and decisions about a case. A published promise to help with recovery proves none of them. Equally, the appearance of a login screen does not show that the root cause was removed, hidden persistence was eliminated, data integrity was restored or dependent services were reconciled.

Sources and evidence limits

  • RFC 2350 — the 1998 BCP, its CSIRT description template and the distinctions among constituency, authority, triage, coordination and optional resolution.
  • FIRST CSIRT Services Framework 2.1 — a later taxonomy of potential services and outcomes; it does not rate a team’s capability, capacity, maturity or quality.
  • NIST SP 800-61 Rev. 3 — April 2025 response and recovery guidance, used here to identify case-specific recovery evidence.
  • RFC 3227 — separate guidance on collecting and archiving evidence.

This analysis does not audit a named CSIRT, measure its latency or claim that a listed service was not performed. It identifies the evidence boundary: a declaration can create a reasonable expectation of support, while execution and outcome require a case record.