RM Compliance
llms.txt
SOC 2/Policies18

Operations security policy

Logging, monitoring, vulnerabilities and patching

Version0.1 draft
OwnerInfrastructure Owner
ReviewYearly
Applies toEvery in-scope host, container, database and application
Markdown

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.
  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.

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.