mazyar/tm_back
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request 'Add security and compliance documentation for ISO/IEC 27001' (#41) from TM-310 into develop
continuous-integration/drone/push Build is passing
Details

Browse Source 
Reviewed-on: https://repo.ravanertebat.com/TM/tm_back/pulls/41
Reviewed-by: Hadi Barzegar <barzagarhadi@gmail.com>
This commit is contained in:
m.nazemi
2026-06-17 00:54:48 +03:30
parent 58345ac4f3 243f667005
commit 7120a954b6
13 changed files with 2496 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/README.md
+18
View File
@@ -19,6 +19,24 @@ Welcome to the Tender Management System documentation. This directory contains a
### 📡 API Documentation
- **[examples/API_EXAMPLES.md](./examples/API_EXAMPLES.md)** - API usage examples and endpoints documentation
### 🔒 Security & Compliance (ISMS)
- **[security/ISMS_FOUNDATION.md](./security/ISMS_FOUNDATION.md)** - ISMS scope, asset inventory, roles, and control baseline
- **[security/RISK_ASSESSMENT_MATRIX.md](./security/RISK_ASSESSMENT_MATRIX.md)** - Initial risk register and treatment plans
- **[security/ISO27001_ROADMAP.md](./security/ISO27001_ROADMAP.md)** - ISO/IEC 27001 certification roadmap and phases
- **[security/GAP_ANALYSIS_REPORT.md](./security/GAP_ANALYSIS_REPORT.md)** - ISO 27001 Clauses 4–10 and Annex A gap analysis
- **[security/STATEMENT_OF_APPLICABILITY.md](./security/STATEMENT_OF_APPLICABILITY.md)** - Annex A control applicability (93 controls)
- **[security/ISMS_SCOPE_APPROVAL.md](./security/ISMS_SCOPE_APPROVAL.md)** - Formal ISMS scope sign-off (Clause 4.3)
#### Policies (Phase 1)
- **[security/policies/information-security-policy.md](./security/policies/information-security-policy.md)** - Top-level ISMS policy (A.5.1)
- **[security/policies/access-control-policy.md](./security/policies/access-control-policy.md)** - Authentication, RBAC, access reviews (A.5.15–A.5.18)
- **[security/policies/incident-response-plan.md](./security/policies/incident-response-plan.md)** - Incident classification, IRT, playbooks (A.5.24–A.5.28)
- **[security/policies/backup-and-recovery-policy.md](./security/policies/backup-and-recovery-policy.md)** - RTO/RPO, backup schedule, restore testing (A.8.13)
- **[security/policies/acceptable-use-policy.md](./security/policies/acceptable-use-policy.md)** - Personnel acceptable use rules (A.6.2)
#### Procedures
- **[security/procedures/risk-assessment-procedure.md](./security/procedures/risk-assessment-procedure.md)** - Risk identification, analysis, and treatment (Clause 6.1.2)
## 🏗️ Project Architecture
### Clean Architecture Layers
docs/security/GAP_ANALYSIS_REPORT.md
+282
View File
@@ -0,0 +1,282 @@
# ISO/IEC 27001 Gap Analysis Report — Tender Management System
| Field | Value |
|-------|-------|
| **Document ID** | ISMS-004 |
| **Version** | 1.0 |
| **Status** | Draft — Pending review |
| **Owner** | Information Security Officer (ISO) |
| **Last Updated** | 2026-06-11 |
| **Assessment Date** | 2026-06-11 |
| **Standard** | ISO/IEC 27001:2022 |
| **Scope** | [ISMS Foundation §3](./ISMS_FOUNDATION.md#3-isms-scope) |
Related: [Statement of Applicability](./STATEMENT_OF_APPLICABILITY.md) | [ISO 27001 Roadmap](./ISO27001_ROADMAP.md)
---
## 1. Executive Summary
This report assesses the current state of the Tender Management (TM) ISMS against **ISO/IEC 27001:2022** mandatory clauses (4–10) and Annex A controls. The assessment is based on documentation review, codebase analysis, and existing operational practices.
### Overall Maturity
| Area | Maturity | Summary |
|------|----------|---------|
| **Clauses 4–6** (Context, Leadership, Planning) | 🟡 Partial | Foundation docs exist; formal leadership approval pending |
| **Clause 7** (Support) | 🟡 Partial | Competence and awareness programs not yet formalized |
| **Clause 8** (Operation) | 🟡 Partial | Technical controls strong; operational procedures incomplete |
| **Clause 9** (Performance evaluation) | 🔴 Minimal | No internal audit program or management review yet |
| **Clause 10** (Improvement) | 🔴 Minimal | Corrective action process not formalized |
| **Annex A** (93 controls) | 🟡 Partial | 6 implemented (7% of 81 applicable), 56 partial (69%), 19 not implemented (23%), 12 N/A (13%) — per [SoA §7](./STATEMENT_OF_APPLICABILITY.md#7-summary-statistics) |
### Key Strengths
- Application-layer security controls (JWT, RBAC, validation, XSS, audit logging)
- Clean Architecture with dependency injection and structured logging
- Initial ISMS documentation suite (foundation, risk matrix, policies)
- Configurable rate limiting and environment-based secret management
### Critical Gaps (Must Address Before Certification)
1. No internal audit program or management review records (Clauses 9.2, 9.3)
2. No SIEM/centralized monitoring (A.8.16)
3. No formal vulnerability management in CI (A.8.8)
4. Secrets in repository / no vault (A.8.9, R-013)
5. No security awareness training program (A.6.3)
6. No vendor security assessments (A.5.19–A.5.22)
7. Encryption at rest not confirmed (A.8.24)
8. Executive sign-off on ISMS scope and policies pending
---
## 2. Assessment Methodology
| Step | Activity |
|------|----------|
| 1 | Review ISMS scope and asset inventory |
| 2 | Map existing controls to ISO 27001:2022 clauses and Annex A |
| 3 | Interview technical leads (informal / codebase-based) |
| 4 | Classify each requirement: **Implemented**, **Partial**, **Not Implemented**, **N/A** |
| 5 | Prioritize gaps by risk linkage ([Risk Assessment Matrix](./RISK_ASSESSMENT_MATRIX.md)) |
| 6 | Define remediation actions in [ISO27001_ROADMAP.md](./ISO27001_ROADMAP.md) Phase 2 |
### Maturity Scale
| Rating | Definition |
|--------|------------|
| **Implemented** | Control documented, implemented, and operating effectively |
| **Partial** | Control exists informally or is incomplete |
| **Not Implemented** | No control or documentation |
| **N/A** | Not applicable to TM scope (with justification) |
---
## 3. Clause 4 — Context of the Organization
| Ref | Requirement | Status | Evidence | Gap / Remediation |
|-----|-------------|--------|----------|-------------------|
| 4.1 | Understanding the organization and its context | **Partial** | [ISMS Foundation §2](./ISMS_FOUNDATION.md#2-organizational-context) | Formalize interested parties register |
| 4.2 | Understanding needs of interested parties | **Partial** | Business objectives in ISMS Foundation | Document customers, regulators, partners explicitly |
| 4.3 | Determining ISMS scope | **Partial** | [ISMS Foundation §3](./ISMS_FOUNDATION.md#3-isms-scope); [Scope Approval](./ISMS_SCOPE_APPROVAL.md) draft | Executive sign-off required |
| 4.4 | Information security management system | **Partial** | ISMS doc structure defined | Complete PDCA operating records |
**Gap actions:**
- Create interested parties register (customers, EU DPA, certification body, cloud providers)
- Obtain signed scope approval from Executive Sponsor
---
## 4. Clause 5 — Leadership
| Ref | Requirement | Status | Evidence | Gap / Remediation |
|-----|-------------|--------|----------|-------------------|
| 5.1 | Leadership and commitment | **Partial** | Roadmap exists; sponsor not yet assigned | Appoint Executive Sponsor; first management review |
| 5.2 | Policy | **Partial** | [Information Security Policy](./policies/information-security-policy.md) draft | Approve and communicate policy |
| 5.3 | Organizational roles, responsibilities, authorities | **Partial** | [ISMS Foundation §5](./ISMS_FOUNDATION.md#5-roles-and-responsibilities) | Assign named individuals to ISO, DPO roles |
**Gap actions:**
- Name and document ISO and DPO (can be interim)
- Communicate approved Information Security Policy to all staff
---
## 5. Clause 6 — Planning
| Ref | Requirement | Status | Evidence | Gap / Remediation |
|-----|-------------|--------|----------|-------------------|
| 6.1.1 | Actions to address risks and opportunities | **Partial** | Risk matrix with 23 risks | Link opportunities (e.g. certification as market differentiator) |
| 6.1.2 | Information security risk assessment | **Implemented** | [Risk Assessment Matrix](./RISK_ASSESSMENT_MATRIX.md), [Procedure](./procedures/risk-assessment-procedure.md) | Maintain quarterly reviews |
| 6.1.3 | Information security risk treatment | **Partial** | Treatment plans in risk matrix | Execute Phase 2 technical remediations |
| 6.2 | Information security objectives | **Partial** | [Information Security Policy §4](./policies/information-security-policy.md#4-information-security-objectives) | Track KPIs monthly |
| 6.3 | Planning of changes | **Not Implemented** | — | Document change planning in change management procedure (Phase 2) |
**Gap actions:**
- Begin executing risk treatment plans (R-001, R-010, R-013, R-015, R-023 priority)
- Draft change management procedure
---
## 6. Clause 7 — Support
| Ref | Requirement | Status | Evidence | Gap / Remediation |
|-----|-------------|--------|----------|-------------------|
| 7.1 | Resources | **Partial** | Roadmap resource estimate | Allocate part-time ISO capacity |
| 7.2 | Competence | **Not Implemented** | — | Define security competency requirements per role |
| 7.3 | Awareness | **Not Implemented** | Acceptable Use Policy draft | Launch onboarding + annual training |
| 7.4 | Communication | **Partial** | Docs in `docs/security/` | Define internal/external comms plan for ISMS |
| 7.5 | Documented information | **Partial** | ISMS doc suite | Document control procedure; version approval workflow |
**Gap actions:**
- Security awareness program (A.6.3) — target Q3 2026
- Document control: naming, approval, retention standards
---
## 7. Clause 8 — Operation
| Ref | Requirement | Status | Evidence | Gap / Remediation |
|-----|-------------|--------|----------|-------------------|
| 8.1 | Operational planning and control | **Partial** | DevOps practices informal | Formalize change and deploy procedures |
| 8.2 | Information security risk assessment | **Implemented** | Quarterly procedure defined | Execute first scheduled review Sep 2026 |
| 8.3 | Information security risk treatment | **Partial** | Phase 2 roadmap | Implement prioritized controls |
**Gap actions:**
- Operational procedures for backup, incident response (drafted — need testing records)
- Change management procedure (Phase 2)
---
## 8. Clause 9 — Performance Evaluation
| Ref | Requirement | Status | Evidence | Gap / Remediation |
|-----|-------------|--------|----------|-------------------|
| 9.1 | Monitoring, measurement, analysis, evaluation | **Partial** | KPIs defined in roadmap | Implement SIEM; monthly KPI reporting |
| 9.2 | Internal audit | **Not Implemented** | — | Schedule first internal audit Q1 2027 |
| 9.3 | Management review | **Not Implemented** | — | First review within 90 days of scope approval |
**Gap actions:**
- **Critical:** Establish internal audit program before Stage 2 audit
- Schedule first management review meeting
- Implement monitoring (A.8.16) for measurable KPIs
---
## 9. Clause 10 — Improvement
| Ref | Requirement | Status | Evidence | Gap / Remediation |
|-----|-------------|--------|----------|-------------------|
| 10.1 | Continual improvement | **Partial** | PDCA in roadmap | Track improvement actions from audits/incidents |
| 10.2 | Nonconformity and corrective action | **Not Implemented** | — | Define CAPA (Corrective and Preventive Action) procedure |
**Gap actions:**
- CAPA procedure linked to incident response and audit findings
- Nonconformity register template
---
## 10. Annex A Summary by Theme
Full control-level detail: [Statement of Applicability](./STATEMENT_OF_APPLICABILITY.md)
| Theme | Total Controls | Implemented | Partial | Not Impl. | N/A |
|-------|----------------|-------------|---------|-----------|-----|
| **A.5** Organizational | 37 | 2 | 25 | 10 | 0 |
| **A.6** People | 8 | 0 | 6 | 2 | 0 |
| **A.7** Physical | 14 | 0 | 3 | 0 | 11 |
| **A.8** Technological | 34 | 4 | 22 | 7 | 1 |
| **Total** | **93** | **6** | **56** | **19** | **12** |
*Counts match [Statement of Applicability §7.1](./STATEMENT_OF_APPLICABILITY.md#71-by-theme). "Partial" indicates the control exists but lacks full documentation, testing, or operating evidence.*
### A.5 — Top Organizational Gaps
| Control | Title | Status | Priority |
|---------|-------|--------|----------|
| A.5.19–A.5.22 | Supplier relationships | Not Implemented | High |
| A.5.29–A.5.30 | Business continuity | Partial | High |
| A.5.35 | Independent review | Not Implemented | Medium |
| A.5.7 | Threat intelligence | Not Implemented | Medium |
| A.5.32 | Intellectual property | Partial | Low |
### A.6 — Top People Gaps
| Control | Title | Status | Priority |
|---------|-------|--------|----------|
| A.6.3 | Security awareness training | Not Implemented | High |
| A.6.1 | Screening | Not Implemented | Medium |
| A.6.6 | NDAs | Partial | Medium |
| A.6.8 | Event reporting | Partial | Medium |
### A.7 — Physical Controls
**11 N/A** — cloud-hosted infrastructure; physical security transferred to cloud provider per shared responsibility model (A.7.1–A.7.6, A.7.8, A.7.10–A.7.13). Provider compliance evidence required (A.5.23).
**3 Partial** — A.7.7, A.7.9, A.7.14 remain applicable for personnel devices accessing TM systems (screen lock, off-premises asset security, equipment disposal).
### A.8 — Top Technological Gaps
| Control | Title | Status | Priority |
|---------|-------|--------|----------|
| A.8.8 | Vulnerability management | Not Implemented | Critical |
| A.8.16 | Monitoring activities | Partial | Critical |
| A.8.24 | Cryptography | Partial | High |
| A.8.2 | Privileged access rights | Partial | High |
| A.8.32 | Change management | Partial | High |
| A.8.29 | Security testing | Not Implemented | High |
| A.8.12 | Data leakage prevention | Not Implemented | Medium |
### A.8 — Fully Implemented Technical Controls (Status = Yes)
| Control | Implementation |
|---------|----------------|
| A.8.3 | RBAC + company-scoped middleware (`pkg/authorization`) |
| A.8.4 | Git-based source control with PR workflow |
| A.8.15 | Structured logging + `pkg/audit` |
| A.8.26 | Govalidator, XSS policy, Swagger |
Additional controls (e.g. A.8.5 authentication, A.8.9 configuration, A.8.28 secure coding) are **Partial** in the SoA — implemented in code but lacking full operating evidence or completeness (MFA, vault, SAST).
---
## 11. Gap Remediation Roadmap
Aligned with [ISO27001_ROADMAP.md](./ISO27001_ROADMAP.md):
| Priority | Gap | Remediation | Phase | Target |
|----------|-----|-------------|-------|--------|
| P0 | No incident response testing | Tabletop exercise | 2 | Q2 2026 |
| P0 | Secrets in repo | Vault + secret scanning | 2 | Q2 2026 |
| P0 | No vulnerability scanning | govulncheck in CI | 2 | Q2 2026 |
| P0 | No management review | First review meeting | 1 | Q3 2026 |
| P1 | No SIEM | Centralized logging + alerts | 2 | Q3 2026 |
| P1 | No encryption at rest | MongoDB/MinIO encryption | 2 | Q3 2026 |
| P1 | No vendor assessments | Vendor questionnaire | 2 | Q4 2026 |
| P1 | No security training | Awareness program | 2 | Q3 2026 |
| P1 | No internal audit | Audit program + first audit | 3 | Q1 2027 |
| P2 | No CAPA procedure | Document CAPA process | 2 | Q3 2026 |
| P2 | No penetration test | External pentest | 4 | Q2 2027 |
---
## 12. Conclusion
The TM platform has a **solid technical security foundation** but lacks the **operational and governance evidence** required for ISO 27001 certification. Phase 1 documentation (foundation, risk assessment, policies, SoA, gap analysis) addresses Clauses 4.3, 6.1.2, and 5.2 at a draft level.
**Recommendation:** Proceed to Phase 2 control implementation while pursuing executive approval of scope and policies. Target first internal audit no later than **Q1 2027** to allow 3+ months of operating evidence before Stage 2 audit.
---
## 13. Document Control
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | 2026-06-11 | Engineering | Initial gap analysis |
| 1.1 | 2026-06-11 | Engineering | Annex A theme table and executive summary aligned with SoA §7 |
**Review**
| Role | Name | Signature | Date |
|------|------|-----------|------|
| ISO | _Pending_ | | |
| Executive Sponsor | _Pending_ | | |
docs/security/ISMS_FOUNDATION.md
+235
View File
@@ -0,0 +1,235 @@
# ISMS Foundation — Tender Management System
| Field | Value |
|-------|-------|
| **Document ID** | ISMS-001 |
| **Version** | 1.0 |
| **Status** | Draft — Initial foundation |
| **Owner** | Information Security Officer (ISO) |
| **Last Updated** | 2026-06-11 |
| **Review Cycle** | Annual (or after major architecture change) |
---
## 1. Purpose
This document establishes the **Information Security Management System (ISMS)** foundation for the Tender Management (TM) platform. It defines security scope, information assets, roles, and the baseline control environment required to support ISO/IEC 27001 certification and GDPR-aligned data protection.
Related documents:
- [ISO 27001 Roadmap](./ISO27001_ROADMAP.md)
- [Risk Assessment Matrix](./RISK_ASSESSMENT_MATRIX.md)
- [Gap Analysis Report](./GAP_ANALYSIS_REPORT.md)
- [Statement of Applicability](./STATEMENT_OF_APPLICABILITY.md)
- [ISMS Scope Approval](./ISMS_SCOPE_APPROVAL.md)
---
## 2. Organizational Context
### 2.1 System Overview
The Tender Management System is a Go-based backend API that:
- Ingests public tender data from TED (Tenders Electronic Daily) and related sources
- Matches tenders to registered companies based on CPV codes, categories, and keywords
- Provides admin panel APIs for user, company, and tender management
- Provides public/mobile APIs for company customers to browse, filter, and interact with tenders
- Sends notifications (email, push via FCM) and supports AI-assisted translation/summarization
- Stores documents and tender artifacts in MinIO object storage
### 2.2 Business Objectives Relevant to Security
| Objective | Security Implication |
|-----------|---------------------|
| Reliable tender data for business decisions | Integrity and availability of tender records |
| Company and customer onboarding | Protection of PII and business credentials |
| Multi-tenant company access | Strong authentication, authorization, and data isolation |
| Regulatory and procurement compliance | Audit trails, data retention, and access control |
| Platform availability for mobile and admin clients | Resilience, monitoring, and incident response |
---
## 3. ISMS Scope
### 3.1 In Scope
| Layer | Components |
|-------|------------|
| **Applications** | `cmd/web` (HTTP API), `cmd/worker` (background jobs), `cmd/scraper` (TED XML ingestion) |
| **Domain services** | User, customer, company, tender, feedback, notification, inquiry, contact, CMS, kanban, dashboard, document scraper, tender approval |
| **Shared packages** | Authorization (JWT), security (XSS/CSP), audit logging, file store, MinIO client, config |
| **Data stores** | MongoDB (primary DB), Redis (cache/sessions/token blacklist), MinIO (files, tender JSON/translations) |
| **External integrations** | Notification service, hCaptcha, AI summarizer/translation service, GoRules (kanban), TED public data sources, FCM (push) |
| **Environments** | Development, staging, production (and associated CI/CD pipelines) |
| **People & processes** | Developers, DevOps, QA, product owners with access to TM infrastructure or production data |
### 3.2 Out of Scope (Initial Phase)
| Item | Rationale |
|------|-----------|
| End-user mobile app codebase | Separate repository; interface governed by API contracts |
| Admin panel frontend | Separate repository; authenticated via same backend |
| Third-party TED infrastructure | Public data source; risk managed via ingestion validation |
| Customer on-premise deployments | SaaS model assumed; revisit if offering self-hosted |
### 3.3 Scope Statement
> The ISMS covers the design, development, deployment, and operation of the Tender Management backend platform, including all information assets processed, stored, or transmitted by `cmd/web`, `cmd/worker`, and `cmd/scraper`, and the supporting MongoDB, Redis, and MinIO infrastructure in scoped environments.
---
## 4. Information Asset Inventory
### 4.1 Classification Levels
| Level | Label | Description | Handling |
|-------|-------|-------------|----------|
| **C1** | Public | Intended for public disclosure | No restrictions |
| **C2** | Internal | Operational data not for public release | Access limited to staff |
| **C3** | Confidential | Business or personal data requiring protection | Encrypted in transit; access on need-to-know |
| **C4** | Restricted | Credentials, secrets, authentication factors | Vault/KMS; never logged; rotation required |
### 4.2 Asset Register
| Asset ID | Asset Name | Type | Owner | Classification | Location | Notes |
|----------|------------|------|-------|----------------|----------|-------|
| A-001 | MongoDB database (`tm`) | Data store | DevOps / DBA | C3 | Managed MongoDB cluster | Companies, customers, tenders, users, feedback, notifications |
| A-002 | Redis cache | Data store | DevOps | C3 | Managed Redis | Sessions, rate limits, token blacklist |
| A-003 | MinIO object storage | Data store | DevOps | C2–C3 | MinIO cluster | Company documents, tender JSON, translations |
| A-004 | Customer PII | Data | Product / DPO | C3 | MongoDB `customers` | Email, name, phone, device tokens |
| A-005 | Company business data | Data | Product | C3 | MongoDB `companies` | Registration, tax ID, address, documents |
| A-006 | User (admin) accounts | Data | Product | C3 | MongoDB `users` | Admin panel operators |
| A-007 | Authentication credentials | Data | ISO | C4 | MongoDB (hashed passwords), env secrets | bcrypt-hashed passwords; JWT signing keys |
| A-008 | JWT access/refresh tokens | Data | ISO | C4 | Client devices, Redis blacklist | Short-lived access tokens |
| A-009 | Application source code | Software | Engineering | C2 | Git repository | Go monorepo `tm_back` |
| A-010 | Configuration & secrets | Config | DevOps | C4 | `.env`, OS env vars, secret manager | DB URIs, API keys, MinIO keys, hCaptcha secret |
| A-011 | Application logs | Data | DevOps | C2–C3 | Log files / log aggregator | Structured logs; must exclude passwords/tokens |
| A-012 | Audit logs | Data | ISO | C3 | Application log pipeline | Login, password reset, admin actions via `pkg/audit` |
| A-013 | TED tender data | Data | Product | C2 | MongoDB `tenders`, `notices` | Public procurement notices |
| A-014 | API endpoints | Service | Engineering | C2 | `cmd/web` Echo server | `/api/v1`, `/admin/v1` |
| A-015 | Worker & scraper jobs | Service | Engineering | C2 | `cmd/worker`, `cmd/scraper` | Scheduled ingestion and translation |
| A-016 | Notification service integration | Service | DevOps | C3 | External HTTP API | Email and messaging |
| A-017 | AI summarizer service | Service | DevOps | C3 | External HTTP API | Tender text sent for translation |
| A-018 | FCM credentials | Config | DevOps | C4 | `docs/fcm/` (must not be committed in prod) | Push notification keys |
| A-019 | Backup snapshots | Data | DevOps | C3 | Backup storage | MongoDB and MinIO backups |
| A-020 | CI/CD pipeline | Process | DevOps | C2 | GitHub / CI runner | Build, test, deploy automation |
### 4.3 Data Flow Summary
```
[TED XML] → Scraper → MongoDB (tenders/notices)
↓
[Admin Panel / Mobile App] → Web API → MongoDB / Redis / MinIO
↓
Worker → AI Service → MinIO (translations)
↓
Notification Service → Email / FCM
```
---
## 5. Roles and Responsibilities
| Role | Responsibilities |
|------|------------------|
| **Executive Sponsor** | Approves ISMS budget, scope, and risk acceptance |
| **Information Security Officer (ISO)** | Owns ISMS, risk register, policies, audit coordination |
| **Data Protection Officer (DPO)** | GDPR/privacy compliance, DPIA, data subject requests |
| **Engineering Lead** | Secure SDLC, code review, dependency management |
| **DevOps Lead** | Infrastructure hardening, secrets, backups, monitoring |
| **Product Owner** | Data classification decisions, retention requirements |
| **All personnel** | Acceptable use, incident reporting, security training |
*Note: One person may hold multiple roles in smaller teams; responsibilities must still be documented.*
---
## 6. Current Security Control Baseline
Controls already implemented in the codebase (to be formalized and verified):
| Control Area | Implementation | ISO 27001 Annex A Reference |
|--------------|----------------|----------------------------|
| Authentication | JWT access/refresh tokens (`pkg/authorization`) | A.8.5 |
| Authorization | Role-based and company-scoped middleware | A.8.3 |
| Input validation | Govalidator on all API forms | A.8.26 |
| XSS prevention | Bluemonday HTML sanitization (`pkg/security`) | A.8.26 |
| Password storage | bcrypt hashing (customer/user services) | A.8.5 |
| Bot protection | hCaptcha integration | A.8.6 |
| Structured logging | Service-layer logging with context fields | A.8.15 |
| Audit events | `pkg/audit` for security-relevant actions | A.8.15 |
| Config secrets | OS env overrides `.env` (`pkg/config`) | A.8.9 |
| Rate limiting | Configurable rate limit (`RateLimitConfig`) | A.8.6 |
| API documentation | Swagger/OpenAPI (`cmd/web/docs`) | A.8.32 |
| File storage | MinIO with access control via file store service | A.8.11 |
### 6.1 Known Gaps (To Address in Roadmap)
- Formal written policies (access control, incident response, backup, change management)
- Documented vulnerability management and penetration testing schedule
- Centralized secrets management (vault) instead of flat env files
- SIEM/alerting for security events
- Formal data retention and deletion procedures
- Business continuity and disaster recovery testing
- Security awareness training records
- Supplier security assessments for AI and notification services
---
## 7. Legal and Regulatory Requirements
| Requirement | Applicability | ISMS Response |
|-------------|---------------|---------------|
| **GDPR** | EU customer/company PII | Lawful basis documentation, DPIA, DSR process, encryption in transit |
| **ISO/IEC 27001** | Certification target | This ISMS foundation and roadmap |
| **Procurement data licensing** | TED public data terms | Source attribution, ingestion compliance review |
---
## 8. ISMS Documentation Structure
```
docs/security/
├── ISMS_FOUNDATION.md ← This document
├── ISO27001_ROADMAP.md ← Certification phases and timeline
├── RISK_ASSESSMENT_MATRIX.md ← Initial risk register
├── GAP_ANALYSIS_REPORT.md ← Clause 4–10 gap analysis
├── STATEMENT_OF_APPLICABILITY.md ← Annex A SoA (93 controls)
├── ISMS_SCOPE_APPROVAL.md ← Scope sign-off (Clause 4.3)
├── policies/ ← Phase 1 deliverables
│ ├── information-security-policy.md
│ ├── access-control-policy.md
│ ├── incident-response-plan.md
│ ├── backup-and-recovery-policy.md
│ └── acceptable-use-policy.md
└── procedures/
├── risk-assessment-procedure.md
├── change-management-procedure.md ← (Phase 2)
└── vendor-management-procedure.md ← (Phase 2)
```
---
## 9. Document Control
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | 2026-06-11 | Engineering | Initial ISMS foundation, scope, asset inventory |
**Approval**
| Role | Name | Signature | Date |
|------|------|-----------|------|
| ISO | _Pending_ | | |
| Executive Sponsor | _Pending_ | | |
---
## 10. Next Steps
1. Review and approve this foundation document with executive sponsor
2. Complete initial risk assessment ([RISK_ASSESSMENT_MATRIX.md](./RISK_ASSESSMENT_MATRIX.md))
3. Execute Phase 1 of the [ISO 27001 Roadmap](./ISO27001_ROADMAP.md)
4. Assign ISO/DPO roles (can be interim)
5. Schedule first management review within 90 days
docs/security/ISMS_SCOPE_APPROVAL.md
+168
View File
@@ -0,0 +1,168 @@
# ISMS Scope Approval
| Field | Value |
|-------|-------|
| **Document ID** | ISMS-006 |
| **Version** | 1.0 |
| **Status** | Pending signature |
| **Owner** | Executive Sponsor |
| **Prepared By** | Information Security Officer (ISO) |
| **Date Prepared** | 2026-06-11 |
| **ISO 27001 Reference** | Clause 4.3 — Determining the scope of the information security management system |
Related: [ISMS Foundation](./ISMS_FOUNDATION.md) | [Gap Analysis Report](./GAP_ANALYSIS_REPORT.md)
---
## 1. Purpose
This document records formal management approval of the **Information Security Management System (ISMS) scope** for the Tender Management platform, as required by ISO/IEC 27001:2022 Clause 4.3.
---
## 2. Organization
| Field | Value |
|-------|-------|
| **Organization** | _[Company legal name]_ |
| **Product / Service** | Tender Management System (TM) |
| **Repository** | `tm_back` (Go backend API) |
| **Business Unit** | Engineering / Product |
---
## 3. Approved ISMS Scope
### 3.1 Scope Statement
> The ISMS covers the design, development, deployment, and operation of the **Tender Management backend platform**, including all information assets processed, stored, or transmitted by the web API (`cmd/web`), background worker (`cmd/worker`), and TED scraper (`cmd/scraper`), together with supporting **MongoDB**, **Redis**, and **MinIO** infrastructure in development, staging, and production environments.
### 3.2 In Scope
| Category | Items |
|----------|-------|
| **Applications** | `cmd/web`, `cmd/worker`, `cmd/scraper` |
| **Domain services** | User, customer, company, tender, feedback, notification, inquiry, contact, CMS, kanban, dashboard, document scraper, tender approval |
| **Shared packages** | Authorization (JWT), security (XSS/CSP), audit logging, file store, MinIO client, configuration |
| **Data stores** | MongoDB (`tm` database), Redis, MinIO (`files`, `documents` buckets) |
| **External integrations** | Notification service, hCaptcha, AI summarizer/translation, GoRules, TED data sources, FCM push |
| **Environments** | Development, staging, production, CI/CD pipelines |
| **Personnel** | Developers, DevOps, QA, product owners with access to TM infrastructure or production data |
| **Locations** | Cloud-hosted infrastructure (provider TBD / per deployment); remote work for engineering staff |
### 3.3 Explicitly Out of Scope
| Item | Rationale | Interface Control |
|------|-----------|-----------------|
| Mobile application codebase | Separate repository and release cycle | API contract (`/api/v1`); JWT authentication |
| Admin panel frontend | Separate repository | API contract (`/admin/v1`); admin JWT + RBAC |
| TED / EU publication infrastructure | Third-party public data source | XML ingestion validation in scraper |
| Customer on-premise deployments | SaaS delivery model | N/A — revisit if product offering changes |
| End-user devices (phones, laptops) | Covered by Acceptable Use Policy, not ISMS technical scope | AUP acknowledgment |
| Physical data center facilities | Cloud shared responsibility model | Provider compliance evidence (A.5.23) |
### 3.4 Boundaries and Interfaces
```
┌─────────────────────────────────────────────────────────────┐
│ APPROVED ISMS SCOPE │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ cmd/web │ │cmd/worker│ │cmd/scraper│ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ └─────────────┼─────────────┘ │
│ ▼ │
│ ┌─────────────────────────────┐ │
│ │ MongoDB │ Redis │ MinIO │ │
│ └─────────────────────────────┘ │
└──────────────┬──────────────────────────────────────────────┘
│ API boundaries (out of scope beyond interface)
┌──────────┼──────────┬─────────────┬──────────────┐
▼ ▼ ▼ ▼ ▼
Mobile Admin Notification AI Service TED (public)
App Panel Service XML feed
(OOS) (OOS) (interface) (interface) (OOS)
```
**OOS** = Out of Scope (interface governed by contracts and vendor assessment)
---
## 4. Interested Parties (Summary)
| Party | Interest | ISMS Response |
|-------|----------|---------------|
| Company customers | PII protection, service availability | Access control, encryption, backup |
| EU data subjects | GDPR rights | DPO oversight, DSR process |
| Engineering team | Secure development environment | Policies, training, tooling |
| Executive management | Certification, risk management | This approval, management review |
| Cloud / SaaS providers | Shared security responsibility | A.5.23 cloud controls |
| Certification body | Conformity evidence | Audit program |
---
## 5. Applicable Requirements
| Requirement | Applicability |
|-------------|---------------|
| ISO/IEC 27001:2022 | Full ISMS certification target |
| GDPR (EU 2016/679) | Customer and company PII processing |
| TED data terms of use | Public procurement data ingestion |
| Customer contracts | Per agreement (security addenda as applicable) |
---
## 6. Asset Summary Reference
Full inventory: [ISMS Foundation §4](./ISMS_FOUNDATION.md#4-information-asset-inventory) — **20 assets** registered (A-001 through A-020).
Key data categories in scope:
- Customer PII (C3)
- Company business data (C3)
- Authentication credentials (C4)
- Tender/procurement data (C2)
- Application logs and audit records (C2–C3)
---
## 7. Scope Change Process
Changes to this scope require:
1. Written justification (new service, architecture change, new data type)
2. Risk assessment per [Risk Assessment Procedure](./procedures/risk-assessment-procedure.md)
3. Update to [ISMS Foundation](./ISMS_FOUNDATION.md), [SoA](./STATEMENT_OF_APPLICABILITY.md), and this document
4. Re-approval by Executive Sponsor
5. Notification to certification body if already certified
---
## 8. Approval
By signing below, management confirms:
1. The scope defined in Section 3 accurately reflects the boundaries of the TM ISMS
2. Resources will be made available to implement and maintain the ISMS per [ISO27001_ROADMAP.md](./ISO27001_ROADMAP.md)
3. Information security objectives in the [Information Security Policy](./policies/information-security-policy.md) are endorsed
4. An Information Security Officer will be designated (named or interim)
---
### Signatures
| Role | Name | Signature | Date |
|------|------|-----------|------|
| **Executive Sponsor** | _________________________ | _________________________ | __________ |
| **Information Security Officer** | _________________________ | _________________________ | __________ |
| **Engineering Lead** | _________________________ | _________________________ | __________ |
| **DevOps Lead** | _________________________ | _________________________ | __________ |
---
## 9. Document Control
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | 2026-06-11 | Engineering | Initial scope approval document |
**Next review:** 2027-06-11 (annual) or upon material architecture change
docs/security/ISO27001_ROADMAP.md
+313
View File
@@ -0,0 +1,313 @@
# ISO/IEC 27001 Certification Roadmap — Tender Management System
| Field | Value |
|-------|-------|
| **Document ID** | ISMS-003 |
| **Version** | 1.0 |
| **Status** | Active roadmap |
| **Owner** | Information Security Officer (ISO) |
| **Last Updated** | 2026-06-11 |
| **Target Certification** | ISO/IEC 27001:2022 |
Related: [ISMS Foundation](./ISMS_FOUNDATION.md) | [Risk Assessment Matrix](./RISK_ASSESSMENT_MATRIX.md)
---
## 1. Executive Summary
This roadmap defines a phased path from the current informal security practices to a certifiable ISMS for the Tender Management backend platform. The plan spans approximately **12–18 months** from foundation to Stage 2 certification audit, assuming dedicated part-time security ownership (0.25–0.5 FTE).
### Current State
- Strong technical controls in application layer (JWT, RBAC, validation, XSS, audit logging)
- No formal ISMS documentation, policies, or certified processes
- Risk assessment and asset inventory now documented (initial versions)
### Target State
- Documented and operating ISMS aligned with ISO/IEC 27001:2022
- Risk treatment plans executed for High and Critical risks
- Internal audit program and management review cycle established
- Successful Stage 1 and Stage 2 certification audits
---
## 2. Certification Timeline Overview
```
Phase 0 ──► Phase 1 ──► Phase 2 ──► Phase 3 ──► Phase 4 ──► Phase 5
Foundation Gap & Implement Operate Pre-Audit Certification
(Complete) Policies Controls ISMS Readiness Audit
│ │ │ │ │ │
Jun 2026 Jul-Aug Sep-Nov Dec-Mar Apr-Jun Jul-Sep 2027
```
| Phase | Name | Duration | Key Deliverable |
|-------|------|----------|-----------------|
| **0** | Foundation | 2 weeks | ISMS scope, asset inventory, risk matrix *(this release)* |
| **1** | Gap Analysis & Policies | 6–8 weeks | Policy suite, SoA draft, gap report |
| **2** | Control Implementation | 10–12 weeks | Technical and procedural controls |
| **3** | ISMS Operation | 12+ weeks | Internal audits, KPIs, management review |
| **4** | Pre-Audit Readiness | 4–6 weeks | Mock audit, evidence pack, corrective actions |
| **5** | Certification Audit | 4–8 weeks | Stage 1 + Stage 2 with accredited CB |
---
## 3. Phase 0 — Foundation (Complete)
**Status:** ✅ Complete as of 2026-06-11
| Task | Deliverable | Status |
|------|-------------|--------|
| Define ISMS scope | [ISMS_FOUNDATION.md §3](./ISMS_FOUNDATION.md#3-isms-scope) | ✅ |
| Create asset inventory | [ISMS_FOUNDATION.md §4](./ISMS_FOUNDATION.md#4-information-asset-inventory) | ✅ |
| Initial risk assessment | [RISK_ASSESSMENT_MATRIX.md](./RISK_ASSESSMENT_MATRIX.md) | ✅ |
| Assign interim ISO role | Pending management approval | ⬜ |
| Executive briefing on ISMS scope | Presentation / sign-off | ⬜ |
---
## 4. Phase 1 — Gap Analysis & Policy Framework
**Target:** Jul–Aug 2026 (6–8 weeks)
### 4.1 Objectives
- Map existing controls to ISO 27001:2022 Annex A
- Identify gaps and produce Statement of Applicability (SoA)
- Publish core ISMS policies
### 4.2 Deliverables
| # | Deliverable | ISO 27001 Reference | Owner | Status |
|---|-------------|---------------------|-------|--------|
| 1.1 | Gap analysis report | Clauses 4–10 | ISO | ✅ Draft |
| 1.2 | Statement of Applicability (SoA) | Annex A | ISO | ✅ Draft |
| 1.3 | Information Security Policy | A.5.1 | Executive Sponsor | ✅ Draft |
| 1.4 | Access Control Policy | A.5.15–A.5.18 | ISO | ✅ Draft |
| 1.5 | Incident Response Plan | A.5.24–A.5.28 | ISO | ✅ Draft |
| 1.6 | Backup & Recovery Policy | A.8.13 | DevOps | ✅ Draft |
| 1.7 | Acceptable Use Policy | A.6.2 | HR / ISO | ✅ Draft |
| 1.8 | Risk Assessment Procedure | Clause 6.1.2 | ISO | ✅ Draft |
| 1.9 | ISMS scope approval (signed) | Clause 4.3 | Executive Sponsor | ✅ Draft — pending signature |
### 4.3 Annex A Gap Snapshot (Initial)
Based on codebase review and [Risk Assessment Matrix](./RISK_ASSESSMENT_MATRIX.md):
| Annex A Theme | Current Maturity | Gap Priority |
|---------------|------------------|--------------|
| A.5 Organizational controls | 2 Yes / 25 Partial / 10 No (of 37) | High |
| A.6 People controls | 0 Yes / 6 Partial / 2 No (of 8) | High |
| A.7 Physical controls | 11 N/A (cloud); 3 Partial (personnel devices) | Transfer to cloud provider |
| A.8 Technological controls | 4 Yes / 22 Partial / 7 No / 1 N/A (of 34) | Medium |
*Per-theme counts: [SoA §7.1](./STATEMENT_OF_APPLICABILITY.md#71-by-theme).*
**Controls with Status = Yes in SoA (fully evidenced):**
| Control | Evidence in Codebase |
|---------|---------------------|
| A.5.9, A.5.12 | Asset inventory; information classification |
| A.8.3 Access restriction | RBAC + company-scoped middleware |
| A.8.4 Access to source code | Git repo with PR review |
| A.8.15 Logging | Structured service logging, `pkg/audit` |
| A.8.26 Application security requirements | Govalidator, XSS policy, Swagger |
**Additional partial in-app controls** (e.g. A.8.5 authentication, A.8.9 configuration, A.8.6 rate limiting) are implemented in code but not yet fully evidenced in the SoA.
**Priority gaps to close in Phase 2:**
| Control | Gap | Planned Action |
|---------|-----|----------------|
| A.8.24 Cryptography | No documented crypto policy; at-rest encryption TBD | Encryption policy; MongoDB/MinIO at-rest |
| A.8.8 Vulnerability management | No formal scanning | CI: govulncheck, SAST, container scan |
| A.8.16 Monitoring | Logs only, no SIEM | Centralized logging + alerts |
| A.5.19–A.5.23 Supplier relationships | No vendor assessments | Vendor questionnaire for AI, notification |
| A.5.29–A.5.30 Business continuity | No DR plan | BCP/DRP with RTO/RPO |
| A.6.3 Security awareness | No training program | Annual training + onboarding module |
---
## 5. Phase 2 — Control Implementation
**Target:** Sep–Nov 2026 (10–12 weeks)
### 5.1 Technical Controls
| Priority | Control | Tasks | Risk IDs | Owner |
|----------|---------|-------|----------|-------|
| P0 | Secrets management | Migrate to vault; remove FCM keys from repo; rotate credentials | R-013 | DevOps |
| P0 | Auth hardening | Rate limit all auth endpoints; MFA for admin users | R-001, R-021 | Engineering |
| P0 | Vulnerability scanning | govulncheck + Dependabot in CI; monthly review | R-010 | Engineering |
| P1 | Encryption at rest | Enable MongoDB and MinIO encryption | R-005, R-006 | DevOps |
| P1 | Monitoring & alerting | Centralize logs; alert on auth failures, 5xx spikes | R-015 | DevOps |
| P1 | RBAC audit | Automated tests for all admin route authorization | R-003 | Engineering |
| P2 | WAF / CDN | DDoS protection for public API | R-012 | DevOps |
| P2 | File upload security | MIME validation, size limits, malware scan | R-011 | Engineering |
| P2 | Refresh token rotation | Complete token rotation implementation | R-002 | Engineering |
### 5.2 Procedural Controls
| Priority | Control | Tasks | Owner |
|----------|---------|-------|-------|
| P0 | Incident response | IR plan, on-call rotation, tabletop exercise | ISO |
| P0 | Change management | PR approval rules, prod deployment checklist | Engineering |
| P1 | Access reviews | Quarterly review of admin and infra access | ISO |
| P1 | Backup verification | Monthly restore test; documented RTO/RPO | DevOps |
| P1 | Vendor management | Security questionnaires for AI, notification, cloud | ISO |
| P2 | DSR process | GDPR data subject request workflow | DPO |
---
## 6. Phase 3 — ISMS Operation
**Target:** Dec 2026 – Mar 2027 (minimum 3 months operation required)
### 6.1 Operating Activities
| Activity | Frequency | Owner | ISO 27001 Reference |
|----------|-----------|-------|---------------------|
| Risk register review | Quarterly | ISO | 6.1.2 |
| Internal audit | Semi-annual | Internal auditor | 9.2 |
| Management review | Quarterly | Executive Sponsor | 9.3 |
| Vulnerability scan review | Monthly | Engineering | A.8.8 |
| Access review | Quarterly | ISO | A.5.18 |
| Backup restore test | Monthly | DevOps | A.8.13 |
| Security awareness training | Annual + onboarding | ISO | A.6.3 |
| Supplier review | Annual | ISO | A.5.19 |
| KPI reporting | Monthly | ISO | 9.1 |
### 6.2 Key Performance Indicators (KPIs)
| KPI | Target | Measurement |
|-----|--------|-------------|
| Critical/High open risks | 0 Critical; ≤3 High | Risk register |
| Mean time to patch (Critical CVE) | ≤ 7 days | Vulnerability tracker |
| Failed login rate | Baseline + alert threshold | SIEM |
| Backup restore success | 100% monthly test | DevOps report |
| Security training completion | 100% staff | HR records |
| Incident response time (P1) | ≤ 1 hour acknowledgment | IR log |
---
## 7. Phase 4 — Pre-Audit Readiness
**Target:** Apr–Jun 2027 (4–6 weeks)
| Task | Description |
|------|-------------|
| Select certification body (CB) | Accredited ISO 27001 registrar |
| Mock Stage 1 audit | Documentation review against Clauses 4–10 |
| Evidence pack assembly | Policies, risk register, audit reports, training records, change logs |
| Corrective actions | Close all findings from mock audit |
| Employee interviews prep | Staff briefed on ISMS policies and their roles |
| SoA finalization | All Annex A controls marked with implementation status |
### 7.1 Evidence Checklist
- [ ] Signed Information Security Policy
- [ ] Approved ISMS scope document
- [ ] Risk assessment and treatment plan (current version)
- [ ] Statement of Applicability
- [ ] Internal audit reports (≥1 cycle)
- [ ] Management review minutes (≥1 cycle)
- [ ] Incident response plan and test record
- [ ] Access review records
- [ ] Vulnerability scan reports
- [ ] Backup/restore test records
- [ ] Training completion records
- [ ] Vendor assessment records
- [ ] Change management records (sample)
---
## 8. Phase 5 — Certification Audit
**Target:** Jul–Sep 2027
### 8.1 Stage 1 — Documentation Review
- CB reviews ISMS documentation for conformity with ISO 27001:2022
- Scope, SoA, risk assessment, and policy completeness verified
- Findings documented; corrective actions before Stage 2
### 8.2 Stage 2 — Implementation Audit
- CB verifies controls are implemented and operating effectively
- Interviews with key personnel
- Sampling of evidence (logs, tickets, access records)
- Nonconformities classified as Minor or Major
### 8.3 Post-Certification
- Surveillance audits annually
- Full recertification every 3 years
- Continuous improvement via PDCA cycle
---
## 9. Resource Estimate
| Role | Effort | Phase(s) |
|------|--------|----------|
| ISO (part-time) | 0.25–0.5 FTE ongoing | All |
| Engineering Lead | 0.1 FTE | 2, 3 |
| DevOps Lead | 0.15 FTE | 2, 3 |
| DPO (part-time) | 0.05 FTE | 1, 2 |
| External consultant (optional) | 5–10 days | 1, 4 |
| Certification body | Fixed fee | 5 |
| Security tooling (SIEM, scanning) | Budget item | 2 |
**Estimated total cost range:** €15,000–€40,000 (highly dependent on org size, tooling, and consultant use)
---
## 10. PDCA Cycle Integration
```
┌─────────────┐
│ PLAN │ Scope, risk assessment, policies, SoA
└──────┬──────┘
▼
┌─────────────┐
│ DO │ Implement controls, training, procedures
└──────┬──────┘
▼
┌─────────────┐
│ CHECK │ Internal audit, KPIs, management review
└──────┬──────┘
▼
┌─────────────┐
│ ACT │ Corrective actions, risk updates, improve
└──────┬──────┘
└──────────► (back to PLAN)
```
---
## 11. Milestones & Decision Gates
| Milestone | Target Date | Gate Criteria |
|-----------|-------------|---------------|
| M0: Foundation approved | 2026-06-30 | Executive sign-off on scope and asset inventory |
| M1: Policy suite published | 2026-08-31 | 5 core policies + risk procedure drafted; pending executive approval |
| M2: Critical risks mitigated | 2026-11-30 | No Critical residual risks |
| M3: ISMS operational | 2027-03-31 | 1 internal audit + 1 management review complete |
| M4: Pre-audit passed | 2027-06-30 | Mock audit with no Major findings |
| M5: ISO 27001 certified | 2027-09-30 | Stage 2 certificate issued |
---
## 12. Document Control
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | 2026-06-11 | Engineering | Initial certification roadmap |
**Approval**
| Role | Name | Signature | Date |
|------|------|-----------|------|
| ISO | _Pending_ | | |
| Executive Sponsor | _Pending_ | | |
docs/security/RISK_ASSESSMENT_MATRIX.md
+166
View File
@@ -0,0 +1,166 @@
# Risk Assessment Matrix — Tender Management System
| Field | Value |
|-------|-------|
| **Document ID** | ISMS-002 |
| **Version** | 1.0 |
| **Status** | Initial assessment |
| **Owner** | Information Security Officer (ISO) |
| **Last Updated** | 2026-06-11 |
| **Review Cycle** | Quarterly (minimum) |
---
## 1. Purpose
This document records the initial information security risk assessment for the Tender Management System ISMS. It identifies threats, evaluates inherent and residual risk, and defines treatment plans aligned with ISO/IEC 27001 Clause 6.1.2 and Annex A controls.
Related: [ISMS Foundation](./ISMS_FOUNDATION.md) | [ISO 27001 Roadmap](./ISO27001_ROADMAP.md)
---
## 2. Methodology
### 2.1 Risk Formula
```
Risk Score = Likelihood (1–5) × Impact (1–5)
```
### 2.2 Likelihood Scale
| Score | Label | Description |
|-------|-------|-------------|
| 1 | Rare | Unlikely in 3+ years |
| 2 | Unlikely | Possible but not expected annually |
| 3 | Possible | May occur once per year |
| 4 | Likely | Expected several times per year |
| 5 | Almost certain | Expected frequently or already observed |
### 2.3 Impact Scale
| Score | Label | Description |
|-------|-------|-------------|
| 1 | Negligible | No data exposure; minimal downtime (<1 h) |
| 2 | Minor | Limited internal data; downtime 1–4 h |
| 3 | Moderate | PII exposure for subset of users; downtime 4–24 h |
| 4 | Major | Large-scale PII breach; regulatory notification; downtime 1–3 days |
| 5 | Critical | Systemic breach; legal liability; prolonged outage (>3 days) |
### 2.4 Risk Level Matrix
| Score Range | Level | Action Required |
|-------------|-------|-----------------|
| 1–4 | **Low** | Monitor; accept with documented justification |
| 5–9 | **Medium** | Mitigate within 6 months |
| 10–15 | **High** | Mitigate within 3 months; management awareness |
| 16–25 | **Critical** | Immediate treatment; executive escalation |
### 2.5 Treatment Options
- **Mitigate** — Apply controls to reduce likelihood or impact
- **Transfer** — Insurance or contractual liability shift
- **Avoid** — Discontinue the activity
- **Accept** — Documented acceptance by authorized role (residual risk only)
---
## 3. Risk Register
### 3.1 Authentication & Access
| Risk ID | Threat | Vulnerability | Asset(s) | L | I | Inherent | Existing Controls | Residual L | Residual I | Residual | Treatment | Owner | Target Date | Status |
|---------|--------|---------------|----------|---|---|----------|-------------------|------------|------------|----------|-----------|-------|-------------|--------|
| R-001 | Credential stuffing / brute force | Login endpoints without sufficient throttling | A-004, A-006, A-007 | 4 | 4 | **16 Critical** | JWT auth, hCaptcha on selected flows, rate limit config | 3 | 3 | **9 Medium** | Enforce rate limiting on all auth endpoints; account lockout; MFA for admin | Engineering | Q3 2026 | Open |
| R-002 | JWT token theft (XSS, MITM) | Tokens in client storage | A-008 | 3 | 4 | **12 High** | HTTPS required in prod; short token TTL; refresh rotation partial | 2 | 3 | **6 Medium** | Complete refresh token rotation; HttpOnly cookies where applicable; CSP headers | Engineering | Q3 2026 | Open |
| R-003 | Privilege escalation | Insufficient RBAC checks on admin routes | A-006, A-014 | 2 | 5 | **10 High** | Role middleware in `pkg/authorization` | 2 | 4 | **8 Medium** | RBAC audit of all admin endpoints; automated authorization tests | Engineering | Q2 2026 | Open |
| R-004 | Orphaned / excessive access | No formal access review process | A-006, A-010 | 3 | 3 | **9 Medium** | Manual provisioning | 2 | 2 | **4 Low** | Quarterly access review procedure; offboarding checklist | ISO | Q3 2026 | Open |
### 3.2 Data Protection & Privacy
| Risk ID | Threat | Vulnerability | Asset(s) | L | I | Inherent | Existing Controls | Residual L | Residual I | Residual | Treatment | Owner | Target Date | Status |
|---------|--------|---------------|----------|---|---|----------|-------------------|------------|------------|----------|-----------|-------|-------------|--------|
| R-005 | Unauthorized PII access | Missing encryption at rest | A-001, A-004, A-005 | 3 | 5 | **15 High** | Network isolation; app-level auth | 2 | 4 | **8 Medium** | Enable MongoDB encryption at rest; field-level encryption for sensitive fields | DevOps | Q3 2026 | Open |
| R-006 | Data breach via backup exposure | Unencrypted or overly permissive backups | A-019 | 2 | 5 | **10 High** | Ad-hoc backups | 2 | 3 | **6 Medium** | Encrypted backups; restricted access; backup retention policy | DevOps | Q3 2026 | Open |
| R-007 | GDPR non-compliance (DSR) | No documented data subject request process | A-004, A-005 | 3 | 4 | **12 High** | — | 3 | 3 | **9 Medium** | DSR procedure; data inventory mapping; deletion API/workflow | DPO | Q4 2026 | Open |
| R-008 | Sensitive data in logs | Accidental logging of passwords/tokens | A-011 | 3 | 4 | **12 High** | Coding standards prohibit password logging | 2 | 3 | **6 Medium** | Log scrubbing; automated secret detection in CI | Engineering | Q2 2026 | Open |
### 3.3 Application Security
| Risk ID | Threat | Vulnerability | Asset(s) | L | I | Inherent | Existing Controls | Residual L | Residual I | Residual | Treatment | Owner | Target Date | Status |
|---------|--------|---------------|----------|---|---|----------|-------------------|------------|------------|----------|-----------|-------|-------------|--------|
| R-009 | Injection attacks (NoSQL, XSS) | Unvalidated user input | A-014 | 3 | 4 | **12 High** | Govalidator; Bluemonday XSS policy | 2 | 3 | **6 Medium** | SAST/DAST in CI; security test cases for injection | Engineering | Q2 2026 | Open |
| R-010 | Dependency vulnerability exploit | Outdated Go modules | A-009 | 4 | 4 | **16 Critical** | go.mod pinned versions | 3 | 3 | **9 Medium** | Dependabot/Renovate; monthly dependency review; `govulncheck` in CI | Engineering | Q2 2026 | Open |
| R-011 | Insecure file upload | Malicious document upload | A-003, A-005 | 2 | 4 | **8 Medium** | File store service; GridFS/MinIO | 2 | 3 | **6 Medium** | MIME validation; size limits; malware scanning | Engineering | Q4 2026 | Open |
| R-012 | API abuse / DoS | High-volume unauthenticated requests | A-014 | 4 | 3 | **12 High** | Rate limit config exists | 2 | 2 | **4 Low** | Enable rate limiting in production; WAF/CDN | DevOps | Q2 2026 | Open |
### 3.4 Infrastructure & Operations
| Risk ID | Threat | Vulnerability | Asset(s) | L | I | Inherent | Existing Controls | Residual L | Residual I | Residual | Treatment | Owner | Target Date | Status |
|---------|--------|---------------|----------|---|---|----------|-------------------|------------|------------|----------|-----------|-------|-------------|--------|
| R-013 | Secret leakage | Secrets in repo, logs, or `.env` files | A-010, A-018 | 3 | 5 | **15 High** | `.gitignore`; env priority system | 2 | 4 | **8 Medium** | Secret manager (Vault/AWS SM); secret scanning in CI; rotate FCM keys out of repo | DevOps | Q2 2026 | Open |
| R-014 | Service outage (MongoDB/Redis/MinIO) | Single points of failure | A-001, A-002, A-003 | 3 | 4 | **12 High** | Managed services assumed | 2 | 3 | **6 Medium** | HA deployment; DR plan; RTO/RPO definitions | DevOps | Q4 2026 | Open |
| R-015 | Insufficient monitoring | Delayed incident detection | A-011, A-012 | 4 | 4 | **16 Critical** | Application logging only | 3 | 3 | **9 Medium** | SIEM integration; alerting on auth failures, error spikes | DevOps | Q3 2026 | Open |
| R-016 | Unpatched OS/container images | Delayed security patching | A-014, A-015 | 3 | 4 | **12 High** | — | 2 | 3 | **6 Medium** | Patch management procedure; automated image scanning | DevOps | Q3 2026 | Open |
### 3.5 Third-Party & Supply Chain
| Risk ID | Threat | Vulnerability | Asset(s) | L | I | Inherent | Existing Controls | Residual L | Residual I | Residual | Treatment | Owner | Target Date | Status |
|---------|--------|---------------|----------|---|---|----------|-------------------|------------|------------|----------|-----------|-------|-------------|--------|
| R-017 | AI service data leakage | Tender text sent to external AI | A-017, A-013 | 3 | 4 | **12 High** | Configurable AI endpoint | 2 | 3 | **6 Medium** | DPA with AI vendor; data minimization; on-prem option evaluation | DPO / DevOps | Q4 2026 | Open |
| R-018 | Notification service compromise | Email content interception | A-016 | 2 | 3 | **6 Medium** | TLS to notification API | 2 | 2 | **4 Low** | Vendor security questionnaire; TLS enforcement | ISO | Q4 2026 | Open |
| R-019 | Compromised TED source data | Malicious XML in scraper pipeline | A-013, A-015 | 2 | 3 | **6 Medium** | XML parser validation | 2 | 2 | **4 Low** | Schema validation; sandboxed parsing; input size limits | Engineering | Q3 2026 | Open |
### 3.6 Human & Process
| Risk ID | Threat | Vulnerability | Asset(s) | L | I | Inherent | Existing Controls | Residual L | Residual I | Residual | Treatment | Owner | Target Date | Status |
|---------|--------|---------------|----------|---|---|----------|-------------------|------------|------------|----------|-----------|-------|-------------|--------|
| R-020 | Insider threat | Broad production DB access | A-001, A-004 | 2 | 5 | **10 High** | — | 2 | 4 | **8 Medium** | Least privilege; break-glass access; audit DB queries | DevOps | Q3 2026 | Open |
| R-021 | Phishing / social engineering | Staff credential compromise | A-006, A-010 | 3 | 4 | **12 High** | — | 2 | 3 | **6 Medium** | Security awareness training; MFA for admin and infra | ISO | Q3 2026 | Open |
| R-022 | Undocumented change deployment | No formal change management | A-009, A-014 | 3 | 3 | **9 Medium** | Git + PR workflow informal | 2 | 2 | **4 Low** | Change management procedure; prod deployment approval | Engineering | Q3 2026 | Open |
| R-023 | Delayed incident response | No IR plan or runbooks | All | 3 | 5 | **15 High** | — | 2 | 4 | **8 Medium** | Incident response plan; tabletop exercise | ISO | Q2 2026 | Open |
---
## 4. Risk Summary Dashboard
| Risk Level | Count | Risk IDs |
|------------|-------|----------|
| **Critical** (16–25) | 0 (after treatment planning) | R-001, R-010, R-015 were Critical inherent — all have mitigation plans |
| **High** (10–15) | 8 residual | R-003, R-005, R-007, R-009, R-013, R-014, R-020, R-023 |
| **Medium** (5–9) | 12 residual | R-001, R-002, R-004, R-006, R-008, R-010, R-011, R-015, R-016, R-017, R-021, R-022 |
| **Low** (1–4) | 3 residual | R-012, R-018, R-019 |
### 4.1 Top Priority Actions (Next 90 Days)
1. **R-023** — Draft and approve incident response plan
2. **R-013** — Remove secrets from repository; implement secret scanning
3. **R-010** — Add `govulncheck` and dependency scanning to CI
4. **R-003** — Complete RBAC audit of admin API routes
5. **R-001** — Enforce authentication rate limiting in production
---
## 5. Risk Acceptance Log
Use this section to record risks explicitly accepted after treatment.
| Risk ID | Residual Score | Accepted By | Role | Date | Justification | Review Date |
|---------|----------------|-------------|------|------|---------------|-------------|
| _None yet_ | | | | | | |
---
## 6. Review History
| Version | Date | Reviewer | Changes |
|---------|------|----------|---------|
| 1.0 | 2026-06-11 | Engineering | Initial risk identification for TM platform |
**Next scheduled review:** 2026-09-11
---
## 7. Annex — Asset Reference
See [ISMS Foundation §4](./ISMS_FOUNDATION.md#4-information-asset-inventory) for full asset inventory (A-001 through A-020).
docs/security/STATEMENT_OF_APPLICABILITY.md
+255
View File
@@ -0,0 +1,255 @@
# Statement of Applicability (SoA) — Tender Management System
| Field | Value |
|-------|-------|
| **Document ID** | ISMS-005 |
| **Version** | 1.0 |
| **Status** | Draft — Pending approval |
| **Owner** | Information Security Officer (ISO) |
| **Last Updated** | 2026-06-11 |
| **Standard** | ISO/IEC 27001:2022 Annex A |
| **Scope** | [ISMS Foundation §3](./ISMS_FOUNDATION.md#3-isms-scope) |
Related: [Gap Analysis Report](./GAP_ANALYSIS_REPORT.md) | [Risk Assessment Matrix](./RISK_ASSESSMENT_MATRIX.md)
---
## 1. Purpose
The Statement of Applicability (SoA) documents:
- Which Annex A controls are **applicable** to the TM ISMS
- Whether each control is **implemented**, **partially implemented**, or **not implemented**
- Justification for exclusions
- Reference to implementation evidence or planned remediation
This document satisfies ISO/IEC 27001:2022 Clause 6.1.3(d) and is a mandatory input for certification audits.
---
## 2. Status Legend
| Status | Meaning |
|--------|---------|
| **Yes** | Applicable and implemented with evidence |
| **Partial** | Applicable; control exists but incomplete or not fully evidenced |
| **No** | Applicable but not yet implemented |
| **N/A** | Not applicable to scope (justification required) |
---
## 3. A.5 — Organizational Controls
| ID | Control | Applicable | Status | Implementation / Justification | Risk Ref |
|----|---------|------------|--------|----------------------------------|----------|
| A.5.1 | Policies for information security | Yes | Partial | [Information Security Policy](./policies/information-security-policy.md) draft; pending approval | — |
| A.5.2 | Information security roles and responsibilities | Yes | Partial | [ISMS Foundation §5](./ISMS_FOUNDATION.md#5-roles-and-responsibilities); named assignments pending | — |
| A.5.3 | Segregation of duties | Yes | Partial | Dev vs DevOps separation informal; no single prod DB write without break-glass | R-020 |
| A.5.4 | Management responsibilities | Yes | Partial | Roadmap and objectives defined; management review not yet held | — |
| A.5.5 | Contact with authorities | Yes | No | No documented contacts with regulators/law enforcement | R-023 |
| A.5.6 | Contact with special interest groups | Yes | No | No ISAC or security forum membership | — |
| A.5.7 | Threat intelligence | Yes | No | No formal threat intel feed or process | — |
| A.5.8 | Information security in project management | Yes | Partial | Major change checklist in risk procedure; informal for small changes | — |
| A.5.9 | Inventory of information and other associated assets | Yes | Yes | [ISMS Foundation §4](./ISMS_FOUNDATION.md#4-information-asset-inventory) — 20 assets | — |
| A.5.10 | Acceptable use of information and other associated assets | Yes | Partial | [Acceptable Use Policy](./policies/acceptable-use-policy.md) draft | — |
| A.5.11 | Return of assets | Yes | No | No formal offboarding asset return checklist | R-004 |
| A.5.12 | Classification of information | Yes | Yes | C1–C4 classification in ISMS Foundation | — |
| A.5.13 | Labelling of information | Yes | No | Classification defined but no labelling in apps/repos | — |
| A.5.14 | Information transfer | Yes | Partial | HTTPS for APIs; email via notification service; no DLP | R-017 |
| A.5.15 | Access control | Yes | Partial | [Access Control Policy](./policies/access-control-policy.md); JWT + RBAC | R-003 |
| A.5.16 | Identity management | Yes | Partial | Unique accounts; provisioning/deprovisioning procedure in policy | R-004 |
| A.5.17 | Authentication information | Yes | Partial | bcrypt passwords; secrets in env; MFA planned | R-001, R-013 |
| A.5.18 | Access rights | Yes | Partial | Quarterly review defined; not yet executed | R-004 |
| A.5.19 | Information security in supplier relationships | Yes | No | No vendor security assessments | R-017, R-018 |
| A.5.20 | Addressing information security within supplier agreements | Yes | No | Contracts lack security clauses review | R-017 |
| A.5.21 | Managing information security in the ICT supply chain | Yes | Partial | Go modules pinned; no formal supply chain policy | R-010 |
| A.5.22 | Monitoring, review and change management of supplier services | Yes | No | No annual vendor review process | R-018 |
| A.5.23 | Information security for use of cloud services | Yes | Partial | Cloud-hosted MongoDB/Redis/MinIO; provider evidence not collected | R-014 |
| A.5.24 | Information security incident management planning and preparation | Yes | Partial | [Incident Response Plan](./policies/incident-response-plan.md) draft | R-023 |
| A.5.25 | Assessment and decision on information security events | Yes | Partial | Severity classification in IR plan; not yet tested | R-023 |
| A.5.26 | Response to information security incidents | Yes | Partial | Playbooks defined; IRT contacts not finalized | R-023 |
| A.5.27 | Learning from information security incidents | Yes | Partial | Post-incident review required in IR plan; no incidents recorded yet | — |
| A.5.28 | Collection of evidence | Yes | Partial | Evidence handling in IR plan; chain of custody untested | — |
| A.5.29 | Information security during disruption | Yes | Partial | RTO/RPO in backup policy; no full BCP document | R-014 |
| A.5.30 | ICT readiness for business continuity | Yes | Partial | Backup policy; DR test not yet performed | R-014 |
| A.5.31 | Legal, statutory, regulatory and contractual requirements | Yes | Partial | GDPR referenced; no requirements register | R-007 |
| A.5.32 | Intellectual property rights | Yes | Partial | Open-source licenses in go.mod; no IP policy | — |
| A.5.33 | Protection of records | Yes | Partial | Audit logs; retention periods not fully defined | — |
| A.5.34 | Privacy and protection of PII | Yes | Partial | PII inventory; DSR process not implemented | R-007 |
| A.5.35 | Independent review of information security | Yes | No | No internal audit or external review yet | — |
| A.5.36 | Compliance with policies, rules and standards | Yes | No | No compliance checks or audit program | — |
| A.5.37 | Documented operating procedures | Yes | Partial | ISMS procedures started; ops runbooks incomplete | — |
---
## 4. A.6 — People Controls
| ID | Control | Applicable | Status | Implementation / Justification | Risk Ref |
|----|---------|------------|--------|----------------------------------|----------|
| A.6.1 | Screening | Yes | No | No background check policy documented | R-021 |
| A.6.2 | Terms and conditions of employment | Yes | Partial | Acceptable Use Policy; HR terms not linked | — |
| A.6.3 | Information security awareness, education and training | Yes | No | No training program or records | R-021 |
| A.6.4 | Disciplinary process | Yes | Partial | Referenced in AUP; HR process not documented | — |
| A.6.5 | Responsibilities after termination or change of employment | Yes | Partial | Deprovisioning in Access Control Policy (24 h) | R-004 |
| A.6.6 | Confidentiality or non-disclosure agreements | Yes | Partial | Assumed for contractors; no central register | — |
| A.6.7 | Remote working | Yes | Partial | VPN/bastion requirement in Access Control Policy | — |
| A.6.8 | Information security event reporting | Yes | Partial | Reporting channels in IR plan; not communicated to staff | R-023 |
---
## 5. A.7 — Physical Controls
| ID | Control | Applicable | Status | Implementation / Justification | Risk Ref |
|----|---------|------------|--------|----------------------------------|----------|
| A.7.1 | Physical security perimeters | N/A | N/A | Cloud provider responsibility (A.5.23) | — |
| A.7.2 | Physical entry | N/A | N/A | Cloud provider responsibility | — |
| A.7.3 | Securing offices, rooms and facilities | N/A | N/A | No on-premise TM infrastructure | — |
| A.7.4 | Physical security monitoring | N/A | N/A | Cloud provider responsibility | — |
| A.7.5 | Protecting against physical and environmental threats | N/A | N/A | Cloud provider responsibility | — |
| A.7.6 | Working in secure areas | N/A | N/A | No secure areas for TM systems | — |
| A.7.7 | Clear desk and clear screen | Yes | Partial | AUP references screen lock; not enforced | — |
| A.7.8 | Equipment siting and protection | N/A | N/A | Cloud-hosted servers | — |
| A.7.9 | Security of assets off-premises | Yes | Partial | AUP device encryption requirement for prod access | — |
| A.7.10 | Storage media | N/A | N/A | No removable media for TM data stores | — |
| A.7.11 | Supporting utilities | N/A | N/A | Cloud provider responsibility | — |
| A.7.12 | Cabling security | N/A | N/A | Cloud provider responsibility | — |
| A.7.13 | Equipment maintenance | N/A | N/A | Cloud provider responsibility | — |
| A.7.14 | Secure disposal or re-use of equipment | Yes | Partial | AUP prohibits local PII storage; no disposal procedure | — |
*Note: A.7.7, A.7.9, A.7.14 remain applicable for personnel devices accessing TM systems.*
---
## 6. A.8 — Technological Controls
| ID | Control | Applicable | Status | Implementation / Justification | Risk Ref |
|----|---------|------------|--------|----------------------------------|----------|
| A.8.1 | User endpoint devices | Yes | Partial | AUP device requirements; no MDM | — |
| A.8.2 | Privileged access rights | Yes | Partial | Break-glass procedure; no PAM tool | R-020 |
| A.8.3 | Information access restriction | Yes | Yes | RBAC + company-scoped middleware (`pkg/authorization`) | R-003 |
| A.8.4 | Access to source code | Yes | Yes | Git repo with PR review; branch protection (assumed) | — |
| A.8.5 | Secure authentication | Yes | Partial | JWT, bcrypt, hCaptcha; MFA not yet enabled | R-001, R-002 |
| A.8.6 | Capacity management | Yes | Partial | Rate limit config; no capacity monitoring | R-012 |
| A.8.7 | Protection against malware | Yes | No | No malware scanning on uploads or endpoints | R-011 |
| A.8.8 | Management of technical vulnerabilities | Yes | No | No govulncheck/SAST in CI | R-010 |
| A.8.9 | Configuration management | Yes | Partial | `pkg/config` env priority; secrets in flat env files | R-013 |
| A.8.10 | Information deletion | Yes | Partial | Domain delete operations; no retention/deletion policy | R-007 |
| A.8.11 | Data masking | Yes | No | Passwords excluded from API responses; no masking elsewhere | — |
| A.8.12 | Data leakage prevention | Yes | No | No DLP tooling | R-008 |
| A.8.13 | Information backup | Yes | Partial | [Backup & Recovery Policy](./policies/backup-and-recovery-policy.md); tests not yet run | R-006, R-014 |
| A.8.14 | Redundancy of information processing facilities | Yes | Partial | Depends on cloud provider HA; not documented | R-014 |
| A.8.15 | Logging | Yes | Yes | Structured service logging; `pkg/audit` for security events | R-008, R-015 |
| A.8.16 | Monitoring activities | Yes | Partial | Application logs only; no SIEM or alerting | R-015 |
| A.8.17 | Clock synchronization | Yes | Partial | NTP assumed on cloud hosts; not verified | — |
| A.8.18 | Use of privileged utility programs | Yes | Partial | DB admin tools restricted; no formal policy | R-020 |
| A.8.19 | Installation of software on operational systems | Yes | Partial | Container/deploy pipeline; no formal whitelist | R-016 |
| A.8.20 | Networks security | Yes | Partial | HTTPS in prod; DB not public; no documented network diagram | — |
| A.8.21 | Security of network services | Yes | Partial | TLS to external APIs; no network service inventory | — |
| A.8.22 | Segregation of networks | Yes | Partial | Dev/staging/prod separated; informal | — |
| A.8.23 | Web filtering | Yes | No | No web filtering for staff endpoints | — |
| A.8.24 | Use of cryptography | Yes | Partial | TLS in transit; at-rest encryption TBD | R-005 |
| A.8.25 | Secure development life cycle | Yes | Partial | `.cursorrules`, code review, Clean Architecture | — |
| A.8.26 | Application security requirements | Yes | Yes | Govalidator, XSS policy, Swagger, response standards | R-009 |
| A.8.27 | Secure system architecture and engineering principles | Yes | Partial | Clean Architecture, DI, no global state | — |
| A.8.28 | Secure coding | Yes | Partial | Coding standards documented; no SAST | R-009, R-010 |
| A.8.29 | Security testing in development and acceptance | Yes | No | Unit tests exist; no security test suite or DAST | R-009 |
| A.8.30 | Outsourced development | N/A | N/A | All TM backend development is in-house; no outsourced development of scoped applications | — |
| A.8.31 | Separation of development, test and production environments | Yes | Partial | Separate env configs; staging data may contain real data | — |
| A.8.32 | Change management | Yes | Partial | Git PR workflow; no formal change procedure | R-022 |
| A.8.33 | Test information | Yes | Partial | Staging should use anonymized data; not enforced | — |
| A.8.34 | Protection of information systems during audit testing | Yes | No | No audit testing procedure | — |
---
## 7. Summary Statistics
Counts derived from the control rows in §3–§6 (authoritative source for cross-document reporting).
### 7.1 By Theme
| Theme | Total | Implemented (Yes) | Partial | Not impl. (No) | N/A |
|-------|-------|-------------------|---------|----------------|-----|
| **A.5** Organizational | 37 | 2 | 25 | 10 | 0 |
| **A.6** People | 8 | 0 | 6 | 2 | 0 |
| **A.7** Physical | 14 | 0 | 3 | 0 | 11 |
| **A.8** Technological | 34 | 4 | 22 | 7 | 1 |
| **Total** | **93** | **6** | **56** | **19** | **12** |
### 7.2 Overall
| Category | Count | % of all 93 |
|----------|-------|-------------|
| Total Annex A controls | 93 | 100% |
| Not applicable (N/A) | 12 | 13% |
| **Applicable** | **81** | **87%** |
| Implemented (Yes) | 6 | 6% |
| Partial | 56 | 60% |
| Not implemented (No) | 19 | 20% |
*Applicable = Total − N/A. Yes/Partial/No counts apply only to applicable controls (6 + 56 + 19 = 81).*
### 7.3 Applicable Controls by Status
Percentages below are of **81 applicable** controls (excluding 12 N/A).
```
Implemented ██░░░░░░░░░░░░░░░░░░░░ 7% (6/81)
Partial █████████████████░░░░░ 69% (56/81)
Not impl. █████░░░░░░░░░░░░░░░░░ 23% (19/81)
```
---
## 8. Priority Remediation (Applicable "No" and Critical "Partial")
| Priority | Control(s) | Action | Target | Owner |
|----------|------------|--------|--------|-------|
| P0 | A.8.8 | Add govulncheck + dependency scanning to CI | Q2 2026 | Engineering |
| P0 | A.8.16 | Deploy centralized logging and alerting | Q3 2026 | DevOps |
| P0 | A.5.35, A.5.36 | Establish internal audit program | Q1 2027 | ISO |
| P1 | A.6.3 | Launch security awareness training | Q3 2026 | ISO |
| P1 | A.5.19–A.5.22 | Vendor security assessments | Q4 2026 | ISO |
| P1 | A.8.24 | Enable encryption at rest | Q3 2026 | DevOps |
| P1 | A.8.5 | Enable MFA for admin users | Q3 2026 | Engineering |
| P1 | A.8.29 | Add security testing to CI/CD | Q3 2026 | Engineering |
| P2 | A.5.5 | Document authority contacts (GDPR DPA) | Q3 2026 | DPO |
| P2 | A.8.7 | Malware scan on file uploads | Q4 2026 | Engineering |
| P2 | A.8.12 | Evaluate DLP for log pipeline | Q4 2026 | DevOps |
---
## 9. Exclusion Justifications
| Control(s) | Justification |
|------------|---------------|
| A.7.1–A.7.6, A.7.8, A.7.10–A.7.13 | TM infrastructure is fully cloud-hosted; physical controls are the responsibility of the cloud/IaaS provider per shared responsibility model. Evidence collected via A.5.23. |
| A.8.30 | All TM backend development is in-house; no outsourced development of scoped applications. |
---
## 10. Document Control
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | 2026-06-11 | Engineering | Initial SoA for 93 Annex A controls |
| 1.1 | 2026-06-11 | Engineering | Reconciled summary counts with control rows; fixed A.8.30 applicability |
**Approval**
| Role | Name | Signature | Date |
|------|------|-----------|------|
| ISO | _Pending_ | | |
| Executive Sponsor | _Pending_ | | |
**Next review:** Quarterly or upon significant scope/control change
---
## 11. Cross-Reference Index
| Document | Purpose |
|----------|---------|
| [GAP_ANALYSIS_REPORT.md](./GAP_ANALYSIS_REPORT.md) | Clause-level gap detail |
| [RISK_ASSESSMENT_MATRIX.md](./RISK_ASSESSMENT_MATRIX.md) | Risk IDs linked in SoA |
| [ISO27001_ROADMAP.md](./ISO27001_ROADMAP.md) | Remediation timeline |
| [policies/](./policies/) | Policy evidence for A.5.x controls |
docs/security/policies/acceptable-use-policy.md
+158
View File
@@ -0,0 +1,158 @@
# Acceptable Use Policy
| Field | Value |
|-------|-------|
| **Document ID** | POL-005 |
| **Version** | 1.0 |
| **Status** | Draft — Pending approval |
| **Owner** | Information Security Officer (ISO) |
| **Effective Date** | _Pending approval_ |
| **Review Cycle** | Annual |
| **ISO 27001 Reference** | A.6.2 — Terms and conditions of employment; A.5.10 — Acceptable use |
Related: [Information Security Policy](./information-security-policy.md) | [Access Control Policy](./access-control-policy.md)
---
## 1. Purpose
This policy defines acceptable and unacceptable use of Tender Management System resources, data, and infrastructure by employees, contractors, and third parties.
---
## 2. Scope
Applies to anyone who:
- Accesses TM production, staging, or development environments
- Handles TM source code, configuration, or customer/company data
- Uses company-issued or personal devices to perform TM-related work
- Integrates third-party services with TM APIs
---
## 3. Acceptable Use
Personnel **may**:
- Access systems and data required for their assigned role
- Use company-approved tools for development, testing, and deployment
- Store TM source code only in authorized Git repositories
- Use staging environments for testing with synthetic or anonymized data
- Report security concerns or suspected incidents without retaliation
- Work remotely using VPN/bastion access as configured by DevOps
---
## 4. Unacceptable Use
Personnel **must not**:
### 4.1 Data Handling
- Copy production PII to personal devices, unauthorized cloud storage, or local unencrypted files
- Share customer or company data with unauthorized persons
- Use production data for development/testing without anonymization approval
- Export bulk data without business justification and ISO approval
### 4.2 Credentials & Access
- Share passwords, API keys, JWT tokens, or SSH keys
- Commit secrets, credentials, or `.env` files with production values to Git
- Use personal accounts for production system access
- Bypass authentication, authorization, or audit controls
- Leave privileged sessions unattended
### 4.3 Systems & Network
- Install unauthorized software on production or staging servers
- Run penetration tests against production without written ISO approval
- Introduce malware, unauthorized scripts, or unvetted dependencies
- Disable security controls (logging, rate limiting, firewalls) without approval
- Mine cryptocurrency or use TM infrastructure for non-business purposes
### 4.4 Development Practices
- Push directly to production branches without peer review
- Deploy untested code to production
- Ignore critical security scan findings without documented risk acceptance
- Log passwords, tokens, or full PII in application logs
### 4.5 Third Parties
- Grant vendor access beyond minimum required scope
- Share API credentials with unauthorized integrators
- Use unapproved AI/LLM tools to process production customer data without DPO review
---
## 5. Device and Remote Work Requirements
| Requirement | Detail |
|-------------|--------|
| Screen lock | Enabled when unattended (≤ 5 min) |
| Full-disk encryption | Required on devices accessing production |
| OS updates | Security patches applied within 30 days |
| Antivirus | Company-approved endpoint protection where applicable |
| Public Wi-Fi | VPN required for production access |
---
## 6. Email and Communication
- Do not transmit passwords or API keys via email or chat
- Use approved secure channels for credential delivery
- Report phishing attempts to ISO immediately
---
## 7. Monitoring and Privacy
The organization reserves the right to monitor use of TM systems and company equipment to:
- Detect security incidents
- Ensure policy compliance
- Protect information assets
Monitoring is conducted in accordance with applicable privacy laws and employment agreements.
---
## 8. Consequences
Violations may result in:
| Severity | Consequence |
|----------|-------------|
| Minor / first offense | Written warning; mandatory retraining |
| Moderate | Suspension of access; formal disciplinary action |
| Severe (data breach, intentional misuse) | Termination; legal action; regulatory reporting |
All violations involving data exposure follow the [Incident Response Plan](./incident-response-plan.md).
---
## 9. Acknowledgment
All personnel must sign or electronically acknowledge this policy:
- Upon onboarding (before production access is granted)
- Annually thereafter
- When materially updated
Records retained by HR/ISO for **3 years**.
---
## 10. Document Control
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | 2026-06-11 | Engineering | Initial policy |
**Approval**
| Role | Name | Signature | Date |
|------|------|-----------|------|
| ISO | _Pending_ | | |
| Executive Sponsor | _Pending_ | | |
docs/security/policies/access-control-policy.md
+174
View File
@@ -0,0 +1,174 @@
# Access Control Policy
| Field | Value |
|-------|-------|
| **Document ID** | POL-002 |
| **Version** | 1.0 |
| **Status** | Draft — Pending approval |
| **Owner** | Information Security Officer (ISO) |
| **Effective Date** | _Pending approval_ |
| **Review Cycle** | Annual |
| **ISO 27001 Reference** | A.5.15–A.5.18 — Access control |
Related: [Information Security Policy](./information-security-policy.md) | [ISMS Foundation §4](../ISMS_FOUNDATION.md#4-information-asset-inventory)
---
## 1. Purpose
This policy defines requirements for granting, reviewing, modifying, and revoking access to Tender Management System resources, ensuring that only authorized individuals and services can access information based on business need.
---
## 2. Scope
Applies to access for:
- **Admin users** — internal operators of the admin panel (`/admin/v1`)
- **Customer users** — company representatives using the mobile/public API (`/api/v1`)
- **Service accounts** — worker, scraper, CI/CD, and integration credentials
- **Infrastructure access** — MongoDB, Redis, MinIO, deployment environments
---
## 3. Access Control Principles
1. **Least privilege** — minimum access required for the role
2. **Need-to-know** — access limited to data required for the task
3. **Separation of duties** — no single person holds unrestricted production access without oversight
4. **Default deny** — access is denied unless explicitly granted
5. **Accountability** — all access is attributable to an individual or service identity
---
## 4. User Access Management
### 4.1 Account Provisioning
| Step | Requirement |
|------|-------------|
| Request | Access request submitted by manager with role justification |
| Approval | ISO or Engineering Lead approves based on role matrix |
| Creation | Account created with default-deny; only required permissions assigned |
| Notification | User receives credentials via secure channel (never email plaintext passwords) |
| Recording | Access grant logged in access register |
### 4.2 Role Matrix — Application Users
| Role | System | Permissions |
|------|--------|-------------|
| **Admin** | Admin panel API | Full CRUD on users, companies, tenders, CMS, notifications |
| **Customer Admin** | Public API | Manage company profile, customers within company, view matched tenders |
| **Customer Analyst** | Public API | View tenders, submit feedback; no user management |
| **Service: Web API** | MongoDB, Redis, MinIO | Read/write per domain; no direct admin DB access |
| **Service: Worker** | MongoDB, MinIO, AI API | Read/write tenders; invoke translation jobs |
| **Service: Scraper** | MongoDB, TED source | Write tenders/notices only |
Technical enforcement: JWT role claims and middleware in `pkg/authorization`; company-scoped access for customer roles.
### 4.3 Role Matrix — Infrastructure
| Role | MongoDB | Redis | MinIO | Production Deploy |
|------|---------|-------|-------|-------------------|
| Developer | Staging read/write | Staging | Staging | No |
| DevOps | Prod read (break-glass write) | Prod | Prod | Yes (with approval) |
| ISO | Audit read-only | No | No | No |
Production database write access requires break-glass procedure (§7).
### 4.4 Account Modification
- Role changes require re-approval by manager and ISO
- Privilege elevation is temporary where possible (time-limited tokens)
### 4.5 Account Deprovisioning
Access must be revoked **within 24 hours** of:
- Employment or contract termination
- Role change removing need for access
- Extended leave (>30 days) for privileged accounts
Checklist: disable admin user account, revoke JWT/refresh tokens (Redis blacklist), remove SSH/infra access, rotate shared secrets if exposed.
---
## 5. Authentication Requirements
### 5.1 Human Users
| Requirement | Admin Users | Customer Users |
|-------------|-------------|----------------|
| Unique account | Mandatory | Mandatory |
| Password complexity | Min 12 chars; mixed case, number, symbol | Min 8 chars; mixed case, number |
| Password storage | bcrypt hash (never plaintext) | bcrypt hash (never plaintext) |
| MFA | Required (target: Q3 2026) | Recommended |
| Session/token TTL | Access token ≤ 15 min; refresh rotation | Access token ≤ 1 h; refresh rotation |
| Failed login lockout | 5 attempts / 15 min lockout | 5 attempts / 15 min lockout |
| hCaptcha | On registration and password reset | On registration and password reset |
### 5.2 Service Accounts
- Unique credentials per service and environment
- Stored in secret manager (not `.env` in production)
- Rotated at least annually or on personnel change
- No shared passwords between services
### 5.3 API Authentication
- All protected endpoints require valid JWT in `Authorization: Bearer` header
- Public endpoints limited to explicitly whitelisted routes (health, public tender list, contact form with hCaptcha)
---
## 6. Access Reviews
| Review Type | Frequency | Reviewer | Scope |
|-------------|-----------|----------|-------|
| Admin user accounts | Quarterly | ISO + Engineering Lead | All active admin users |
| Customer admin accounts | Semi-annual | Product Owner | Accounts inactive >90 days |
| Infrastructure access | Quarterly | DevOps Lead | SSH, DB, MinIO, CI/CD |
| Service account credentials | Semi-annual | DevOps Lead | All non-human identities |
Findings are documented and remediated within 30 days.
---
## 7. Break-Glass Access
Emergency production access when normal procedures cannot meet operational need:
1. Request logged in incident/ticket system with justification
2. Approved by DevOps Lead or ISO (second approver if requester is DevOps Lead)
3. Time-limited (maximum 4 hours)
4. All actions logged and reviewed within 48 hours post-event
5. Credentials rotated if break-glass credentials were used
---
## 8. Remote Access
- Production infrastructure accessible only via VPN or bastion host
- No direct public exposure of MongoDB, Redis, or MinIO ports
- Admin panel and API served over HTTPS only in production
---
## 9. Violations
Unauthorized access attempts, credential sharing, or bypassing access controls must be reported immediately per the [Incident Response Plan](./incident-response-plan.md).
---
## 10. Document Control
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | 2026-06-11 | Engineering | Initial policy |
**Approval**
| Role | Name | Signature | Date |
|------|------|-----------|------|
| ISO | _Pending_ | | |
| Executive Sponsor | _Pending_ | | |
docs/security/policies/backup-and-recovery-policy.md
+172
View File
@@ -0,0 +1,172 @@
# Backup & Recovery Policy
| Field | Value |
|-------|-------|
| **Document ID** | POL-004 |
| **Version** | 1.0 |
| **Status** | Draft — Pending approval |
| **Owner** | DevOps Lead |
| **Maintained By** | DevOps Lead |
| **Effective Date** | _Pending approval_ |
| **Review Cycle** | Annual |
| **ISO 27001 Reference** | A.8.13 — Information backup |
Related: [Information Security Policy](./information-security-policy.md) | [Incident Response Plan](./incident-response-plan.md)
---
## 1. Purpose
This policy defines backup requirements, retention periods, and recovery objectives for Tender Management System data to ensure business continuity and data protection.
---
## 2. Scope
Covers backup and recovery for:
| Asset | ID | Backup Method |
|-------|-----|---------------|
| MongoDB (`tm` database) | A-001 | Automated snapshots / mongodump |
| MinIO object storage | A-003 | Bucket replication or periodic sync |
| Redis | A-002 | RDB snapshots (cache — lower priority) |
| Application configuration | A-010 | Version-controlled templates; secrets in vault |
| Application logs | A-011 | Log aggregator retention |
---
## 3. Recovery Objectives
| Metric | Definition | Target |
|--------|------------|--------|
| **RTO** (Recovery Time Objective) | Maximum acceptable downtime | **4 hours** (production API) |
| **RPO** (Recovery Point Objective) | Maximum acceptable data loss | **1 hour** (MongoDB); **24 hours** (MinIO documents) |
RTO/RPO are reviewed annually and after major architecture changes.
---
## 4. Backup Requirements
### 4.1 MongoDB
| Parameter | Requirement |
|-----------|-------------|
| Frequency | Continuous oplog / hourly snapshots (production) |
| Retention | Daily: 30 days; Weekly: 12 weeks; Monthly: 12 months |
| Storage | Separate region/account from production |
| Encryption | Encrypted at rest (AES-256 or provider equivalent) |
| Access | DevOps Lead + break-glass only |
**Collections in scope:** `companies`, `customers`, `users`, `tenders`, `notices`, `feedback`, `notifications`, and all domain collections.
### 4.2 MinIO
| Parameter | Requirement |
|-----------|-------------|
| Frequency | Daily incremental; weekly full sync |
| Retention | 30 days rolling |
| Scope | `files` and `documents` buckets (company docs, tender JSON, translations) |
| Encryption | Server-side encryption enabled |
| Versioning | Bucket versioning enabled where supported |
### 4.3 Redis
| Parameter | Requirement |
|-----------|-------------|
| Frequency | Daily RDB snapshot |
| Retention | 7 days |
| Note | Redis holds ephemeral cache/session data; rebuild acceptable within RTO |
### 4.4 Configuration & Secrets
- Infrastructure-as-code and config templates in Git
- Production secrets in secret manager (not backed up in plaintext)
- Secret manager backup per provider documentation
---
## 5. Backup Security
1. Backups classified **C3 Confidential** — same protection as source data
2. Backup storage not publicly accessible
3. Backup access logged and restricted to authorized DevOps personnel
4. Backup encryption keys managed separately from backup data
5. No backup data transferred to unauthorized regions (GDPR data residency compliance)
---
## 6. Recovery Procedures
### 6.1 MongoDB Full Restore
1. Identify target recovery point (timestamp before incident)
2. Provision clean MongoDB instance or restore to staging first
3. Restore from snapshot / mongodump
4. Verify document counts and sample integrity checks
5. Update application connection string
6. Run application smoke tests (auth, tender list, company profile)
7. Monitor for 24 hours post-restore
### 6.2 MinIO Restore
1. Identify affected buckets/prefixes
2. Restore from backup or cross-region replica
3. Verify file accessibility via file store service
4. Re-run worker jobs for any missing derived data (translations)
### 6.3 Partial Restore (Single Collection / Document)
- Use point-in-time recovery or selective mongorestore
- Requires IC approval for production partial restores
- Audit log entry required
---
## 7. Backup Testing
| Test | Frequency | Success Criteria |
|------|-----------|------------------|
| MongoDB restore to staging | **Monthly** | Data integrity verified; app connects successfully |
| MinIO file restore (sample) | **Quarterly** | Random files readable and checksum-valid |
| Full DR simulation | **Annual** | RTO/RPO met in tabletop or live test |
| Backup job monitoring | **Daily** | All scheduled backups complete without error |
Test results documented with date, tester, outcome, and remediation items.
---
## 8. Responsibilities
| Role | Responsibility |
|------|----------------|
| DevOps Lead | Implement and monitor backups; conduct restore tests |
| ISO | Verify policy compliance; include backup status in management review |
| Engineering Lead | Validate application behavior post-restore |
| IC (during incident) | Authorize production restore; communicate status |
---
## 9. Failure Handling
If a scheduled backup fails:
1. Automated alert to DevOps on-call
2. Investigate and re-run within **4 hours**
3. If unrecoverable, escalate to P2 incident if production data at risk
4. Document failure and resolution in backup log
---
## 10. Document Control
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | 2026-06-11 | Engineering | Initial policy |
**Approval**
| Role | Name | Signature | Date |
|------|------|-----------|------|
| DevOps Lead | _Pending_ | | |
| ISO | _Pending_ | | |
docs/security/policies/incident-response-plan.md
+222
View File
@@ -0,0 +1,222 @@
# Incident Response Plan
| Field | Value |
|-------|-------|
| **Document ID** | POL-003 |
| **Version** | 1.0 |
| **Status** | Draft — Pending approval |
| **Owner** | Information Security Officer (ISO) |
| **Effective Date** | _Pending approval_ |
| **Review Cycle** | Annual (+ after every P1/P2 incident) |
| **ISO 27001 Reference** | A.5.24–A.5.28 — Incident management |
Related: [Information Security Policy](./information-security-policy.md) | [Risk Assessment Matrix](../RISK_ASSESSMENT_MATRIX.md)
---
## 1. Purpose
This plan defines how the organization detects, responds to, contains, and recovers from information security incidents affecting the Tender Management System. It ensures consistent handling, timely notification, and post-incident improvement.
---
## 2. Scope
Covers security incidents involving:
- Unauthorized access to TM systems or data
- Data breaches (PII exposure)
- Malware or ransomware
- Denial of service affecting production
- Secret/credential leakage
- Insider threats
- Third-party service compromises affecting TM
---
## 3. Incident Classification
| Severity | Label | Criteria | Response Time |
|----------|-------|----------|---------------|
| **P1** | Critical | Active data breach; production down; credential leak in public repo | Acknowledge ≤ 1 h; escalate immediately |
| **P2** | High | Suspected breach; partial outage; unpatched critical CVE exploited | Acknowledge ≤ 4 h |
| **P3** | Medium | Failed attack attempt; non-production compromise; policy violation | Acknowledge ≤ 1 business day |
| **P4** | Low | Near-miss; informational alert; minor misconfiguration | Acknowledge ≤ 3 business days |
---
## 4. Incident Response Team (IRT)
| Role | Responsibility | Primary | Backup |
|------|----------------|---------|--------|
| **Incident Commander (IC)** | Overall coordination, decisions, communications | ISO | Engineering Lead |
| **Technical Lead** | Investigation, containment, remediation | DevOps Lead | Senior Backend Dev |
| **Communications Lead** | Internal/external notifications, status updates | Product Owner | Executive Sponsor |
| **Legal / DPO** | Regulatory notification, GDPR assessment | DPO | External counsel |
| **Scribe** | Timeline, evidence, post-incident report | Assigned per incident | — |
Contact list maintained separately (not in repository) with 24/7 reachability for P1/P2.
---
## 5. Response Phases
```
Detect → Triage → Contain → Eradicate → Recover → Learn
```
### 5.1 Detect & Report
**Anyone** who suspects an incident must report immediately via:
1. Direct message to ISO or DevOps Lead
2. Dedicated security channel (e.g. `#security-incidents`)
3. Email: `security@<company-domain>` (to be configured)
Do **not** discuss suspected breaches on public channels until IC approves.
**Automated detection sources (target state):**
- SIEM alerts (auth failure spikes, error rate anomalies)
- Secret scanning in CI
- Dependency vulnerability alerts
- Cloud provider security notifications
- User/customer reports
### 5.2 Triage
IC performs within response time SLA:
1. Confirm or rule out incident
2. Assign severity (P1–P4)
3. Activate IRT if P1/P2
4. Open incident ticket with unique ID: `INC-YYYY-NNN`
5. Begin incident timeline log
### 5.3 Contain
Short-term actions to limit damage:
| Scenario | Containment Actions |
|----------|---------------------|
| Compromised admin account | Disable account; revoke JWT; force password reset |
| Leaked API key / secret | Rotate credential; invalidate old tokens; audit access logs |
| Active data exfiltration | Block IP/rate limit; disable affected endpoint; snapshot logs |
| Ransomware / malware | Isolate affected hosts; preserve forensic images |
| DDoS | Enable WAF/CDN rules; rate limiting; contact provider |
Preserve evidence: do not delete logs; snapshot affected systems before remediation where feasible.
### 5.4 Eradicate
- Remove attacker access (patch vulnerability, close misconfiguration)
- Scan for persistence (backdoors, unauthorized accounts)
- Verify root cause is addressed
### 5.5 Recover
- Restore services from clean backups if needed
- Monitor for recurrence (enhanced logging, 72-hour watch period)
- Confirm normal operation with smoke tests
- Communicate all-clear to stakeholders
### 5.6 Post-Incident Review (Learn)
Required for all P1/P2 incidents within **10 business days**:
- Timeline reconstruction
- Root cause analysis
- Control gaps identified
- Corrective/preventive actions with owners and dates
- Update [Risk Assessment Matrix](../RISK_ASSESSMENT_MATRIX.md) if new risks identified
- Tabletop or walkthrough if process gaps found
---
## 6. Communication Plan
### 6.1 Internal
| Severity | Notify |
|----------|--------|
| P1 | IRT, Executive Sponsor, all engineering — immediately |
| P2 | IRT, Engineering Lead, DevOps — within 4 h |
| P3 | ISO, relevant team lead — within 1 business day |
| P4 | ISO — log only |
### 6.2 External
| Condition | Action | Timeline |
|-----------|--------|----------|
| Personal data breach (GDPR) | Notify supervisory authority | ≤ 72 hours of awareness |
| Personal data breach (high risk to individuals) | Notify affected data subjects | Without undue delay |
| Contractual obligation | Notify affected customers | Per contract terms |
| Public disclosure | Press/ status page | IC approval only |
DPO assesses GDPR notification requirement for any incident involving customer/company PII (assets A-004, A-005).
---
## 7. Evidence Handling
- Logs exported and stored in tamper-evident location
- Chain of custody documented for forensic artifacts
- Incident records retained for **3 years** minimum
- Access to incident evidence restricted to IRT and Legal/DPO
---
## 8. Playbooks
### 8.1 Credential Leak in Git Repository
1. **Contain:** Revoke/rotate leaked secret immediately
2. **Eradicate:** Remove secret from git history (`git filter-repo` or BFG); force push with approval
3. **Investigate:** Audit usage logs for unauthorized access during exposure window
4. **Recover:** Deploy rotated credentials; verify services operational
5. **Learn:** Enable secret scanning in CI; review commit practices
*Applies to risk R-013; FCM keys and MinIO credentials are high priority.*
### 8.2 Suspected Unauthorized Admin Access
1. Disable affected admin account(s)
2. Blacklist active JWTs in Redis
3. Review `pkg/audit` logs for anomalous actions
4. Force password reset and enable MFA
5. RBAC audit of actions performed during compromise window
### 8.3 Production API Outage (Security-Related)
1. Determine if attack-related (DoS) vs. infrastructure failure
2. If DoS: enable rate limiting, WAF rules, scale resources
3. If compromise: isolate, preserve logs, follow containment playbook
4. Status communication via Communications Lead
---
## 9. Testing and Training
| Activity | Frequency |
|----------|-----------|
| Tabletop exercise (simulated P1) | Annual |
| Contact list verification | Quarterly |
| Playbook review | Annual or after P1/P2 |
| Security awareness (incident reporting) | Onboarding + annual |
First tabletop exercise target: **Q2 2026** (per [Risk R-023](../RISK_ASSESSMENT_MATRIX.md)).
---
## 10. Document Control
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | 2026-06-11 | Engineering | Initial plan |
**Approval**
| Role | Name | Signature | Date |
|------|------|-----------|------|
| ISO | _Pending_ | | |
| Executive Sponsor | _Pending_ | | |
docs/security/policies/information-security-policy.md
+156
View File
@@ -0,0 +1,156 @@
# Information Security Policy
| Field | Value |
|-------|-------|
| **Document ID** | POL-001 |
| **Version** | 1.0 |
| **Status** | Draft — Pending approval |
| **Owner** | Executive Sponsor |
| **Maintained By** | Information Security Officer (ISO) |
| **Effective Date** | _Pending approval_ |
| **Review Cycle** | Annual |
| **ISO 27001 Reference** | A.5.1 — Policies for information security |
Related: [ISMS Foundation](../ISMS_FOUNDATION.md) | [ISO 27001 Roadmap](../ISO27001_ROADMAP.md)
---
## 1. Purpose
This policy establishes the organization's commitment to protecting information assets processed by the **Tender Management (TM) System**. It defines principles, responsibilities, and requirements that all personnel, contractors, and third parties must follow.
---
## 2. Scope
This policy applies to:
- All employees, contractors, and third parties with access to TM systems or data
- The ISMS scope defined in [ISMS Foundation §3](../ISMS_FOUNDATION.md#3-isms-scope): `cmd/web`, `cmd/worker`, `cmd/scraper`, MongoDB, Redis, MinIO, and integrated services
- All information classified C2 (Internal) and above
---
## 3. Policy Statement
Management is committed to:
1. **Protecting** the confidentiality, integrity, and availability of information assets
2. **Complying** with applicable legal and regulatory requirements, including GDPR
3. **Implementing** an ISMS aligned with ISO/IEC 27001:2022
4. **Managing** information security risks through a documented risk assessment process
5. **Continuously improving** security controls via the Plan-Do-Check-Act (PDCA) cycle
Information security is everyone's responsibility. No business objective justifies unacceptable risk to customer data or system integrity without documented risk acceptance by authorized management.
---
## 4. Information Security Objectives
| # | Objective | Measure | Target |
|---|-----------|---------|--------|
| O-1 | Protect customer and company PII | Data breach incidents | Zero confirmed breaches per year |
| O-2 | Maintain platform availability | Uptime of production API | ≥ 99.5% monthly |
| O-3 | Respond to security incidents promptly | P1 incident acknowledgment time | ≤ 1 hour |
| O-4 | Remediate critical vulnerabilities | Mean time to patch (Critical CVE) | ≤ 7 days |
| O-5 | Maintain security awareness | Training completion rate | 100% of in-scope personnel |
| O-6 | Progress toward ISO 27001 certification | Roadmap milestone completion | Per [ISO27001_ROADMAP.md](../ISO27001_ROADMAP.md) |
Objectives are reviewed quarterly during management review.
---
## 5. Roles and Responsibilities
| Role | Responsibilities |
|------|------------------|
| **Executive Sponsor** | Approves this policy; allocates resources; chairs management review |
| **Information Security Officer (ISO)** | Operates ISMS; maintains risk register; coordinates audits and incidents |
| **Data Protection Officer (DPO)** | Ensures GDPR compliance; oversees DPIAs and data subject requests |
| **Engineering Lead** | Secure SDLC; code review; vulnerability remediation |
| **DevOps Lead** | Infrastructure security; secrets management; backups and monitoring |
| **All personnel** | Comply with policies; report incidents; complete security training |
---
## 6. Core Security Principles
### 6.1 Confidentiality
- Access to information is granted on a need-to-know basis
- PII and credentials must not be disclosed to unauthorized parties
- Secrets must never be committed to source control or included in logs
### 6.2 Integrity
- Production changes require peer review and follow change management procedures
- Data modifications must be traceable through audit logs where applicable
- Input validation is mandatory at all API boundaries
### 6.3 Availability
- Critical services (API, database, object storage) must have documented recovery procedures
- Capacity and rate limiting must protect against abuse-related outages
### 6.4 Defense in Depth
Security controls are layered across application, infrastructure, and process levels. No single control is relied upon exclusively.
### 6.5 Least Privilege
Users, services, and processes receive the minimum access required to perform their function.
---
## 7. Supporting Policies and Procedures
This policy is supported by:
| Document | ID |
|----------|-----|
| [Access Control Policy](./access-control-policy.md) | POL-002 |
| [Incident Response Plan](./incident-response-plan.md) | POL-003 |
| [Backup & Recovery Policy](./backup-and-recovery-policy.md) | POL-004 |
| [Acceptable Use Policy](./acceptable-use-policy.md) | POL-005 |
| [Risk Assessment Procedure](../procedures/risk-assessment-procedure.md) | PROC-001 |
---
## 8. Compliance and Enforcement
- Violations of this policy may result in disciplinary action, up to and including termination of employment or contract
- Regulatory breaches may result in legal liability and notification to supervisory authorities
- All personnel must acknowledge this policy upon onboarding and annually thereafter
---
## 9. Exceptions
Exceptions to this policy require:
1. Written request with business justification
2. Risk assessment of the exception
3. Approval by ISO and Executive Sponsor
4. Time-bound validity (maximum 12 months)
5. Entry in the risk acceptance log ([Risk Assessment Matrix §5](../RISK_ASSESSMENT_MATRIX.md#5-risk-acceptance-log))
---
## 10. Document Control
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | 2026-06-11 | Engineering | Initial policy |
**Approval**
| Role | Name | Signature | Date |
|------|------|-----------|------|
| Executive Sponsor | _Pending_ | | |
| ISO | _Pending_ | | |
---
## 11. Distribution
This policy is available to all in-scope personnel via the `docs/security/policies/` repository path and must be communicated during onboarding.
docs/security/procedures/risk-assessment-procedure.md
+177
View File
@@ -0,0 +1,177 @@
# 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_ | | |