RELEASE · v1.0.0-rc1 → v1.0

What Version 1 includes.

IR 2.0 is a modular operating model for incident response — open, adoptable at any scale, evidence-first by construction. This page describes what v1.0 contains, what it deliberately does not, and what is planned for v1.1.

This framework supports resilience, evidence, and readiness. It does not certify compliance, guarantee security, or guarantee cyber-insurance eligibility. It is not a substitute for professional legal, regulatory, or insurance advice.

Current
v1.0.0-rc1
Target
v1.0.0
Status
Release candidate
Scope
Core framework + starter adoption materials
License
CC BY 4.0 (prose/diagrams) + MIT (code/templates)
Note
Stable core; no breaking changes planned after rc1. Pre-release: tag pending gate closure.
Not included in v1.0
  • Compliance certification
  • Insurance eligibility
  • Premium reduction
  • Vendor product
  • Managed service
  • Legal / IR / insurance advice
§ 01 — Inventory

What v1.0 includes.

The following is the real rc1 inventory — verified against the repository tree. Each item listed is on disk and ship-quality. Items marked "stub" are present as placeholders with full packs deferred to v1.1.

Packs (7 full + 1 stub)

  • v0.1.0 · Active Starter Pack
  • v0.2.0 · Draft Business Email Compromise (BEC) Pack
  • v0.3.0 · Draft Cyber Insurance Readiness Packet
  • v0.3.0 · Draft Program Charter Pack
  • v0.4.0 · Draft Foundations Pack
  • v0.5.0 · Draft Tabletop Exercise Pack
  • v0.6.0 · Draft Reversibility Score Pack
  • Stub Ransomware Pack — full pack deferred to v1.1

Standards index mappings (Claim level 3)

  • NIST CSF 2.0
  • NIST SP 800-61 Rev. 3
  • CIS Controls v8.1
  • ISO/IEC 27035-1:2023
  • ISO/IEC 27035-2:2023

Core templates (5)

  • Decision Log
  • Evidence Register
  • Incident Brief
  • Insurer Evidence Packet
  • Post-Mortem

Tools and guides

  • Pack Validator (Python 3.8+ CLI)
  • Evidence Binder structure guide (5-tab)
  • Worked example — small-team operational context
  • Worked example — MSP operational context
  • Worked example — enterprise operational context

Core canon

  • Four Pillars: Governance · Architecture · Technology · Culture
  • Calm Loop: Sense → Decide → Act → Learn
  • Incident Phases: Detect → Contain → Restore → Prove → Learn
  • Six Principles: Security by default · Modular by construction · One control, many checkboxes · Evidence as data · Reversibility-gated automation · Calm Loop discipline
  • Reversibility Score instrument (5 dimensions × 1–5 → 5–25; Green / Yellow / Red bands)
§ 02 — Adoption stages

One adopter. Three stages.

v1.0 is built for organizations that lack a mature or structured incident-response program — at any scale, in any operational context. Crawl, Walk, and Run are not audience segments; they are stages the same adopter moves through. The framework scales to operational context; it does not gate-keep by size.

Stage 01

Crawl

Targets: ≤5 IT → 30 d · 6–25 IT → 14 d · 26+ IT → 14 d

Produce the first working IR layer. No full program required.

Deliver
  • One-page IR plan with named owner
  • Call tree (≥3 roles)
  • Big-3 evidence: MFA, EDR, immutable backup
  • Starter playbook (one scenario)
  • Evidence folder with basic artifacts
Outcome: named owners, basic evidence, first tabletop completed.
Stage 02

Walk

Targets: ≤25 IT → 90 d · 26+ IT → 60 d

Formalize and test what Crawl built. Move from one-pager to a tested plan.

Deliver
  • Formal playbook set (BEC, Ransomware, Stolen Cred)
  • Tabletop exercise run with AAR
  • Metrics baseline started
  • Reversibility Score policy documented
  • Handoff latency measured
Outcome: tested plan, repeatable and documented response process.
Stage 03

Run

Sustained operational state — no fixed duration

Normalization layer. Evidence consistency, automation gates, measurable improvement.

