Risk Management Policy

1. Purpose

This policy establishes how Lever AI identifies security and privacy risks, decides what to do about them, and keeps those decisions visible until they are resolved. It gives the risk-management commitment in the Information Security Policy its operating form: a single risk register, a simple scoring scale, explicit treatment decisions with named owners, and a quarterly review. The process is deliberately lightweight — sized so that a founder-led team will actually run it, rather than aspirationally heavy and therefore ignored.

2. Scope

This policy covers risks to the confidentiality, integrity, and availability of the information and systems Lever AI operates, including risks to customer data, risks arising from the behaviour of the AI agent in customer environments, and risks arising from the company's vendors and subprocessors. It applies to all Lever AI personnel. General commercial risk is outside its scope.

3. Policy

3.1 The risk register

The company maintains one risk register. Each entry records: a plain-language description of the risk; the date raised and its source; a named owner; the likelihood and impact ratings and the resulting score (section 3.3); the treatment decision and its status (section 3.4); and the date of the last review. The register is the single place where known risks live: a risk that is not in the register is, for the purposes of this policy, not being managed.

3.2 Identifying risks

Risks enter the register from the company's normal work rather than from a separate assessment bureaucracy. The standing sources are:

• incident root-cause analyses performed under the Incident Response and Business Continuity Policy;
• customer security questionnaires and contractual due diligence, which regularly surface gaps worth managing;
• engagement and onboarding reviews, including issues observed while monitoring live customer runs;
• vulnerability findings that cannot be remediated within the targets of the Vulnerability Management Policy, and observations from log review under the Logging and Monitoring Policy;
• subprocessor onboarding and annual re-reviews under the Vendor and Third-Party Risk Management Policy;
• findings of the annual internal audit under the Internal Audit Policy; and
• significant changes to the business, the technology, the team, or the threat environment.

Any member of staff may raise a risk directly at any time, and is expected to.

3.3 Scoring — the 3×3 matrix

Each risk is rated for likelihood and impact on a three-point scale, and its score is the product of the two. Ratings are a considered judgement by the owner and the Founder, not a calculation exercise.

3.4 Treatment decisions

Every risk carries one explicit decision: treat (reduce it, with named actions), accept (carry it knowingly), transfer (place it with a party better able to hold it, for example a provider), or avoid (stop doing the thing that creates it). Acceptance of any risk requires the Founder's sign-off, is recorded with its rationale, is time-bound, and lapses unless re-affirmed at review — a risk is never accepted silently or indefinitely. Completed treatments are verified before a risk is closed, and closure is recorded with the evidence relied on.

3.5 Quarterly review

The Founder reviews the full register at least quarterly with the engineers involved. The review adds newly identified risks, re-scores anything that has changed, checks progress on every open treatment, re-affirms or lapses standing acceptances, and closes what has genuinely been resolved. The outcome of each review is recorded. The review may be held alongside the quarterly access review under the Access Control Policy, so that the two recurring disciplines reinforce each other rather than compete for time.

3.6 How the register connects to the rest of the programme

The register is deliberately wired into the two policies that generate and consume its content:

• Fed by incident response. Every incident root-cause analysis performed under the Incident Response and Business Continuity Policy is checked for residual risk: anything the fix does not fully resolve enters the register with an owner, so incidents leave a trace beyond their immediate remediation.
• Feeds internal audit — and is fed back by it. The register and its review history are a standing input to the annual internal audit under the Internal Audit Policy, which uses them to judge whether risk management is actually operating. In turn, every audit finding is entered into this register with an owner and target date, and is tracked to closure through the quarterly reviews.

4. Responsibilities

The Founder owns the risk register, chairs the quarterly review, and is the only person who can accept a risk on the company's behalf. Each risk has a named owner responsible for progressing its treatment. Every member of staff is responsible for raising risks they become aware of. Detailed security roles are set out in the Security Roles and Responsibilities document.

5. Exceptions

Exceptions to this policy require the Founder's written approval, a recorded rationale and compensating control, and an expiry date. Accepting an individual risk is not an exception to this policy — it is the process of section 3.4 working as designed.

6. Review

This policy is reviewed at least annually and after any significant change to the business, the service, or the threat environment. The register itself is reviewed quarterly under section 3.5.