Risk Assessment Policy

Document control

Field	Value
Owner	Ron Benisty — CTO & CSO (ron.b@iontwrks.com)
Status	Approved
Version	1.0
Classification	Confidential
Approved by	Ron Benisty — CTO & CSO
Approval date	2026-05-26 (Tuesday)
Last reviewed	2026-05-26
Review cycle	Annual — next review due May 2027
Parent policy	Secure SDLC (SSDLC)

Satisfies SOC 2 Type II CC3.1–CC3.4 (risk-assessment family) and ISO/IEC 27001:2022 Clause 6.1 (actions to address risks and opportunities); reinforces A.5.7 (threat intelligence). Closes Gap 12 of the SSDLC gap analysis.

---

1. Purpose

The holistic, recurring risk-management exercise for S.E.T. Complements two narrower risk practices already in place:

• Per-epic application risk is owned by the Security Requirements & Threat Modeling Policy — risks identified at design time, per feature.
• Per-finding technical-vulnerability risk is owned by the Vulnerability Management Policy — risks identified by scanners and reports, per CVE.

This policy covers everything else: operational, compliance, business-continuity, sub-processor, customer-data, and strategic risk. It is also the place where the two narrower practices roll up periodically.

2. Scope — risk categories

Category	Examples
Application security	Aggregate exposure visible only across many epic threat models (e.g. "tenant-isolation depends on one middleware that every team touches")
Operational	Key-person dependency, single-point-of-failure roles, runbook gaps, incident-response readiness, on-call coverage
Compliance	Amendment 13, GDPR, SOC 2, ISO 27001 — exposure to non-compliance, new regulation, change in scope
Business continuity	Region failure, sub-processor outage exceeding SLA, DR-drill failure modes
Customer-data	Cross-tenant exposure aggregate risk, data-classification drift, audit-log retention failure
Sub-processor	WorkOS, AWS, Cloudflare, Logz.io, GitHub, future additions — concentration risk, vendor solvency, breach exposure
Strategic / business	Customer concentration, contract renewal exposure, regulatory market shifts, talent risk

One unified register covers all seven categories. Auditors prefer one place to look.

3. Cadence

Three recurring cycles. Each produces a durable, sampleable artifact.

Cycle	When	What it does	Output
Annual full assessment	Every February (aligned with the SSDLC annual review)	Re-evaluate every risk in the register; identify new risks; re-score each; re-set treatment + owner + target	New Risk Register version + summary memo retained ≥ 24 months
Quarterly review	End of Q1, Q2, Q3, Q4	Review changes since last cycle; status of every Critical + High mitigation; status of every open vuln-management exception (closes the loop with Gap 8); add any new risks	One-page review record retained ≥ 24 months
On-major-change trigger	Within 5 business days of the trigger	Risk delta — what changed, what new risks emerged, what existing scores need re-rating	Trigger memo + register update retained ≥ 24 months

Major-change triggers (any one):

• A new sub-processor that handles tenant data is onboarded.
• A new tenant tier or pricing model is introduced.
• A new product line / portal / major feature is launched.
• A Sev 1 incident occurs (per Incident Response).
• A material architecture change (new trust boundary, new region, new auth model).
• A regulator publishes new applicable rules (e.g. Amendment 13 amendment, new ISO revision).

4. Scoring — 5×5 grid

Every risk is scored on Impact and Likelihood, each on a 1–5 scale. The two are multiplied for a Risk Score of 1–25.

Impact scale

Score	Impact	Description
5	Severe	Existential — multi-tenant data breach, regulatory ban, prolonged outage, loss of certification
4	Major	Significant — major customer loss, multi-day outage, single-tenant breach, lawsuit
3	Moderate	Material but manageable — single-customer impact, partial outage, minor regulatory finding
2	Minor	Limited — internal disruption, recoverable in hours, no customer-visible impact
1	Negligible	Operational nuisance — no measurable business impact

Likelihood scale

Score	Likelihood	Description
5	Almost certain	Expected within the next year unless prevented
4	Likely	Probable within the next year
3	Possible	Could plausibly happen within the next year
2	Unlikely	Possible but improbable within the next year
1	Rare	Would be surprising; conceivable but with no leading indicators

Risk tiers

Score range	Tier	Treatment urgency
15–25	Critical	Treatment within 90 days; CTO & CSO direct attention; reported on every quarterly review
10–14	High	Treatment within 6 months; reviewed every quarterly cycle
5–9	Medium	Active monitoring; treatment within 12 months
1–4	Low	Review at next annual cycle

Scoring is re-justified at every annual cycle — scores don't survive automatically across cycles.

5. The Risk Register

Location: docs/risk-register.md — single Markdown file, version-controlled in repo, diffable across cycles, no separate tool. Same pattern as threat models.

Mandatory fields per risk

Field	Notes
Risk ID	R-001, R-002, … — sequential; never reused after closure
Title	One-line summary
Category	One of the seven in §2
Description	What the risk is, the scenario in which it materializes
Impact	Score 1–5 + reasoning
Likelihood	Score 1–5 + reasoning
Score	Impact × Likelihood = 1–25; tier (Critical / High / Medium / Low)
Treatment	Mitigate / Accept / Transfer / Avoid (per §6)
Owner	Single named accountable party (CTO & CSO unless explicitly delegated)
Target date	Per the §4 urgency table
Current mitigations / compensating controls	What is already reducing this risk today
Linked artifacts	PRs, threat models, incidents, sub-processor agreements
Last reviewed	YYYY-MM-DD
Next review	Quarter / annual cycle this risk is due in

Register template

# S.E.T Risk Register