Deliver
  • Evidence consistency across Calm Loop cycles
  • Reversibility-gated automation live
  • Board reporting with metrics
  • Post-mortem closure tracked
  • Pack governance in place
Outcome: structured automation roadmap, measurable resilience loop running.

See Crawl, Walk, Run for the full adoption doc and By Team Size for operational-context guidance.

§ 03 — Release inventory table

v1.0 at a glance.

Columns: area, what is included, user value, status. All items marked Shipped are on disk at rc1. Insurance-related copy is hedged per claims policy — the framework structures evidence commonly requested in cyber-insurance applications; it does not imply acceptance or eligibility.

Area Included in v1.0 User value Status
Packs 7 full packs: Starter · BEC · Insurance Readiness · Program Charter · Foundations · Tabletop · Reversibility Score Modular units for each incident type and governance need Shipped
Packs Ransomware Pack (stub only) Placeholder; full pack in v1.1 Stub / v1.1
Standards Index mappings: NIST CSF 2.0 · SP 800-61 Rev. 3 · CIS Controls v8.1 · ISO/IEC 27035-1 & -2:2023 One control evidences against multiple frameworks Shipped
Templates Decision log · Evidence register · Incident brief · Insurer evidence packet · Post-mortem Structured artifacts for every Calm Loop step Shipped
Tools Pack Validator (Python 3.8+ CLI) Validates pack structure before review submission Shipped
Guides Evidence Binder structure guide (5-tab) Assembles pack outputs for insurer / auditor conversations Shipped
Examples Worked examples: small-team · MSP · enterprise operational contexts Concrete implementation patterns for each operational context Shipped
Insurance prep Cyber Insurance Readiness Packet — structures evidence commonly requested in cyber-insurance applications Supports preparation for application and renewal conversations Shipped
Canon Four Pillars · Calm Loop · Incident Phases · Six Principles · Reversibility Score instrument Stable conceptual foundation; no breaking changes after rc1 Shipped
Reversibility Reversibility Score: 5 dimensions × 1–5 → total 5–25; Green (5–9) / Yellow (10–15) / Red (16–25) bands; floor rule Decision instrument for automation gate policy Shipped
§ 04 — Roadmap

What comes next.

This roadmap restates ROADMAP.md in the public repository. Status labels are directional, not commitments to specific dates or feature sets.

Status model: Shipped — on disk at rc1 · Planned — intended for a named version · Candidate — under consideration, not yet scheduled · Under consideration — traced to open questions, not a planned release
v1.0.0
Shipped at rc1

Stable Core — tag pending gate closure

All inventory above is shipped at rc1. Remaining gates before the v1.0 tag:

Pending: field reports ×3 (BEC · Insurance Readiness · Foundations) · Legal review · Broker review
Closed: voice corpus validation (2026-06-10) · Walk/Run scope lock (2026-06-10)
v1.1
Planned

Post-v1.0 additions

Content (deferred from v0.2–v0.4 roadmap):

  • Ransomware Pack (full)
  • Cloud Compromise Pack
  • 1–2 specialist / sector packs (field-report-gated)

Maturity tooling (deferred from v0.3 roadmap):

  • Breach Survival Score calculator
  • Evidence Freshness tracker
  • Automation Debt assessment
  • Pack Registry automation

Infrastructure:

  • Full Pack Registry (machine-validatable schema)
  • Community contribution infrastructure
  • SIEM / SOAR integration guides
  • IR 2.0 assessment tool
  • Training materials
Beyond v1.1
Under consideration

Candidate directions — not scheduled, not committed

These directions are traced to open questions in the repository. They will be considered for scheduling only once field-report signal justifies promotion from candidate to planned.

  • Additional sector packs (MSP/MSSP · Legal Hold · Insider Risk · Identity Compromise · Third-Party Incident)
  • Common Controls Backbone / assurance layer
  • Extended peer review and external validation
  • Community-governed pack registry
These status labels are directional, not a commitment to specific dates, feature sets, or release cadences. v1.1 scope is informed by what field reports surface from v1.0 adopters.
§ 05 — Pack format

