Logging and Monitoring Policy

1. Purpose

This policy defines what Lever AI records about the operation of its systems, how those records are protected and retained, and how they are reviewed so that security events can be detected, investigated, and evidenced. Its aim is an honest, durable, attributable record of what the service did, for whom, and under which version of the software. It is informed by ISO/IEC 27001:2022 Annex A and the SOC 2 Trust Services Criteria.

2. Scope

This policy applies to all Lever AI personnel and to any contractor or third party acting on the company's behalf. It covers all production systems the company operates in delivering its service — the agent service and MCP tool server on Microsoft Azure, their managed data stores, and the deployment pipeline — and the logs and telemetry those systems produce. Logs produced inside a customer's own infrastructure by the customer-hosted execution component remain in the customer's environment and under the customer's control.

3. Policy

3.1 What is logged

The following records are produced today and must be maintained:

New production components must produce application logging to at least this standard before release.

3.2 Log content and protection

Logs and telemetry must never contain credentials, tokens, keys, or other secrets; this is a hard rule, and any occurrence is treated as a security incident, with the exposed credential rotated. Logs record only what their purpose requires, and personal data in logs is minimised. Access to logs, the telemetry ledger, and transcripts is restricted on the least-privilege terms of the Access Control Policy and is included in the quarterly access review. Logs are written to durable managed stores and must not be altered or deleted outside the retention schedule; the deployment record's version stamping makes production activity attributable to the source and deploy that produced it. System clocks are synchronised by the cloud platform's time service, so records can be correlated reliably.

3.3 Retention

Application and audit logs are retained for 12 months and then deleted, unless a customer contract, a legal obligation, or an open incident investigation requires longer. Records that are also customer engagement data or operational telemetry — agent session transcripts and the per-turn telemetry ledger — follow the schedule in the Data Retention and Disposal Policy, which prevails where the two differ. Logs relevant to an incident are preserved under the Incident Response and Business Continuity Policy until the incident and any follow-up are closed.

3.4 Review and monitoring

Log review is engineer-driven: engineers examine logs, telemetry, and transcripts when investigating errors, anomalies, and suspected security events, and whenever an incident is raised. In addition, a monthly sweep of application logs, the telemetry ledger, and cloud platform logs is performed, looking for authentication anomalies, unexpected access patterns, error spikes, and signs of misuse; its completion and any observations are recorded. Lever engineers also monitor live onboarding runs while customer work is in flight. As a small, founder-led team, the engineers who review the logs are also those who operate the systems; strict separation of duties is not practicable at current headcount, and the compensating controls are the durable, attributable records themselves — version-stamped deploys, the per-turn ledger, and full transcripts — together with the recorded monthly sweep and the annual check under the Internal Audit Policy. Service availability is monitored against the company's 99% monthly availability commitment, set in the Incident Response and Business Continuity Policy; a breach of that commitment is handled as an incident under the same policy.

3.5 Alerting and tooling

Lever AI does not operate a SIEM today, and log review is not continuous or automated beyond the Azure platform's default capabilities; the company states this plainly rather than implying otherwise. Centralised log aggregation and automated alerting on security-relevant events is a committed item on the company's security roadmap, and this policy will be updated when it is in place. Anything found through review or monitoring that suggests a security event is reported and handled under the Incident Response and Business Continuity Policy, and systemic findings feed the risk register under the Risk Management Policy.

4. Responsibilities

The Security Owner owns this policy, ensures the monthly sweep happens and is recorded, and decides when a finding becomes an incident. The Engineering owner is responsible for the logging implementation, for keeping secrets out of logs, for the durability and retention of the log stores, and for the version stamping of deployments. All personnel are responsible for reporting anything anomalous they see in system behaviour or records without delay.

5. Exceptions

Any exception to this policy must be requested in writing, assessed for risk by the Security Owner, approved by the Founder, limited in time, and recorded with its scope and compensating controls. Exceptions are reviewed at each policy review and lapse at their end date unless re-approved. No exception may authorise writing credentials or tokens to logs.

6. Review

This policy is reviewed at least annually and whenever there is a significant change — including the introduction of centralised alerting, a new production component, or an incident that exposes a gap in what is logged. The document owner maintains its version history.