Aventora Information Security Risk Management Policy
| Field | Value |
|---|---|
| Document Name | Information Security Risk Management Policy |
| 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 risk posture, legal/regulatory requirements, or operating model |
| Classification | Internal / Customer Shareable |
| Approval Status | Approved by Management — see Version History |
Document Control
This policy establishes Aventora Inc. (“Aventora,” “we,” “us,” or “our”) requirements for identifying, assessing, tracking, treating, accepting, monitoring, reporting, and periodically reviewing information security risks.
Aventora maintains a documented process for identifying, assessing, tracking, treating, accepting, and periodically reviewing information security, privacy, operational resilience, third-party, cloud, application, and AI-related risks.
This document is intended for enterprise customers, security assessors, privacy officers, procurement teams, and Aventora personnel. It supports security and privacy reviews and vendor risk questionnaires. Aventora does not claim formal certification or attestation under any specific security or privacy framework based on this document alone. Binding obligations of a customer relationship are those set out in the executed services agreement, data processing terms, and applicable law.
This policy is proportionate to Aventora’s current size and operating model. It does not assert that certifications, independent audits, penetration tests, centralized SIEM, or other maturity controls are fully implemented unless separately evidenced.
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 |
|---|---|---|---|
| Chief Executive Officer / Management | Management | Approved | August 1, 2026 |
| Document Owner (Information Security Officer) | Information Security Officer | Approved | August 1, 2026 |
| Engineering Lead | Engineering Lead | Approved | August 1, 2026 |
This policy is effective upon the Effective Date stated above and was approved by Management on the Approval Date. Material revisions require re-approval and an updated version history entry.
Table of Contents
- Purpose
- Scope
- Policy Objectives
- Roles and Responsibilities
- Risk Identification
- Risk Assessment
- Risk Scoring
- Risk Treatment
- Risk Ownership
- Residual Risk
- Risk Acceptance
- Risk Monitoring
- Risk Reporting
- Quarterly Review Requirements
- Significant-Change Review Triggers
- Record Retention
- Policy Exceptions
- Policy Review and Approval
- Related Documents
- Version History
1. Purpose
This policy:
- Establishes Aventora’s Information Security Risk Management Program;
- Defines how information security and related risks are identified, assessed, scored, treated, accepted, monitored, and reported;
- Assigns ownership and accountability for risks and treatment actions; and
- Sets minimum review cadence and event-driven reassessment requirements.
Detailed scoring methodology, treatment workflow, and record templates are defined in the Risk Assessment and Treatment Procedure.
2. Scope
This policy applies to information security and related risks affecting:
| In scope | Description |
|---|---|
| Engagement Hub | Aventora Engagement Hub / Aventora-Assistant platform services |
| Aventora Admin | Administrative web application used to configure and operate Hub tenants |
| Domain Assistant | Domain chatbot / Domain Assistant (domain-chatbot) services |
| Supporting operations | Production and pre-production environments, cloud infrastructure, CI/CD, logging, backups, and operational processes supporting the systems above |
| Risk categories | Information security, privacy, operational resilience, third-party/subprocessor, cloud, application, and AI-related risks |
This policy does not independently govern products outside the systems listed above unless Management extends the program in writing. Customer-specific contractual security schedules may impose additional requirements for a given deployment.
Personnel covered include employees, contractors, and service providers who design, operate, secure, or make decisions affecting the in-scope systems.
3. Policy Objectives
Aventora’s risk management objectives are to:
- Identify threats and vulnerabilities that could affect confidentiality, integrity, availability, privacy, or contractual compliance;
- Assess inherent and residual risk using a consistent methodology;
- Prioritize treatment of High and Critical risks;
- Document risk ownership, treatment decisions, and acceptance where applicable;
- Maintain an authoritative risk register for in-scope systems;
- Review the risk register at least quarterly and upon defined significant-change triggers; and
- Provide Management with visibility into material risks and overdue treatment actions.
4. Roles and Responsibilities
| Role | Responsibility |
|---|---|
| Management | Approves this policy; reviews High and Critical residual risks; approves formal risk acceptances for High/Critical residual risk; allocates resources for treatment |
| Information Security Officer | Owns this policy and the risk management program; maintains the risk register; coordinates assessments and quarterly reviews; reports status to Management |
| Privacy Officer | Identifies and assesses privacy and data-subject-rights risks; advises on privacy treatment and acceptance |
| Engineering Lead | Ensures technical risks are identified; assigns System Owners and Control Owners; drives remediation in product and infrastructure |
| System Owner | Owns risks affecting a specific service or asset; ensures treatment progress and accurate register updates |
| Control Owner | Operates or maintains a control that reduces risk; provides evidence of control effectiveness when requested |
| Treatment Owner | Executes assigned mitigation actions by the target date; updates status and evidence references |
| All personnel | Report newly identified risks, control failures, and significant changes through established channels (including security@aventora.ai) |
Where a named individual has not been designated for a role, the function listed above MUST fulfill the responsibility.
5. Risk Identification
Risks MUST be identified from sources including, as applicable:
- Architecture and data-flow reviews;
- Access control and privileged-access reviews;
- Vulnerability, dependency, and secure-development findings;
- Security incidents and near misses;
- Audit, assessment, and penetration-test findings (when performed);
- Vendor / subprocessor due diligence;
- Privacy and retention reviews;
- AI feature and provider reviews;
- Legal, regulatory, and contractual change analysis; and
- Significant operational or infrastructure changes.
Newly identified risks MUST be recorded in the risk register with sufficient description to support assessment and treatment.
6. Risk Assessment
Each recorded risk MUST be assessed to determine:
- Affected asset, service, or process;
- Threat and vulnerability or exposure;
- Existing controls;
- Inherent likelihood and impact;
- Treatment decision and planned mitigation (if any);
- Residual likelihood and impact after existing and planned controls; and
- Owners, dates, and review schedule.
Assessments MUST follow the Risk Assessment and Treatment Procedure.
7. Risk Scoring
Aventora uses a 5 × 5 Likelihood × Impact model. Risk Score = Likelihood × Impact.
| Score range | Rating |
|---|---|
| 1–5 | Low |
| 6–10 | Medium |
| 11–15 | High |
| 16–25 | Critical |
Inherent and residual scores MUST be recorded. Scoring definitions and field requirements are specified in the Risk Assessment and Treatment Procedure.
8. Risk Treatment
Available treatment decisions are:
| Decision | Meaning |
|---|---|
| Mitigate | Reduce likelihood and/or impact through controls or remediation |
| Accept | Formally accept residual risk within defined conditions and time limits |
| Transfer | Shift risk through contract, insurance, or third-party arrangement where appropriate |
| Avoid | Discontinue or do not pursue the activity that creates the risk |
High and Critical risks MUST have documented treatment plans, owners, target dates, and Management review. Treatment plans SHOULD use the Risk Treatment Plan template maintained with the program records.
9. Risk Ownership
Every risk in the register MUST have:
- A Risk Owner accountable for the risk decision and residual risk posture;
- A Treatment Owner when mitigation or transfer actions are open; and
- A Control Owner for material existing controls where practical.
Ownership is assigned by role (for example, Information Security Officer, Engineering Lead, System Owner). Named individuals may be recorded in internal operational records.
10. Residual Risk
Residual risk is the risk remaining after considering existing controls and, where applicable, the expected effect of approved treatment in progress. Residual scores MUST be updated when material control changes occur or when treatment is completed.
11. Risk Acceptance
Risk acceptance MUST be documented when Aventora elects to accept residual risk rather than fully mitigate, transfer, or avoid it.
- Acceptance is time-limited and MUST be reconsidered at the next scheduled review or sooner following a significant change.
- Accepted High or Critical residual risks MUST have formal documented approval by Management (or designated approver) using the Risk Acceptance Record.
- Acceptance records MUST include business justification, existing and compensating controls, residual rating, acceptance period, and reassessment date.
12. Risk Monitoring
The Information Security Officer MUST monitor:
- Open High and Critical risks and overdue treatment actions;
- Changes in control effectiveness indicated by incidents, findings, or operational metrics;
- Vendor/subprocessor and AI-provider risk signals; and
- Progress against target treatment dates tied to pilot, go-live, and roadmap milestones.
13. Risk Reporting
At least quarterly, and after event-driven reviews when material, the Information Security Officer SHOULD report to Management:
- Count and trend of High and Critical risks;
- Newly identified, closed, increased, and decreased risks;
- Overdue treatment actions;
- Accepted risks approaching expiration; and
- Recommendations requiring Management decision or resources.
Customer-facing communications MUST NOT disclose internal risk-register scores, vulnerability detail, or remediation status except as approved for a specific engagement.
14. Quarterly Review Requirements
The risk register MUST be reviewed at least quarterly.
Each quarterly review MUST produce a Risk Review Record documenting participants, risks reviewed, decisions, and action items. Reviews may be combined with related security governance meetings provided the required record is completed.
15. Significant-Change Review Triggers
In addition to the quarterly cadence, the risk register MUST be reviewed:
- Following significant architectural or infrastructure changes;
- Before onboarding material new subprocessors or technology providers;
- Before launching services that materially change data processing;
- Following security incidents;
- Following significant vulnerability, audit, penetration-test, or compliance findings; and
- Following material legal or regulatory changes.
Event-driven reviews MUST use the Risk Review Record and identify the trigger.
16. Record Retention
Aventora MUST retain risk management records for at least three (3) years, or longer if required by contract or law, including:
- Approved versions of this policy and the Risk Assessment and Treatment Procedure;
- Current and prior risk register versions (or equivalent change history);
- Risk review records;
- Risk treatment plans; and
- Risk acceptance records.
Sensitive operational risk records are stored in internal / restricted documentation locations and are not published on the public documentation site.
17. Policy Exceptions
Exceptions to this policy MAY be granted only where:
- A legitimate business or technical requirement exists;
- Compensating controls are documented;
- The exception is approved by the Information Security Officer and, for High/Critical residual risk, Management;
- The exception is time-bound and reviewed at least at the next quarterly risk review; and
- Material customer-facing impacts are disclosed or agreed where required by contract.
Exception records MUST include the requirement waived, justification, approver, effective dates, and remediation plan if applicable.
18. Policy Review and Approval
This policy MUST be reviewed at least annually by the Information Security Officer and submitted to Management for re-approval when material changes are made.
Operational risk-register reviews occur at least quarterly as specified in Section 14.
19. Related Documents
| Document | Relationship |
|---|---|
| Risk Assessment and Treatment Procedure | Scoring methodology, treatment workflow, and blank record templates |
| Customer Security Package | Index of customer-shareable security documentation |
| Security Overview | Platform security commitments summary |
| Personal Data Privacy & Protection Policy | Privacy risk and personal data protection requirements |
| Data Classification and Handling Policy | Classification and handling requirements informing impact assessment |
| Vendor Management Policy | Third-party and subprocessor risk controls |
| AI Governance Policy | AI-related risk management expectations |
| Incident Response | Incident-driven risk reassessment inputs |
| Business Continuity | Resilience and recovery risk context |
| Vulnerability Management | Vulnerability findings as risk inputs |
| Secure Development Lifecycle (SDLC) Policy | Application and change-related risk controls |
| Application Change Management Policy | Change risk and approval practices |
| Authentication and Access Control | Access-related control context |
| API Security Policy | API authentication and integration security |
Internal operational artifacts (risk register, scored reviews, treatment status, and evidence index) are maintained in restricted internal documentation and are not part of the public Customer Security Package.
20. 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 Information Security Risk Management Policy establishing the formal program for Engagement Hub, Aventora Admin, and Domain Assistant |
Contact
| Purpose | Contact |
|---|---|
| Document Owner | Information Security Officer — security@aventora.ai |
| Privacy inquiries | privacy@aventora.ai |
| Security questionnaires | security@aventora.ai or sales@aventora.ai |
This document is provided for informational and contractual support purposes. It does not constitute legal advice. Binding customer commitments are those in the executed agreement and DPA.