# 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