Mazyar
06e663b691
- Introduced a comprehensive suite of security documents to support ISO/IEC 27001 certification, including the ISMS Foundation, Risk Assessment Matrix, Gap Analysis Report, Statement of Applicability, and ISO27001 Roadmap. - Updated the README to include links to the new security documentation, enhancing the project's compliance framework and providing clear guidance on security policies and procedures. This addition strengthens the overall security posture of the Tender Management System and aligns with industry standards for information security management.
5.5 KiB
5.5 KiB
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 | Information Security Policy
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) 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)
- Applicable legal/regulatory requirements (GDPR, contracts)
- Risk criteria (scales defined in Risk Assessment Matrix §2)
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 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 |