# Risk Assessment Procedure

| Field | Value |
|-------|-------|
| **Document ID** | PROC-001 |
| **Version** | 1.0 |
| **Status** | Draft — Pending approval |
| **Owner** | Information Security Officer (ISO) |
| **Effective Date** | _Pending approval_ |
| **Review Cycle** | Annual |
| **ISO 27001 Reference** | Clause 6.1.2 — Information security risk assessment |

Related: [Risk Assessment Matrix](../RISK_ASSESSMENT_MATRIX.md) | [Information Security Policy](../policies/information-security-policy.md)

---

## 1. Purpose

This procedure defines how information security risks are identified, analyzed, evaluated, treated, and reviewed for the Tender Management ISMS.

---

## 2. Scope

Applies to all assets within the ISMS scope ([ISMS Foundation §3](../ISMS_FOUNDATION.md#3-isms-scope)) and all personnel involved in risk management activities.

---

## 3. Roles

| Role | Responsibility |
|------|----------------|
| **ISO** | Facilitates assessment; maintains risk register; reports to management |
| **Asset Owners** | Provide context on threats and controls for their assets |
| **Engineering / DevOps Leads** | Identify technical vulnerabilities and treatment options |
| **Executive Sponsor** | Accepts residual risks above threshold |
| **DPO** | Assesses privacy impact for PII-related risks |

---

## 4. Risk Assessment Process

```
Context → Identify → Analyze → Evaluate → Treat → Monitor → Review
```

### 4.1 Establish Context

Before each assessment cycle, confirm:

- Current ISMS scope and asset inventory ([ISMS Foundation §4](../ISMS_FOUNDATION.md#4-information-asset-inventory))
- Applicable legal/regulatory requirements (GDPR, contracts)
- Risk criteria (scales defined in [Risk Assessment Matrix §2](../RISK_ASSESSMENT_MATRIX.md#2-methodology))

### 4.2 Risk Identification

Sources of risk information:

| Source | Examples |
|--------|----------|
| Asset-based | Unauthorized access to MongoDB, MinIO data loss |
| Threat-based | Credential stuffing, supply chain CVE, insider threat |
| Vulnerability scans | govulncheck, container scans, penetration test findings |
| Incidents | Post-incident review findings |
| Audit findings | Internal/external audit nonconformities |
| Change requests | New AI integration, new data store, architecture change |

Each risk receives a unique ID: `R-NNN` (sequential in risk register).

### 4.3 Risk Analysis

For each identified risk, document:

| Field | Description |
|-------|-------------|
| Risk ID | Unique identifier |
| Threat | What could happen |
| Vulnerability | Weakness exploited |
| Affected asset(s) | Asset IDs from inventory |
| Likelihood (1–5) | Per scale in risk matrix |
| Impact (1–5) | Per scale in risk matrix |
| Inherent score | L × I before controls |
| Existing controls | Current mitigations |
| Residual L / I / Score | After existing controls |

### 4.4 Risk Evaluation

Compare residual score against acceptance criteria:

| Score | Level | Decision |
|-------|-------|----------|
| 1–4 | Low | Accept with monitoring |
| 5–9 | Medium | Treat within 6 months |
| 10–15 | High | Treat within 3 months |
| 16–25 | Critical | Immediate treatment; no acceptance without Executive approval |

Risks above **Medium** must have a documented treatment plan before acceptance.

### 4.5 Risk Treatment

Select one or more options:

- **Mitigate** — Implement control (preferred)
- **Transfer** — Insurance, vendor contract
- **Avoid** — Remove activity from scope
- **Accept** — Document in risk acceptance log with approver signature

Treatment plan must include: owner, target date, actions, and expected residual score.

### 4.6 Monitor and Review

- Track treatment plan progress in risk register
- Re-score risks when controls are implemented
- Close risks only when residual score is at or below accepted level

---

## 5. Assessment Triggers

| Trigger | Action |
|---------|--------|
| **Scheduled review** | Full register review quarterly |
| **Major change** | Assess new/changed assets before production deployment |
| **Incident (P1/P2)** | Ad-hoc assessment within 10 business days |
| **New vulnerability (Critical)** | Assess within 48 hours |
| **Audit finding** | Add/update risk within 5 business days |
| **Annual comprehensive** | Full methodology re-validation |

---

## 6. Major Change Assessment Checklist

Use before deploying significant changes (new service, data store, third-party integration):

- [ ] New assets added to inventory?
- [ ] Data classification determined?
- [ ] Threats and vulnerabilities identified?
- [ ] Controls designed before go-live?
- [ ] DPO consulted if PII involved?
- [ ] Residual risk acceptable or treatment plan in place?
- [ ] Risk register updated?

---

## 7. Reporting

| Report | Audience | Frequency |
|--------|----------|-----------|
| Risk register (current) | ISO, Engineering/DevOps leads | Continuous |
| Risk summary dashboard | Management review | Quarterly |
| Critical/High open risks | Executive Sponsor | Immediate + monthly |
| Treatment plan status | ISO | Monthly |

Report format: [Risk Assessment Matrix](../RISK_ASSESSMENT_MATRIX.md) sections 3–4.

---

## 8. Records Retention

- Risk register versions: **3 years**
- Risk acceptance decisions: **3 years**
- Assessment meeting notes: **3 years**

---

## 9. Document Control

| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | 2026-06-11 | Engineering | Initial procedure |

**Approval**

| Role | Name | Signature | Date |
|------|------|-----------|------|
| ISO | _Pending_ | | |
| Executive Sponsor | _Pending_ | | |