What a Pack looks like.

A Pack adapts the framework to a specific incident type, environment, or operational need. Each pack is a strict subset of the 18-section PACK_SPEC_TEMPLATE.md — the authoritative contract. The card below shows the public-facing fields; see CONTRIBUTING.md for the full spec.

Pack at a glance — public-facing subset of the 18-section spec
Pack ID
e.g. ir2-bec-v0.2.0
Pack Name
Human-readable name
Maturity phase
Stub · Active · Draft · Review · Stable
Pillar
Governance · Architecture · Technology · Culture
Claim level
1–4 (per CLAIMS_POLICY)
Problem it solves
One sentence
Trigger
What event or decision activates this pack
Outputs / Evidence
Named artifacts this pack produces
Verification
How outputs are confirmed correct
Dependencies
Other packs or controls required
Anti-scope
What this pack explicitly does not cover
Reversibility Score ceiling
Highest expected score on the 5–25 scale (Green / Yellow / Red)

This at-a-glance card is a strict subset — it does not replace or redefine the 18-section spec. The authoritative contract is PACK_SPEC_TEMPLATE.md. See CONTRIBUTING.md for the full review process.

§ 06 — Pack graduation

How items graduate from candidate to shipped.

Every pack proposal follows the same path through the repository review gates. Nothing in this roadmap graduates by fiat — promotion is evidence-gated.

Gate 01

Pack Proposal

Open a GitHub Pack Proposal issue using the template in .github/ISSUE_TEMPLATE/pack_proposal.md. The proposal must articulate the problem, trigger, and anti-scope before any drafting begins.

Gate 02

18-Section Spec Approval

The full 18-section PACK_SPEC_TEMPLATE.md contract is completed and approved by the maintainer before the pack enters drafting. No spec approval, no draft.

Gate 03

Review Gauntlet

Draft passes through the full review process documented in CONTRIBUTING.md and REVIEW_PROCESS.md — including claims-policy review and at least one field report per flagship pack.

§ 07 — Scope limits

What v1.0 deliberately does not include.

These limits are by design. Some are candidates for future versions; others are permanent out-of-scope by policy.

Compliance certification

IR 2.0 maps to NIST CSF, SP 800-61, CIS Controls, and ISO 27035. It does not certify compliance with any of them.

Cyber-insurance eligibility or premium outcomes

The Insurance Readiness Packet structures evidence commonly requested in applications. It does not imply eligibility, acceptance, or premium reduction.

Vendor product or managed service

IR 2.0 is an open framework, not a product. No vendor relationship, SaaS subscription, or managed service is implied or offered.

Legal, regulatory, or insurance advice

Nothing in IR 2.0 constitutes legal advice, regulatory guidance, or professional insurance counsel. Engage qualified advisers for those decisions.

Full Ransomware Pack

The Ransomware Pack ships as a stub at v1.0. The full pack — facilitator guide, three scenarios, AAR template — is planned for v1.1.

Maturity tooling (Breach Survival Score, Evidence Freshness tracker, Automation Debt assessment)

These three instruments were in the original v0.3 roadmap and were deferred. They are planned for v1.1.

Full Pack Registry

The Pack Registry stub from v0.1.0 remains the registry mechanism at v1.0. Machine-validatable schema and automated registry build are planned for v1.1.

Community contribution infrastructure

The field-report path is staged. Full community contribution infrastructure — GitHub Discussions, contributor onboarding, regular cadence — is planned for v1.1.

§ 08 — Where to go next

Version 1, meet your adopter.

Version 1 is what's available. Crawl/Walk/Run is where to start. Packs are what to add as you go.

01

Start here

Crawl, Walk, Run — the adoption stages, targets, and outputs for your operational context.

Read Crawl, Walk, Run →
02

Measure progress

Metrics Ladder — what to measure at each stage and how to know when you've leveled up.

Read the Metrics Ladder →
03

Scale your context

By Team Size — implementation playbooks for each operational context with Week 1 checklists.

Read By Team Size →
04

Contribute a Pack

Have a field report, a new incident type, or a gap to fill? The contribution path is open.

Contribute →