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

Add security and compliance documentation for ISO/IEC 27001

Browse Source 
- Introduced a comprehensive suite of security documents to support ISO/IEC 27001 certification, including the ISMS Foundation, Risk Assessment Matrix, Gap Analysis Report, Statement of Applicability, and ISO27001 Roadmap.
- Updated the README to include links to the new security documentation, enhancing the project's compliance framework and providing clear guidance on security policies and procedures.

This addition strengthens the overall security posture of the Tender Management System and aligns with industry standards for information security management.
This commit is contained in:
Mazyar
2026-06-11 01:53:24 +03:30
parent 4f05516fc2
commit 06e663b691
13 changed files with 2473 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
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.