RFC 2350: describing your CSIRT in seven parts

RFC 2350 carries the number BCP (2) 21 in the best current practice series of the IETF (3). It was written by Nevil Brownlee and Erik Guttman, within the GRIP working group, and published in June 1998. Twenty-eight years later it remains the reference version: no RFC has replaced it, and the series page records three errata against it.

Its purpose is simple. It expresses what the Internet community expects of a CSIRT (4), a name the text treats as identical to the older term CERT (5), and it provides a template for the team to fill in and publish. That document is now required for Trusted Introducer accreditation, expected in a FIRST (6) membership application, and taken up as a minimum requirement by the SIM3 (7) maturity model.

• Seven parts, around thirty items, and a fully completed example provided as an appendix.
• No answer is imposed: the text describes what each subject means, not what should be written under it.
• One obligation of substance: publish. The text states that teams publishing this information to their constituency, meaning the client base they serve, is mandatory.
• Filling in and publishing this document has been a must for Trusted Introducer accredited teams since May 2009.
• Parameter O-5 of SIM3 takes up its minimum content, contact information, service windows, service description and disclosure policy, with a publicly available English version.
• The text has aged on cryptography and on the links it cites, not on the questions it asks.

The text sets its own limit in the abstract: it is not possible to define a set of requirements that would suit every team, but it is possible and helpful to list the topics that concern the communities being served. No topic therefore comes with a correct answer. Each one is discussed for what it means, and the team decides.

What is not left to choice is publication. The text is explicit: whatever the type of team, the constituency must know its policies and procedures, and it is therefore mandatory for the team to publish them. The same passage notes that not everything is meant to be public, since understanding a team’s internal workings is not required in order to report an incident to it.

Two appendices carry most of the practical use of the document. Appendix D gives the seven-part template. Appendix E gives a fully completed example, that of a fictitious university CERT. The example comes with an explicit reservation: it does not amount to endorsement by the working group or by the IETF of any particular set of procedures or policies, and the text states that using it as it stands is neither mandatory nor even appropriate in most cases.

The structure of Appendix D is designed to communicate a team’s policies and procedures to its constituency and to outside organisations, other teams in particular.

One difference between the two appendices is worth noting. The template in Appendix D stops at three items for the first part. The completed example in Appendix E adds a fourth, authenticating the document, which states where the signatures of the published versions can be found. It is that four-item version that most documents published today follow.

The difficulty of an RFC 2350 does not lie in the drafting. It lies in four decisions the text forces a team to put into words, and which are rarely written down anywhere else.

The constituency

The text asks for a perimeter to be drawn around the group being served, and then for the Policies part to explain how requests from outside that perimeter are handled. A team that chooses not to publish its constituency has to set out the reasoning behind that choice, the typical case being a commercial team bound by client contracts. The text also anticipates overlapping perimeters, as when a service provider serves customers who have teams of their own.

The authority

The text separates the perimeter of the constituency from the scope of control, and asks for the second to be identified. A team can serve a population without having the power to act on all of its systems. If other teams operate hierarchically inside the perimeter, they have to be named. The text then adds a blunt warning: disclosing a team’s authority may expose it to claims of liability, and every team is advised to seek legal advice on the matter.

The level of support

Part 4.1 asks for the list of incident types the team can address and the level of support attached to each, together with the factors that make that level vary, workload and completeness of the information reported. Since no list of incident types can be exhaustive, the text also asks for the default level of support for cases not listed. It adds that acting on vulnerability information is an optional proactive service policy, not a core service requirement for a CSIRT.

The disclosure policy

This is the most demanding part, and the text takes a position on it. It notes that the default status of any information a team receives is usually confidential, but that rigid adherence to that principle makes the team look like an informational black hole, which reduces the cooperation it gets from clients and from other organisations. The document therefore has to say what information will be reported or disclosed, to whom, and when.

The example in Appendix E shows what a complete answer looks like: seven categories of information, from private user information to statistical information by way of what it calls embarrassing information, set against eleven classes of recipient, from management to law enforcement, taking in the press, vendors and other teams. That example carries no normative weight, but it gives the measure of the work.

On this particular point, a team writing its RFC 2350 in 2026 no longer has to invent its own grammar for onward sharing: TLP (8) 2.0 provides it, and saying that it applies is enough.

A 1998 RFC could have remained a curiosity. Three mechanisms turned it into a mandatory step.

• Accreditation. Filling in and publishing an RFC 2350 has been a must for Trusted Introducer accredited teams since May 2009. The document is presented there as the practice that urges every security team to state its mandate and its services clearly.
• Membership. The site visit report template used by FIRST for candidate teams states that team information is available in RFC 2350 format in the application documentation.
• Maturity. Parameter O-5 of SIM3 requires contact information, service windows, a concise description of the services offered and the policy on information handling and disclosure, publicly available in English. RFC 2350 is the standardised way to publish that set. The full walkthrough of the model’s forty-five parameters is in the article on SIM3 v2 interim.

