Cyber Risk Management Framework

ReactionGears LLC

Document Owner Mike Kerr, Founder & Principal Engineer
Version 1.0
Effective Date August 31, 2026
Last Reviewed August 31, 2026
Review Cadence Annually, and after any significant incident or change
Primary Standard NIST Cybersecurity Framework (CSF) 2.0
Supporting Standards ISO/IEC 27001:2022, NIST SP 800-30 (risk assessment)
Companion Document ReactionGears LLC Information Security Policy v1.0

1. Purpose

This Cyber Risk Management Framework (“the Framework”) establishes how ReactionGears LLC identifies, assesses, treats, and monitors cybersecurity risk. It provides a repeatable, standards-aligned method for making risk-based security decisions and demonstrates the Company’s due diligence to clients and partners.

The Framework is built on the NIST Cybersecurity Framework (CSF) 2.0 and its six Functions — Govern, Identify, Protect, Detect, Respond, and Recover — and adopts a risk assessment methodology consistent with NIST SP 800-30. Control objectives are cross-referenced to ISO/IEC 27001:2022 (see Section 9) so that clients operating under either standard can map our practices to their own.

2. Scope

The Framework covers all information assets, systems, cloud services, accounts, and networks used by ReactionGears to deliver services, and all cybersecurity risks that could affect the confidentiality, integrity, or availability of client or Company information. It applies to the Principal and any approved subcontractor.

Detailed control implementations are documented in the companion Information Security Policy; this document defines the risk process that governs and improves those controls.

3. Governance (NIST CSF: GOVERN)

  • Accountability: The Principal (Mike Kerr) owns cyber risk management, sets the risk appetite, approves risk treatments, and reviews the risk register.
  • Risk appetite: ReactionGears maintains a low tolerance for risks to the confidentiality and integrity of client data, credentials, and source code. Availability risks are managed to a level appropriate to each client’s contractual expectations. Risks assessed as High or above are not accepted without a documented, time-bound remediation plan.
  • Policy framework: Security controls are defined in the Information Security Policy and are reviewed at least annually and upon material change.
  • Third-party/supply-chain risk: Subprocessors are selected and reviewed based on their security posture and recognized certifications (see the Information Security Policy, Section 10). Supply-chain risk is treated as a first-class category in the risk register.

4. Risk Management Methodology

ReactionGears follows a continuous, five-step risk cycle:

4.1 Identify Risks

Risks are identified from asset reviews, project onboarding, changes to systems or subprocessors, dependency and vulnerability monitoring, incident lessons-learned, and the threat landscape (e.g., phishing, credential theft, supply-chain compromise, data exposure, transaction fraud, service outage).

4.2 Assess Risks

Each risk is scored on Likelihood and Impact using a 1–5 scale. The Risk Score = Likelihood × Impact (range 1–25) maps to a rating:

Likelihood Description
1 – Rare Unlikely in normal operations
2 – Unlikely Could occur but not expected
3 – Possible Might occur occasionally
4 – Likely Expected to occur at some point
5 – Almost certain Expected to occur frequently
Impact Description
1 – Negligible No meaningful effect
2 – Minor Limited, easily recovered
3 – Moderate Noticeable disruption or limited data exposure
4 – Major Significant client impact, sensitive data exposure
5 – Severe Critical breach, major data loss, or legal/financial harm

Risk rating from score: Low (1–4), Medium (5–9), High (10–15), Critical (16–25).

Impact → / Likelihood ↓ 1 2 3 4 5
5 5 10 15 20 25
4 4 8 12 16 20
3 3 6 9 12 15
2 2 4 6 8 10
1 1 2 3 4 5

4.3 Treat Risks

For each risk, one of four treatment strategies is selected:

  • Mitigate — apply or strengthen controls to reduce likelihood and/or impact (default for Medium and above).
  • Transfer — shift risk to a third party (e.g., using a PCI-compliant payment processor, cyber insurance, or a managed provider’s controls).
  • Avoid — stop or change the activity that creates the risk.
  • Accept — formally accept a Low residual risk, documented and approved by the Principal.

The residual risk is re-scored after treatment.

4.4 Monitor & Report

Risks and treatments are tracked in the Risk Register (Section 6). Open risks are reviewed at least quarterly for the Principal’s active engagements and immediately when a new threat, incident, or significant change arises.

4.5 Review & Improve

Lessons from incidents, near-misses, and control testing feed back into risk identification and control improvements (continuous improvement, aligned with ISO 27001’s Plan-Do-Check-Act cycle).

5. NIST CSF 2.0 Function Implementation

GOVERN (GV)

