Operations security policy

How we keep our devices, servers and networks secure in daily operation. It applies to every employee, to every device used for work, and to all systems in the scope of the ISMS.

Annex A controls: 5.7, 8.1, 8.6, 8.7, 8.8, 8.9, 8.15, 8.16, 8.17, 8.20, 8.21, 8.22, 8.23, 8.34.

User endpoint devices (8.1)

Every laptop and desktop used for work, company-owned or your own, meets these rules (security):

• The disk is fully encrypted (disk encryption).
• The operating system and browser install security updates automatically, on a version their vendor still supports.
• The firewall is on.
• The screen locks automatically after at most 10 minutes without use, and by hand whenever you leave the device (lock your computer).
• The built-in malware protection of the operating system is on.
• Passwords live in Bitwarden, and 2FA is on wherever a service offers it.
• Company data does not go on USB drives.
• Developers may have local administrator rights.
• A lost or stolen device is reported at once as an incident (incident management policy).

Every quarter the Information Security Officer picks two employees at random. They send screenshots that show disk encryption, update status, firewall and screen lock settings. The result, and the fix for any deviation, is recorded in that quarter’s recurring task.

Protection against malware (8.7)

• Endpoints run the malware protection of their operating system, and software comes only from the distribution or the official vendor.
• Incoming mail passes the spam and phishing filter of our mail server. Employees learn to recognise phishing (scam and phishing emails) and flag suspicious mail as spam.
• Servers run only distribution packages and container images built from Git or pulled from official registries at a pinned version (image tags and pull policy).
• Renovate proposes a new dependency release only after a waiting period, so a compromised release is usually caught upstream before it reaches us (external dependencies).

Threat intelligence and technical vulnerabilities (5.7, 8.8)

• The Information Security Officer and Infrastructure subscribe to a vulnerability feed for the technologies we run (Stack Watch, with our stack selected: operating systems, container platform, Coolify, GitLab, Keycloak, databases, web servers and language runtimes). A relevant alert becomes an issue.
• Renovate reports known vulnerabilities in the dependencies of every scanned repository and labels the fixing update security. Projects that use static analysis, secret scanning or container scanning run them in their pipeline (secure development policy).
• The news round of every ISMS security meeting covers new threats and what they mean for us (awareness).
• Vulnerabilities are fixed in order of severity: critical ones within 7 days, high ones within 30 days, others in regular maintenance. When no fix exists yet, Infrastructure or the Project lead applies a mitigation, such as disabling a feature or restricting access, and the risk goes into the risk register.
• Servers install operating system security updates automatically and reboot in a maintenance window; CI runners drain their jobs first. A daily check reports pending updates and reboots per server as an issue.
• Platform software (GitLab, Coolify, Keycloak, Sentry, mail server) runs at a pinned version. Its upgrades follow the procedures in the infra repository.

Capacity management (8.6)

• Servers ship metrics to the central monitoring stack. Alert rules for disk, CPU, memory and load (for example disk use above 90%) post to Mattermost (monitoring).
• Infrastructure acts on capacity alerts by cleaning up, resizing or adding servers, and checks sustained disk growth in the daily maintenance check.
• The Project lead plans capacity for the expected growth of their product, using load tests for the busiest flows (testing).

Configuration management (8.9)

• The infra repository defines our infrastructure as code: Ansible roles for hosts, OpenTofu for Coolify resources and DNS, and the declared cloud firewall rules. Applications are deployed by Coolify from their Git repositories (deployments).
• Servers start from a standard image: Ubuntu LTS, installed and configured by the Ansible baseline role or the Coolify server hardening checklist. Developer containers start from a shared golden image.
• Configuration changes go through a merge request, as the change management policy describes. A manual change on a server is added to the infra repository, so the repository stays the source of truth. Drift checks compare the live configuration with the repository.
• Secrets are not stored in the repositories: they come from Bitwarden, the secret store or the environment variables of the deployment.

Logging (8.15)

• Servers and applications log events, errors and administrative activity. Logs are shipped to the central log store (Loki), which keeps them for 90 days. Sentry keeps application errors for 120 days.
• Keycloak records login and administrative events. GitLab keeps the history of every change, merge request and approval, and Coolify keeps a log of every deployment.
• Reading logs requires company SSO in Grafana or the credentials of the log store, and so does writing to it.
• Applications do not log passwords, tokens or more personal data than needed to trace an incident.

Monitoring activities (8.16)

• Prometheus alert rules cover host health, service availability, HTTPS probes and certificate expiry. Alertmanager posts alerts to the infrastructure alert channel in Mattermost and to the channel of the product concerned.
• An uptime monitor per company checks the public services from outside and publishes a status page (service status).
• Sentry reports application errors to the product team.
• Infrastructure follows the infrastructure alert channel and the Project lead follows the alerts of their product. An alert that may be a security event is handled through the incident management policy.

Clock synchronisation (8.17)

• Servers synchronise their clocks with NTP through the time service of the operating system. The monitoring stack records the synchronisation status of every server, so log timestamps from different systems can be compared.
• Endpoints use the automatic time setting of their operating system.

Network security (8.20, 8.21, 8.22)

• Every server blocks incoming traffic by default and opens only the ports its services need, through the host firewall or the cloud firewall. The rules are documented in the infra repository, each with the reason it exists.
• SSH accepts keys only, never passwords. Private SSH keys live in Bitwarden.
• Administrative dashboards, such as Coolify, and internal services are reachable only from the office network, the company VPN and addresses allowlisted by name.
• Public services use HTTPS only, with automatically renewed certificates; HTTP redirects to HTTPS. Internal web services sign in through company SSO with 2FA.
• Network services from suppliers, such as hosting, DNS and the office internet connection, are covered by the supplier management policy.
• Networks are segregated by purpose: production, staging and review run on separate servers; internal servers sit behind a firewall that admits only the office network, the VPN and allowlisted addresses; each company runs its products on its own Coolify team and servers; CI jobs and developer containers run isolated from their host.

Web filtering (8.23)

Browsers keep their built-in protection against phishing and malware sites switched on, such as Safe Browsing in Chrome and Firefox or SmartScreen in Edge. This is the web filtering for our remote, cloud-based work.

Protection during audit testing (8.34)

• Audits use read-only access and exports by default. Auditor accounts are temporary and removed after the audit.
• Technical tests on production systems, such as scans or penetration tests, are agreed in advance with Infrastructure and the Project lead: scope, a time window outside peak hours, and who monitors the systems during the test.

Responsibilities

• The Information Security Officer owns this policy, runs the quarterly endpoint check and keeps the vulnerability feed subscription.
• Infrastructure runs the servers, networks, monitoring, logging and configuration management, and fixes vulnerabilities in the platform.
• The Project lead fixes vulnerabilities in their product, follows its alerts and plans its capacity.
• Employees keep their devices compliant and report incidents.

Review: yearly by the Information Security Officer.