The exercise is not limited to CSIRTs either. The team type document published by FIRST defines four types of incident management team, each aligned with the services it provides: CSIRTs, PSIRTs (9), SOCs (10) and ISACs (11). The reasoning behind RFC 2350 holds for all four: say who you serve, what you handle, how you can be reached and what you disclose.

Reading RFC 2350 today means separating the reasoning, which has not moved, from the technical examples, which date from 1998. The table below does the sorting.

One remark in the text is worth rereading in the light of what followed. The authors wrote that a central repository of all completed templates would be very useful, that none existed at the time of writing, and that this might change. The Trusted Introducer and FIRST directories now fill that role, and search engines do the rest, which the text also anticipated.

What the text itself flags as critical

The points below are not outside recommendations. They appear in the RFC, and they describe what makes a published document useful or harmful.

• The completed template must state when it was last changed, and how to learn about future updates. Without that, misunderstandings build up over time, and the text warns that an outdated document can do more harm than good.
• The document should be protected by a digital signature, which the text strongly recommends for the online version as well as for update messages.
• Whoever reads the document must be able to check its authenticity, so the signature has to be published alongside it.
• The document belongs on the team’s own information server. The text flags the problem that remains: the constituency still has to find out that the team exists.
• Where the document is translated, the translated version carries a warning and a pointer to the original, and the text supplies an example clause making the original version prevail in case of divergence.
• The constituency is entitled to expect the services described in the published document. What goes in it commits the team.

The method

• Start from Appendix D for the structure and from Appendix E for the level of detail, without reusing the policies of the example, which bind no one.
• Settle the four decisions from the previous section before opening the editor. That is where the real work sits.
• Name the services with the CSIRT Services Framework rather than with the organisation’s internal vocabulary.
• Anchor the disclosure policy to TLP 2.0 and the incident classification to the RSIT.
• Publish at a stable address, in plain text and in PDF, with the detached signature next to it, and a version number carrying its date.
• Publish an English version, which is what parameter O-5 of SIM3 requires and the condition for being readable by teams abroad.
• Read documents already published by other teams before writing your own. Team Cymru, KIT-CERT and REN-ISAC publish theirs, the second with a signed version in PDF and in plain text, the third with a version number and a notification list.

The content of the RFC was taken from the page as rendered by the series editor, not from secondary coverage. The community requirements come from the organisations that set them.

1. RFC (1): Request for Comments, the reference document series published by the Internet community.
2. BCP (2): Best Current Practice, the category of RFC that states a practice in force, identified by its own series number.
3. IETF (3): Internet Engineering Task Force, the organisation that produces Internet standards.
4. CSIRT (4): Computer Security Incident Response Team.
5. CERT (5): Computer Emergency Response Team, the older name, equivalent to CSIRT.
6. FIRST (6): Forum of Incident Response and Security Teams, the worldwide organisation of incident response teams.
7. SIM3 (7): Security Incident Management Maturity Model, the model used to measure the maturity of security incident management.
8. TLP (8): Traffic Light Protocol, the marking protocol that governs onward sharing of information.
9. PSIRT (9): Product Security Incident Response Team, the incident response team of a product vendor or manufacturer.
10. SOC (10): Security Operations Centre, the team in charge of monitoring and detection.
11. ISAC (11): Information Sharing and Analysis Center, a sector-level information sharing body.
12. PGP (12): Pretty Good Privacy, a mechanism for encrypting and signing messages, standardised as OpenPGP.
13. PEM (13): Privacy Enhanced Mail, a secure messaging mechanism of the 1990s, based on a hierarchy of certification authorities.
14. MOSS (14): MIME Object Security Services, another message security mechanism from the same period.
15. S/MIME (15): Secure MIME, the certificate-based standard for signing and encrypting electronic mail.
16. DES (16): Data Encryption Standard, a symmetric encryption algorithm withdrawn from use.
17. RSIT (17): Reference Security Incident Taxonomy, the reference taxonomy of security incidents developed with ENISA support.

1. IETF, RFC 2350, BCP 21, Expectations for Computer Security Incident Response, June 1998, record accessed 15 September 2026. rfc-editor.org
2. IETF, RFC 2350, full text, accessed 15 September 2026. rfc-editor.org
3. Trusted Introducer, De-Facto Standards for CSIRTs and other security teams, accessed 15 September 2026. trusted-introducer.org
4. FIRST, site visit report template for membership candidates, accessed 15 September 2026. first.org
5. FIRST, CSIRT Services Framework v2.1.0, accessed 15 September 2026. first.org
6. FIRST, Team Types within the Context of Security Incident Management, version 1.2, accessed 15 September 2026. first.org
7. FIRST, Traffic Light Protocol, accessed 15 September 2026. first.org
8. Open CSIRT Foundation, SIM3 v2 interim, Full Standard, 1 January 2023. opencsirt.org
9. ENISA, Reference Security Incident Taxonomy, accessed 15 September 2026. github.com
10. Team Cymru, RFC 2350 document, accessed 15 September 2026. team-cymru.com
11. KIT-CERT, CERT Description as per RFC 2350, accessed 15 September 2026. cert.kit.edu
12. REN-ISAC, CSIRT RFC 2350, accessed 15 September 2026. ren-isac.net