Forty-five parameters, five levels, a licence that is free for internal use and an online self-assessment open to anyone. SIM3 (1) measures the maturity of security incident management, and its full version 2, expected in the course of 2026, will open it to the other families of security teams.
The essentials
SIM3 is the model used to measure the maturity of security incident management. It is owned by the OCF (2), which allows and promotes its free use for internal and not-for-profit purposes. The reference version is v2 interim, published on 1 January 2023 and still in force at the time of writing. It is signed by Don Stikvoort, Klaus-Peter Kossakowski and Mirosław Maj.
The model was written for CSIRTs (3), a name the standard treats as identical to the older term CERT (4). It is now used well beyond that perimeter, and the full version 2, expected in the course of 2026, will explicitly cover four families of teams, SOCs (5) among them. Vulnerability management teams, often called VOCs (6), are not named in the announced typology, but the model reads for them too, for the reason set out below.
- A single scale of five levels, 0 to 4, valid for all forty-five parameters, with no variant per domain.
- Four quadrants, Organisation, Human, Tools and Processes, chosen so that parameters are as mutually independent as possible.
- Four pillars covered, prevention, detection, resolution, quality control and feedback.
- Eight parameters carry a minimum requirement written into the model, the rest being left to the team’s judgement.
- An online self-assessment tool, free of charge, that walks through the model parameter by parameter.
- Public baselines that say what to aim for in a given context, from eleven parameters for FIRST (7) membership to all forty-five for the ENISA (8) baselines.
- A typology of four team types, CSIRT, SOC, PSIRT (9) and ISAC (10), agreed with FIRST in 2023 and built into the full version 2.
SIM3 does not produce an overall score, it produces a profile of forty-five values. In most cases, moving up one level means writing down what the team already knows how to do, then having it approved. Neither of those two operations depends on a tool or on a budget.
What SIM3 measures
The model rests on three elements, and nothing else. Maturity parameters, forty-five of them, which are the quantities measured. Quadrants, four of them, which are the categories the parameters belong to. Levels, five of them, which express the value measured on each parameter.
The stated subject is not incident response alone, it is security incident management as a whole, which has four pillars: prevention, detection, resolution, quality control and feedback. The primary scope is cyber security incidents, those involving computers of all sorts, network appliances including IoT devices, networks themselves and the information held on them and conveyed through them. The model states that this scope can be widened or narrowed, usually with no significant consequence for the measurement.
| Quadrant | Parameters | What the quadrant looks at |
|---|---|---|
| O, Organisation | 11 | The mandate, the constituency served, authority, responsibility, services, and the framework that ties it all together |
| H, Human | 7 | Ethics, staff resilience, expected skills, training, external networking |
| T, Tools | 10 | Knowledge of the estate, sources, messaging, incident tracking, resilience of the basic means, and the prevention, detection and resolution toolsets |
| P, Processes | 17 | Escalations, detection, resolution, audit, information handling, reporting, meetings, relations with peers |
The split into quadrants is not cosmetic. It was built so that two parameters in the same quadrant overlap as little as possible, which avoids measuring the same thing twice and makes the resulting profile usable.
The model uses the word CSIRT for reasons of word economy, to describe any security incident management capability to which SIM3 is applied, whether that capability is a team, a service or a function. The text acknowledges that a more neutral term would be better on substance, and keeps CSIRT because it is already understood by everyone.
The five levels, and what they ask for
The same scale applies to all forty-five parameters. That simplicity is a deliberate choice by the authors, who consider it more useful than the precision a per-parameter scale would bring.
| Level | Wording used by the model | What it takes to reach it |
|---|---|---|
| 0 | Not available, undefined, unaware | The subject has not been discussed in the team yet. Starting to discuss it is often enough to move up |
| 1 | Implicit | The subject is known and considered, but not written down. Several team members will describe it differently |
| 2 | Explicit, internal | The subject is written down, without being formalised. A team wiki or a shared site is enough |
| 3 | Explicit, formalised on the authority of the team head or above | The written material is approved or published by the team head, or by a higher level |
| 4 | Explicit, audited on the authority of governance levels above the team head | Level 3, plus a check run by a higher level, with feedback to the team |
What level 2 is worth
The model explicitly recommends an internal documentation space of the wiki type, for two reasons. The first is that processes, tools and policies become available to the people doing the incident work. The second is that hyperlinks allow parameters to be connected to each other, the information sources list pointing for instance to the processes that use those sources.
One frequent case is worth knowing. When a tool holds information relevant to a parameter without the team head having ratified it, the parameter sits at level 2. The model gives the example of the incident tracking system, which almost always carries a drop-down list of incident categories: as long as that list has not been formally approved, the incident classification parameter is capped at level 2.
The three conditions for level 4
Level 4 is the only level that sits outside the team’s own decision-making. It implies level 3, plus the active attention of a governance level above the team head, for which evidence must exist. Three elements are required.
- There is a process of checking, assessing or auditing the parameter, run on the authority of a governance level above the team head.
- That process is followed regularly. The model sets no rule yet, and takes as best practice at least once every two years, and usually once a year.
- That process is active, meaning that a feedback mechanism towards the team head and the team accompanies the check and the report that follows from it.
Two cases give clear-cut evidence. The first is a parameter whose subject is unambiguously part of a country’s cyber security legislation: the parameter then scores level 4, on the understanding that the team still has to implement it internally for the law to have any effect. The second is a team charter that includes a paragraph on the assessments and audits the team is subject to. An internal self-assessment, on its own, is never sufficient to establish level 4.
The authors acknowledge the limit of their choice: a few parameters, once applied to a real team, are reluctant to be mapped onto a specific level. They observe that since 2008 the advantages of the single scale have far outweighed those quirks. An honest assessment therefore accepts a few judgement calls, and documents them.
The forty-five parameters, quadrant by quadrant
The full list is the best way into the model, because it shows straight away how much is already in place in a team that works. Most parameters describe ordinary practice, and the only question asked about them is whether that practice is written down and approved.
Quadrant O, Organisation, eleven parameters
| Parameter | What it looks at |
|---|---|
| O-1 Mandate | The team’s assignment, derived from a higher governance level |
| O-2 Constituency | The client base served by the team, internal to the organisation or external |
| O-3 Authority | What the team is allowed to do towards its constituency, escalation included |
| O-4 Responsibility | What the team is expected to do towards its constituency |
| O-5 Service Description | What the service is, and how to reach it |
| O-6 Public Media Policy | How to deal with the press and social media, crisis situations included |
| O-7 Service Level Description | What the constituency and peer teams can expect, in time and in quality |
| O-8 Incident Classification | The availability and application of a classification scheme to recorded incidents |
| O-9 Participation in CSIRT Systems | Membership of an established cooperation, directly or through an upstream team |
| O-10 Organisational Framework | The team charter, which brings O-1 to O-9 together in a controlling document |
| O-11 Security Policy | The security framework the team operates within, business continuity included |
Two parameters in this quadrant deserve close reading. The gap between O-3 and O-4 is natural, since a team is almost always more responsible than it is empowered. The model warns that this gap should not grow too wide, otherwise the team is expected to handle matters it has no power over. As for O-6, it is the addition made by v2 interim: v1 therefore had forty-four parameters, and this one is omitted from scoring when the assessment is run against v1.
Quadrant H, Human, seven parameters
| Parameter | What it looks at |
|---|---|
| H-1 Code of Conduct, Practice or Ethics | The rules for professional behaviour, including outside work |
| H-2 Staff Resilience | Continuity of the service during illness, holidays or departures |
| H-3 Skillset Description | The skills expected on each position, technical and soft |
| H-4 Staff Development | The professional development policy for team members |
| H-5 Technical Training | The programme through which the expected technical skills are acquired |
| H-6 Soft Skills Training | The programme for communication and presentation training, crisis communication included |
| H-7 External Networking | The policy on sending team members to community meetings |
The model is explicit on a point that is often missed: a generic ethics code held by the host organisation does not satisfy H-1, because it says nothing about the work the team actually does. Two texts are offered as a starting point, the Trusted Introducer CSIRT Code of Practice and EthicsFIRST.
Quadrant T, Tools, ten parameters
| Parameter | What it looks at |
|---|---|
| T-1 IT Assets and Configurations | Knowledge of the hardware, software and configurations in use in the constituency |
| T-2 Information Sources List | Where vulnerability, threat and scanning information comes from |
| T-3 Consolidated Messaging Systems | Message systems open to all team members |
| T-4 Incident Tracking System | The ticketing or workflow tool that records incidents and tracks their handling |
| T-5 Resilient Voice Calls | Availability of voice means, at the level demanded by O-7 |
| T-6 Resilient Messaging | Availability of message means, at the level demanded by O-7 |
| T-7 Resilient Internet Access | Availability of Internet access, at the level demanded by O-7 |
| T-8 Incident Prevention Toolset | The tools that keep incidents from happening, or their results |
| T-9 Incident Detection Toolset | The tools that detect incidents, or their results |
| T-10 Incident Resolution Toolset | The tools used to handle incidents once they have happened |
For the last three parameters, the model does not require the team to operate the tools itself. It can be their architect, their user, or only the recipient of their results, provided its role is defined for each of them. The same flexibility applies to T-1: the team does not have to manage the CMDB (11), it has to have access to it.
Quadrant P, Processes, seventeen parameters
| Parameter | What it looks at |
|---|---|
| P-1 Escalation to Governance Level | Raising critical incidents to the right level of management |
| P-2 Escalation to Press Function | Direct access to spokespersons, including outside business hours |
| P-3 Escalation to Legal Function | Direct access to legal experts, including outside business hours |
| P-4 Incident Prevention Process | How the team prevents incidents, vulnerability and patch advisories included |
| P-5 Incident Detection Process | How the team detects incidents, triage included |
| P-6 Incident Resolution Process | The generic sequence: analysis, response, closing, lessons learnt |
| P-7 Specific Incident Processes | The tailored sequences, by incident category |
| P-8 Audit and Feedback Process | How the team is assessed, and how the feedback comes back to it |
| P-9 Emergency Reachability Process | How to reach the team in an emergency, outside the service windows |
| P-10 Best Practice Internet Presence | The standard mailbox names, the web presence and the social media policy |
| P-11 Secure Information Handling Process | How the team handles the confidential information it receives |
| P-12 Information Sources Process | The life cycle of information sources, from adding one to removing it |
| P-13 Outreach Process | The relationship with the constituency outside incidents, with a channel back to the team |
| P-14 Governance Reporting Process | What the team reports to its management, statistics included |
| P-15 Constituency Reporting Process | What the team publishes towards its constituency, or beyond it |
| P-16 Meeting Process | The rhythm, scope and format of internal meetings, action points included |
| P-17 Peer Collaboration Process | Working with peer teams, SOCs, PSIRTs and ISACs included |
The P quadrant is the largest, and it is also the one where progress comes fastest. Two parameters can be carried by a single document: P-5 and P-6 are often combined into one incident management process, which the model accepts as long as both detection and resolution are done justice, and as long as the same level is chosen for both. P-7 can likewise be folded into P-6, in the form of alternative paths for specific incident types.
The eight minimum requirements written into the model
Out of forty-five parameters, eight carry an explicit minimum requirement. They are the only places where the model imposes content rather than a degree of formalisation, and they make a useful starting list.
- O-5: contact information, service windows, a concise description of the services offered, and the policy on information handling and disclosure, publicly available in English.
- O-7: the speed of reaction to incoming reports, with a human reaction within two working days for peer teams.
- O-10: the charter describes the mission and parameters O-1 to O-9, by reference to other documents or by combining them.
- H-2: three members at least, part-time or full-time.
- T-5: a fallback mechanism for voice call outages.
- P-10: the
cert@andsecurity@addresses are tracked by the team, some form of web presence exists at least internally, and a social media policy is written down. - P-11: the process supports TLP (12).
- P-17: the process defines who the peers are and ensures two-way trusted communication with them.
Two external references are cited by the model as a way of going further without reinventing anything. RFC (13) 2350 is the standardised way to publish the service description expected by O-5, with a public English version. RFC 2142 lists the standard mailbox names to be tracked under P-10, postmaster and webmaster deserving particular attention.
The model allows certain parameters to be marked as not applicable, in which case they are omitted from scoring. That covers T-8 and P-4 for a purely coordinating team, which does not prevent incidents itself, and P-15 for a team that explicitly chooses to report internally only. O-6 is added to that list when the assessment is run against v1.
What the model says to a SOC, a VOC and a product team
The question comes up every time the model is presented: SIM3 talks about CSIRTs, can it be used by a team that does not go by that name. The answer lies in the text itself and in the way the model is already used.
The text first. The word CSIRT there describes any security incident management capability to which the model is applied, whether that capability is a constituted team, a service or a function. Nothing in the forty-five parameters assumes a particular organisation: a mandate, a constituency, sources, tooling and processes exist in a SOC just as they do in a VOC.
Practice second. Three public facts show that the question has already been settled on the ground.
- The baseline developed in 2023 by FIRST and the OCF for FIRST membership covers eleven of the forty-five parameters, and applies to any type of applying team, CSIRT, SOC, ISAC or PSIRT.
- The Trusted Introducer certification baseline, which dates back to 2010, is used successfully for all types of accredited teams, not only for CSIRTs.
- The typology of four team types, CSIRT, SOC, PSIRT and ISAC, was agreed with FIRST in 2023 and shapes the full version 2 of the model.
The VOC is not named in that typology of four. That does not put it outside the model: its activity is found in parameters that already exist, in particular T-8 and P-4, the latter explicitly naming the issuing of vulnerability and patch advisories among prevention processes.
Where each type of team recognises itself first
The model imposes no reading order. The table below offers an entry point per type of team, built from the parameters where its daily work appears most directly. This mapping is a reading, it is not part of the standard.
| Type of team | Parameters to look at first | What is often already in place |
|---|---|---|
| CERT or CSIRT | O-1 to O-5, O-10, P-6, P-7, P-11, P-17 | Resolution processes, relations with peers, information handling |
| SOC | T-9, P-5, T-3, T-4, O-7, O-8, P-1, P-9 | The detection toolset, incident tracking, reachability |
| VOC | T-1, T-2, T-8, P-4, P-12, O-8, P-14, P-15 | Knowledge of the estate, sources, advisory production |
| Product team, or PSIRT | O-2, O-5, P-4, P-13, P-17, O-6 | Relations with researchers and customers, advisory publication |
The benefit of a shared model shows up here. When a SOC, a VOC and a CERT are assessed on the same scale and against the same parameters, their profiles become comparable, and both the overlaps and the gaps between them become visible. That is especially true of the escalation parameters, P-1 to P-3, which are not shared between teams and which tend to be discovered during a crisis.
Baselines, or how to know what to aim for
A baseline is a well defined set of minimum values for all or part of the parameters, in a specific context. It can also carry additional demands of its own, independent from SIM3. It answers the question every team asks after its first self-assessment: what level should we aim for, on which parameter.
| Baseline | Year | Coverage | Use |
|---|---|---|---|
| Trusted Introducer Certification | 2010 | 44 of the 45 parameters | Certification and recertification every three years, open by choice to accredited TF-CSIRT members |
| ENISA Basic, Intermediate, Advanced | 2019 | All 45 parameters | National and sectoral teams, used by the EU CSIRTs Network, updated in 2024 |
| ENISA Expert | 2024 | All 45 parameters | Stricter than Advanced, arising from the NIS2 (14) Directive, with no recommendation for use outside the EU so far |
| FIRST membership | 2023 | 11 of the 45 parameters | Teams applying for membership, of any type |
| CSIRTAmericas | 2024 | All 45 parameters | National and sectoral teams applying to the CSIRTAmericas cooperation, published by the Organization of American States |
All of these baselines are represented in the online self-assessment tool. Since early 2026, a selector makes it possible to display only the ones a team cares about, and to hide the rest.
The OCF deliberately keeps that number low, since too large a catalogue would only blur the picture. It recommends the three ENISA baselines, Basic, Intermediate and Advanced, for general use anywhere on the planet, a national team in one country not being fundamentally different from a national team in another. Several commercial teams have taken them up as well.
Without a baseline, a self-assessment produces a profile with no target, and the discussion quickly turns into personal opinion. With a baseline, every gap becomes a named action, tied to a specific parameter and to a level to reach. That is the difference between describing a situation and holding a plan.
Where to start
The path below follows the order of the levels and assumes nothing beforehand, no budget and no particular tool.
- Run the self-assessment. The OCF online tool walks through the model parameter by parameter, with the wording of the standard and the additional guidance. A team that goes through it together gets its first profile in a single working session.
- Pick a target. A baseline, chosen to fit the context, turns that profile into a list of gaps. The three ENISA baselines fit most situations, the FIRST one if membership is the goal.
- Deal with the eight minimum requirements first. There are few of them, they are explicit, and their absence shows up immediately in any audit.
- Turn the level 1 parameters into level 2. Write down what the team already knows how to do, in an internal documentation space that allows parameters to be linked to each other. This is the fastest gain the model offers.
- Turn the level 2 parameters into level 3. Have the team head approve what has become consensus. The model strongly recommends adding an expiry and maintenance mechanism for those pages, which several wiki engines can handle.
- Open the path to level 4. Build P-8, the audit and feedback process, and add a paragraph on assessments and audits to the O-10 charter. The model advises acknowledging the auditor’s independent position while requesting a minimum set of aspects the team wants to be audited on, most of the O parameters, plus H-2, P-1 and P-2.
- Use the companion standards. The FIRST CSIRT Services Framework to map services under O-5, the CSIRT Roles and Competences document for skills under H-3, RFC 2350 for publication, the Trusted Introducer Code of Practice or EthicsFIRST for H-1, and an established incident taxonomy for O-8.
Assessment or audit
Both routes exist and they answer different questions. The object of an assessment is improvement. It can be internal, consultancy based or membership related, and evidence can be asked for without being mandatory. An audit is a different demand: it only deserves the name, by OCF standards, if all parameters are tested and if every level awarded rests on evidence. Only a certified SIM3 auditor can run one, with a report and a certificate valid for a maximum of three years, and the auditor has to report the audit to the OCF, team name and date only, with no content.
SIM3 is owned by the OCF, which allows and promotes free use of the model for internal and not-for-profit purposes. Any commercial use, for audits or otherwise, and any form of SIM3 training, requires explicit prior permission from the OCF. The foundation also invites anyone wishing to expand the model to get in touch, so as to avoid competing variants.
What the full version 2 will bring
The v2 interim carries that name for a reason. It is a stage, and the full version 2 is announced for the course of 2026. It will optimise the model not only for CSIRTs, whatever name they go by, but also for ISACs, SOCs and PSIRTs.
Work started today is not wasted for all that. For CSIRTs, v1 and v2 interim are compatible, with the single exception of parameter O-6, which v1 lacked. The other differences are not fundamental: a number of parameter names were updated, and the text was improved throughout. A team documenting its parameters now builds an asset that will survive the change of version.
Adoption is broad and still spreading. Beyond the OCF, FIRST, ENISA and the EU CSIRTs Network, the Nippon CSIRT Association and the worldwide Global Forum on Cyber Expertise community have all embraced v2 interim or are in the process of doing so.
The publication of the full version 2 is announced without a precise date. The OCF reference page, consulted on 15 September 2026, still designates v2 interim as the reference version. A team starting today therefore starts on v2 interim, and that is the right call.
Source qualification
Most of this article comes from the standard itself and from the pages published by the organisation that owns it. The level of evidence is high, with two reservations of limited scope.
| Item | Status | Comment |
|---|---|---|
| Content of the model, parameters, quadrants and levels | corroborated | The v2 interim standard published by the OCF, and the SIM3 Model & References page |
| Number of parameters, forty-five | corroborated | Counted in the standard, confirmed by the OCF Baselines page, which refers to a forty-five parameter CSIRT profile |
| Minimum requirements and parameters that can be set aside | corroborated | Collected parameter by parameter from the text of the standard |
| Coverage, year and use of the baselines | single source | The OCF Baselines page, not cross-checked against a third-party publication |
| Typology of four team types agreed with FIRST in 2023 | single source | The OCF SIM3 Model & References page |
| Publication date of the full version 2 | single source | Announced for the course of 2026, with no precise date |
| Secondary coverage stating forty-four parameters | discarded | That figure matches v1, before parameter O-6 was added |
| Content of the full version 2 beyond the typology | discarded | Not published at the time of writing |
Assessment
This analysis is built on the SIM3 v2 interim standard, on the pages published by the OCF and consulted on 15 September 2026, and on the companion documents cited. The parameter count, the list of minimum requirements and the list of parameters that can be set aside were collected from the text of the standard. The mappings offered between parameters and team types are not part of the model, they are the author’s reading. The ratings in the grid above are judgement, not measurement.
Glossary
- SIM3 (1): Security Incident Management Maturity Model, the model used to measure the maturity of security incident management.
- OCF (2): Open CSIRT Foundation, the foundation that owns and publishes SIM3.
- CSIRT (3): Computer Security Incident Response Team.
- CERT (4): Computer Emergency Response Team, the older name, treated as identical to CSIRT by the model.
- SOC (5): Security Operations Centre, the team in charge of monitoring and detection.
- VOC (6): Vulnerability Operations Centre, the team dedicated to vulnerability management.
- FIRST (7): Forum of Incident Response and Security Teams, the worldwide organisation of incident response teams.
- ENISA (8): the European Union Agency for Cybersecurity.
- PSIRT (9): Product Security Incident Response Team, the incident response team of a product vendor or manufacturer.
- ISAC (10): Information Sharing and Analysis Center, a sector-level information sharing body.
- CMDB (11): Configuration Management Database, the database holding the configurations of the IT estate.
- TLP (12): Traffic Light Protocol, the marking protocol that governs onward sharing of information.
- RFC (13): Request for Comments, the reference document series published by the Internet community.
- NIS2 (14): the European Union directive on the security of network and information systems, second version.
Sources
- Open CSIRT Foundation, SIM3 v2 interim, Security Incident Management Maturity Model, Full Standard, 1 January 2023. opencsirt.org
- Open CSIRT Foundation, SIM3 Model & References, accessed 15 September 2026. opencsirt.org
- Open CSIRT Foundation, SIM3 Baselines, accessed 15 September 2026. opencsirt.org
- Open CSIRT Foundation, SIM3 Online Tool, accessed 15 September 2026. opencsirt.org
- Open CSIRT Foundation, SIM3 self-assessment tool, accessed 15 September 2026. sim3-check.opencsirt.org
- Open CSIRT Foundation, Audits, accessed 15 September 2026. opencsirt.org
- Open CSIRT Foundation, Assessments, accessed 15 September 2026. opencsirt.org
- Open CSIRT Foundation, Certified SIM3 Auditors, accessed 15 September 2026. opencsirt.org
- Open CSIRT Foundation, SIM3 v1, old standard, accessed 15 September 2026. opencsirt.org
- FIRST, CSIRT Services Framework v2.1, accessed 15 September 2026. first.org
- FIRST, CSIRT Roles and Competences, accessed 15 September 2026. first.org
- FIRST, Traffic Light Protocol, accessed 15 September 2026. first.org
- FIRST, EthicsFIRST, accessed 15 September 2026. ethicsfirst.org
- Trusted Introducer, CSIRT Code of Practice, accessed 15 September 2026. trusted-introducer.org
Marked TLP:CLEAR, PAP:CLEAR. Unlimited disclosure, no restriction on use.
The analysis presented here reflects the author’s own views and rests on the public sources listed above.