Risk strategy, roles, risk appetite, and policy ownership are defined and held by the Principal; supply-chain risk is actively managed. (See Section 3.)

IDENTIFY (ID)

  • Maintain an inventory of information assets, systems, cloud services, and subprocessors per engagement.
  • Identify the data types handled and their classification (see Information Security Policy, Section 4).
  • Continuously identify vulnerabilities via dependency monitoring and provider advisories.

PROTECT (PR)

  • Identity & access management: least privilege, MFA, password manager, scoped client credentials.
  • Data security: encryption in transit and at rest; secrets kept out of code; tenant isolation (e.g., Postgres RLS).
  • Platform security: full-disk encryption, patching, host firewalls, environment separation.
  • Secure development lifecycle and change management. (Detailed in the Information Security Policy, Sections 5–9.)

DETECT (DE)

  • Monitor authentication and provider security alerts on critical accounts (email, GitHub, cloud, Stripe).
  • Use automated secret-scanning and dependency vulnerability alerts on repositories.
  • Review application, deployment, and access logs where available for anomalies.

RESPOND (RS)

  • Follow the incident response process (Information Security Policy, Section 12): contain, assess, notify affected clients without undue delay and no later than 72 hours, remediate.
  • Default immediate action on any exposed credential is rotation.

RECOVER (RC)

  • Restore systems and data using version control and managed-provider backups / point-in-time recovery.
  • Conduct a post-incident review to capture root cause and improvement actions.
  • Communicate recovery status to affected clients.

6. Risk Register

The risk register is the operational record of this Framework. Each entry is tracked with the following fields, and reviewed on the cadence in Section 4.4.

Fields: ID · Risk description · Category · Affected asset · Likelihood (1–5) · Impact (1–5) · Inherent score · Treatment strategy · Controls applied · Residual score · Owner · Status · Review date.

Illustrative entries

ID Risk Category L I Inherent Treatment Controls Residual
R-01 Credential/API key exposed in source code Data exposure 3 5 15 (High) Mitigate Secret scanning, env vars, immediate rotation, MFA 4 (Low)
R-02 Phishing leads to account compromise Access 3 4 12 (High) Mitigate MFA on all critical accounts, password manager, vigilance 4 (Low)
R-03 Subprocessor breach (e.g., cloud provider) Supply chain 2 4 8 (Medium) Transfer/Mitigate Reputable certified providers, least-privilege access, encryption 4 (Low)
R-04 Lost or stolen laptop Device 2 4 8 (Medium) Mitigate Full-disk encryption, auto-lock, remote wipe where available 2 (Low)
R-05 Multi-tenant data leakage between clients App security 2 5 10 (High) Mitigate Postgres RLS, environment separation, code review 4 (Low)
R-06 Production service outage Availability 2 3 6 (Medium) Transfer/Mitigate Redundant managed hosting, backups, rollback 3 (Low)
R-07 Vulnerable third-party dependency App security 3 3 9 (Medium) Mitigate Dependency scanning, prompt patching 3 (Low)

(The live register is maintained separately and provided to clients on request under NDA.)

7. Continuous Improvement

This Framework and its controls are reviewed at least annually and after any significant incident or change to systems, services, or obligations. Improvement actions are tracked to completion and re-assessed for residual risk.

8. Roles and Responsibilities

  • Principal (Mike Kerr): Owns the Framework and risk register; performs risk assessments; approves treatments and risk acceptances; leads incident response and recovery.
  • Subcontractors/Collaborators (if engaged): Comply with controls, report risks and incidents, and support remediation.

9. Standards Mapping

This Framework is organized around NIST CSF 2.0 and maps to ISO/IEC 27001:2022 as follows (indicative):

NIST CSF 2.0 Function Corresponding ISO/IEC 27001:2022 areas
Govern Clauses 4–6 (Context, Leadership, Planning); A.5 Organizational controls
Identify Clause 6.1 (Risk assessment); A.5.9 Inventory of assets; A.5.19–5.23 Supplier relationships
Protect A.5.15–5.18 Access control; A.8 Technological controls; A.6 People controls
Detect A.8.15 Logging; A.8.16 Monitoring activities
Respond A.5.24–5.28 Information security incident management
Recover A.5.29–5.30 Continuity; A.8.13 Information backup

Risk assessment methodology (Section 4) aligns with NIST SP 800-30 and ISO/IEC 27005.


This Framework describes the cyber risk management approach of ReactionGears LLC and is provided for vendor and client due diligence. It should be read alongside the ReactionGears LLC Information Security Policy. Specific contractual security terms take precedence over this general framework.

ReactionGears LLC · Yorba Linda, California · [email protected] · www.reactiongears.com