Vulnerability Management Policy

1. Purpose

This policy defines how Lever AI learns of security vulnerabilities that affect its service, assesses how serious they are, and remediates them within defined timeframes. Its aim is that no known weakness is left unowned: every vulnerability the company becomes aware of is recorded, assigned a severity, and either fixed on schedule or explicitly risk-accepted with the Founder's sign-off. It supports the Information Security Policy and operates alongside the Secure Development (SDLC) Policy and the Change Management Policy.

2. Scope

This policy applies to all Lever AI personnel and to any contractor acting on the company's behalf. It covers the software the company writes and operates — the agent service, the MCP tool server, and the admin web interface — together with their third-party dependencies and the configuration of the Microsoft Azure infrastructure they run on. Defects and weaknesses discovered in a customer's platform during engagement work are in scope for handling and disclosure under section 3.6, although their remediation belongs to the platform vendor.

3. Policy

3.1 Sources of vulnerability intelligence

Lever AI monitors the following sources, which together are proportionate to a small company operating a fully managed cloud estate:

• Platform and provider advisories — security advisories published by the company's cloud and service providers (Microsoft Azure, Anthropic, GitHub) for the managed services the company relies on.
• Dependency alerts — the native dependency-vulnerability alerting of the company's source-control platform, which must be enabled on the private repositories that hold the service's code, covering the third-party packages the service is built from.
• Incident findings — weaknesses established by root-cause analysis under the Incident Response and Business Continuity Policy.
• Reports received — vulnerabilities reported by personnel, customers, or external parties, which are triaged through this policy like any other source.

The company does not currently operate a dedicated vulnerability-scanning platform beyond these sources and the cloud provider's platform defaults; this is stated plainly rather than implied otherwise. Adoption of additional automated scanning is a roadmap commitment to be revisited at each annual review as the company grows.

3.2 Triage and severity

Each vulnerability the company becomes aware of is recorded and assessed for whether it applies to the service and how exploitable it is in the service's actual configuration. It is then assigned a severity of Critical, High, Medium, or Low, informed by the reporter's or industry scoring (such as CVSS) but decided on Lever AI's own context — a vulnerability in a dependency the service does not exercise may be downgraded, and one that exposes customer data or credentials is never graded below High.

3.3 Remediation targets

Remediation is completed within the following targets, measured from the day Lever AI becomes aware of the vulnerability. The targets are maximums: fixes are made sooner where the risk warrants it, and a vulnerability known to be actively exploited is treated as a security incident under the Incident Response and Business Continuity Policy, whatever its nominal severity.

3.4 Remediation and verification

Fixes reach production only through the controls of the Change Management Policy: version control, the mandatory offline behaviour test suite, and the deploy gate, with every deployment version-stamped and attributable. Dependency updates are reviewed before adoption as required by the Secure Development (SDLC) Policy. Where a vulnerability was established by an incident, regression tests derived from the incident's own payloads are added to the release gate so the weakness cannot recur unnoticed. A vulnerability is closed only when the fix is confirmed deployed, not when a fix is merely identified.

Where a target genuinely cannot be met — for example when no fixed version of a dependency exists — the risk is either mitigated with a recorded compensating control or accepted through the exception process in section 5, and the acceptance is entered in the risk register maintained under the Risk Management Policy.

3.5 Penetration testing

Lever AI commits to commissioning an independent third-party penetration test of the service at least annually, covering the internet-facing service and its supporting infrastructure. No third-party penetration test has been performed as of the effective date of this policy; the first such test is a committed forward obligation under this policy, and this is stated plainly so that the company's customer-facing answers remain accurate. Findings from each test are triaged and remediated under the targets in section 3.3, and a summary of results and remediation status is made available to customers on request under confidentiality obligations.

3.6 Vulnerabilities in customer and third-party platforms

Weaknesses discovered in a customer's platform in the course of engagement work are disclosed responsibly to that platform's vendor and are not disclosed publicly or to other parties; their handling is coordinated under the Incident Response and Business Continuity Policy where customer data is at risk. For vulnerabilities in subprocessor services, the company relies on the provider's advisories and remediation, tracked under the Vendor and Third-Party Risk Management Policy, and applies any action required on its own side within the targets above.

3.7 Software inventory

The service's third-party components are fully enumerated in its dependency lockfiles, from which a software bill of materials can be generated on customer request.

4. Responsibilities

The Security Owner owns this policy, monitors the sources in section 3.1, triages and records vulnerabilities, and tracks remediation against the targets. The Engineering owner implements and deploys fixes through the change-management controls. The Founder approves any risk acceptance or exception. Every member of staff reports suspected vulnerabilities promptly and without blame.

5. Exceptions

Any exception to this policy — including exceeding a remediation target — must be requested in writing, assessed for risk, limited in time, approved by the Founder, and recorded together with the compensating controls that apply while it stands.

6. Review

This policy is reviewed at least annually and whenever there is a significant change to the service, its dependencies, or the threat environment. The document owner maintains its version history.