Internal Audit Policy

1. Purpose

Policies that are never checked drift into fiction. This policy establishes Lever AI's internal audit: a recurring, recorded self-assessment of whether the company's security policies are current, whether practice matches what they say, and where the programme falls short of the external standards it is aligned to. Its output is not a report that sits in a drawer — every finding becomes a tracked entry in the company's risk register with an owner and a date.

2. Scope

The audit covers the entire Lever AI policy suite — the Information Security Policy and its supporting policies, and the extended suite of which this policy is part — together with the operating controls those policies mandate: access and credential management, change and deployment control, logging and telemetry, vendor management, data handling and retention, personnel controls, and the AI write-safety controls of the AI Governance Policy. It covers both Lever-operated systems and the company's working practices inside customer engagements.

3. Policy

3.1 The annual self-assessment

At least once a year the company performs a self-assessment against every policy in the suite. For each policy the assessment answers three questions: is the policy still accurate and current; is actual practice what the policy says it is; and can that be shown with evidence. Evidence is sampled from the records the controls themselves produce — quarterly access-review records, version-stamped deployment records and the version endpoint, test-suite results, the per-turn telemetry ledger and session transcripts, risk-register review records, subprocessor re-review records, and training completion records under the Security Awareness and Training Policy. A control that cannot show evidence is recorded as a finding, not excused.

3.2 Mapping to external standards

Each audit maintains and refreshes a mapping of the policy suite's controls to ISO/IEC 27001:2022 Annex A, recording for each Annex A control whether it is addressed, addressed with limitations, not applicable (with the reason), or a gap. The mapping is informed by the SOC 2 Trust Services Criteria where customers ask in those terms. The mapping is an alignment exercise: it identifies gaps honestly and feeds them into findings. It is not, and is never described as, certification.

3.3 Independence and segregation of duties

Where headcount allows, each area is audited by a founder or engineer who is not primarily responsible for the area being audited, so that no one solely marks their own work. Lever AI is a company of single-digit headcount, and this policy is honest about what that means: full auditor independence is not always possible, and there is no separate audit function. Where the same people who operate a control must also assess it, the compensating controls are mandatory: the assessment is grounded in the mechanical records listed in section 3.1 — version-stamped deploys, recorded test runs, the telemetry ledger, access-review records — rather than in self-attestation; the evidence consulted is cited in the audit record so the conclusion can be re-checked; and the full results are reviewed by the Founder, who is accountable for their honesty.

3.4 Findings and follow-up

Every finding is recorded with a severity, a named owner, and a target date, and is entered into the risk register under the Risk Management Policy, where the quarterly risk reviews track it to closure. Findings are closed only when the fix is verified, not when it is promised. A finding that is overdue, or that recurs at the next audit, is escalated to the Founder for a decision on record: fix it, re-plan it with a new date, or formally accept the risk under the Risk Management Policy.

3.5 Records

Each audit produces a dated record of its scope, the evidence examined, the Annex A mapping, the findings, and the Founder's review. Audit records are retained across audit cycles so that successive audits can be compared and recurring findings recognised. Summaries may be shared with customers under confidentiality at the Founder's discretion, always represented as what they are under section 3.6.

3.6 Relationship to external assurance

Lever AI holds no independent security certifications or attestations of its own. The audit described here is an internal self-assessment, and it is never represented — in questionnaires, sales conversations, or customer documents — as an external audit or a certification. Where certification-level assurance is relevant, the company relies on the published certifications of its subprocessors under the Vendor and Third-Party Risk Management Policy. If the company commissions external assurance — such as the annual third-party penetration test committed to in the Vulnerability Management Policy, or a future certification audit — the internal audit's records and Annex A mapping are the preparation for it, and the external results are triaged through the same findings process in section 3.4.

4. Responsibilities

The Founder is accountable for this policy: the Founder schedules the annual audit, assigns auditors under section 3.3, reviews the results, and decides escalations under section 3.4. Whoever performs an audit is responsible for grounding it in evidence and recording findings without softening them. Finding owners are responsible for closing their findings by the target date. 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. Deferring the annual audit is an exception and is recorded as such, with the new date committed at the time of deferral.

6. Review

This policy is reviewed at least annually and after any significant change to the policy suite, the team, or the standards the company aligns to. Each audit cycle itself reviews whether this policy's process remains proportionate and effective.