Aventora Risk Assessment and Treatment Procedure
| Field | Value |
|---|---|
| Document Name | Risk Assessment and Treatment Procedure |
| Version | 1.0.1 |
| Effective Date | July 27, 2026 |
| Approval Date | August 1, 2026 |
| Last Reviewed | August 1, 2026 |
| Document Owner | Information Security Officer |
| Review Frequency | Annually; upon material changes to the risk methodology |
| Classification | Internal / Customer Shareable |
| Approval Status | Approved by Management — see Version History |
| Parent Policy | Information Security Risk Management Policy |
Document Control
This procedure defines Aventora’s methodology for assessing, scoring, treating, accepting, and reviewing information security and related risks under the Information Security Risk Management Policy.
This document describes governance and methodology suitable for customer and assessor review. Detailed risk register entries, scores for specific vulnerabilities, remediation status, and architecture weaknesses are maintained in internal restricted records and are not published here.
Aventora does not claim that all controls referenced as future treatment are currently operational. Planned controls are tracked in internal remediation and risk records.
RFC 2119 Terminology
The key words “MUST,” “MUST NOT,” “REQUIRED,” “SHALL,” “SHALL NOT,” “SHOULD,” “SHOULD NOT,” “RECOMMENDED,” “MAY,” and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
Approval
| Role | Name | Signature | Date |
|---|---|---|---|
| Management | Management | Approved | August 1, 2026 |
| Document Owner (Information Security Officer) | Information Security Officer | Approved | August 1, 2026 |
Table of Contents
- Purpose and Scope
- Definitions
- Risk Assessment Process
- Likelihood Scale
- Impact Scale
- Risk Score Calculation and Ratings
- Register Fields
- Treatment Decisions
- Treatment Planning Requirements
- Risk Acceptance Requirements
- Review Cadence and Triggers
- Milestone Categories for Target Dates
- Templates
- Related Documents
- Version History
1. Purpose and Scope
This procedure applies to the same in-scope systems as the parent policy:
- Engagement Hub (Aventora-Assistant);
- Aventora Admin; and
- Domain Assistant (
domain-chatbot);
including supporting cloud, application, privacy, third-party, resilience, and AI-related risks for those systems.
2. Definitions
| Term | Meaning |
|---|---|
| Inherent risk | Risk level before considering existing controls (or assuming controls are ineffective) |
| Existing controls | Controls currently implemented and operating that reduce likelihood or impact |
| Residual risk | Risk remaining after existing controls (and, where noted, expected effect of approved in-progress treatment) |
| Risk owner | Role accountable for the risk decision and residual risk posture |
| Control owner | Role responsible for operating or maintaining a material control |
| Treatment owner | Role responsible for completing mitigation/transfer/avoidance actions |
| Target treatment date | Date by which treatment actions are planned to complete |
| Risk acceptance | Documented Management decision to accept residual risk for a defined period |
| Review date | Date the risk was last formally reviewed |
| Evidence reference | Link or identifier for supporting artifacts (tickets, docs, configs, test results) |
3. Risk Assessment Process
For each risk, assessors MUST:
- Describe the risk, category, affected asset/service/process, threat, and vulnerability or exposure;
- Document existing controls honestly (do not treat planned controls as existing);
- Score inherent likelihood and impact;
- Select a treatment decision;
- Document planned mitigation and owners when treatment is Mitigate, Transfer, or Avoid;
- Score residual likelihood and impact;
- Set target dates using the milestone categories in Section 12;
- Record last and next review dates; and
- Link evidence references where available, or mark evidence as Planned / Pending Implementation.
High and Critical inherent or residual risks MUST be escalated to Management review.
4. Likelihood Scale
| Score | Rating | Guidance |
|---|---|---|
| 1 | Rare | May occur only in exceptional circumstances |
| 2 | Unlikely | Could occur, but not expected under normal operations |
| 3 | Possible | Might occur at some time |
| 4 | Likely | Will probably occur in most circumstances |
| 5 | Almost Certain | Expected to occur in most circumstances |
5. Impact Scale
| Score | Rating | Guidance (confidentiality, integrity, availability, privacy, contractual) |
|---|---|---|
| 1 | Negligible | Minimal operational or customer impact; easily contained |
| 2 | Minor | Limited impact; localized inconvenience or limited data exposure |
| 3 | Moderate | Noticeable customer, operational, or compliance impact |
| 4 | Major | Significant customer data, availability, or contractual impact |
| 5 | Critical | Severe or widespread impact to customers, trust, legal obligations, or service viability |
Impact assessment SHOULD consider data classification, multi-tenant exposure, regulated personal information, and contractual commitments.
6. Risk Score Calculation and Ratings
Risk Score = Likelihood × Impact
Inherent Score and Residual Score are each calculated using this formula.
| Score range | Rating |
|---|---|
| 1–5 | Low |
| 6–10 | Medium |
| 11–15 | High |
| 16–25 | Critical |
7. Register Fields
The authoritative risk register MUST include at least:
| Field | Required |
|---|---|
| Risk ID | Yes |
| Risk title | Yes |
| Risk description | Yes |
| Risk category | Yes |
| Affected asset, service, or process | Yes |
| Threat | Yes |
| Vulnerability or exposure | Yes |
| Existing controls | Yes |
| Inherent likelihood | Yes |
| Inherent impact | Yes |
| Inherent score | Yes |
| Treatment decision | Yes |
| Planned mitigation | When Mitigate/Transfer/Avoid |
| Risk owner | Yes |
| Treatment owner | When actions open |
| Target date | When actions open |
| Status | Yes |
| Residual likelihood | Yes |
| Residual impact | Yes |
| Residual score | Yes |
| Last review date | Yes |
| Next review date | Yes |
| Evidence or related document | Yes (or Planned / Pending Implementation) |
| Comments | Recommended (including pilot/go-live/roadmap timing) |
The populated register is an internal confidential artifact.
8. Treatment Decisions
| Decision | When to use |
|---|---|
| Mitigate | Controls or remediation can reduce residual risk to an acceptable level |
| Accept | Residual risk is within appetite for a defined period; further mitigation not currently practical |
| Transfer | Contractual allocation, insurance, or third-party responsibility appropriately addresses the risk |
| Avoid | The activity can be discontinued or not pursued |
9. Treatment Planning Requirements
For High and Critical risks, Aventora MUST maintain a documented treatment plan including:
- Risk ID and mitigation action;
- Required control;
- Owner and priority;
- Dependencies;
- Target date and status;
- Evidence required; and
- Residual-risk reassessment upon completion.
Treatment plans MAY be individual records or tracked as linked actions in the register and remediation tracker, provided the required fields are complete.
10. Risk Acceptance Requirements
Risk acceptance MUST:
- Be documented in a Risk Acceptance Record;
- Be time-limited;
- Be reconsidered at the next scheduled review or sooner after a significant change;
- Include business justification, existing controls, compensating controls, residual rating, and expiration/reassessment date; and
- For High or Critical residual risk, receive formal documented Management approval.
11. Review Cadence and Triggers
| Review type | Requirement |
|---|---|
| Quarterly | Full or prioritized register review at least once per quarter |
| Significant change | Review upon triggers listed in the parent policy |
| Initial formal review | Documented when the program is first established |
Each review MUST produce a Risk Review Record.
12. Milestone Categories for Target Dates
Target dates SHOULD be categorized as:
| Category | Use |
|---|---|
| Before Gallagher pilot environment activation | Controls required before pilot environment processing of Gallagher data |
| Before production go-live | Controls required before production customer go-live |
| Within 30 days after pilot start | Near-term hardening after pilot begins |
| Within 60–90 days (security maturity roadmap) | Planned maturity improvements not blocking pilot activation |
| Ongoing quarterly or annual activity | Recurring control activities (reviews, training, monitoring refresh) |
Planned Gallagher pilot controls MUST NOT be represented as already operational until implemented and verified.
13. Templates
Blank templates below are for governance use. Completed records with scores, vulnerability detail, and remediation status are stored internally and marked:
Internal — Confidential — Not for Public Distribution
13.1 Risk Review Record Template
| Field | Value |
|---|---|
| Review date | |
| Review type | Quarterly / Event-driven / Initial formal |
| Review trigger | Scheduled / describe trigger |
| Participants | Roles/names |
| Risks reviewed | List or attach register extract |
| New risks identified | |
| Risks closed | |
| Risks increased | |
| Risks decreased | |
| Accepted risks | |
| Overdue actions | |
| Control changes | |
| Incidents or findings considered | |
| Decisions made | |
| Action items | |
| Owners | |
| Target dates | |
| Approval | Role, name, signature, date |
13.2 Risk Acceptance Record Template
| Field | Value |
|---|---|
| Risk ID | |
| Risk description | |
| Business justification | |
| Existing controls | |
| Residual risk rating | Score and Low/Medium/High/Critical |
| Reason further mitigation is not currently practical | |
| Compensating controls | |
| Acceptance period | |
| Expiration or reassessment date | |
| Risk owner | |
| Approver | |
| Approval date |
Statement: Risk acceptance is time-limited and must be reconsidered during the next scheduled review or sooner following a significant change.
13.3 Risk Treatment Plan Template
| Field | Value |
|---|---|
| Risk ID | |
| Mitigation action | |
| Required control | |
| Owner | |
| Priority | Critical / High / Medium / Low |
| Dependencies | |
| Target date | |
| Status | Open / In progress / Complete / Deferred |
| Evidence required | |
| Completion date | |
| Residual-risk reassessment | Date and updated residual score |
14. Related Documents
- Information Security Risk Management Policy
- Customer Security Package
- Vendor Management Policy
- AI Governance Policy
- Vulnerability Management
- Incident Response
- Secure Development Lifecycle (SDLC) Policy
- Application Change Management Policy
15. Version History
| Version | Date | Author / Owner | Summary of Changes |
|---|---|---|---|
| 1.0.1 | August 1, 2026 | Information Security Officer | Management approval recorded; status updated from Draft to Approved by Management |
| 1.0 | July 27, 2026 | Information Security Officer | Initial Risk Assessment and Treatment Procedure with 5×5 methodology and blank templates |
Contact
Document Owner: Information Security Officer — security@aventora.ai