# 18 Operations security policy: logging, monitoring, vulnerabilities and patching

| | |
| --- | --- |
| Version | 0.1 draft |
| Owner | Infrastructure Owner |
| Review | Yearly |
| Applies to | Every in-scope host, container, database and application |

## Logging

1. Every in-scope system sends logs to the central log platform: OS authentication and sudo, SSH, audit daemon, firewall, web server and edge, application, database errors and connections, deploys (OPS-01).
2. Applications write an audit log line for sign-in, sign-out, failed sign-in, MFA change, password reset, role and permission change, data export, deletion, administrative action, and API key creation. The line has the time in UTC, actor, action, target, result and source address.
3. Logs never contain passwords, tokens, card data, health data, message bodies, file contents or children's data (playbook red line 8).
4. Retention is 1 year in India; at least 180 days for CERT-In. Logs are append-only for everyone except the platform's retention job.
5. Clocks on every host synchronise to a reliable time source (CERT-In requires NTP sync to NIC or NPL servers, or traceable equivalents).

## Monitoring and alerting

1. Alerts fire for: repeated failed sign-ins and new admin sign-ins, privilege changes, health check failures, 5xx rate above baseline, certificate expiry within 14 days, disk above 85 percent, database connection saturation, backup failure, restore test failure, and scanner critical findings (OPS-02, AVL-01).
2. Alerts go to a private paging channel that reaches a human within 15 minutes during the on-call window. Public notification topics are not used for alerts.
3. External uptime monitoring checks every in-scope public endpoint from outside the network every minute (AVL-02).
4. A probe that cannot run reports "unknown", never "ok". An alert that has been unknown for an hour raises its own alert.

## Vulnerability management

1. Dependency scanning on every PR and weekly on the default branch. Container image scanning on build. Host vulnerability scanning weekly (OPS-03).
2. Fix within: **critical 7 days, high 30 days, medium 90 days**. A finding that will miss its window needs a risk acceptance under [10](/soc2/10-information-security#exceptions).
3. An independent penetration test of the in-scope external surface runs yearly and after major architecture changes (MON-02). Findings become tickets with the same fix windows.
4. The trust-surface probe (`audit/probe.py`) runs monthly against every in-scope host (MON-04).
5. Reports from outside researchers arrive through security.txt and are handled under [20](/soc2/20-incident-response).

## Patching

1. Security updates install automatically on every host (unattended upgrades or the provider's equivalent).
2. Other OS, runtime and database updates are applied monthly through the change process; a reboot schedule is kept (OPS-04).
3. Unsupported operating systems, runtimes and databases are not used in production. End-of-life dates are tracked in the asset inventory.

## Malware

Hosts run only what the deploy pipeline put there. Uploads to in-scope products are type-checked, size-capped and scanned before they are served to anyone else (OPS-09). Endpoints run the OS's built-in protection.

## Capacity

CPU, memory, disk, database connections and queue depth are graphed and alerted. Capacity is reviewed quarterly against growth (AVL-01).