**Last updated**: {YYYY-MM-DD}
**Last full assessment**: {YYYY-MM-DD}
**Next full assessment**: {YYYY-MM-DD}
**Last quarterly review**: {YYYY-QN}

---

## Risk levels

| Score | Tier | Treatment urgency |
|---|---|---|
| 15–25 | **Critical** | Treatment within 90 days |
| 10–14 | **High** | Treatment within 6 months |
| 5–9 | **Medium** | Active monitoring; treatment within 12 months |
| 1–4 | **Low** | Review at next cycle |

## Active risks

### R-001 — {Title}

- **Category**: {Application Security / Operational / Compliance / BC / Customer Data / Sub-processor / Strategic}
- **Description**: {what the risk is, the scenario where it materializes}
- **Impact**: {Severe (5)} — {one-sentence reasoning}
- **Likelihood**: {Possible (3)} — {one-sentence reasoning}
- **Score**: 15 — **Critical**
- **Treatment**: {Mitigate / Accept / Transfer / Avoid}
- **Owner**: CTO & CSO
- **Target date**: {YYYY-MM-DD}
- **Current mitigations**: {what already reduces this risk}
- **Linked artifacts**: {PR / issue / threat model / incident IDs}
- **Last reviewed**: {YYYY-MM-DD}
- **Next review**: {YYYY-QN or full-assessment}

(repeat per risk)

## Closed risks

{Risks moved out of "Active" — kept for audit history. Include closure date + reason.}

6. Treatment options

For every risk in the register, exactly one treatment is selected at scoring time:

Treatment	When to use	Required
Mitigate	Likelihood or impact can be reduced via a control we implement (process change, technical control, architectural change)	A specific mitigation action + owner + target date in the register
Accept	The residual risk is acceptable; the cost of mitigation exceeds the expected loss	CTO & CSO sign-off in the register entry; explicit acknowledgement of the residual risk; reviewed at every annual cycle (same discipline as vuln-management exceptions)
Transfer	Risk is pushed to a third party — cyber-insurance, a sub-processor's contractual SLA, customer indemnification	Reference the contractual mechanism + the entity assuming the risk
Avoid	The business decision is changed to eliminate the risk (e.g., don't enter a market, don't onboard a class of customer)	The avoidance decision recorded with the business owner

7. The process — per cycle

7.1 Annual full assessment

1. CTO & CSO prepares the draft in the four weeks before the cycle, drawing on:
   • The current Risk Register (carry-over + status of last year's treatments)
   • Last 12 months of incident records (IR)
   • Last 12 months of vulnerability-management trends (Vuln Mgmt) — recurring classes, open exceptions
   • All sub-processor changes
   • All threat models filed since last cycle
   • Compliance horizon (new regulations, framework revisions)
2. S.E.T-team review — every active member provides input on operational + customer-data risks.
3. External input where applicable — auditor's prior findings, advisor consultation.
4. CTO & CSO approves the new Register version with a signed memo summarizing changes.
5. Treatment plans assigned — owners + target dates per risk.
6. Register committed to repo as the new "Last full assessment" version.
7. Summary memo retained ≥ 24 months per the Evidence Collection & Retention Policy.

7.2 Quarterly review

1. CTO & CSO reviews every Critical and High risk — status of treatment, any new evidence of likelihood/impact change.
2. Reviews every open vuln-management exception — confirms compensating control still in place, target date still realistic.
3. Adds any new risks identified since last cycle (incidents, sub-processor changes, threat-model output).
4. Updates the Register in repo.
5. One-page review record committed to docs/risk-reviews/{YYYY-QN}.md and retained ≥ 24 months.

7.3 On-major-change cycle

1. Within 5 business days of the trigger.
2. CTO & CSO performs a delta analysis — what changed, what new risks emerged, which existing scores need re-rating.
3. Register updated; affected risks re-scored.
4. Trigger memo retained as the cycle's evidence.

8. Integration with other policies

The Risk Register is a hub — these are its inputs and outputs:

Other policy	Relationship
Security Requirements & Threat Modeling	Each epic's threat model contributes application risks; aggregate exposure is reviewed annually here
Vulnerability Management	Every open exception is reviewed at every quarterly cycle; recurring vulnerability classes flow up as risks
Incident Response	Every Sev 1 + Sev 2 incident triggers an on-major-change cycle to update the register
Backup & Recovery	Annual DR-drill outcomes feed business-continuity risks
Decommissioning	Sub-processor changes trigger on-major-change cycle
Audit Testing Scope	External-auditor findings feed compliance risks
RACI	CTO & CSO is the accountable owner for the register; operations RACI is the input on operational risks
Evidence Collection & Retention	The register itself + every cycle's memo are evidence artifacts

9. Evidence + retention

Artifact	Retention
The Risk Register file (docs/risk-register.md)	Lifetime of S.E.T (versioned in git)
Annual-cycle summary memo	≥ 24 months
Quarterly review record (per quarter, in docs/risk-reviews/)	≥ 24 months
Major-change trigger memo	≥ 24 months
CTO & CSO approval comments (in git history / signed memos)	≥ 24 months

All retained per the Evidence Collection & Retention Policy. SOC 2 Type II will sample annual + quarterly + trigger artifacts across the audit window.

10. Document change history

Version	Date	Author	Description of change	Approved by
1.0	2026-05-26	Ron Benisty (CTO & CSO)	Initial version — seven risk categories; annual + quarterly + on-major-change cadence; 5×5 qualitative scoring with four risk tiers; Markdown Risk Register with mandatory fields; four treatment options (Mitigate / Accept / Transfer / Avoid). Closes the loop with Vulnerability Management exception review.	Ron Benisty (CTO & CSO)